本文定位：失败复盘。它不是产品宣传稿，而是把一个常见的企业数字化问题拆成“背景—症状—方案—结果—经验”，方便你对照自己的情况判断。
一、背景：问题不是突然出现的
客户的大屏做得很漂亮，有销售额、订单数、客户数、库存金额和地图动效。上线第一周大家都觉得不错，一个月后老板基本不看。
二、关键症状：真正卡住业务的地方
复盘发现，大屏展示的是“已经发生的结果”，但没有告诉管理层“现在该处理什么”。销售额低了不知道是哪类客户，库存高了不知道哪些 SKU，订单延期了不知道卡在哪个责任人。
三、落地/救火路径：先收口，再扩展
救火时我们把大屏改成经营会页面。首页不再堆指标，而是显示本周必须处理的异常：毛利异常订单、停滞商机、库存呆滞、回款逾期、项目超预算。
四、结果：能被管理动作验证的变化
每个异常都能点进去看到责任人、原因、建议动作和上次处理记录。会议从看数字变成清任务，老板才重新开始用。
五、给同行的建议：别先追求大而全
经营分析不是把数字放大，而是把动作提前。不能推动动作的指标，再漂亮也只是装饰。
六、可直接照抄的检查清单
| 检查项 | 要问的问题 | 不合格信号 |
|---|---|---|
| 业务目标 | 这次项目到底要让哪个指标变好？ | 只说“提升效率”，没有具体场景 |
| 数据来源 | 关键数据现在在哪里、谁负责维护？ | 数据散在个人 Excel 和聊天记录里 |
| 责任闭环 | 异常出现后谁处理、多久复查？ | 只有提醒，没有责任人和复查机制 |
| 上线范围 | 第一阶段哪些必须做、哪些先不做？ | 一期就想覆盖所有部门 |
| 管理承接 | 上线后在哪个会议、哪个岗位使用？ | 系统上线后没人固定看 |
七、复盘后重新设计的指标分层
这类项目补救时，不能只把原来的图表换个位置，而要先把指标分成三层：第一层是老板每周必须拍板的经营问题，例如回款逾期、毛利异常、库存呆滞；第二层是部门负责人能负责的过程指标，例如销售跟进停滞、采购到货延迟、生产排产冲突；第三层才是展示性结果指标，例如累计销售额、客户数、门店数。
我们后来把大屏首页从“看起来很完整”改成“本周必须处理的 8 个异常”。每个异常都要求带上责任人、金额影响、截止时间和上次处理记录。如果某个指标不能对应到下一步动作，就从首页移走，最多放进二级分析页。这个动作让会议节奏发生了变化：老板不再问“这个数字什么意思”，而是直接问“这 3 个异常今天谁处理”。
还有一个关键点：经营大屏要和会议机制绑定。没有周经营会、日例会或专项复盘会承接，大屏就会变成展厅屏幕。上线后至少连续 4 周由老板或业务负责人带着页面开会，才能把“看数字”变成“用数字管事”。
八、大屏没人用，通常是因为没有连接会议
经营大屏失败，不一定是图表做得差，而是它没有进入管理节奏。很多企业上线时很热闹，屏幕上有销售额、客户数、订单数、地图和排行榜，但每周经营会还是靠各部门自己做 PPT。大屏如果不被会议引用，很快就会变成前台展示。
救火时我们会先问三个问题：老板每周固定看哪几个指标，指标异常后谁解释，解释后谁负责动作。如果回答不出来，就先不要继续加图表。这个项目最后把十几个图压缩成五个经营问题：收入是否达标、毛利是否异常、交付是否延期、库存是否积压、回款是否有风险。每个问题对应一张清单和一个责任部门。
大屏从“展示指标”变成“推动会议”，使用率才会起来。否则再漂亮的视觉效果，也无法改变管理动作。
九、指标字典比可视化更重要
经营看板最容易吵的是口径。销售说成交额按合同算，财务说按回款算，交付说项目未验收不能算。没有指标字典，大屏上的数字越实时，争议越大。
所以重做时要先定义指标：名称、计算公式、数据来源、刷新频率、负责人、异常阈值、处理动作。只有这些内容确定后，图表才有意义。可视化只是最后一层，前面真正决定成败的是口径和责任。
十、落地前可以先问自己的五个问题
第一，当前最痛的业务动作是什么，是销售漏跟、库存不准、项目亏损、数据口径不一，还是系统没人用？如果一句话说不清，说明项目目标还需要继续收敛。第二，这个动作今天的数据在哪里，是系统里、Excel 里、微信群里，还是某个人脑子里？数据越分散，第一阶段越要小。第三，谁是这个数据的负责人，谁有权决定字段口径和流程变化？没有负责人，系统上线后也会变成无人维护的表。
第四，异常出现后谁处理，处理结果回写到哪里？很多数字化项目只做到“发现问题”，没有做到“问题被处理并复查”，价值会卡在最后一公里。第五，老板或管理层准备在哪个会议里固定使用这套系统？如果上线后没有会议承接，大家很快会回到原来的汇报方式。
这五个问题的答案，比功能清单更重要。功能清单决定开发什么，五个问题决定系统上线后有没有人用、有没有人维护、有没有管理动作跟上。
十一、适合先做小诊断的企业画像
如果你的企业已经有一些系统，但数据分散、口径不一、老板看数还要等人导表，适合先做诊断；如果你的企业还主要靠 Excel、钉钉群和人工审批，也适合先做诊断，因为这时最重要的是确认第一阶段到底该系统化哪一段。
不适合一上来做大项目的情况也很明确：目标太泛，只说“全面数字化”；内部没人能拍板；历史数据没人愿意清；业务部门只想让 IT 自己解决；老板希望一次上线解决所有问题。遇到这些情况，先做 1 到 2 周的小范围梳理，反而比直接开发更省钱。
开沿通常会把诊断结果拆成三张图：业务流程图、数据流转图、一期范围图。三张图对齐后，再决定用标准 SaaS、低代码、钉钉二开、系统集成还是定制开发。这样做慢在前面，快在后面，也能减少上线后推倒重来的概率。
补充一点：第一阶段还要提前约定复盘节奏。上线后的前四周，建议每周固定看一次使用数据、异常清单和业务反馈，把必须改的小问题快速收掉，把“以后再说”的需求放进二期池。这样既能保护一期范围，也能让业务团队看到系统是在持续服务他们，而不是上线后就没人管。
还有一个容易忽略的动作，是给二期需求设入口。业务在试运行期提出的新想法，不要马上塞回一期，也不要简单拒绝，而是记录触发场景、预期收益和影响范围。等一期稳定后，再按收益和复杂度排序处理，项目节奏会稳很多。
十二、开沿的建议
如果你看到这里，最该做的不是立刻问“做一套多少钱”，而是先把当前流程画出来：数据从哪里来，谁加工，谁决策，谁执行，结果回写到哪里。只要这条链路不清楚，系统越复杂，后期越难维护。
开沿更愿意先做小范围诊断：选一个高频场景，确认数据和责任是否能闭环，再判断适合低代码、标准 SaaS、二开还是定制。这样预算更可控，也更容易让团队真正用起来。
