先把「80%」这个数字的算法说清楚
项目复盘里最不值钱的一句话是「效率大幅提升」,最值钱的是把提升幅度怎么算出来的讲清楚。这个项目对外说的「效率提升 80%」,口径是生产运营日报的准备与核对时长:
效率提升幅度 =(改造前单次人工作业耗时 − 改造后单次人工作业耗时)÷ 改造前单次人工作业耗时
统计范围限定为「数据准备 + 口径核对 + 异常排查」三段,不含开会讨论本身。
为什么要把范围限定住?因为「效率」这个词在不同人嘴里指的是不同东西:有人指人力投入,有人指决策速度,有人指报表产出频率。口径不先定死,验收时一定吵架。
改造前:早会前一天的「人肉数仓」
项目启动前的状态其实很典型:
- 生产、设备、能耗、库存数据分散在多个业务系统里,没有统一出口;
- 每天早上需要人工从各系统导出、拼接、核对,报表出来时早会已经开完了;
- 同一个「产量」在不同报表里数字不一致,因为口径不同(含不含试生产、按班次还是按日);
- 异常靠人盯,往往发现时已经影响了下游排产。
这些问题的共同点是:不是缺数据,是缺一个让数据能被稳定使用的底座。
双层构建:应用层 + 支撑层
我们没有直接去做一块「好看的大屏」,而是分两层建:
| 层次 | 包含内容 | 解决的问题 |
|---|---|---|
| 应用层 | 生产运营大屏、管理看板、移动端查询 | 让不同角色在同一个数字上对话 |
| 支撑层 | 数据采集与汇聚、指标体系、质量监控、权限 | 让屏幕上的数字可信、可持续更新 |
我们常跟客户讲:大屏是所有数据工作的验收界面,不是它的起点。如果支撑层没建好,大屏上线第一周很好看,第二周开始就没人看了——因为数字不再可信。
指标体系:大屏真正的技术含量在这里
一块大屏好不好,不看动效,看指标能不能对得上。这一步我们做了三件事:
- 指标口径统一:每个指标写清楚计算逻辑、取数范围、更新频率,形成《指标字典》;
- 指标责任人:每个核心指标指定唯一业务负责人,数字对不上时找谁,是明确的;
- 同名不同义排查:把各系统里叫法相同、算法不同的指标全部拉出来对齐,这一步往往会推翻不少历史报表。
《指标字典》看起来是文档工作,实际是整个项目最有复用价值的资产——后面做数据资产入表、做智能问数,都要回到这份字典。
从「看数」到「用数」:异常先说话
项目后期我们加了一层规则预警:指标越过阈值自动提示,并附上「可能相关的三个原因方向」。变化看上去很小,但用户行为变了——过去是「打开大屏找问题」,现在是「大屏告诉我哪里有问题」。
这也是判断一个数据项目是否真有价值的标志:用户从主动查数,变成被动接收结论。
验收口径怎么定,才不会变成一笔糊涂账
- 事前约定:效率指标在项目启动时就写入验收标准,而不是上线后补;
- 可复现:统计方法要能被第三方按同样步骤复算出来;
- 区分系统指标与业务指标:系统上线时间、报表数量是过程指标,不能拿来当效率提升;
- 双方确认:业务方签字确认基线数据,避免事后对基线有分歧。
本文要点
- 「效率提升 80%」的口径是日报准备与核对时长(数据准备 + 口径核对 + 异常排查)
- 大屏项目必须双层构建:应用层负责呈现,支撑层负责可信
- 核心资产是《指标字典》与指标责任人机制,不是屏幕本身
- 价值分水岭:用户从主动查数变成接收结论
- 效率指标必须在项目启动时写入验收标准,并保证可复现
微信内识别二维码分享此文