第一步：选域与基线
选一个业务价值清楚、跨部门较少的业务域，记录当前的取数时间、口径冲突与人工环节。为什么从域开始？因为全公司级评估容易变成填表，单域基线能直接指向改进行动。产出物是一页现状图，标注系统、数据与责任人。
第二步：数据与 owner
列出该域的关键数据项、来源系统、更新频率与使用方，为每项指定 owner。怎么做才不流于形式？让 owner 参与口径确认与质量抽检，并把结果纳入部门例会。没有 owner 的数据项，应标注为风险而不是默认可用。
第三步：主数据与接口
优先统一客户、物料、供应商等主数据，能用接口同步的不要人工导表。边界是：接口改造要评估对现有系统的影响，先做只读同步，再考虑写入。改造期间保留人工兜底，避免业务中断。
第四步：口径字典与改进
把关键指标的定义、计算公式与责任人写成字典，选两三个指标做九十天改进，例如缩短取数时间或消除一处口径冲突。改进要有前后对比数据，否则无法判断是否真的变好，也无法向管理层证明投入值得，这正是为什么要留对比数据。
第五步：复测与 AI 决策
九十天后复测同一组指标，确认改进是否稳定，再决定是否启动 AI 场景。若取数仍需数天、口径仍冲突，说明基础未稳，应继续治理。这个顺序能避免把组织问题误当成技术问题，边界在数据是否稳定。
适用与不适用
适合谁
- 准备启动数字化改进、愿从单域做起的企业
- 数据口径混乱、报表常打架的中型公司
- 想在上 AI 之前补齐数据基础的业务负责人
不适合谁
- 期望一次性完成全面改造、不愿分批推进的团队
- 没有任何业务系统、也暂不需要治理的小微企业
典型场景
一家批发企业选订单履约域做基线，发现库存数据来自三个系统且口径不同。团队指定库存 owner，统一商品编码，先做只读接口同步，再用九十天把取数时间从数天缩短到当天。复测通过后才启动补货建议试点。
可执行步骤
- 选一个业务域，记录取数时间、口径冲突与人工环节，形成一页现状基线
- 逐项列出关键数据项、来源系统与使用方，并为每一项指定唯一的 owner
- 先统一客户、物料等主数据，再推进只读接口同步，同时保留人工兜底
- 编写指标口径字典，并从冲突最多的指标里挑出两三个可量化的改进项
- 九十天后复测同一组指标，确认改进已经稳定，再决定是否投入 AI 场景
常见坑
- 一上来就做全公司评估，问卷冗长，结论往往无法落到行动，还消耗了管理层与一线部门的信任。
- 主数据改造同时改写入逻辑，业务一旦中断，项目只能被迫回滚，进度倒退，团队士气也受损。
- 改进没有前后对比数据，就无法判断真实效果，后续预算也难以延续，项目很容易在半途停摆。
自检与验收清单
- 是否只选定一个业务域，并完整记录下现状基线
- 关键数据是否都有唯一的 owner 与考核
- 主数据是否统一，接口是否先只读、然后再写入
- 改进是否有可核对的前后对比数据来作为支撑
常见问题
九十天够吗？
九十天够验证方向，但不够完成全面治理。这段时间的目标是证明某个缺口可以被补上，并形成可复用的方法。全面推广要按业务域分批推进，每一批都设复测点，稳一步再走一步。
业务部门不配合怎么办？
先把改进目标与业务痛点绑定，例如缩短对账时间、减少缺货。让业务先看到直接收益，比发文件更有效。同时把数据 owner 的职责写进岗位说明与考核，避免责任悬空。
什么时候可以上 AI？
当目标场景所需的数据能在可接受时间内取出、口径一致，并且有明确的复核人时，就可以小范围试点。不必等全公司都成熟，但必须先确保该场景的输入足够可靠。