Неограниченные разделы рабочего потока

В вытягивающей системе, связанной с теорией ограничений и известной как «барабан-буфер-канат», WIP-лимит всех рабочих станций после бутылочных горлышек не установлен. Это основано на предположении, что пропускная способность этих рабочих узлов выше, чем у бутылочных горлышек, так что они обладают резервной мощностью, что приводит к простою. Поэтому устанавливать WIP-лимит нет необходимости. Это отражено на рис. 10.2а, который основывается на метафоре, использованной в книге Элияху Голдратта и Джеффа Кокса «Цель: процесс непрерывного улучшения»[7] и показывает скаутский патруль, идущий змейкой. Между ведущим и самым медленным скаутом (четвертый в змейке) натянут канат. Самый медленный в змейке – это и есть бутылочное горлышко в пропускной способности (то есть в темпе хода скаутов). Необходим только один канат, поскольку скауты, идущие вслед за самым медленным из них, никогда от него не отстают, так как могут идти быстрее, чем четвертый в змейке, который снижает темп перемещения всего патруля.

Рис. 10.2. Человечки, иллюстрирующие четыре различных варианта WIP-лимитов в разных вытягивающих системах

В канбан-системе WIP-лимиты предусмотрены для большинства или даже всех рабочих узлов потока. Это является потенциальным преимуществом, поскольку препятствия, возникающие в связи с непредсказуемой вариативностью, могут сделать бутылочным горлышком любой предыдущий этап. Установление WIP-лимита вместе с канбан-системой быстро остановит очередь, так что система не подвергнется засорению и перегрузке. Когда препятствие устранено, система без помех перезапустится. Установление WIP-лимитов по канбану показано на рис. 10.2 г, где канаты связывают цепочку скаутов в соответствии с принципами канбана. В этом случае каждый человечек связан со следующим в цепочке. Чтобы контролировать темп перемещения всего скаутского патруля, требуется пять канатов.

В некоторых случаях в канбан-системе приемлемо отсутствие лимита на следующие этапы процесса. В примере Microsoft XIT было высказано предположение, что пользовательская база, доступная для проведения приемочного тестирования, практически бесконечна и доступна сразу же, поэтому для приемочного тестирования не нужны WIP-лимиты. В Corbis ограничения не касались очереди на подготовку к релизу. Это основывалось на предположении, что очередь на подготовку к релизу никогда не превысит пропускную способность при установленной двухнедельной каденции релиза. А если все же скапливался излишний материал для подготовки релиза, это повышало его сложность, так что координационные и операционные издержки на релиз слишком возрастали и пришлось бы установить WIP-лимиты и на этом этапе. Однако в Corbis такого не случалось, поэтому ограничения для данной фазы не устанавливались.