RuoYi Office 文档

Appearance

SpringBoot+Vue3 绩效驾驶舱设计：8项KPI、4类风险，把平均分升级为完成率与堵点名单 ​

🌐 演示地址：https://ruoyioffice.com | 📦 源码1·GitHub：ruoyi-office | 📦 源码2·GitCode：ruoyi-office | 📦 源码3·Gitee：ruoyi-office | 💬 微信：17156169080（备注「RuoYi Office」）

管理者真正关心的并不是“这批人的平均分是多少”，而是“考核完成了多少、卡在哪个阶段、哪些部门落后、哪些人需要马上处理”。RuoYi Office 的绩效驾驶舱用 3 级筛选、8 项 KPI、4 类统计视图、4 类风险名单和 3 种业务下钻，把静态结果汇总做成可行动的过程管理入口。

绩效驾驶舱与风险预警 - 功能架构全景

▲ 绩效驾驶舱全景：公司/部门/批次筛选统一限定统计口径，8 项 KPI 给出管理摘要，阶段漏斗与 3 类分布图定位堵点，4 类风险名单通过 bizId/bizType 下钻到计划、评价单或结果详情。

引言：为什么“平均分 82.6”不能指导管理动作？ ​

平均分是结果指标，但它不能回答过程问题。 一家有多个公司、十几个部门的企业进入季度考核后，管理者通常会遇到四种追问：

  • 完成率到底多少：100 人参评，完成 80 人和完成 30 人，即使平均分相同，管理风险完全不同。
  • 流程卡在哪里：目标确认、自评、上级评审、HR 校准、结果确认，任何阶段都可能形成积压。
  • 风险具体是谁：看到“逾期 12 项”还不够，必须能定位员工、部门、批次、环节和业务单据。
  • 低分是否具有连续性：单期低分可能是波动，连续多期低于阈值才更值得管理者关注。

传统统计页往往只展示批次数、参与人数、平均分和金额合计。 这些数字适合汇报，却不适合催办和干预。

管理问题只看平均分的盲区驾驶舱给出的答案
本轮考核是否按计划推进看不到已完成/总数完成率 + 考核单总数/完成数
哪个环节最堵看不到状态分布7 阶段漏斗
哪个部门落后缺少横向比较部门完成率排序
哪些批次异常不同批次混在一起批次完成率对比
谁需要立即处理汇总数字无法定位人员4 类风险名单
点击后去哪处理统计页与业务页割裂bizType + bizId 下钻

下面所有能力边界均以当前产品实现为准。 本文不会把规则统计包装成预测模型，也不会虚构自动发消息或人才九宫格。 ​

一、业务升级：从“结果报表”到“行动驾驶舱” ​

1.1 驾驶舱不是大屏，而是管理动作入口 ​

绩效驾驶舱是一个面向管理者的聚合视图，用于把考核过程、完成质量和风险对象放进同一统计口径。 它的价值不在于图表多，而在于每个数字都能回答一个管理问题。 本次设计形成一条清晰链路：

text
公司 / 部门 / 批次
        ↓
8 项 KPI 摘要
        ↓
阶段漏斗 + 部门完成率 + 等级分布 + 批次完成率
        ↓
逾期 / 未填报 / 连续低分 / 申诉积压
        ↓
计划详情 / 评价单详情 / 结果详情

筛选决定“看哪一块组织、哪几批考核”。 KPI 决定“问题是否严重”。 图表决定“问题集中在哪里”。 风险名单决定“下一步处理谁”。 业务下钻决定“管理动作在哪里完成”。

1.2 三层信息密度 ​

驾驶舱把信息分成摘要、诊断、行动三层。

层级页面内容管理用途是否可直接行动
摘要层8 项 KPI快速判断总体进度与风险规模间接
诊断层漏斗、部门/等级/批次图表定位堵点与结构异常间接
行动层4 类风险名单找到具体员工和业务环节是

这种层次避免了把几十个指标平铺在同一屏。 管理者先看摘要，再看分布，最后进入名单。

1.3 风险预警是规则识别，不是黑盒预测 ​

当前实现采用确定性业务规则。 每一条风险都有可解释的触发条件和来源数据。

风险类型接口字段触发逻辑主要来源
逾期未办overdue当前日期晚于对应截止日且环节未完成计划、评价单、批次日期
未填报unfilled目标待确认，或评价单仍待自评计划、评价单
连续低分consecutiveLowScore最近连续 N 期得分均低于阈值绩效结果
申诉积压appeals评价单处于申诉处理中状态评价单

