Константный WIP-лимит

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

Если вы используете персональный WIP-лимит - то надо договариваться либо об общем стандарте количества незавершенной работы у сотрудников, либо придумывать персональное значение лимита каждому. Если вы используете ограничение количества незавершенной работы по активностям, то надо договариваться о значении лимита для каждой активности. В свете этого всего, выработка всего одного соглашения об ограничении и договоренность об одном числе выглядит достаточно простой.

ConWIP ограничивает количество незавершенной работы на всей системе целиком, а следовательно появляется понимание емкости производственной системы.

Понимание емкости производственной системы помогает вашему заказчику более эффективно работать с потенциальными запросами на реализацию. При пополнении производственной системы ваш заказчик всегда будет знать, сколько рабочих элементов можно запустить в производственную систему. Если интенсивность появления этих запросов у заказчика превышает интенсивность, с которой запросы попадают в производственную систему, то у заказчика появляется явный сигнал о том, что необходимо как-то эти запросы сортировать и запускать в производственную систему запросы, которые несут максимальную ценность.

Понимание емкости производственной системы помогает вашему заказчику выработать механизм исследования потенциальных запросов для выявления тех, которые должны попасть в производственную систему и тех, которые необходимо выкинуть, а также сбалансировать этот механизм с возможностями производственной системы.

Не всякое использование WIP-лимитов делает производственную систему вытягивающей, мы об этом писали в статье персональный WIP-лимит. Использование ConWIP делает вашу производственную систему вытягивающей, т.к. новая работа попадает в производственную систему только тогда, когда под нее освобождается емкость, и это, в свою очередь, позволяет повысить предсказуемость производственной системы.

Внутри производственной системы все активности не будут ограничены и это чревато тем, что люди смогут бесконтрольно перегружать себя набирая себе много работы, хоть и в рамках общего ограничения на всю систему. Это будет приводить к задержкам связанным с контекстными переключениями и задержками связанными с чрезмерным распараллеливанием работы. Про последнее чуть подробнее.

Представим простую ситуацию, что у нас есть 5 рабочих элементов и каждый из них можно сделать за 2 дня. Все эти 5 рабочих элементов попали в производственную систему одновременно и дальше могут быть обработаны специалистом. Давайте посчитаем время цикла от попадания рабочего элемента в производственную систему, до завершения работы первым специалистом в режиме последовательной работы:

• Время цикла первого рабочего элемента будет равно 2 дням, т.к. этот рабочий элемент не лежал во входной очереди и сразу попал к специалисту в работу;
• Время цикла второго рабочего элемента будет равно 4 дням, т.к. он лежал 2 дня во входном буфере и ждал, когда специалист освободится от работы над первым рабочим элементом, а дальше 2 дня шла его реализация;
• Время цикла третьего рабочего элемента будет равно 6 дням. Считаем по аналогии с предыдущим пунктом
• Время цикла четвертого рабочего элемента будет равно 8 дням.
• Время цикла пятого рабочего элемента будет равно 10 дням.

Общее время, за которое вся работа пройдет через специалиста будет равна сумме всех времен, которые сотрудник потратит на работу, а это 2 дня на каждый рабочий элемент, в результате общее время выполнения этого заказа у него будет 10 дней. Посмотрите на иллюстрацию, там на сетевой диаграмме показано, как это все будет реализовано.

Если специалист сразу возьмет в работу все рабочие элементы и будет постоянно переключаться между ними, то даже если мы будем игнорировать контекстные переключения, реализация этих пяти рабочих элементов будет выглядеть следующим образом:

Время выполнения заказа специалистом будет то же самое, но есть нюанс - первый рабочий элемент будет завершен специалистом раньше, следовательно есть шанс, что при дальнейшей обработке запроса заказчик получит результат раньше.

При использовании ConWIP выбор распараллеливания или последовательной работы не регламентирован ограничением на активность и отдается на откуп специалисту, который может делать это абсолютно рандомно, следовательно внутри производственной системы у нас нет вытягивающего процесса, что может повлиять на общее время производства системы.

Если заглянуть глубже в приведенный выше пример, мы можем увидеть, что следствием отсутствия лимита на активности будет хаотическая нагрузка на людей, что сделает процесс работы рваным (где-то он будет затягиваться, а где-то проходить быстро) и эта рваность будет обусловлена не правилами работы производственной системы, а личными действиями каждого сотрудника (о распараллеливании работы). Это чревато не только влиянием на время производства, но и влиянием на перегрузку и выгорание сотрудников. Может сложиться ситуация, когда у сотрудника “то густо, то пусто” и это будет негативно влиять на работу.

Важно будет отметить, что поток работы может быть рваным изначально из-за того, что нагрузка на разных специалистов в рамках разных рабочих элементов разная, но эта рваность потока будет связана со спецификой нагрузки, а в случае с ConWIP ситуация будет усугубляться еще и человеческим фактором и их нерегулируемыми решениями внутри системы.

Самый простой способ - это посмотреть сколько рабочих элементов находится в системе сейчас и договориться о том, что это число и будет Константным WIP-лимитом. Дальше на Канбан Митингах мы сможем увидеть сигналы о том, что в системе находится работы слишком много - что вызывает излишние задержки, или, что в системе находится работы слишком мало - что вызывает простои персонала.

Конечно есть! Вы могли бы сделать распределение емкости системы, например по типам работ. Например, у вас в системе ограничение ConWIP равное 10 рабочим элементам и есть 2 типа работ: Задачи на разработку и задачи на поддержку. Вы могли бы распределить емкость системы так, чтобы у вас в системе было 8 задач разработки и 2 задачи поддержки. Завершив одну задачу разработки в систему можно будет взять другую задачу разработки. Завершив одну задачу поддержки в систему можно будет взять другую задачу поддержки.

Аналогичным образом вы могли бы разделить емкость по классам обслуживания, по компонентам, по заказчикам, по проектам, да в общем по любой кластеризации, которая вам необходима.