RuoYi Office 文档

Appearance

绩效管理整体设计方案 ​

文档说明 ​

  • 更新日期：2026-05-04
  • 适用范围：ruoyi-office 人力资源模块绩效管理整体方案重构
  • 文档用途：统一绩效一期的产品模型、流程设计、数据边界、页面拆分和实施路线，作为后续后端、前端、BPM 和联调验收的总纲

本版方案将绩效闭环收敛为“绩效计划 + 考核评价单”双核心模型，并以流程节点驱动自评、评审、校准、结果确认和申诉处理，解决原先功能入口分散、角色边界混杂、页面权限难配置的问题。

一、整体定位 ​

1.1 产品定位 ​

绩效管理不是独立的战略绩效平台，而是企业一体化 HRM 中的绩效执行子域。一期不追求复杂战略工具，而是优先把用户最常用、最容易理解的一条主链跑通：

  1. HR 配置方案、模板、周期。
  2. 员工和上级确认目标。
  3. 系统自动生成考核评价单并启动流程。
  4. 员工完成自评。
  5. 上级完成评审。
  6. HR 完成校准。
  7. 被考核人完成结果确认，必要时发起申诉。
  8. 结果归档，并为后续薪酬联动预留标准口径。

1.2 设计原则 ​

  1. 简化优先：围绕一张评价单串完整流程，不再把评分、确认、申诉拆成多个让用户难理解的业务入口。
  2. 角色清晰：员工只做自评和结果确认，上级只做评审，HR 只做校准，申诉按单据节点继续流转。
  3. 流程驱动：节点权限、待办生成、按钮显示统一由 BPM 节点控制，不再主要依赖页面里的状态判断。
  4. 单据统一：前端多个功能页本质上都是同一张评价单的不同视图，不生成额外业务单据。
  5. 留痕优先：原评分、校准结果、确认结果、申诉内容、申诉后结果都要保留。
  6. 复用现有：尽量复用现有 PerformancePlan、PerformancePlanItem、PerformanceReview、PerformanceCalibration、PerformanceResult 和 BPM 任务列表能力。

二、建设范围 ​

2.1 一期范围 ​

一期围绕“目标确认后自动生成评价单”的主链建设，包含：

  • 绩效方案管理
  • 指标库与模板管理
  • 绩效等级规则管理
  • 绩效周期发布
  • 员工绩效计划生成与目标确认
  • 基于目标确认自动生成考核评价单
  • 自评填报
  • 评审填报
  • 校准填报
  • 结果确认
  • 申诉管理
  • 证据沉淀与 OA 工作汇报同步
  • 绩效结果归档
  • 薪酬联动预留

2.2 二期增强 ​

二期再扩展以下能力：

  • 复杂协同评价与匿名 360
  • 试用期绩效、专项绩效、项目绩效
  • 强制分布和组织效能分析
  • 绩效改进计划与培训联动
  • 调薪建议自动联动
  • 移动端全链路闭环

2.3 一期明确不做 ​

  • 独立战略绩效平台
  • 大而全人才盘点
  • 复杂匿名评价
  • 多组织复杂分布算法
  • AI 自动写评语

三、业务总体蓝图 ​

3.1 核心闭环说明 ​

  1. HR 维护绩效方案、模板、指标和等级规则。
  2. 创建绩效周期后，系统按组织范围生成员工绩效计划。
  3. 员工与上级完成目标确认。
  4. 目标确认成功后，系统自动生成一张 考核评价单 PerformanceAssessmentBill。
  5. 系统为该评价单启动主流程，并把待办推送给被考核人执行自评。
  6. 自评完成后自动进入评审节点，由审批人完成评分。
  7. 评审完成后进入校准节点，由 HR 或指定校准人完成校准。
  8. 校准完成后进入结果确认节点，由被考核人确认结果。
  9. 若被考核人认可结果，则流程结束并归档；若不认可，则从同一张评价单发起申诉流程。
  10. 申诉流程完成后，评价单输出申诉后最终结果，并统一归档。

