项目刚启动时，诊断通常这样安排：各部门负责人轮流到会议室，讲一遍自己这块怎么走，实施顾问记在白板上，两三天下来画出一张挺整齐的流程图。问题是，这张图往往是流程应该长什么样，不是它实际长什么样。
真正卡住上线的，多半在那些没被讲出来的地方：一张单子在系统里走完，还要在微信群里补一句；一个数字要先从另一张表里抄过来；某个环节只有一个人知道怎么改。这些不会出现在汇报里。
一、跟着单据走，比听汇报省事
挑一两张最近真实发生过的单据，从发起到归档，一路跟下去。采购就从申请到入库到发票，生产就从订单到领料到完工入库。不预设它该经过哪几步，看到什么记什么。
重点留意三类动作：哪里需要手工再抄一遍，哪里要等一个不在系统里的确认，哪里事后补录。这三处基本就是后面蓝图和接口要处理的地方。
一张单跟下来，比开两场会得到的有效信息多。因为单据不会替谁修饰，它到哪一步停了、被谁拿走改了，都是发生过的。
二、问操作的人，不只问管的人
部门负责人讲的是规则，一线操作的人讲的是做法。两者不一致的地方，恰恰是要紧的地方。比如制度写着领料必须先开单，现场为了赶工会先拿料、下班前集中补单。听着像违规，其实说明流程设计和现场节奏没对上。
三、别在诊断阶段给方案
现场一说出问题，实施方很容易顺口接一句「这个我们系统能解决」。话一出口，后面访谈就变了味：对方开始按功能清单讲需求，而不是讲实际怎么干活。
诊断阶段该收的是事实：哪几处有断点、断点影响谁、现在靠什么兜着、兜不住的时候会怎样。方案放到蓝图阶段再谈，那时才有足够上下文判断值不值得改、改动牵扯到谁。
四、诊断要交出什么
- 一两张单据的实际流转路径，标出系统外环节与手工环节。
- 口径不一致的地方：同一个数在两处不一样，或者同一个词两边定义不同。
- 现有兜底方式：靠谁、靠哪张表、靠哪个群，以及这个人不在时会怎样。
- 各方最想先解决的一两件事，分开记，不急着合并成一张需求清单。
这份东西不用写得很漂亮，能对着它和对方确认「是不是这样」就够了。确认得越具体，蓝图阶段返工越少。
流程图可以画得很顺，单据不会配合。先看它实际怎么走，再决定系统里该有什么。