规则可复核，是这套设计的重要边界。 它没有预测某人未来会离职，也没有自动给员工贴人才标签。 ​

二、统计口径：先把“看谁、看哪批”说清楚 ​

2.1 公司、部门、批次三级筛选 ​

驾驶舱支持按公司、部门和多个考核批次筛选。 前端公司变化时会重新加载该公司下的部门树，并清理不再有效的部门值。 后端则在计划、评价单、结果三类查询中同步应用 companyId 与 deptId。 这意味着 KPI、图表和风险名单使用同一组织口径，不会出现“卡片看全公司、名单只看某部门”的错位。 批次筛选支持多选。 前端把 periodIds 转为逗号分隔的 periodIdStr 传给 GET 接口。 后端同时兼容列表参数和逗号字符串，并用 LinkedHashSet 去重。

2.2 未选批次时的默认范围 ​

用户未选择考核批次时，后端不是查询全部历史数据。 默认范围是：

  1. 状态在 1 到 4 的进行中批次；
  2. 再补充最近 3 个状态大于等于 5 的已出结果批次。

这个默认值兼顾当前过程和近期趋势。 它也避免全历史扫描造成页面信息过载。 批次下拉选项最多返回 30 条状态有效的记录。

2.3 低分阈值与连续期数 ​

请求对象暴露两个风险参数：

  • lowScoreThreshold：连续低分阈值，默认 70；
  • consecutivePeriodCount：连续期数，默认 3，若传入小于 2 的值也回退为 3。

当前前端开放了低分阈值输入框。 连续期数在页面请求中固定传 3。 因此当前用户可直接调整“多少分算低分”，而“连续多少期”暂按 3 期执行。

参数后端默认值当前前端行为作用
公司空下拉可清空限定组织
部门空随公司联动限定部门
批次进行中 + 近 3 个已出结果多选限定时间范围
低分阈值70可输入 0~100连续低分判断
连续期数3固定传 3最近连续期判断

三、8 项 KPI：不只看分数，更看进度和风险 ​

3.1 8 项指标的真实含义 ​

响应对象 Kpis 定义了 8 个字段。 其中页面用 6 张卡片展示，完成率卡片同时显示“完成数/总数”，因此 8 个统计量都进入了管理视野。

KPI字段计算口径管理意义
活动批次数activePeriodCount状态 1~4 的批次数当前并行推进规模
完成率completionRate完成单数 / 考核单总数 × 100%总体进度
逾期数overdueCount逾期风险项数量紧急待办规模
风险人数riskPeopleCount逾期、连续低分、申诉人员去重需要关注的人数
平均分averageScore有分结果的算术平均值结果水平参考
申诉数appealCount申诉处理中评价单数量异议积压程度
考核单总数billTotal筛选范围内评价单数完成率分母
考核单完成数billFinished状态 50 或 64 的评价单数完成率分子

这里有两个容易误读的细节。 第一，完成的判断包含正常完成状态 50 和申诉完成状态 64。 第二，风险人数不是四类风险的简单相加。 它只对逾期、连续低分和申诉人员做去重；仅“未填报但未逾期”的人员不会计入风险人数。

3.2 完成率为什么比参与人数更重要 ​

参与人数只能说明覆盖规模。 完成率能够说明过程质量。 例如两个部门都有 50 人参评：

  • A 部门完成 45 人，完成率 90%；
  • B 部门完成 20 人，完成率 40%。

若只看参与人数，两者完全相同。 驾驶舱按评价单终态计算完成率，能直接暴露推进差异。 完成率保留 1 位小数，采用 HALF_UP。

3.3 平均分保留，但不让它垄断决策 ​

平均分仍然有价值。 它来自筛选范围内 score 非空的绩效结果，保留 2 位小数。 但平均分只是 8 项指标之一。 页面同时把完成率、逾期、风险人数和申诉放在同一行，迫使管理视角从“分高不高”扩展到“过程顺不顺”。

绩效驾驶舱首屏 - 筛选区、KPI 与风险预警名单

▲ 绩效驾驶舱首屏：顶部按公司、部门、批次和低分阈值统一筛选；KPI 区突出进行中批次、完成率、逾期待办、风险人数、平均得分和申诉中，风险预警区直接列出当前需处理人员。 ​

