1.6 我怎样跟着一件事走完公司

项目经理老周告诉我，交付延期是因为销售交接资料不完整。销售小林却说，自己已经把客户要求都放进 CRM 了。

如果我分别找两个部门开会，他们都能证明自己做了工作。我决定不讨论谁对谁错，只跟着那笔订单从头走一遍。

我记录的不是部门，而是状态变化

客户最初只是表达兴趣，后来需求被确认，公司给出方案，双方签约，项目启动，客户验收，财务收款。每一次变化都应该有进入条件、负责人和留下的证据。

我问小林：“你说可以交接时，确认了什么？”他回答合同已签。老周却需要客户数据、项目范围和验收人都明确后才能排期。

两个人说的“可以开始”不是同一件事。这就是断点。

我又找了一笔同类型、按时上线的订单。它在合同签署前就确认了客户数据、项目范围和验收人，项目经理也参加了最后一次方案复核。

延期订单和顺利订单经过相同部门，差异不在谁更努力，而在交接状态是否清楚。只看失败订单，我可能会增加更多审批；有了对照，我知道真正要复制的是“承诺前确认交付条件”。

这笔订单从接触到收款用了二百多天，真正准备方案、实施和验收的工作时间只占一部分。更多时间花在等待客户回复、等待内部批准、重新解释需求和补齐资料上。

我把每一步分成三类：正在产生客户需要的结果、为了纠正前面问题而返工、什么也没发生只是等待。

AI 很适合减少整理和等待，但前提是公司先说清楚谁在什么条件下作决定。否则，自动提醒只会让更多人更频繁地催促一个仍然没有负责人解决的问题。

等待也要分开看。等待客户决定可能是正常销售周期，等待内部找不到批准人则是公司断点；等待必要的质量检查可以保护结果，等待重复录入没有价值。

我不会把所有等待都当成浪费，也不会为了缩短周期跳过客户和风险需要的判断。

管理书把客户需求从开始到结果的完整过程叫端到端价值流。白话就是：跟着一件事一直走到真正完成，不因为它换了部门或系统就停止。

画图时，我只保留四类信息：这件事现在是什么状态，谁负责让它进入下一状态，需要什么事实，以及在这里通常等多久或返工几次。

我让 AI 全栈工程师先做一个订单时间线：自动汇总已有记录，但每个状态必须保留来源和确认人。系统可以提示“缺少客户验收人”，不能因为合同已签就推断“已具备交付条件”。

验收时，我会用一笔顺利订单和一笔延期订单，看它能否准确还原两者在哪里走向不同。

销售确认客户目标和承诺，项目负责人确认启动条件，财务说明开票与回款，数据主人说明状态来源，我负责沿订单连接它们。AI 全栈工程师实现的是已经确认的状态与交接，不负责替业务发明“完成”的定义。

系统不可用时，订单仍要有最小人工交接；负责人不在线时要有替补；资料冲突时保持未确认，不能为了让流程继续而猜一个状态。

我请一个没有参加绘制的人，拿新订单沿图判断现在处于什么状态、下一步由谁完成、缺什么事实。如果他仍要问“这个部门平时怎么处理”，说明图只画了名称，没有画工作条件。

真正可用的价值流图，会让团队看见第一个断点和可以观察的结果，而不是把公司画成几十个方框。

我把顺利订单 YS-24-009 和延期订单 YS-24-017 按同一组状态排在一起：

状态	进入下一步需要什么	YS-24-009	YS-24-017
客户目标已确认	问题、决定人和时间要求有来源	已确认	已确认
方案能力已核对	标准与非标准要求被明确区分	非标准接口已标出	售前个人文档写了风险，下游未见
额外工作已决定	工作量、客户条件和价格有人确认	技术确认会完成	没有共同决定
合同条件已确认	范围、责任、验收和付款一致	客户准备事项进入附件	只写“提供所需资料与权限”
项目可以启动	资源与客户条件已经具备	具备	合同签署被当成启动条件
验收与付款完成	客户确认结果并按节点付款	基本按期	验收晚 42 天，尾款晚 49 天

两笔订单第一次明显走向不同，不是在项目执行，而是在非标准接口从“被发现”进入“由谁决定”的位置。

这张对照表进入商业系统图后，下一章的问题自然出现了：售前已经看见风险，为什么没有人必须在对客前作决定？这不是再画一个流程框能回答的，而要看权力、后果和岗位目标：为什么大家都努力，公司仍然卡住。