3.2 为什么采用这套模型 ​

  1. 用户只需要理解“计划先确认，后续都处理评价单”，心智负担最小。
  2. 自评、评审、校准、结果确认天然就是流程节点，适合 BPM 待办模型。
  3. 同一张单据按节点拆分视图，便于按用户、角色、权限进行菜单配置。
  4. 申诉不是独立业务域，而是评价单的扩展分支，便于留痕和追溯。

四、核心业务模型 ​

4.1 双核心模型 ​

一期统一为两个核心主档：

  1. PerformancePlan

    • 负责考核基础口径。
    • 包含周期、员工、直属上级、模板、目标确认状态等信息。
    • 是“计划生成”和“目标确认”的业务主体。

  2. PerformanceAssessmentBill

    • 负责评分与确认流程执行。
    • 在计划确认目标后自动生成。
    • 是“自评、评审、校准、结果确认、申诉”的流程主体。

4.2 关键对象职责 ​

4.2.1 绩效方案 PerformanceScheme ​

  • 定义周期类型、评分规则、等级规则和节点审批策略。
  • 决定评审人、校准人、申诉审核人等分配方式。

4.2.2 指标库 PerformanceIndicator ​

  • 维护标准指标、评分口径、数据来源、默认权重。
  • 供模板和计划项复用。

4.2.3 绩效模板 PerformanceTemplate ​

  • 按岗位序列、组织、职级维护标准考核模板。
  • 组合指标项、证据要求、评分规则。

4.2.4 绩效周期 PerformancePeriod ​

  • 承载一个考核周期的业务范围和时间边界。
  • 负责生成计划和控制目标确认窗口。

4.2.5 员工绩效计划 PerformancePlan ​

  • 记录员工在周期内的正式绩效计划。
  • 保存目标确认口径和计划快照。
  • 每个计划只对应一张评价单。

4.2.6 绩效计划项 PerformancePlanItem ​

  • 存储指标项、目标值、实际值、权重、数据来源。
  • 是评分表格中的最小业务单元。

4.2.7 考核评价单 PerformanceAssessmentBill ​

  • 作为主流程和申诉流程的统一单据。
  • 保存当前节点、当前处理人、流程实例、结果快照、申诉状态。
  • 是前端五个任务视图的共同数据源。

4.2.8 绩效证据 PerformanceEvidence ​

  • 统一归集 OA 工作汇报、附件、关键事项、补充说明。
  • 在自评、评审、校准、申诉校准阶段都作为事实依据。

4.2.9 绩效评审记录 PerformanceReview ​

  • 记录自评、评审、申诉审核等节点评分和意见。
  • 按 assessmentBillId + reviewType 存储节点留痕。

4.2.10 绩效校准记录 PerformanceCalibration ​

  • 记录主流程校准和申诉校准的调整内容。
  • 保存校准分、校准说明、调整原因。

4.2.11 绩效结果 PerformanceResult ​

  • 保存原结果、确认结果、申诉后结果的快照。
  • 是后续归档、统计、薪酬联动的数据出口。

五、流程设计 ​

5.1 主流程 ​

主流程围绕评价单执行，建议流程定义 Key 为 hr_performance_assessment_bill。

节点如下：

  1. self_review

    • 处理人：被考核人本人
    • 操作：提交自评、自评说明、补充证据

  2. leader_review

    • 处理人：直属上级，或方案配置的指定角色/指定人员
    • 操作：提交评审分、评语

  3. hr_calibration

    • 处理人：HRBP / HR 角色 / 指定用户
    • 操作：提交校准分、校准意见、结果建议

  4. result_confirm

    • 处理人：被考核人本人
    • 操作：确认结果，或发起申诉

5.2 申诉流程 ​

申诉仍绑定在同一张评价单上，建议流程定义 Key 为 hr_performance_assessment_appeal。