四、4 类分析视图：从总量定位结构性堵点 ​

4.1 阶段漏斗：7 个节点看考核停在哪里 ​

阶段漏斗不是传统营销漏斗，而是绩效流程状态计数。 后端按计划和评价单状态组装 7 个节点：

text
目标待确认
目标已确认
待自评
待评审
待校准
待结果确认
已完成

“目标待确认”和“目标已确认”来自绩效计划。 其余节点来自评价单。 前端目前用柱状图展示，横轴是阶段，纵轴是人数。 这样能快速判断积压主要发生在员工、主管、HR 还是结果确认环节。

4.2 部门完成率：按低完成率优先暴露 ​

部门完成率以评价单为基础。 后端按 deptId + deptName 分组，分别统计总数、完成数与完成率。 没有部门的数据统一归入“未分配部门”。 后端列表按完成率升序排列。 前端反转后绘制横向条形图，以适配图表阅读方向。 工具提示同时展示百分比和 完成数/总数，避免小样本部门仅凭百分比产生误判。

4.3 等级分布：看结果结构，不做人才九宫格 ​

等级分布来源于绩效结果的 level 字段。 未定级结果统一归入“未定级”。 前端以环形饼图展示等级名称、人数和占比。 它用于观察 S/A/B/C/D 等级结构。 当前实现没有绩效—潜力双轴，也没有人才九宫格。

4.4 批次完成率：比较不同考核周期的推进质量 ​

批次完成率按每个筛选批次统计评价单总数、完成数和完成率。 前端以纵向柱状图对比。 该视图适合回答：

  • 当前季度是否比上季度推进更慢；
  • 某个月度批次是否长期未收尾；
  • 多个并行批次中哪个最需要催办。

四类分析视图各自解决不同问题。

视图数据维度最适合回答的问题
阶段漏斗流程节点卡在哪一步
部门完成率组织部门哪个部门落后
等级分布绩效等级结果结构如何
批次完成率考核批次哪一批推进异常

五、4 类风险名单：规则、边界与下钻对象 ​

5.1 逾期未办：截止日之后仍停在当前环节 ​

逾期判断统一使用 today.isAfter(deadline)。 也就是说，到期日当天不算逾期，从下一天开始进入风险。 不同阶段对应不同日期：

当前阶段对比日期风险备注示例
目标待确认批次开始日已超过批次开始日
待自评自评截止日已超过自评截止日
待上级评评审截止日已超过评审截止日
待校准校准截止日已超过校准截止日

目标待确认的计划既会进入未填报名单，也可能在超过批次开始日后进入逾期名单。 待自评评价单同样可能同时属于未填报和逾期。 这是不同管理视角下的合理交集，不是重复数据错误。

5.2 未填报：范围比“所有未完成”更窄 ​

当前 unfilled 只收集两类对象：

  1. 状态为 1、仍待目标确认的绩效计划；
  2. 状态为 10、仍待员工自评的评价单。

待上级评审、待校准和待结果确认不进入未填报。 这些阶段若超期，会进入逾期名单。 因此“未填报”更接近员工端尚未完成目标确认或自评，而不是所有流程待办的统称。

5.3 连续低分：只看最近连续 N 期 ​

连续低分按员工分组。 每名员工的结果按 periodId 倒序排列，截取最近 N 条。 只有最近 N 期的每一期得分都严格小于阈值，才生成风险。 若阈值是 70：

  • 69 / 68 / 65：命中；
  • 69 / 70 / 65：不命中，因为 70 不小于 70；
  • 69 / 68：不命中，因为不足 3 期；
  • 69 / 68 / 65 / 90：命中，因为只判断最近 3 期。

风险备注会记录最近各期得分与阈值。 风险行关联最近一期结果的 ID，便于下钻结果详情。 需要注意：当前“最近”按批次 ID 倒序近似判断，不是按开始日期重新排序。 在本项目批次按时间递增创建的约定下，这个规则保持简单且可解释。

5.4 申诉积压：状态 60~63 都算处理中 ​

申诉中的判断范围是评价单状态 60 到 63。 这覆盖待发起/处理中到待申诉结果确认，但不包含状态 64 的申诉完成。 风险行阶段名称优先使用评价单的当前节点名称。 若当前节点名称为空，则显示“申诉处理中”。 申诉数 KPI 与申诉风险名单使用同一个 isAppealOpen 判断。

5.5 每类最多返回 50 行 ​

