「这个订单现在到哪一步了」——这个问题如果需要打三通电话才能回答，说明履约过程是不可见的。
订单履约横跨销售、计划、采购、生产、物流，是最容易断链的一段。这篇讲怎么把它串起来。
先画出真实的流转路径
不是画理想流程图，是记录实际发生的路径。方法很简单：随机抽三到五个已完成的订单，逐一回溯它经过了哪些环节、每个环节由谁处理、在哪里等待。
你大概率会发现几件事：
- 实际路径和流程文件对不上
- 有些环节的等待时间远超处理时间
- 同类订单走了不同的路径，取决于经手人
这三点本身就是改进清单。
定义状态，而不是堆信息
可视化的核心是状态定义，不是把所有信息都显示出来。一个订单在任意时刻应该能落到唯一一个明确状态上。
一组常见的状态划分：
- 已接单，待评审
- 已评审，待排产
- 已排产，待物料
- 生产中
- 已完工，待检验
- 已入库，待发运
- 已发运
关键是每个状态之间要有明确的触发条件和责任人。状态之间含糊，看板上就会大量堆积在「进行中」。
把等待时间显示出来
多数看板只显示当前状态，不显示「在这个状态待了多久」。但延期恰恰产生于等待，不是产生于加工。
建议至少显示两个时间：在当前状态的停留时长，以及距离承诺交期的剩余天数。这两个数一放上去，异常订单会自己浮出来，不需要人去找。
异常要有出口
看到异常不等于解决异常。可视化系统必须配一套处理规则，否则红灯亮着没人管，很快就没人看了。
最小规则集：
- 什么条件算异常（停留超过 N 天、剩余天数低于生产周期）
- 异常出现后通知谁
- 多久内必须给出处理结论
- 处理结论记在哪
从哪里开始
不要一次覆盖所有订单类型。建议先选一类：批量最大、流程最标准的那一类。它的路径最清晰，最容易跑通，跑通后再往复杂订单扩。
先做到这三件事，就已经能解决大部分「订单在哪」的问题：
- 每个订单有唯一明确的状态
- 每个状态显示停留时长
- 异常有明确的通知与响应规则
至于更精细的产能仿真、智能排程，那是后面的事。顺序反了，前面的基础不牢，后面的模型算出来也没人信。