如何改进业务流程
如何改进业务流程：先为现状建立基线，找出原因而不是症状，一次只改一件事，并在结案之前验证这次改动确实起了作用。
改进业务流程，意味着为当前实际发生的情况建立基线，找出问题的原因而不是它的症状，一次只改一件事，并验证这次改动是否真的起了作用。
简而言之
- 先为现状建立基线——面对一个谁都没有认可过的流程，您无法证明有所改进。
- 遏制只是止血；它不是解决办法，而且应当单独记录。
- 一次只改一件事，否则您不会知道是哪一次改动起了作用。
- 在约定的期限之后验证成效，用的是您一开始采用的那个指标。
- 去掉一个步骤是改进。增加一个审批人通常不是。
多数改进都败在诊断这一步
流程改进有一种众所周知的失败模式，而它与懒惰无关。它是从症状出发做诊断：发票付晚了，于是加一个审批人；工单被重开了，于是加一份检查表。每一种都是对某个观察结果的合理反应，但都没有落在事情为什么会发生上。半年之后，指标纹丝不动，流程里却多了一个步骤——这才是跳过诊断所累积起来的真实代价。
替代做法不是为分析而分析。它是一个特定的顺序：把当前实际发生的情况描述到足以拿来争论的细致程度；在不假装遏制就是解决办法的前提下遏制眼前的损害；找出一个有证据支持的原因；只改一件事；然后在宣布完成之前检查它是否奏效。最后这一步是最常被省掉的，也是唯一能把改进与瞎忙区分开的一步。
下面的示例是一个根本原因分析流程，它是任何改进工作底下的诊断引擎。它包含两条让它保持诚实的路径：一条证据不足的分支，可以带着有记录的局限性结案，而不是编造一个原因；以及一个验证循环，会把未经证实的假设送回去重新分析。
改进底下的那次诊断
一个从问题提出到纠正措施获批的根本原因分析流程。留意团队通常在哪里抄近路。
先定义问题，再提出理论
按观察到的样子描述，就一份书面的问题陈述达成一致，实施遏制，然后再组建调查团队。在有人已经形成理论之后才写的问题陈述，往往会把那个理论写进去，接下来的分析也就只是印证它。
证据，以及没有证据时的那条分支
一个有三条出路的充分性决策：继续、扩大收集范围，或者带着有记录的数据局限性结案。正是第三条路，阻止了一次调查在日志早已轮替之后编造出一个原因。
检验假设，而不是随手挑一个
提出原因假设，用证据加以检验，在原因未获证实时回到循环里。然后把根本原因与促成因素分开——这是一个独立的步骤，因为团队否则就会针对最容易修复的那个因素去写措施。
获批并有资源保障的措施
记录调查结论，提出措施，一次可以把措施退回的审批，最后生成一条指定了责任人的 CAPA 记录。改进正是死在措施已经谈妥、却没有人为所需时间买单的那一点上——这也是审批被画成一道闸门的原因。
运作方式
为流程当前的样子建立基线
和实际执行这项工作的人一起绘制现状流程，把例外情况和变通做法都包括进去，并记录一两个指标：周期时间、返工率、每条分支上的业务量。没有一条大家认可的基线，日后任何关于改进的说法都可能被质疑，而且一定会被质疑。
陈述问题时不要把原因写进去
“发票付款延迟”是一个问题。“审批人慢”是一个穿着问题外衣的理论，任何从这里出发的分析都会止步于这里。用观察结果和指标来写这份陈述，然后让证据来说明涉及的是谁或是什么。
遏制，并把它记录为遏制
在问题正在造成实际损害的地方，先把它止住——但要把它登记为一项临时措施，写明责任人和结束日期。悄悄留在原地的遏制会变成一个永久的额外步骤，同时还消解了去寻找真正原因的压力。
找出一个有证据支持的原因
趁数据还在的时候收集，重建事件经过，提出不止一个假设并加以检验。停在第一个说得通的解释上，是最常见的一种失败，这也是示例里的验证决策会回到循环、而不是继续往下走的原因。
只改一件事
挑出针对该原因的最小改动，定义什么算成功、到什么时候算，并且单独实施。打包在一起的改动会让归因变得不可能：指标动了，您不知道该保留哪一次改动；指标没动，您不知道该回退哪一次。
在约定期限之后验证，然后更新流程图
等到跑过足够多的周期、能看出信号时再回来，与基线做比较。如果奏效了，就更新流程图及其获批版本，让新的做法成为有文档记录的做法。如果没有奏效，就重新打开分析，而不是在第一次改动之上再叠加第二次。
应避免的错误
没有基线就做改进
没有一份获得认可的现状，就没有办法证明这次改动有帮助——也没有办法察觉它其实没有帮助。
把增加审批人当成解决办法
这是最顺手的反应，它可靠地让流程变慢，却完全没有触及错误为什么会发生。多数真正的改进是去掉一个步骤。
把多项改动打包在一起
一次改五项，只会得到一个含糊的结果。把它们排成先后顺序，哪怕这让人觉得慢。
从不验证
没有人检查过的改进，只是一个附了项目计划的假设。验证这一步，正是改进与瞎忙之间的分界。
改进你们自己的流程
把根本原因分析示例作为您自己的图表打开，或者先绘制你们的现状流程，再从那里往下做。
相关指南
常见问题
我该如何着手改进一个业务流程？
和实际做这件事的人一起，把当前实际发生的情况画出来，例外情况也包括在内。几乎每一个停滞下来的改进项目，都是因为它从一个假想的流程出发，而不是从有文档记录的流程出发，而假想的版本永远都是顺利路径。一旦现状存在并且大家认可，问题往往会自己浮现——无人负责的步骤、返工循环，以及接收方没有被通知到的交接，在纸面上都看得见。
症状和根本原因有什么区别？
症状是您观察到的现象：发票付晚了、工单被重开、交付被遗漏。根本原因是您可以移除、从而让症状无法再次发生的那个东西。改进工作在处理症状时会失败，因为由此产生的改动——再加一个审批人、再加一份检查表——只增加成本，却触及不到机制。检验是否为根本原因的标准是：移除它是否本可以避免这个问题，以及证据是支持这一点，还是仅仅不排斥它。
改进流程一定要用精益或六西格玛吗？
不必，尽管两者都提供了有用的术语。真正起作用的机制不依赖任何方法论：把当前流程记录下来，测量一些东西，找出一个有证据支持的原因，一次只改一件事，然后验证。正式的项目体系带来严谨性和共同语言，规模大时确实有帮助；它们也带来管理成本，对单个流程而言这笔成本可能超过其价值。先从这个顺序开始，如果改进工作的体量值得，再引入框架。
怎样让一次改进持续下去？
更新有文档记录的流程及其获批版本，告知受影响的人，并在一个季度之后再检查一次。只活在项目报告里的改动，几个月内就会退回原样，因为有文档记录的流程仍然描述着旧做法，新同事也是照着它接受培训的。改进不是在改动做完时就结束；它是在流程图、培训和实际做法三者说法一致时才结束。