后端通过 RISK_LIMIT = 50 限制每类风险列表。 这个限制控制了驾驶舱响应体和前端表格负载。 页面表格默认每页显示 8 行。 如果企业规模更大，后续可以把风险名单拆成独立分页接口。 当前实现适合“驾驶舱快速发现 + 点击处理”的定位。

绩效驾驶舱图表区 - 阶段、部门、等级和批次完成率

▲ 驾驶舱图表区：阶段漏斗、部门完成率、等级分布与批次完成率集中展示；底部保留风险名单入口，具体人员明细见上一张首屏截图。 ​

六、业务下钻：让风险名单真正可处理 ​

6.1 bizId + bizType 是统计与业务之间的桥 ​

风险行不仅返回展示字段，还携带 bizId 与 bizType。

bizId 表示业务对象主键。

bizType 表示业务对象类型。

bizType风险来源下钻页面
plan目标未确认计划计划详情
assessment_bill自评、评审、校准、申诉评价单评价单详情
result连续低分结果绩效结果详情

这个设计没有在后端拼接前端路由。 后端只描述业务语义，前端根据类型选择页面。 因此 API 可以保持跨端稳定，路由调整也只影响前端映射。

6.2 风险行包含的定位信息 ​

RiskItem 返回以下字段：

  • 员工 ID、工号、姓名；
  • 部门 ID、部门名称；
  • 批次 ID、批次名称；
  • 阶段编码、阶段名称；
  • 分数、等级、规则备注；
  • 业务 ID、业务类型。

这些字段足以让管理者在不下钻时理解风险，也能让页面准确打开对应对象。

6.3 批次工作台与驾驶舱的分工 ​

驾驶舱回答跨公司、跨部门、跨批次的全局问题。 批次工作台则更适合处理某一个批次内的具体阶段任务。 两者不是重复页面：

  • 驾驶舱强调横向比较与风险发现；
  • 批次工作台强调单批次推进与阶段操作；
  • 计划、评价单、结果详情负责最终业务处理。

绩效批次工作台 - 单批次阶段推进总览

▲ 绩效批次工作台：承接驾驶舱发现的问题，在单个考核批次内查看阶段进度与处理对象；驾驶舱负责发现，工作台和业务详情负责推进。 ​

七、后端实现：一个接口聚合三类业务数据 ​

7.1 聚合入口：统一选批次，再查计划、评价单和结果 ​

getCockpit 先解析阈值与连续期数，再确定批次范围。

批次为空时直接返回默认空结构，避免前端做大量空值判断。 下面是入口方法的真实源码裁剪：

