Основные вопросы:
- Как мы можем ограничить Работу в процессе, не используя ограничения WIP по столбцам?
- Как мы можем Отложить обязательства до последнего момента, не нарушая даты поставок и сохраняя количество Работы в процессе минимальным?
- Какую политику Пополнения работы нам стоит использовать и какой Сигнал пополнения должен инициировать ее применение?
Буфер необходимо поместить перед Ограничением, при этом в буфере должно быть достаточно работы, чтобы Ограничение не простаивало (например, две единицы работы / проекта). Как только Ограничение освобождается, оно подает Сигнал пополнения (барабан) и вытягивает (веревка) из буфера свою часть следующей единицы работы. Как только остальные участники процесса слышат барабан, они вытягивают свои части следующей единицы работы из буфера.
Даже если буфер находится где-то в середине процесса, следует рассматривать Сигнал пополнения, как исходящий из системы и обращенный к бэклогу (т.е. списку возможных проектов). Из этого списка опций выбирается очередной (самый приоритетный) проект, и он становится обязательством, его части попадают в очереди работы всех команд.
Размер буфера особенно важен, если Ограничение находится в середине Потока. Суть в том, что буфер - это не про размер / количество работы, а про время, за которое работа достигает ограничения. Поэтому в буфере должно быть достаточно проектов, чтобы буфер не пересыхал и постоянно мог доставлять работу до Ограничения.
Работа должна попадать в систему с той же скоростью, с которой Ограничение способно ее выполнить. Если работы больше, то Ограничение будет перегружено, а это приведет к увеличению объема Работы в процессе, ухудшению Эффективности по потоку, накоплению очередей в разных частях системы и росту среднего Времени Потока. Если работы меньше, то ограничение простаивает, а это - невосполнимая потеря для выработки всей системы в целом, как операционной, так и финансовой.