先看一个例子。

一家公司每天通过营销获得100条线索，销售把其中50条转成订单，但交付团队每天最多只能完成10个订单。

这家公司每天最多能完成多少个订单？

不是100个，也不是50个，而是10个。前提是订单充足，流程能够稳定运行。

老板一着急，开始抓执行、搞培训。营销拿到200条线索，销售转化100个订单，大家都在加班，汇报PPT上的数字也越来越漂亮。

可交付能力没有变。每天仍然只能完成10个订单。

多出来的订单不断积压，等待时间越来越长。催单、插单和投诉接踵而来，交付团队越忙越乱。

再给营销加人呢？

每天的线索增加到300条，最终还是只能交付10个订单。局部数字越来越好，整体结果纹丝不动。

问题不是大家不够努力，而是力气用错了地方。

再看一个经典故事。

一支童子军队伍远行，有个叫赫比（Herbie）的孩子走得最慢。走得快的人不断停下来等他，落在后面的人又要拼命追赶。队伍被越拉越长，全队始终快不起来。

骂赫比走快点没有用，催前面的人走得更快也没有用。他们本来就比赫比快，走得再快，最后还是要等。

真正有效的办法，是替赫比分担一部分背包。赫比走快以后，全队共同前进的速度也提高了。

这个故事来自高德拉特与杰夫·科克斯合著的商业小说《目标》，最早出版于1984年。它说明了串联流程的一个基本特点：只要各环节必须依次完成，整个流程的产出上限就会受到某个必要环节的处理能力限制。

现实中的瓶颈，未必像赫比那样显眼。

拿财务审批来说。项目里不管多大一笔费用，都要一层层往上走。有时连0.56元的微信认证费用，也要排队进入老板的审批窗口。

这时候，项目推进得有多快，不再取决于下面的人做得多快，而取决于老板一天能审批多少单。大家都准备好了，只差最后一个签字，整个项目就只能停在那里。

写作也是一样。

你写不出东西，可能会怪自己文笔不好、打字太慢。但写作也有流程：收集材料、形成判断、搭建结构、完成初稿、修改。

如果材料已经积累了很多，却迟迟没有形成核心判断，那么真正卡住写作的就不是文笔，而是"形成判断"这一步。

这些场景说的是同一件事：产出上不去，不一定是所有环节都不够好。真正限制整体结果的，通常只是一个主要瓶颈，或者少数几个共同约束。

这就是瓶颈效应。

在给定目标和条件下，系统的产出上限会受到一个或少数关键约束的限制。继续优化其他环节，整体结果通常不会明显改善。只有提高瓶颈的有效处理能力，或者解除相应限制，系统的上限才可能提高。

任何系统的产出，都受制于它最窄的地方。流水线也好、团队研发也好、审批流程也好，还是你个人的生活也好，整体的总吞吐量都只由一个环节决定，那就是最慢的那个环节。在非瓶颈上使劲，越努力，积压可能越多。

所以，先别急着优化全流程。

方向错了，越努力，积压可能越多。

在环节相互依赖的串联流程中，最终产出不是各环节处理量的简单相加，而是受到当前瓶颈的限制。

瓶颈就像高速公路上最窄的一段车道。其他路段修得再宽，车流到了这里仍然要减速。只有拓宽最窄的路段，整条路的通行能力才可能提高。等它被拓宽以后，另一段道路又可能成为新的瓶颈。

这里需要分清"瓶颈"和"系统约束"。

瓶颈通常指流程中处理能力不足的环节，比如设备太慢、人手不足，或者任务处理速度跟不上。

这里说的不是理论能力，而是有效能力。比如一台设备标称每天能处理100件，但扣除等待、停机、返工和质量损失，实际可能只能完成60件。真正影响系统运行的是后面的60件。

系统约束的范围更广。除了处理能力，它还可能来自规则、授权、信息、资金或市场需求。瓶颈是系统约束的一种，也是最常见的。

面对这些限制，可以先问：

如果单独调整一个环节没有效果，还要继续检查是否存在共同约束。

瓶颈与木桶原理也不一样。

木桶原理寻找的是最弱的一项，瓶颈模型寻找的是当前真正限制目标的一项。某个环节即使能力较弱，只要有替代方案或备用能力，它可能是短板，却未必是瓶颈。

回到开头的例子。

交付每天只能完成10个订单。新增线索会滞留在销售端，已经转化的订单则积压在交付端。等待时间越长，催单、插单和投诉就越多。

