如何改进业务流程
如何改进业务流程：先为现状建立基线，找出原因而不是症状，一次只改一件事，并在结案之前验证这次改动确实起了作用。
运作方式
为流程当前的样子建立基线
和实际执行这项工作的人一起绘制现状流程，把例外情况和变通做法都包括进去，并记录一两个指标：周期时间、返工率、每条分支上的业务量。没有一条大家认可的基线，日后任何关于改进的说法都可能被质疑，而且一定会被质疑。
陈述问题时不要把原因写进去
“发票付款延迟”是一个问题。“审批人慢”是一个穿着问题外衣的理论，任何从这里出发的分析都会止步于这里。用观察结果和指标来写这份陈述，然后让证据来说明涉及的是谁或是什么。
遏制，并把它记录为遏制
在问题正在造成实际损害的地方，先把它止住——但要把它登记为一项临时措施，写明责任人和结束日期。悄悄留在原地的遏制会变成一个永久的额外步骤，同时还消解了去寻找真正原因的压力。
找出一个有证据支持的原因
趁数据还在的时候收集，重建事件经过，提出不止一个假设并加以检验。停在第一个说得通的解释上，是最常见的一种失败，这也是示例里的验证决策会回到循环、而不是继续往下走的原因。
只改一件事
挑出针对该原因的最小改动，定义什么算成功、到什么时候算，并且单独实施。打包在一起的改动会让归因变得不可能：指标动了，您不知道该保留哪一次改动；指标没动，您不知道该回退哪一次。
在约定期限之后验证，然后更新流程图
等到跑过足够多的周期、能看出信号时再回来，与基线做比较。如果奏效了，就更新流程图及其获批版本，让新的做法成为有文档记录的做法。如果没有奏效，就重新打开分析，而不是在第一次改动之上再叠加第二次。
常见问题
我该如何着手改进一个业务流程？
和实际做这件事的人一起，把当前实际发生的情况画出来，例外情况也包括在内。几乎每一个停滞下来的改进项目，都是因为它从一个假想的流程出发，而不是从有文档记录的流程出发，而假想的版本永远都是顺利路径。一旦现状存在并且大家认可，问题往往会自己浮现——无人负责的步骤、返工循环，以及接收方没有被通知到的交接，在纸面上都看得见。
症状和根本原因有什么区别？
症状是您观察到的现象：发票付晚了、工单被重开、交付被遗漏。根本原因是您可以移除、从而让症状无法再次发生的那个东西。改进工作在处理症状时会失败，因为由此产生的改动——再加一个审批人、再加一份检查表——只增加成本，却触及不到机制。检验是否为根本原因的标准是：移除它是否本可以避免这个问题，以及证据是支持这一点，还是仅仅不排斥它。
改进流程一定要用精益或六西格玛吗？
不必，尽管两者都提供了有用的术语。真正起作用的机制不依赖任何方法论：把当前流程记录下来，测量一些东西，找出一个有证据支持的原因，一次只改一件事，然后验证。正式的项目体系带来严谨性和共同语言，规模大时确实有帮助；它们也带来管理成本，对单个流程而言这笔成本可能超过其价值。先从这个顺序开始，如果改进工作的体量值得，再引入框架。
怎样让一次改进持续下去？
更新有文档记录的流程及其获批版本，告知受影响的人，并在一个季度之后再检查一次。只活在项目报告里的改动，几个月内就会退回原样，因为有文档记录的流程仍然描述着旧做法，新同事也是照着它接受培训的。改进不是在改动做完时就结束；它是在流程图、培训和实际做法三者说法一致时才结束。