36 个月路线图：不是项目排期表，是决策的时间化表达
本系列为虚构教学案例。上一篇：《目标应用架构怎么画，以及一份真实格式的 ADR：为什么 OMS 先于 ERP》
第 4 篇把目标架构和 ADR 讲完了。这篇回答最后一个排序问题：这些决策，按什么顺序在 36 个月里落地？
先给结论：路线图不是项目排期表。大多数路线图失败在三个地方------把所有项目平铺到时间轴上（没有取舍）、给老板看的版本过于美化（没有风险）、里程碑写成"XX 系统上线"（没有验收标准）。宏远这张图的每一条线、每一个菱形，都是前面几篇决策的"时间化表达"。
一、先兑现第 2 篇的伏笔：病分四类，药分三期
第 2 篇我们把五域的病分成了急性病（销售、供应链）、慢性病（财务）、绝症（合规）、免疫缺陷（治理），结尾留了个问题：预算只够救一个域你选哪个。现在揭晓路线图的答案------不是四选一，而是按"哪个不先治会死"排期，同时每个阶段都要给绝症上药。
| 分期 | 主题 | 治什么病 | 关键动作 |
|---|---|---|---|
| Phase 1（0--6 月） | 止血 | 急性病 | 诊断 + MDM + OMS 先行 |
| Phase 2（6--18 月） | 换器官 | 慢性病根子 | ERP 切换 + WMS + CRM |
| Phase 3（18--36 月） | 强体质 | 绝症根治 + 免疫重建 | 数据平台 + 合规常态化 |
读者评论里有人质疑：合规是"绝症"，为什么系统性治理排在最后 18 个月，而不是第一天就全上？这是本系列最值得一辩的取舍，我放在第四节展开。
二、Phase 1（0--6 月）：止血，但止血钳的位置有讲究
四条工作线：现状诊断与架构基线 （M0--M2）、MDM + PIM 商品主数据 （M1--M6）、OMS 订单中台 （M2--M6）、治理机制启动（M1--M4，数据 Owner 制度 + 架构评审会首次运转）。
注意三个细节：
- MDM 比 OMS 早一个月启动。ADR-002 的逻辑：OMS 要吃商品主数据，主数据不干净，OMS 只是把乱从渠道搬到了中台。一个月的先导期，是给主数据清洗留的"脏数据处理窗口"。
- 桥接债如期而至 。ADR-001 里登记的 TD-003（OMS↔U8+ 桥接接口）M5 开工、持续到 M12------技术债不是"以后再说"，而是在路线图上占了格子、排了工期、标了责任人。
- 治理机制在第一阶段就启动，哪怕只是最小化运转。第 2 篇说过治理是免疫缺陷：等系统都上完了再补治理，等于楼盖完了再打地基。
Phase 1 验收（M6） ：错单率 ≤0.3%（基线 1.8%）、一物多码率 <2%（基线 23%）、数据 Owner 制度实质运转（每个核心实体有唯一责任人）。------注意全部是业务数字，没有一个写"OMS 上线"。
三、Phase 2（6--18 月）：换器官，ERP 切换是全系列最高风险动作
六条线：ERP 选型与实施 （M6--M14）、iPaaS （M7--M12，先于 ERP 切换完成------新 ERP 不许再用点对点接入）、海外仓 WMS （M9--M14）、越南工厂工单系统 （M10--M15）、CRM（M12--M17）。
ERP 切换（M14--M15）单独说，因为它是全路线图上唯一不可回滚、必须一次成功的动作。三个设计决定：
- 为什么 M6 才选型，M14 才切换，中间 8 个月在干什么？ 答：数据迁移演练。新 ERP 失败的第一大死因不是软件功能，是脏数据迁移。MDM 在 Phase 1 已经跑了 6 个月，商品主数据基本干净，但客户、供应商、期初余额的清洗和三轮迁移演练，必须占满这 8 个月。切换窗口只有 72 小时，演练要做三次。
- 为什么 WMS 和越南工单系统错开 ERP 切换窗口？ 三条大系统同时切换 = 故障无法归因。越南工单系统的意义在第 3 篇说过------让越南的"真相"实时可见------它独立于 ERP 切换，M15 验收"越南实时可见"。
- CRM 排最后，因为它依赖客户主数据，而客户主数据的清洗在 ERP 切换时才真正完成。顺序链兑现：MDM → OMS → CRM。
Phase 2 验收（M18） ：双法人一套账（月结回到 5 天内）、越南工单实时可见、无新增点对点接口（iPaaS 覆盖率 100%）。
四、Phase 3（18--36 月）：强体质，以及那场关于"绝症"的辩论
四条线：BI 数据平台 （M18--M27）、数据合规体系 GDPR 常态化 （M18--M30）、IAM 深化 （M19--M26）、架构治理常态化（M18--M36，技术雷达 + 评审会进入常态节奏）。
回到开头那个质疑：GDPR 是"绝症"，为什么系统性合规在 M18 才开始？我的辩护分两层：
第一层，合规的"最小动作"其实第一天就有。 Phase 1 的治理机制启动包含三件事：客户数据盘点（数据散在 5 个系统的清单化）、影子 IT 收编（第 2 篇说的自购 SaaS 全部登记）、数据 Owner 制度。这三件事不能止血，但能把裸奔状态从"全裸"降到"有遮羞布"。
第二层，系统性合规依赖数据集中，而数据集中恰恰是前 18 个月的建设成果。 GDPR 的核心动作------数据主体权利响应（访问、删除、可携带）------在数据散于 5 个系统时是不可执行的：你连数据在哪都说不清，怎么响应删除请求？合规自动化是数据平台的下游，这不是拖延，是依赖链。 但风险登记在案：M6--M18 期间若发生数据泄露，公司没有技术能力完整响应------这个风险在路线图的评审记录里，由 CISO 虚线岗位持续盯防。
Phase 3 验收（M30 / M36） ：GDPR 合规审计通过；全公司一个 GMV（第 1 篇老板问题的最终答案）；技术雷达每年两轮、评审会每月一次进入常态。
五、画路线图的三个纪律（带走就能用）
- 里程碑必须是可验证的业务状态，不是"系统上线"。 "OMS 上线"不算里程碑------上线第一天错单率还是 1.8%。"错单率 ≤0.3%"才算。上线是动作，数字才是结果。
- 依赖链画在图上，不藏在心里。 MDM→OMS、MDM→ERP、数据集中→合规自动化------每条依赖都要能指出来，被人挑战时拿得出 ADR 编号。路线图上每一条线的位置，都应该能回溯到一篇 ADR。
- 技术债和风险必须占格子。 TD-003 桥接占了 M5--M12；GDPR 风险登记了 M6--M18 的暴露窗口。路线图上没有格子的债，就是不存在的债------直到它炸掉。
架构师思考问题：看这张甘特图，M12 前后是最危险的时段------OMS 刚验收、ERP 切换在即、桥接债还在还。假如你是宏远架构师，M12 时老板看完数据觉得"系统建得不错"，决定把 BI 数据平台提前到 M13 启动（"数据反正都在 OMS 里了"），你接不接这个需求？接，Phase 2 的资源怎么保？不接，怎么跟老板解释"为什么数据在库里却还不能做 BI"？------这道题有真实项目原型的味道，把你的回答写在评论区，第 6 篇治理篇我们会回收这道题。