如果非瓶颈环节继续向下游释放超过瓶颈能力的任务，积压就会增加，交付时间也会拉长。

这就是局部优化带来的假象：每个部门的数据都在增长，系统真正完成的产出却没有变化。

超过下游处理能力的局部产出，会变成在制任务，也就是已经进入流程、尚未完成交付的订单和工作。它们占用资金和注意力。拖得太久，订单可能取消，信息也可能失效。

瓶颈也不是固定不变的。

假设公司把交付能力从每天10个提高到120个。交付不再是瓶颈，但销售每天最多只能转化100个订单。系统的产出上限提高到了100个，销售成了新的瓶颈。

任务类型、任务数量和处理方式变化时，各环节的相对能力也会变化，瓶颈就可能转移。改善不是一次修补，而是一个不断重复的过程。

高德拉特把这个过程概括为五步：识别约束，充分利用约束，让其他活动服从约束，提升约束，然后重新检查，防止原来的管理习惯变成新的限制。

别急，这个道理用数字看最直白。

一条生产线有A、B、C、D四道工序，每天工作420分钟。假设每道工序只有一台设备，所有产品都必须依次经过这四道工序，暂时不考虑停机和返工。

四道工序加工一件产品，分别需要4分钟、7分钟、10分钟和5分钟。

算下来：

- A每天能做105件；

- B每天能做60件；

- C每天能做42件；

- D每天能做84件。

C每天只能完成42件，是整条生产线的瓶颈。因此，生产线每天最多完成42件。

现在把B的加工时间从7分钟降到5分钟。B的能力从每天60件提高到了84件，但整条生产线仍然只能完成42件，因为C没有变化。改善非瓶颈，不改变产出上限。回到现实：你团队里那个最慢的环节，就是你的C工序。

如果给C增加一套同样的并行设备，C的能力从42件提高到84件。整条生产线每天最多能完成60件，B接过了瓶颈的位置。

约束理论有没有实际效果？

Mabin和Balderstone整理过已发表的约束理论应用案例，其中不少组织报告了交付周期缩短、库存减少和财务指标改善。不过，这些样本主要来自已经发表的制造业成功案例，不能把它们理解成使用约束理论后的普遍保证。

瓶颈还经常和延迟一起出现。延迟效应关心"结果什么时候出现"，瓶颈效应关心"当前哪里限制结果"。延迟会让瓶颈信号晚一些暴露，也会让改善效果晚一些出现。判断得太早，可能找错瓶颈，也可能把有效措施误判为无效。

找瓶颈，是不是只要找处理速度最慢的环节？

没那么简单。

一个工位加工单件产品的时间最长，但它只处理少数产品，还有多台并行设备，平时并不繁忙。另一个工位虽然单件速度更快，却是所有产品的必经之路，任务长期排满。

前一个工位更慢，后一个工位却更可能成为瓶颈。

忙也不是可靠标准。

利用率只能说明一个环节有多忙，不能说明它是否限制了整体结果。一个利用率达到90%的环节，如果增加它的能力以后，系统产出仍然不变，它就不是当前唯一的瓶颈。

排队最长的地方也未必是瓶颈。

批量释放任务、返工、优先级调整，都可能制造长队。反过来，现场没有长队，也不能证明没有瓶颈。预约制或按需处理的流程，可能把等待藏到系统外部。

还要小心名义能力。

一台设备名义上每天能处理100件，但换型、维修、良率损失和协作等待都会占用时间。扣除这些损失，实际能力可能只有60件。如果计划仍然按100件安排，瓶颈就藏在两者之间的差值里。

最容易出问题的，是把某个人称为"瓶颈员工"。

某个人工作慢，不等于问题出在他本人。可能是任务太多，可能是缺少工具和授权，也可能是流程要求他等待别人。

瓶颈分析诊断的是角色和流程，不是人格。

判断瓶颈时，最值得问的问题是：

如果会，它很可能是瓶颈或共同约束之一。

如果没有改善，不能立刻排除它。还要检查是否存在另一个共同约束，改善幅度是否足够，或者观察时间是否太短。

比如销售和交付每天都只能处理10个订单。

单独把销售提高到12个，系统仍然只能交付10个；单独把交付提高到12个，销售也只能提供10个订单。

两个环节同时卡在10个。单点调整无效，不代表它们都不是约束，而是需要联合调整，或者先把其中一个提高到足以越过共同限制的程度。

