看板实践：如何限制在制品（WIP）？

有人说看板不就是一个板（物理板或电子板）再加上一些图案吗？ 严格意义上来说，我认为一个合格的看板除了可视化，至少还需要进行在制品限制并建立拉动。换句话说，没有在制品限制的看板是没有“灵魂”的。

那么，在制品的限制到底应该怎么做呢？我们应该如何计算或设置在制品限制的数值呢？

04 在制品限制的实践

05 如何计算WIP的数值

01   为何要限制在制品（WIP）

我们在之前的文章“偷走你时间的第一只“黑手——在制品过多”中探讨了什么是在制品、在制品的不良影响，以及导致在制品过多的原因等。本文中我们不再重复赘述。 （点击图片查看原文）

影响1: 价值延期交付，客户满意度下降

影响2: 内容切换成为常态，影响工作效率

02   在制品（WIP）限制的目标

5）在整体或局部工作流程上建立一个拉动系统

03   在制品（WIP）限制的好处

12）有助于减少或消除三种核心类型的浪费:Muda、Muri、Mura。

04   在制品（WIP）限制的实践

实践1：为个人设置 在制品限额

在制品限制的一种方式是限制每个人同时进行的工作项，如下图，每个人最多的WIP是3个。也就是说，当你手上的三个工作项都受到阻碍无法进行下去时，你无法启动新的工作项，而是要想办法优先解决当前受到阻碍的工作项。

聚焦完成，停止启动！

图片来源：Kanban Maturity Model

基于个人设置WIP在个人看板是比较常见的，但在团队协作的团队看板中，我们更建议采用基于活动限制WIP。

实践2：为活动设置WIP限额

如下图所示，比较常见的做法是基于活动（Activity）进行在制品限制。

• Input Queue（5）
• Analysis（4）
• Unordered Activities（4）
• Build Ready（3）

• Test（2）

图片来源：Kanban Maturity Model

实践3： 跨多个活动的WIP限制

当我们在自组织团队或是一个人同时具备多种技能的时候，同一个人会同时负责开发（Development）和测试（Test）等多项工作。

图片来源：Kanban Maturity Model

在这种情况下，开发完成的工作项卡片仍然会流向测试阶段，但是由于同一个工作项的开发和测试工作均由同一个人完成，此时不存在任何交接或着拉动的行为。因此我们没有必要对单个活动进行WIP限制，推荐的做法是设置跨活动的WIP限制即可。

实践4： 为上游看板设置WIP最小值

在看板方法的设计可以分为上游看板和下游看板。

下游看板（Delivery，交付看板）的目标是尽快并高质量地完成工作项。对于下游看板我们通常只会设置最大的在制品限额。

图片来源：Kanban Maturity Model

而上游看板（Discovery，探索看板）的目标是发现、探索和分析潜在有价值的机会，在这个探索的过程中会丢弃很多没有价值或是不可行的选项。为了保障最终有足够数量的机会/订单留向下游的交付系统，我们可以为上游看板的活动设置最小的在制品限额。

实践5： 按照工作类型设置WIP

在看板成熟度级别比较高的组织，我们可以根据工作类型或服务类别的不同来分配在制品限额。

图片来源：Kanban Maturity Model

如上图所示，所有活动的在制品限制的总额是20。那么，我们可以根据不同的请求量来为不同的工作类型分配容量（WIP）

• 变更请求（Change Request）=12
• 维护工作（Maintenance）=2
• 产品缺陷（Product Defect）=6

05   如何计算在制品（WIP）的数值

在制品限制的数值到底应该怎么计算？这是大家问过最多的问题。WIP的数值没有标准，只有经验主义。推荐的做法是根据经验主义来设置WIP，观察前置时间和系统忙碌情况的变化（通过累积流图）趋势，从而不断地调整WIP以达到最佳的流动效率和前置时间。

在此，我摘录了2本权威书籍对在制品（WIP）数值设置的一些描述，大家可以作为参考。

一种做法是，在最初的时候在制品限额应设置得比较宽松，使在第一次实施拉动系统时，变异性、浪费和瓶颈不会对系统产生重大的影响。

另一派采用的是截然不同的方法，他们建议，不要为了避免阻力而设置过于宽松的在制品限额，相反，每个阶段都应该设有缓冲区，并且应该对每个活动步骤都设置严格的限额。瓶颈与变异性会先通过这些缓冲队列的占用程度自动显现出来，然后，进行微小且简单的调整，减少缓冲区的大小，进而消除不必要的缓冲区。

——《看板方法：科技企业渐进变革成功之道》

A commonly asked question is “how do I calculate the WIP limit?” The answer is often unsatisfactory to many people: at Toyota, the process is empirical— someone makes their best guess and then they adjust from there. David has gone as far as to suggest that in sixteen years of practice and touring the world observing implementations, it is unusual to see a WIP of more than ten, while a WIP of one is rare. So, given this evidence, start with five and adjust from there.

Other methods exist based on policy, such as “one per person plus three blockers”; it may even be possible to use a local implementation of Little’s Law, looking at the local cycle time (which should be Gaussian distributed) and the arrival rate to calculate a WIP limit. However, this assumes that you have some flexibility of staffing levels. Another approach is to start with what you have now and slowly reduce until you start to inflict idle time and other delays on the system’s flow. The best advice is not to get too hung up on WIP limits and recognize that the system can adjust based on feedback.

-- Kanban Maturity Model

注：部分文字和图片来源于网络，如有侵权请联系删除。

——END——