诊断怎样找到问题
诊断先量再断，把企业的规矩查清写明，才能做成系统里的规则
SZV 做诊断，先量再断：先用单据上的时间量出各环节停了多久，再用访谈解释原因，最后断言症结在管理还是在系统。这一步把企业现有的规矩查清、写明，后面才能做成系统里的规则。流程只有一两个环节、问题已经明确的企业，用不上这套取证。
取证的来源
官网写的是「制度与做法的出入多半源于权责不清」，这是 SZV 的开工假设。「多半」是概率判断，诊断把它当作待检验的说法：先量出时间，再看症结在哪。
单据在某个环节停得久，原因可以是等人签字，也可以是退回重走、规则没写清，或者两套系统要重复录入。时间由单据量出来，原因由访谈判断。
| 取证处 | 能回答 | 回答不了 |
|---|---|---|
| 账目 | 钱从哪里来、花到哪里去，按科目与对手方归类 | 这笔钱谁批的、批了多久 |
| 流程（单据） | 每个环节停了多久、经手人是谁 | 为什么停；并行会签与退回重走会被算错 |
| 一线访谈 | 做事的人怎么做，与制度条文哪里不一致 | 讲述受记忆和立场影响，不能单独定论 |
任何一类取证回答不了的，可以由其余的补。
单据停留统计的读法
单据流转时长统计，按每条事件与同一张单据下一条事件的时间差，算出各环节的停留，再取中位数和九成分位数。这个算法有几处容易读错：
| 读错的地方 | 原因 | 怎样避免 |
|---|---|---|
| 把间隔当等待 | 每个环节只有一个时间戳时，两条事件的间隔里等待和处理分不开 | 需要区分时，要每个环节有开始和完成两个时间，或用访谈估计 |
| 并行会签、退回重走 | 算法假设一张单据一次只走一条线；并行和回退时，时间差不等于某个环节的停留 | 把这类单据单独挑出来，用访谈核对实际走法 |
| 夜里与周末 | 非工作时间的间隔被算进等待，没人上班的时间被读成瓶颈 | 开工时约定非工作时间扣除还是计入 |
| 停得久就是瓶颈 | 停留长只说明单据在那里等；等什么，要由访谈回答 | 先列出停留最长的环节，再逐个问原因 |
看到「某环节中位数最长」时，它只是待查的线索，还不是诊断结论。
诊断交付进入系统
诊断交出企业全貌、改造清单、权责清单。它们是文件，不是系统里的数据。进入规则表、权限和审批链，要经设计阶段，由 SZV 与企业逐项确认。
图里只有设计阶段一道转换，改造清单中属于制度与流程的项不进表。
| 交付物 | 设计阶段从中读出什么 | 进到哪里 |
|---|---|---|
| 权责清单 | 每个事项谁有资格签、谁执行、留痕记在哪 | 审批链的签核位与资格；权限里职位带的能力 |
| 改造清单 | 系统层的项：审批层级压缩要改哪条链，资金口径统一要改哪个口径 | 单型注册表的签核位序列与金额档位；口径定义表 |
| 企业全貌 | 有哪些单据类型、职位、分支、资金口径要登记 | 注册表、职位、口径的候选清单，作核对依据，不直接生成行 |
改造清单按三层排先后：组织与权责，流程与考核，系统。只有第三层的项会走到这张表里；考核指标重定这类项，改的首先是制度文件。
口径定义表的做法见客户资料与统计口径。
进入系统的路径
设计阶段定下初始内容，上线后再改，路径不同：
| 内容 | 上线后怎么改 |
|---|---|
| 规则参数的值，如时限、复核线、开关 | 变更单：提议、检查、批准，由写入入口追加一行，见修改一条规则 |
| 金额档位、审批单型注册表 | 随版本发布追加新行，旧行由触发器拒改拒删；在途单仍按建单时的链走，见审批流转 |
| 判据种类、签核位种类 | 判据的含义在解释器的代码里，新增要发版 |
| 口径定义 | 改口径新增一个版本，旧版本退役，见客户资料与统计口径 |
| 个人授权 | 追加一行，可加可减，每条留痕，见配置一个人的权限 |
| 职位带的能力 | 上线后怎样改，这里不展开，见配置一个人的权限 |
诊断时先问一句：清单里的条件，用的是系统已有的判据，还是需要新增的？前者只追加数据，后者要写代码。哪些判据已有，在设计阶段对照系统逐条确认。
限制与不适用
- 诊断对数据有要求：单据没有带时间的记录时，停留时长量不出来，流程一处的结论只能靠访谈和抽样单据。
- 两周内能做多深，取决于数据到位。
- 流程只有一两个环节、问题已经明确的企业，用不上这套取证。
其他做法
| 做法 | 它解决什么 | 为什么不用 |
|---|---|---|
| 诊断时直接把权责清单逐行转成规则表 | 省掉一轮转换 | 清单只有谁定、谁做、谁担、留痕四列；审批链一行还要金额线、签核位种类、可否代签、时限，这些要对着企业逐项定 |
| 先上系统，边用边理权责 | 早点见到效果，留痕先跑起来 | 规则一旦在系统里，改参数要走变更单，批准前不生效；金额档位要随版本发布。未定稿的争议写进系统，每次改动都付这份成本 |
第二行是官网「系统排在最后」的一个理由。常见的另一种做法是先上线留痕，再从记录里看出管理问题；它的代价是上表所说的变更成本。
与常见做法对照
流程挖掘（process mining）从系统留下的事件记录还原流程。Wikipedia 的条目写明，事件记录要关联到案例编号、活动、时间戳三样；分析分三类：从记录发现流程模型，拿记录与既有模型对照找偏差（一致性检查），分析处理时间等性能。Celonis 的介绍页把瓶颈、偏离、重复步骤列为流程挖掘的用途。
| 问题 | 流程挖掘的通行做法 | SZV 的诊断 | 代价 |
|---|---|---|---|
| 量什么 | 事件记录上的流程变体、偏离、性能 | 单据停留时长，按单据类型和环节分组 | 变体与返工要靠人看单据和访谈发现 |
| 对照制度 | 一致性检查，记录对照流程模型 | 访谈对照表：左列制度条文，右列一线讲述，逐条标一致或不一致 | 人工逐条做，条文多时慢 |
| 一张单据关联多个对象 | OCEL 2.0 让一个事件关联多个对象 | 一张单据一条线统计 | 付款单与合同、发票之间的等待不在统计里 |
一张单据一条线是否够用，取决于企业的单据关联有多重。
验收时可以问的问题
- 请核对诊断结论里，流程一处的依据是带时间的事件记录，还是访谈与抽样单据。
- 请在设计阶段逐条对照：权责清单里的条件，哪些用系统已有的判据，哪些要新增并随版本发布。
- 请核对改造清单里，哪些项属于系统层、会进表，哪些留在制度文件里。