2.11 我怎样安排 3 个月和 6 个月路线

经营层希望三个月看到结果，信息团队估计六个月才能完成全部系统连接。两种说法都可能对，关键是每个阶段准备证明什么。

我把两条时间线放到同一张纸上以后，先纠正了一个误会：三个月不是改造完公司，六个月也不是等所有系统接好再让员工使用。三个月用来走完一条受控灯塔，六个月用来观察经营结果、稳定采用并决定是否迁移到其他价值流。

我按风险逐步增加动作

第一个阶段确认基线、样本和权限；第二阶段让 AI 只整理、比较和提示；第三阶段让少量员工在真实订单中使用；只有前面证据成立，才讨论在规则内执行低风险动作并扩大用户。

每个阶段都必须得到业务证据，再进入下一阶段。路线图不是日期表，而是一串带条件的授权。

我先写状态，再写月份

第一个状态是“我们能重复说明当前问题”，需要章程、基线和样本。第二个状态是“AI 能在历史事件中可靠整理与提示”。第三个状态是“少量员工能在真实工作中确认建议”。第四个状态才是“部分低风险动作可以在规则内执行”。

日期只是对资源和节奏的估计。如果历史样本尚未通过，即使已经到第五周也不能进入真实客户；如果证据提前稳定，也不需要为了遵守计划空等。

我曾经把“第八周上线”写进路线图，团队便在高风险案例失败时仍想按时发布。后来我改为“关键验收案例通过后进入受控试用”，日期压力才不会压过业务边界。

云枢科技的一个边界用例就是客户在方案和合同里使用了两个不同主体。系统若不能显示冲突而是自行选择一个主体，即使其他九成样本都整理正确，也不能进入真实订单。这个失败不是“还有一个小问题”，而是说明客户、合同和权限可能连错。

三个月适合什么公司

数字化基础较好、流程负责人明确、资料可用且灯塔范围较窄时，可以采用三个月加速路线：四周诊断与设计，四周建设和历史样本验证，四周真实试用与结果复核。

三个月路线还要求关键岗位能快速作决定、新旧流程的切换由负责人管理、失败后能回到人工。云枢科技具备这些条件，才选择十二周灯塔。

这不是读者必须遵守的学习期限，也不是三个月改造整家公司。它只是一条企业灯塔的执行参考。

六个月为什么更常见

当数据分散、跨部门争议大或需要改变制度时，我会用六个月。前两个月诊断和整理基础，中间两个月完成灯塔试点，最后两个月稳定使用、扩大范围并把能力交给内部团队。

六个月不是让学习拖长，而是给组织变化和结果观察留下时间。以 YS-24-017 为例，从合同到验收用了 132 天，尾款又晚了 49 天。即使新流程在第十二周已经减少资料退回，我们仍然不能据此宣布回款改善；一笔新订单还没有走到能观察尾款的时间点。

路线选择由转型负责人组织，业务、数据、工程和风险负责人共同说明条件，CEO 决定资源和跨部门冲突。我负责把每个阶段的证据、权限与停止条件连起来。AI 全栈工程师按阶段建设，不因为技术已经实现就自行扩大真实动作。

每一个阶段都要能正常、异常和失败

正常事件证明主流程可以完成，异常事件证明员工知道何时接管，失败事件证明系统能停止并恢复。三类事件没有走通，就不扩大用户和权限。

路线图还要写清人员退出、资料中断、成本过高和客户事故时怎么办。等待、缩小、转人工或停止，都是合法路径，不是项目失败后才临时想的补救。

云枢科技的十二周路线并不是十二周功能表

阶段	我们要证明的经营状态	必须拿到的证据	不能进入下一阶段的情况	失败后的动作
第 1—4 周：诊断与目标设计	团队能用同一组事实重复说明问题	CEO 授权、20 笔订单样本、修订基线、断点和灯塔边界经负责人确认	关键断点只能靠部门意见说明，或客户资料用途仍不清	缩小资料和流程范围，继续诊断
第 5—8 周：历史订单验收	AI 能整理来源、显示缺失和冲突，并在不确定时停下	正常、顺利、延期、主体冲突、权限不足和系统失败用例通过	高风险遗漏、把未知写成已确认、来源无法追溯	修改任务说明；关键边界仍失败则停止进入真实订单
第 9—12 周：受控真实试用	九名首批用户在新订单中实际使用并会接管	使用记录、人工更正、退回原因、风险错误和每周现场走查	长期双录、负责人不作决定、越权或对客误发	保持只读、减少用户、恢复旧流程或暂停
第 4—6 月：稳定与经营观察	新方式不依赖 FDE 盯场，并开始出现可解释的过程和结果变化	采用稳定、异常有人接管、范围返工和等待对照、成本与事故记录	只有展示次数增加，经营记录没有改变	不扩大价值流和权限，重新判断是否值得继续

日期仍然保留，因为公司需要安排人员和预算；但每一行真正控制推进的是证据。第八周历史用例没有通过，真实试用就顺延，而不是把失败案例移出验收集。

我把资源冲突也放进路线图

第一版路线图里，销售负责人、交付负责人和数据负责人在多个阶段都被写成“参与”。这三个字没有说明他们究竟要花多少时间，也没有说明谁能代替。

经营层最后确认：销售与交付负责人每周参加一次决定会，并在两个工作日内处理升级；数据负责人前八周优先解决客户主体、来源和权限，不同时承担经营问答助手；九名首批用户每周各提供一到两笔真实订单，不要求额外维护一套完整记录。任何一位共同负责人连续两周无法履责，灯塔不扩大范围。

这项约束让六个月路线也发生变化。原计划第四个月同时启动员工知识助手和客户成功流程，复核后改为先看灯塔是否形成可复用的资料责任、身份权限和事件记录，再决定第二条价值流。所谓“规模化”不能只是同时启动更多项目。

我怎样复核路线图仍然可信

每两到四周，经营层只看四件事：已经获得什么业务证据，哪些假设被推翻，当前投入和风险如何，下一阶段要增加什么权限与资源。

如果汇报只剩功能完成百分比，说明路线图又变回技术项目计划。公司购买的是经营状态改变，不是更多页面和模型。

复核时我还要求把“已经看到”和“仍要等待”分开。资料缺失更早暴露、员工开始接管，是十二周内可以观察的过程变化；项目毛利、验收和尾款是否改善，要等足够多的新订单走完整个周期。虚构教学案例也不能把预期写成已经发生的客户成果。

这份填写后的条件式路线已经装入 云枢科技诊断证据包。但路线图本身不能调人、开放资料或指定负责人。第 2 卷最后一步，是让经营层对范围、资源、权限、停止条件和下一次复核作出可追责的决定：我怎样让经营层真正作出决定。