节点如下：

  1. appeal_start

    • 处理人：被考核人本人
    • 操作：填写申诉原因、申诉说明、附件

  2. appeal_audit

    • 处理人：直属上级 / 部门负责人 / HR 负责人
    • 操作：审核申诉是否进入复核

  3. appeal_calibration

    • 处理人：HR 或绩效委员会角色
    • 操作：重新校准，输出申诉后结果

  4. appeal_result_confirm

    • 处理人：被考核人本人
    • 操作：确认申诉后结果

5.3 流程运行原则 ​

  1. 一张评价单在同一时刻只能处于一个主节点或申诉节点。
  2. 主流程结束后，如发起申诉，再启动申诉流程实例，不新建新单据。
  3. 所有节点都需要记录处理人、处理时间、处理意见和结果快照。
  4. 若申诉未通过，保留原确认结果；若申诉校准后重新确认，则形成申诉后最终结果。

六、前端视图设计 ​

6.1 菜单收敛 ​

一期前端菜单建议收敛为：

  1. 绩效设置
  2. 绩效周期
  3. 绩效计划
  4. 自评填报
  5. 评审填报
  6. 校准填报
  7. 结果确认
  8. 申诉管理
  9. 绩效结果
  10. 绩效统计

6.2 五个任务视图 ​

五个功能页本质上都是同一张评价单的列表过滤：

  1. 自评填报

    • 待处理：currentNodeKey = self_review
    • 已处理：当前用户已完成自评

  2. 评审填报

    • 待处理：currentNodeKey = leader_review
    • 已处理：当前用户已完成评审

  3. 校准填报

    • 待处理：currentNodeKey = hr_calibration
    • 已处理：当前用户已完成校准

  4. 结果确认

    • 待处理：currentNodeKey = result_confirm
    • 已处理：当前用户已确认结果

  5. 申诉管理

    • 待处理：节点属于 appeal_start、appeal_audit、appeal_calibration、appeal_result_confirm
    • 已处理：当前用户参与过申诉流程

6.3 统一详情页 ​

详情页只保留一个统一组件，例如 绩效评价单详情，展示：

  • 基本信息：编号、周期、员工、部门、直属上级、当前节点、流程状态
  • 指标评分表：目标值、实际值、自评分、评审分、校准分、最终分、说明
  • 证据列表：OA 工作汇报、附件、人工补充说明
  • 历史轨迹：主流程处理记录、申诉流程处理记录

底部按钮按节点动态显示：

  • self_review：提交自评
  • leader_review：提交评审
  • hr_calibration：提交校准
  • result_confirm：确认结果、发起申诉
  • appeal_start：提交申诉
  • appeal_audit：提交申诉审核
  • appeal_calibration：提交申诉校准
  • appeal_result_confirm：确认申诉结果

七、状态设计 ​

7.1 绩效计划状态 ​

建议保留以下轻量状态：

  • 草稿
  • 待确认目标
  • 已确认目标
  • 已生成评价单
  • 已关闭

7.2 评价单状态 ​

建议围绕流程节点维护统一状态：

  • 待自评
  • 待评审
  • 待校准
  • 待结果确认
  • 已完成
  • 申诉中
  • 申诉待审核
  • 申诉待校准
  • 申诉待结果确认
  • 申诉完成

7.3 结果状态 ​

  • 原结果
  • 已确认结果
  • 申诉后结果
  • 已归档

八、数据模型建议 ​

8.1 建议核心表 ​

配置层：

  • hrm_performance_scheme
  • hrm_performance_indicator
  • hrm_performance_template
  • hrm_performance_template_item
  • hrm_performance_grade_rule

执行层：

  • hrm_performance_period
  • hrm_performance_plan
  • hrm_performance_plan_item
  • hrm_performance_assessment_bill
  • hrm_performance_evidence

留痕层：

  • hrm_performance_review
  • hrm_performance_calibration
  • hrm_performance_result

