如何识别流程中的瓶颈
如何识别流程瓶颈：绘制整条流程，找出工作排队堆积的位置而不是人员忙碌的位置，并把真正的约束与返工、等待区分开。内附实时示例。
瓶颈就是工作到达速度快于其离开速度的那一个步骤。要找到它，靠的是寻找队列而不是寻找忙碌的人，并把真正的约束与返工区分开。
简而言之
- 瓶颈在队列所在之处，而不在最忙的人所在之处。
- 任一时刻只有一个约束；解决了它，约束就会转移到别处。
- 返工循环看起来像产能问题，其实不是——它们是质量问题。
- 等待外部方是一种可以据以排期、却无法靠增加人手绕开的瓶颈。
- 衡量某个步骤前面的队列，而不是执行该步骤的人的利用率。
忙碌不等于受约束
问一个团队瓶颈在哪里，得到的答案通常是谁最忙。这是一个合理的猜测，而且往往是错的。瓶颈是流程的结构属性：工作到达速度快于其离开速度的那一个步骤，于是它前面形成队列，而下游的一切都在闲置等待。忙碌是散布在各处的；约束在任一时刻都只存在于一个确切的位置。
可靠的找法是去找队列。事项在哪里堆积？系统中最陈旧的工作停在哪里？人们把哪个步骤描述成“一直在等的那一步”？流程图之所以能让这些问题有答案，是因为它一次性呈现整条流程，而且能区分三样在单个团队内部看起来完全相同的东西：真正的产能约束、把同一件事项来回送两遍的返工循环，以及对流程之外某个人的等待。
下面的示例是一个退货流程，它在这一点上格外诚实。货物到达的速度快于检验的速度，检验分出四条路径，而其中一半路径又汇回同一个补偿决策。逐步走一遍，看看工作会在哪里积聚。
流程会在哪里堵住
一个从申请到退款的退货流程。留意哪些步骤的工作流入快于流出。
保护队列的那道闸门
在签发 RMA 之前进行的退货政策核对。这类闸门看起来像官僚手续，实则承重：凡是通过这一点的，都会变成下游约束的工作量，所以一道松垮的闸门就是伪装过的产能问题。
所有环节都在等的那一步
货物持续到达，而检验是一个有四种可能结果的单一步骤。这正是约束的典型形态：到达率高、只有一条入口、过程中需要专业判断。如果退货处理很慢，在给其他任何地方加人之前，先看这里。
三个看起来像业务量的循环
有缺陷的物品分流到维修或报废的决策，未发现故障的退回给客户，可再销售的重新入库。每一条都是先前某个决策制造出来的额外工作——把它们分别绘制出来，正是区分产能问题与质量问题的办法。
末端的汇合
所有路径最终都落到同一个补偿决策上，然后是同一个通知客户的步骤。汇合点是次生瓶颈：它们继承了每一条汇入分支的到达率，而当各条分支被单独审视时，这一点很容易被漏掉。
运作方式
先绘制整条流程，再去测量任何东西
只看一个团队的步骤是找不到约束的，因为它前面的队列按定义属于别人的问题。先用泳道画出端到端的流程；在收集到任何数据之前，形态本身通常已经提示了答案。
找出队列
对每个步骤都问：前面有多少事项在等，其中最早的一件已经等了多久。这两个数字识别约束的速度快过任何计时练习，而且通常可以从已经在跟踪这些工作的系统里直接取出。
把返工与吞吐量分开
沿着图中的每一个循环走一遍。一件事项走两遍就会占用约束两次，所以百分之二十的返工率就是砍掉百分之二十的产能。这是穿着产能外衣的质量问题，给受约束的步骤加人并不能解决它。
标出您无法控制的等待
等待客户、供应商或承运商的时间是真实的日历时间，却不是人手问题。把这些步骤放进它们自己的泳道，讨论时才能把可以排期绕开的和真正能改变的区分开。
检查汇合点
几条分支汇入同一个步骤时，该步骤就继承了它们全部的到达率。这类地方经常被漏掉，因为每条分支单独看都还应付得来。流程图能让汇合显形，而按团队出的报表做不到。
先修复，再重新绘制
缓解一个约束，必然把它推到别处。在收拾完第一个瓶颈之前就要为第二个做准备：改动之后重新走一遍流程图，并预期队列会重新出现在下一个需要判断的步骤上。
应避免的错误
衡量利用率而不是队列
一个忙碌的团队可能只是为高业务量配足了人手。步骤前面的队列才是信号；人们干得多辛苦不是。
把返工当成需求
为吸收返工而增加产能既昂贵又是永久性的。弄清楚物品为什么会退回来更便宜，通常也更快。
优化非约束步骤
让一个本来就有余力的步骤更快，除了在约束处堆出更长的队列之外，什么也产生不了。
相信第一个答案
人们抱怨的那个步骤，是他们看得见的那个。约束往往在抱怨的上游一步，悄无声息地设定着到达率。
找出你们自己的瓶颈
把退货示例作为您自己的图表打开，用你们的步骤替换掉里面的步骤，并记下每个步骤前面的队列。
相关指南
常见问题
什么是流程瓶颈？
它是流程中工作到达速度快于其离开速度的那一个步骤，于是它前面形成队列，而下游每一个步骤都在低于产能地运行、等待。任何流程在任一时刻都只有一个约束，这正是瓶颈分析比笼统的效率工作更有用的原因：改进其他任何地方，都不会改变整体速率。缓解了它，约束就会转移，通常转移到下一个需要判断而非单纯执行的步骤。
我该怎么找出流程中的瓶颈？
去看工作在哪里等待，而不是人在哪里忙碌。两个问题就能找到它：每个步骤前面排着多少事项，其中最早的一件已经放了多久。流程图正是让这两个问题能够端到端被回答的东西，因为受约束步骤前面的队列，通常压在与拥有该步骤的团队完全不同的另一个团队身上。相比之下，利用率数字在哪里看起来都差不多。
瓶颈和延误是一回事吗？
不是，把两者混为一谈会让改进工作走错地方。瓶颈是产能约束——工作到达快于离开。延误还可能是等待外部方、把事项攒到周五再处理的批量规则，或者接收方没有被通知到的交接。这些要靠改变触发条件或排期来解决，而不是靠增加产能，而能把它们区分开的正是流程图。
找到瓶颈之后我该做什么？
按这个顺序：先停止把本不该进来的工作喂给它，因为一道松垮的入口闸门是最便宜的修复；然后清除返工循环，因为一件事项走两遍就会占用约束两次；接着把不需要它那种专业判断的工作从它身上拿走。增加产能放在最后，因为它是最昂贵的选项，而且约束只会在下一个需要做决定的步骤上重新出现。