遇到"每个环节都在优化，整体产出却不动"时，可以按五步处理。这五步构成一个循环：前三步是诊断和利用，后两步是投入和复测。不是做完一次就结束，而是反复循环。

第一步，定目标和边界

目标不同，瓶颈也可能不同。

做用户增长，如果目标是增加新用户，限制可能出现在投放和获客；如果目标是提高活跃用户数，问题可能出在留存。

目标没有说清楚，所谓的"瓶颈"就只能靠猜。

同时要明确哪些条件不能牺牲。安全、合规和质量底线不是等待消灭的障碍，而是必须保留的边界。

第二步，找瓶颈

先问：减少哪个限制，最可能改善整体结果？

可以查看历史数据，也可以通过模拟或小规模试验验证。小幅提高一个疑似瓶颈的能力，观察整体产出、等待时间和积压是否变化，再与改善其他环节时的结果比较。

分析不用等到百分之百确定。

只要证据足以说明某个因素正在持续限制目标，而且已经找到一个成本可控、结果可观察的改善动作，就可以先做小范围尝试。

容量型瓶颈通常会留下两个信号：它前面长期积压任务，它本身很少空闲。

调整以后再看验证结果：它的有效能力提高后，整体指标是否随之改善。

如果约束来自规则或授权，"是否空闲"就没有多少意义。重点要看规则放宽以后，整个流程是不是真的变快了。

第三步，先把现有能力用足

找到瓶颈后，不要马上增加人手或设备。先清理瓶颈上的等待、停机、返工、中断和无效占用。

控制任务释放节奏也很关键。交付每天只能完成10个订单，销售就不能把100个订单都承诺为当天或短期交付，而应按照实际能力安排交付时间。线索可以继续进入培育池或预约名单，但真正释放给交付团队的订单量，要和交付节奏相匹配。

非瓶颈环节不必追求随时满负荷。它首先要保证瓶颈得到稳定、合格的输入，而不是不断制造新的积压。

第四步，必要时提升瓶颈

现有能力被充分利用以后，如果瓶颈仍然限制整体结果，再考虑增加人手、设备或替代路径。

扩容需要花钱，也需要时间。投入之前，重新确认瓶颈的位置没有因为需求、任务结构或流程变化而转移。

第五步，复测

改善以后，重新测量实际产出、交付周期、积压数量和质量。

如果整体指标改善了，说明方向正确。接下来还要检查新的约束出现在哪里，然后重新开始下一轮。

每轮分析结束时，可以留下一张诊断卡：

这张卡让所有人看到同一套判断，也给下一轮复盘留下依据。

把资源优先用在瓶颈上，更可能改善整体结果。非瓶颈即使有余量，也不等于有人在偷懒。余量可以用来支持瓶颈、处理波动、维护质量，为下一轮改善做准备。

不一定。

前文讨论的主要目标，是提高单位时间内真正完成的产出。质量、成本、安全、抵抗波动的能力以及未来能力同样需要改善，只是它们未必直接提高眼前的产出上限。

有些限制本来就不该取消。

机场安检会降低旅客通过速度，但它保护的是安全。代码评审可能拖慢发布，却能提前发现重要缺陷。

只有当这些控制环节的处理能力持续限制目标流量时，它们才同时构成瓶颈。此时应该提高准确性和处理效率，而不是简单取消。

时间也会改变判断。

今天的瓶颈，下个月可能已经转移。一次活动带来的临时拥堵，也不一定值得增加长期固定产能。更稳妥的办法是先用预约、临时资源和优先级应对，再观察它是否会持续出现。

需求不足时，系统内部可能没有正在限制产出的容量瓶颈。

如果市场每天只有5个订单，交付能力即使有10个，也不是当前限制。继续扩大交付能力没有意义，真正卡住结果的是需求。

多个共同约束出现时，不能执着于寻找唯一瓶颈。可能需要联合调整，系统结果才会变化。

波动同样会制造等待。

即使平均处理能力足够，任务耗时忽长忽短、返工增加或者任务随机到达，仍然可能形成队列。这时除了找瓶颈，还要管理任务进入的节奏，并在瓶颈前保留适量缓冲。缓冲太少，瓶颈可能无事可做；太多，又形成新的积压。

还要区分瓶颈和杠杆点。

杠杆点是只需较小改变，就可能引发较大系统变化的位置。瓶颈通常是提高当前产出的优先候选，但不一定是最佳干预位置。有时修改规则、重建信息流或改变目标，比直接扩充瓶颈更有效。