8.2 hrm_performance_assessment_bill 建议字段 ​

  • bill_code
  • plan_id
  • period_id
  • employee_id
  • employee_name
  • company_id
  • company_name
  • dept_id
  • dept_name
  • leader_user_id
  • leader_user_name
  • current_node_key
  • current_node_name
  • current_assignee_id
  • current_assignee_name
  • main_process_instance_id
  • main_process_status
  • appeal_process_instance_id
  • appeal_process_status
  • status
  • final_score
  • final_level
  • final_coefficient
  • result_confirm_status
  • appeal_status
  • remark

8.3 留痕表设计原则 ​

  1. PerformanceReview 记录自评、评审、申诉审核。
  2. PerformanceCalibration 记录主流程校准和申诉校准。
  3. PerformanceResult 记录原结果、确认结果、申诉后结果快照。
  4. 所有留痕表都建议增加 assessmentBillId 字段，避免后续再从计划维度拼装流程历史。

九、与现有模块打通 ​

9.1 OA 工作汇报 ​

  • 工作汇报继续作为绩效证据来源。
  • 在评价单详情中统一展示已同步的工作汇报摘要。
  • 工作汇报不直接替代评分，但可作为纪律类或执行类指标依据。

9.2 薪酬模块 ​

  • 一期先预留标准结果出口，不强耦合复杂计算。
  • 薪酬取数统一从 PerformanceResult 的最终结果快照读取。
  • 若有申诉，以申诉后最终确认结果为准。

9.3 BPM 模块 ​

  • 复用 BPM todo/done/detail 通用页面能力。
  • 评价单详情走业务表单方式挂接到 BPM 详情壳。
  • 节点字段权限跟随 nodeKey 动态变化。

十、实施路线 ​

Phase 1 文档与模型统一 ​

  • 统一整体方案、MVP 和 BPM 文档口径。
  • 明确双核心模型、主流程、申诉流程、五个任务视图。

Phase 2 后端底座 ​

  • 新增 hrm_performance_assessment_bill 表和 DO/Mapper/Service。
  • 改造目标确认逻辑，自动生成评价单。
  • 打通主流程和申诉流程实例绑定。
  • 让 review/calibration/result 围绕 assessmentBillId 留痕。

Phase 3 Web 页面 ​

  • 保留 绩效计划 页作为计划追踪入口。
  • 新增五个任务页。
  • 抽统一评价单详情组件。
  • 以 nodeKey 驱动字段权限和按钮显示。

Phase 4 联调与验收 ​

  • 联调主流程：确认目标 -> 生成评价单 -> 自评 -> 评审 -> 校准 -> 结果确认。
  • 联调申诉流程：发起申诉 -> 审核 -> 校准 -> 申诉结果确认。
  • 验证轨迹、留痕、归档和统计。

十一、一期验收标准 ​

  1. 计划确认目标后，系统自动生成一张评价单并挂接流程。
  2. 自评、评审、校准、结果确认都基于同一张评价单执行。
  3. 前端有 自评填报、评审填报、校准填报、结果确认、申诉管理 五个入口。
  4. 每个入口都能分为 待处理 和 已处理 两个页签。
  5. 页面权限按流程节点动态控制，非当前节点只能只读。
  6. 被考核人在结果确认节点既可确认，也可发起申诉。
  7. 申诉链路结束后，系统能保留原结果和申诉后结果两套快照。
  8. 绩效结果可用于后续归档、统计和薪酬取数。

十二、结论 ​

绩效一期的关键，不是继续把功能拆成更多业务域和页面，而是把用户路径做顺：

  1. 先有绩效计划。
  2. 确认目标后自动生成评价单。
  3. 所有评分、确认、申诉都围绕这张评价单流转。
  4. 不同菜单只是同一张单据在不同节点下的任务视图。

这套方案既符合用户理解，也更利于后续权限配置、流程扩展和开发落地。

联系我们

获取报价、演示和二开方案

微信咨询二维码

微信咨询

17156169080

添加时备注「RuoYi Office」

在线体验商业版