java
public PerformanceStatisticsCockpitRespVO getCockpit(PerformanceStatisticsCockpitReqVO reqVO) {
    PerformanceStatisticsCockpitReqVO req =
            reqVO == null ? new PerformanceStatisticsCockpitReqVO() : reqVO;
    BigDecimal lowScoreThreshold = req.getLowScoreThreshold() == null
            ? DEFAULT_LOW_SCORE : req.getLowScoreThreshold();
    int consecutiveCount = req.getConsecutivePeriodCount() == null
            || req.getConsecutivePeriodCount() < 2
            ? DEFAULT_CONSECUTIVE : req.getConsecutivePeriodCount();
    List<PerformancePeriodDO> allPeriods = performancePeriodMapper.selectSimpleList();
    List<Long> requestedPeriodIds = resolveRequestedPeriodIds(req);
    List<PerformancePeriodDO> scopedPeriods = resolvePeriods(allPeriods, requestedPeriodIds);
    List<Long> periodIds = scopedPeriods.stream()
            .map(PerformancePeriodDO::getId).filter(Objects::nonNull).toList();
    PerformanceStatisticsCockpitRespVO resp = new PerformanceStatisticsCockpitRespVO();
    if (periodIds.isEmpty()) {
        return resp;
    }
    // 后续按同一范围查询计划、评价单、结果并完成聚合

接口路径是：

text
GET /admin-api/hrm/performance-statistics/cockpit

控制器权限沿用绩效结果查询权限：

text
hrm:performance-result:query

接口返回统一使用 CommonResult<PerformanceStatisticsCockpitRespVO>。

7.2 KPI 聚合：完成状态、比例和平均分 ​

KPI 聚合直接基于已经筛选好的批次、评价单和结果。 真实源码裁剪如下：

java
private void fillKpis(PerformanceStatisticsCockpitRespVO resp,
                      List<PerformancePeriodDO> periods,
                      List<PerformanceAssessmentBillDO> bills,
                      List<PerformanceResultDO> results) {
    Kpis kpis = resp.getKpis();
    kpis.setActivePeriodCount((int) periods.stream()
            .filter(p -> p.getStatus() != null
                    && p.getStatus() >= 1 && p.getStatus() <= 4)
            .count());
    int total = bills.size();
    int finished = (int) bills.stream().filter(this::isFinished).count();
    kpis.setBillTotal(total);
    kpis.setBillFinished(finished);
    kpis.setCompletionRate(rate(finished, total));
    kpis.setAppealCount((int) bills.stream().filter(this::isAppealOpen).count());
    if (!results.isEmpty()) {
        BigDecimal sum = results.stream().map(PerformanceResultDO::getScore)
                .filter(Objects::nonNull).reduce(BigDecimal.ZERO, BigDecimal::add);
        kpis.setAverageScore(sum.divide(BigDecimal.valueOf(results.size()),
                2, RoundingMode.HALF_UP));
    }
}

逾期数与风险人数依赖风险识别结果，因此在 fillRisks 中补齐。 这种顺序避免重复扫描风险对象。

7.3 连续低分：最近 N 期全部低于阈值 ​

连续低分识别先按员工分组，再取最近 N 条。 下面的裁剪保留了排序、数量门槛、全低判断和下钻对象：

java
List<PerformanceResultDO> ordered = entry.getValue().stream()
        .sorted(Comparator.comparing(PerformanceResultDO::getPeriodId).reversed())
        .toList();
if (ordered.size() < consecutiveCount) {
    continue;
}
List<PerformanceResultDO> recent = ordered.subList(0, consecutiveCount);
boolean allLow = recent.stream()
        .allMatch(r -> r.getScore().compareTo(threshold) < 0);
if (!allLow) {
    continue;
}
PerformanceResultDO latest = recent.get(0);
RiskItem item = new RiskItem();
item.setEmployeeId(latest.getEmployeeId());
item.setEmployeeName(latest.getEmployeeName());
item.setPeriodId(latest.getPeriodId());
item.setStage("consecutive_low_score");
item.setStageLabel("连续低分");
item.setScore(latest.getScore());
item.setLevel(latest.getLevel());
item.setBizId(latest.getId());
item.setBizType("result");

代码使用严格小于号。 因此阈值本身不属于低分，这一点应在业务口径说明中保持一致。

7.4 风险人数采用员工去重 ​

风险人数通过 Set<Long> 汇总员工 ID。 它将逾期、连续低分、申诉三类名单合并后去重。 同一员工同时逾期和连续低分，只计 1 人。 员工 ID 为空的风险行不会进入人数统计。 这使“风险项数量”和“风险人数”形成两个互补指标：

  • 逾期数回答有多少个问题；
  • 风险人数回答涉及多少个人。

八、前端实现：筛选、图表与下钻保持轻量 ​

8.1 API 层把数组转换为 GET 友好参数 ​

前端类型完整映射了 KPI、漏斗、部门完成率、批次完成率和风险结构。 请求时抽出 periodIds，转换为逗号字符串：

typescript
export function getPerformanceStatisticsCockpit(
  params: PerformanceStatisticsApi.CockpitReq,
) {
  const { periodIds, ...rest } = params;
  return requestClient.get<PerformanceStatisticsApi.CockpitResp>(
    '/hrm/performance-statistics/cockpit',
    {
      params: {
        ...rest,
        periodIdStr: periodIds?.length
          ? periodIds.join(',')
          : undefined,
      },
    },
  );
}

这段代码只有一个传输层职责。 页面仍然使用 number[]，后端 GET 绑定则得到稳定字符串。

8.2 通用图表卡片只负责渲染 option ​

cockpit-chart.vue 接收标题、高度和 ECharts option。

它不理解绩效业务。 页面负责构造漏斗、部门、等级和批次的 option，通用组件只在 option 变化时重新渲染。 这种拆分让 4 张图共享卡片布局，又保留各自的业务格式化逻辑。

8.3 风险标签页按同一表格切换数据源 ​

页面维护 activeRiskTab。 计算属性根据标签返回四个数组之一：

text
overdue  → risks.overdue
unfilled → risks.unfilled
lowScore → risks.consecutiveLowScore
appeals  → risks.appeals

表格列保持一致。 阶段列根据标签显示不同颜色：

  • 逾期、连续低分使用红色；
  • 申诉使用警告色；
  • 未填报使用处理中颜色。

8.4 点击整行按业务类型路由 ​

前端下钻逻辑没有依赖风险名称，而是依赖 bizType。 真实源码裁剪如下：

typescript
function openRisk(row: PerformanceStatisticsApi.RiskItem) {
  if (row.bizType === 'plan' && row.bizId) {
    router.push({
      path: '/hrm/performance/assessment-task/plan-info',
      query: { id: row.bizId },
    });
    return;
  }
  if (row.bizType === 'assessment_bill' && row.bizId) {
    router.push({
      path: '/hrm/performance/assessment-task/assessment-info',
      query: { id: row.bizId, viewMode: 'view' },
    });
    return;
  }
  if (row.bizType === 'result' && row.bizId) {
    router.push({
      path: '/hrm/performance/result-info',
      query: { id: String(row.bizId) },
    });
  }
}

整行点击降低了操作成本。 用户不需要先找一个很小的“详情”按钮。 ​

九、设计决策：为什么这样做 ​

9.1 一个聚合接口，保证同屏口径一致 ​

若每张卡片、每张图、每个风险标签分别请求接口，页面会产生多个时间点的快照。 考核状态恰好变化时，完成率与风险名单可能对不上。 当前实现通过一个接口返回所有驾驶舱数据。 优点是口径一致、加载状态简单。 代价是后端一次查询并聚合三类业务对象。 在当前驾驶舱范围和每类风险最多 50 行的设计下，这个取舍合理。

9.2 规则在后端，展示在前端 ​

逾期、申诉中、连续低分等规则都由后端判断。 前端只负责展示与路由。 这样避免不同客户端各自实现规则后出现差异。 低分阈值和连续期数仍通过请求参数传入，为规则留出可配置空间。

9.3 风险对象保留业务类型，而不是统一成评价单 ​

目标未确认发生在计划上。 自评、评审、校准和申诉发生在评价单上。 连续低分来自结果。 如果强行把所有风险映射到评价单，会丢失最自然的业务入口。

bizType + bizId 允许每类风险回到真正的数据源。

9.4 明确不做的能力 ​

当前版本没有以下能力：

  • 不基于历史数据预测未来绩效；
  • 不自动向员工或主管发送风险消息；
  • 不提供人才九宫格；
  • 不把连续低分直接解释为淘汰建议；
  • 不替代管理者对异常数据的人工复核。

这些边界能防止统计看板被误解为自动决策系统。 ​

十、技术亮点总结 ​

设计点实现方式业务价值
统一筛选公司、部门、批次共同限定三类数据KPI、图表、名单口径一致
智能默认批次进行中 + 近 3 个已出结果兼顾当前推进与近期趋势
8 项 KPI进度、风险、结果三类指标摆脱平均分单一视角
7 阶段漏斗计划状态 + 评价单状态快速发现流程堵点
部门完成率部门分组并统计完成数/总数横向定位落后组织
等级分布结果等级聚合观察结果结构
批次完成率按批次独立统计比较周期推进质量
4 类风险逾期、未填报、低分、申诉把汇总变成名单
连续低分最近 N 期严格低于阈值识别持续性问题
风险人数去重员工 ID Set 聚合区分风险项和涉及人数
业务下钻bizType + bizId从发现直接进入处理
响应限流每类风险最多 50 行控制驾驶舱负载

十一、快速体验 ​

在线演示：https://ruoyioffice.com/web/（账号 admin / 密码 admin123） 操作路径：HRM 人力资源 → 绩效管理 → 绩效统计 推荐体验流程：

  1. 先不选择批次，观察系统默认加载进行中批次与最近 3 个已出结果批次。
  2. 切换公司，确认部门树随公司变化，且原有无效部门会被清空。
  3. 选择一个部门，对比完成率、逾期数和风险人数如何变化。
  4. 多选两个批次，在批次完成率图中比较推进差异。
  5. 调整低分阈值，观察连续低分名单是否变化。
  6. 在风险预警中依次切换逾期、未填报、连续低分和申诉积压。
  7. 点击一条风险记录，确认进入计划、评价单或结果详情。
  8. 打开批次工作台，继续处理单批次的阶段任务。

本地启动：

powershell
cd W:\ruoyi-office\ruoyi-office
mvn -P boot -DskipTests compile
powershell
cd W:\ruoyi-office\ruoyi-office-vben
pnpm dev:antd

本地前端默认访问地址为 http://localhost:5800。 后端默认端口为 48080，管理端 API 前缀为 /admin-api。 源码仓库：

平台地址
GitHubhttps://github.com/yuqing2026/ruoyi-office
GitCodehttps://gitcode.com/zhouzhongyan/ruoyi-office
Giteehttps://gitee.com/yqzy1688/ruoyi-office

基础能力可通过在线演示和源码仓库了解。 完整版本、持续维护与企业落地方案请按实际需求咨询。 ​

十二、从源码得到的实施建议 ​

12.1 先统一状态口径，再做图表 ​

完成率最容易因“什么算完成”产生争议。 本实现明确把状态 50 与 64 都视为完成。 企业二次开发时，应先确认申诉完成是否计入本批次完成，再扩展其他状态。

12.2 截止日必须与业务阶段一一对应 ​

不同阶段使用不同截止日。 不要用一个批次结束日期判断全部逾期，否则无法说明到底是员工、主管还是 HR 超期。

12.3 连续低分必须同时说明阈值和窗口 ​

“连续低分”不是一个完整口径。 完整口径应写成“最近 3 期均低于 70 分”。 当前风险备注正是按这个方式生成，方便管理者复核。

12.4 风险名单要能回到业务对象 ​

只展示员工姓名会导致管理者再次搜索。 风险行至少应携带业务主键和业务类型。 下钻是驾驶舱从“可看”变成“可用”的关键一步。 ​

结语 ​

绩效驾驶舱的核心不是把平均分画得更漂亮，而是建立“统计口径—结构诊断—风险名单—业务处理”的闭环。 这次实现用 8 项 KPI 保留总体判断，用阶段漏斗和 3 类分布图定位组织与批次差异，再用 4 类规则风险把问题落实到人和单据。 整个过程基于可解释规则。 管理者能知道为什么某人进入名单，也能点击记录回到计划、评价单或结果详情。 这种“摘要 + 诊断 + 行动”的设计也可以推广到招聘进度、培训完成率、合同履约、项目里程碑和资产盘点等管理场景。 如果你正在建设绩效系统，建议先问三个问题：

  1. 你们的完成口径是什么？
  2. 最容易堵在哪个阶段？
  3. 风险名单能否一键回到业务单据？

欢迎在评论区分享你们更关注“部门完成率”还是“连续低分”，也欢迎体验真实页面后交流改进建议。 ​

常见问题（FAQ） ​

绩效驾驶舱的完成率如何计算？ ​

完成率等于已完成评价单数除以评价单总数，再乘 100%。 当前状态 50（正常完成）和 64（申诉完成）都计为已完成，结果保留 1 位小数。

连续低分预警是如何识别的？ ​

系统按员工汇总有得分的绩效结果，按批次 ID 倒序取最近 N 期。 最近 N 期每一期都严格小于低分阈值才命中；默认 N 为 3、阈值为 70。

风险人数为什么不等于四类风险人数相加？ ​

同一员工可能同时出现在逾期、连续低分和申诉名单中，风险人数会按员工 ID 去重。 另外，仅未填报但尚未逾期的人员当前不计入风险人数 KPI。

未选择考核批次时会查询全部历史数据吗？ ​

不会。 默认查询状态 1~4 的进行中批次，再加入最近 3 个状态大于等于 5 的已出结果批次。

点击风险记录可以直接处理吗？ ​

可以下钻到对应业务详情。 计划风险进入计划详情，评价环节和申诉风险进入评价单详情，连续低分进入绩效结果详情。

这套驾驶舱是否包含预测、自动通知和人才九宫格？ ​

当前不包含。 现有能力是基于业务状态、截止日期、历史结果和阈值的可解释规则统计；完整产品能力与企业落地方案可通过在线演示和咨询进一步了解。 ​

💡 想要体验 RuoYi Office 的绩效驾驶舱？

🌐 在线演示：https://ruoyioffice.com/web/（账号 admin / admin123）

📦 源码仓库：GitHub | GitCode | Gitee

💬 技术咨询：添加微信 17156169080，备注「RuoYi Office」

⭐ 如果本文对你的绩效系统设计有帮助，欢迎 Star、收藏并分享给团队！

联系我们

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

微信咨询二维码

微信咨询

17156169080

添加时备注「RuoYi Office」

在线体验商业版