本文定位：匿名客户案例。它不是产品宣传稿，而是把一个常见的企业数字化问题拆成“背景—症状—方案—结果—经验”，方便你对照自己的情况判断。
一、背景：问题不是突然出现的
这家客户有 40 多家门店，收银系统能出销售额，但老板真正想看的是毛利、库存、会员复购、店长动作和异常门店。项目开始前，总部每天靠群里发截图和 Excel 汇总，数据慢一天，还经常口径不一致。
二、关键症状：真正卡住业务的地方
我们没有先替换收银系统，而是先定义门店经营指标字典：销售额、客单价、毛利率、库存周转、缺货次数、会员新增、复购、店长巡检。能从系统取的自动取，取不到的先通过钉钉表单补齐。
三、落地/救火路径：先收口，再扩展
第一阶段做日报自动汇总，第二阶段做区域对比，第三阶段加异常提醒。比如连续 3 天客单价低于同区域均值、某 SKU 多店缺货、会员新增突然下降，系统会自动推给运营负责人。
四、结果：能被管理动作验证的变化
上线后经营会发生了变化。以前每家门店讲自己的理由，现在先看同口径数据，再讨论动作。总部也能区分“临时波动”和“需要下店辅导”的门店。
五、给同行的建议：别先追求大而全
这个案例的关键经验是：连锁数据中台不要从大屏开始，而要从经营动作开始。指标只有能触发动作，才不是装饰。
六、可直接照抄的检查清单
| 检查项 | 要问的问题 | 不合格信号 |
|---|---|---|
| 业务目标 | 这次项目到底要让哪个指标变好？ | 只说“提升效率”，没有具体场景 |
| 数据来源 | 关键数据现在在哪里、谁负责维护？ | 数据散在个人 Excel 和聊天记录里 |
| 责任闭环 | 异常出现后谁处理、多久复查？ | 只有提醒，没有责任人和复查机制 |
| 上线范围 | 第一阶段哪些必须做、哪些先不做？ | 一期就想覆盖所有部门 |
| 管理承接 | 上线后在哪个会议、哪个岗位使用？ | 系统上线后没人固定看 |
七、这个项目验收时看三个动作
第一，看数据是不是能在固定时间自动生成。连锁门店最怕总部每天等门店截图，日报如果还靠人手汇总，就很难坚持。第二，看异常是不是能分派到人。比如库存异常、客单价异常、会员新增异常，必须明确到区域经理、店长或运营负责人。第三，看会议是否真的改变。经营会如果仍然靠各店口头解释，说明系统只是多了一张报表；如果会议直接围绕异常清单排动作，才算跑通。
我们建议连锁企业第一阶段不要做太多花哨指标，先把“门店、商品、会员、库存、人员动作”五类数据口径统一。口径统一以后，再做区域对比、趋势预测和店长考核，数据才不会越用越乱。
八、日报不是目的，经营动作才是目的
这个项目一开始没有直接做大屏，是因为大屏很容易变成展示工程。老板真正需要的不是每天看到很多图，而是知道哪些门店要处理、由谁处理、处理后有没有改善。所以第一阶段我们把日报设计成“动作入口”：销售额下降只是信号，系统还要同时给出客单价、毛利率、库存、会员新增和店长巡检记录，帮助运营判断原因。
例如某家门店连续三天销售额下降，如果客流没降但客单价下降，可能是搭配销售问题；如果销售额下降同时缺货次数上升，可能是补货问题；如果会员新增和复购都下降，可能是店长动作或活动执行问题。只有把指标和动作放在一起，经营会才不会停留在“为什么下降”的争论里。
我们还给每类异常绑定了责任人：库存异常推给商品负责人，会员异常推给运营，巡检异常推给区域督导。异常不是发到群里让大家围观，而是进入待办，下一次经营会看处理结果。
九、连锁经营驾驶舱的最小版本
对连锁企业来说，最小版本不需要复杂 BI。先把门店、区域、品类、会员、库存、巡检这几个维度统一，再固定每天输出三类信息：今天哪里异常、异常可能因为什么、谁负责处理。
当总部能稳定用这些信息开会，再逐步增加趋势预测、补货建议、会员分层和活动复盘。否则一开始就做炫酷大屏，只会让数据团队忙于做图，业务团队却不知道下一步该干什么。
十、落地前可以先问自己的五个问题
第一，当前最痛的业务动作是什么，是销售漏跟、库存不准、项目亏损、数据口径不一，还是系统没人用？如果一句话说不清，说明项目目标还需要继续收敛。第二，这个动作今天的数据在哪里，是系统里、Excel 里、微信群里，还是某个人脑子里？数据越分散，第一阶段越要小。第三，谁是这个数据的负责人，谁有权决定字段口径和流程变化？没有负责人，系统上线后也会变成无人维护的表。
第四，异常出现后谁处理，处理结果回写到哪里？很多数字化项目只做到“发现问题”，没有做到“问题被处理并复查”，价值会卡在最后一公里。第五，老板或管理层准备在哪个会议里固定使用这套系统？如果上线后没有会议承接，大家很快会回到原来的汇报方式。
这五个问题的答案，比功能清单更重要。功能清单决定开发什么，五个问题决定系统上线后有没有人用、有没有人维护、有没有管理动作跟上。
十一、适合先做小诊断的企业画像
如果你的企业已经有一些系统，但数据分散、口径不一、老板看数还要等人导表，适合先做诊断；如果你的企业还主要靠 Excel、钉钉群和人工审批，也适合先做诊断，因为这时最重要的是确认第一阶段到底该系统化哪一段。
不适合一上来做大项目的情况也很明确：目标太泛，只说“全面数字化”；内部没人能拍板；历史数据没人愿意清；业务部门只想让 IT 自己解决；老板希望一次上线解决所有问题。遇到这些情况，先做 1 到 2 周的小范围梳理，反而比直接开发更省钱。
开沿通常会把诊断结果拆成三张图：业务流程图、数据流转图、一期范围图。三张图对齐后，再决定用标准 SaaS、低代码、钉钉二开、系统集成还是定制开发。这样做慢在前面，快在后面，也能减少上线后推倒重来的概率。
补充一点：第一阶段还要提前约定复盘节奏。上线后的前四周，建议每周固定看一次使用数据、异常清单和业务反馈，把必须改的小问题快速收掉，把“以后再说”的需求放进二期池。这样既能保护一期范围，也能让业务团队看到系统是在持续服务他们，而不是上线后就没人管。
十二、开沿的建议
如果你看到这里，最该做的不是立刻问“做一套多少钱”，而是先把当前流程画出来：数据从哪里来，谁加工，谁决策，谁执行，结果回写到哪里。只要这条链路不清楚，系统越复杂，后期越难维护。
开沿更愿意先做小范围诊断：选一个高频场景，确认数据和责任是否能闭环，再判断适合低代码、标准 SaaS、二开还是定制。这样预算更可控，也更容易让团队真正用起来。
