Представьте, что вы отвечаете за организацию цепочки поставок и продаж в продуктовом магазине. Давайте для определенности считать, что речь идет об вкусных йогуртах. У вас есть производитель, поставляющий определенный объем продукции, есть склад (ну очень бОООльшой) и обычная магазинная витрина, откуда покупатели разбирают упаковки к себе в сумки. Она имеет конечный размер и может разместить сравнительно небольшое число упаковок продуктов. Как бы вы договорились с поставщиком об объемах регулярных поставок?

В этой системе есть WIP лимит, определяемый размерами самой витрины. Больше, чем она может вместить, ничего выложить не получится (просто некуда). Если поставлять продуктов меньше, чем раскупается, то на полке периодически не будет ничего, а значит будет потеряна прибыль и клиенты (кому понравится магазин, где ничего нет). Если заранее заказать больше упаковок, чем можно продать, скажем, за день, то складские остатки начнут увеличиваться и, как минимум, «заморозят» свободные деньги или, как максимум, со временем продукты испортятся. Важно сделать так, чтобы скорость поставок была синхронизирована со скоростью потребления.

Конечно можно попытаться компенсировать рост поставок, выкладывая в торговый зал больше упаковок (например на пол, соседнюю витрину). Однако поднимать таким образом продажи это тоже самое, как добавлять в принтер больше бумаги, в надежде на увеличение скорости печати. У системы есть свойственная ей скорость (потребления, печати и др. ), которую нельзя бесконечно стимулировать «впихивая невпихуемое». Этот подход называется проталкиванием (PUSH) когда в систему сначала «закачивают» элементы работы, а потом думают, что с этим делать.

Альтернативным вариантом является «вытягивающася» система, которая в 50е годы была подсмотрена начальником механического цеха компании Тойота Тайити Оно во время его поездки в США. По его воспоминаниям идея вытягивания (PULL) в магазине как раз в момент осмотра подобной витрины. Этот человек (к слову создатель Toyota Production System) обратил внимание, что система работает в обратную сторону: вначале покупатели разбирают продукты на полке, а уже потом сотрудники магазина пополняют со склада ровно столько, сколько было куплено за день и на основании этих данных делают заказ на склад. По его возвращении на родину этот принцип лег в основу работы с Канбан доской: вначале проверяются те элементы работы, которые расположены как можно ближе к концу процесса и только после освобождения соответствующего WIP лимита переходим к предшествующим этапам (прямо как в игре в «пятнашки»). Другими словами перед тем как начать делать что-нибудь нужное, сначала завершить то, что вам казалось нужным нужным до этого.

Принцип вытягивания нашел свое отражение не только в Канбан. Его следы также видны и в SCRUM. Так в Планировании Спринта Команда разработки сама прогнозирует задачи, которые могут быть сделаны в предстоящем спринте (вытягивание), а не автоматически получает их от Владельца продукт согласно заранее предопределенному «нормативу» или текущей необходимости (проталкивание).

Вытягивание, в принципе настроено на поддержание командой её естественного ритма, когда нет авралов и переработок (состояние потока). Конечно иногда бывают моменты когда нужно «поднажать» и достигнуть краткосрочных целей. Но принцип вытягивания помогает соответствовать долгосрочной цели, которая лучше всего написана в тексте манифеста Agile разработки программного обеспечения: «Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно».

В прошлый раз ( http://kanban.club/all/wip-limit/ ) мы говорили о применении WIP лимита в качестве инструмента для управления производительностью отдельного этапа конвейера. Теперь поговорим о том, как WIP лимит можно использовать для настройки всей производственной цепочки.

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

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

1. рост времени обработки. В соответствии с законом Литтла, который мы обсудили в первой части, время нахождения элемента работы в системе прямо пропорционально числу таких элементов. Например, чем больше статей одновременно вы пишите в kanban.club, тем дольше будет писаться каждая из них по отдельности:)
2. потеря актуальности/порча элементов работы/хранение из-за долгого нахождения в очереди. Это может быть что угодно: от бизнес требований заказчика до парного молока.
3. снижение оборачиваемости капитала. Любое незавершенное производство означает, что потраченные на него деньги еще не скоро вернутся в компанию. При этом не стоит забывать, что деньги сами по себе тоже имеют стоимость в виде процентной ставки по банковским кредитам.
4. скрытые проблемы производства. Наличие внутренних очередей затрудняет диагностику проблем. Например, если в ней есть элемент работы, содержащий дефект, то выявить их удастся только тогда, когда до такого элемента работы дойдет очередь обработки. Все это время ожидания проблема будет находиться без решения.
5. отложенная прибыль. Чем позже мы получим продукт, который можно продать на рынке, тем меньше мы получим прибыли, не так ли?

Но можно ли избежать таких «узких мест»? Они есть в любом реальном конвейере и их наличие говорит о том, что конвейер скорее жив, чем мертв. Вопрос не в том, как их избежать, а как научиться с ними работать.

Пропускная способность всей системы ограничивается самым узким местом этой системы (см рисунок). Попытка выжать максимум на каждом этапе конвейера приведет только к потерям из за формирования ненужных очередей. Как это ни парадоксально, но работа на 100% загрузки вне узкого места может приносить вред, а не пользу.

Делать ей было совершенно нечего, а сидеть без дела, сами знаете, дело нелегкое. Алиса в стране чудес (Льюис Кэрролл)

Такое случается, когда каждый этап конвейера сфокусирован на оптимизации своей работы без оглядки на вопрос «как это выглядит с точки зрения всей системы?». Это носит название «локальная оптимизация» и является распространенным примером, когда «добрыми намерениями, дорога в ад выстроена». Каждый элемент производственной системы должен производить скорее не «столько, сколько может», а «столько, сколько нужно». Идеальная система должна уметь перераспределять избыток мощности на те участки, где она необходима. Вот где концепцию T-shaped people сложно переоценить.

Алгоритм «настройки» такой системы может проиллюстрировать на примере Пяти Направляющих Шагов Теории Ограничений Элияху Голдратта (см. Eliyahu M. Goldratt, Jeff Cox. The Goal: A Process of Ongoing Improvement):

1. Найти ограничение системы. Узкое место, перед которым формируются наибольшие очереди нашего конвейера и будет тем самым ограничением системы, с которого мы начнем настройку.
2. Решить, как максимально использовать ограничение системы. Помните сколько стоит простой системы в узком месте? Следовательно именно здесь нам важно вывести участок на «пик формы». Механизм нам уже известен из предыдущей статьи — нужно подобрать значение WIP лимита при котором этот этап конвейера обладает максимальной пропускной способностью, но при этом сохраняет приемлемое значение времени обработки. По сути узкое место будет единственным участком, где мы сознательно добиваемся максимума утилизации ресурсов. Безусловно использование WIP лимита не отменят использования любых других доступных и приемлемых для вас средств оптимизации в этом месте.
3. Подчинить все остальное этому решению.
   В отличие от предыдущего этапа все участки конвейера до узкого места должны производить только то количество работы, которое может быть обработано узким местом. Для этого WIP лимиты на эти участках должны быть «зажаты», чтобы не формировались запасы незавершенного производства. Обратите внимание, что на этих этапах окажутся недоиспользованные ресурсы (ведь там раньше был избыток мощности, верно?). Не беспокойтесь, мы подумаем и об этом :)
   Помните мы говорили, что пропускная способность это переменная величина? Узкое место — не исключение. Для компенсации таких колебаний перед ним можно предусмотреть небольшую очередь, которая будет буфером, обеспечивающим узкое место работой если в нем появится избыток мощности.
   А что будет на участках после узкого места? Их пропускная способность заведомо выше и следовательно наша цель здесь уменьшить WIP лимиты, обеспечив быстрое время обработки и высвободив «лишние» ресурсы
4. Расширить ограничение (ограничения) системы. Теперь, когда система функционирует без внутренних запасов, дополнительный рост пропускной способности можно сделать либо улучшив технологию обработки в узком месте, либо перераспределив «избыточные» ресурсы, освободившиеся в предыдущем этапе в узкое место. Лучше делать и то и другое.
5. Вернитесь к шагу 1. Поздравляю, теперь Вы получили настроенную систему, но так ли это на самом деле? В результате наших действий система поменялась. Теперь узкое место может переместиться, а значит процесс улучшения будет циклическим.

Вы можете не изменяться. Выживание не является обязанностью. Э.Деминг

Канбан обычно связывают с ожиданиями по повышению пропускной способности системы. Канбан содержит простой, но мощный инструмент — ограничение количества незавершенной работы или WIP (work in progress) лимиты. В этой статье разберемся, как они работают, на примере отдельной операции. Во второй части мы разберемся как этот механизм работает при наладке производственной цепочки

Эксперимент с многозадачностью

Наверняка вы обращали внимание, что попытка делать несколько задач одновременно скорее приводит к тому, что все задачи делаются и дольше и хуже. Насколько именно? Проведем небольшой эксперимент с друзьями. Попросим одного из них (назовем его разработчик) переписать имена всех остальных друзей (заказчиков), по одному имени на каждой отдельной карточке. Заказчики записывают время начала и окончания работы на своей карточке с именем (более подробно можно посмотреть здесь https://www.crisp.se/gratis-material-och-guider/multitasking-name-game).

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

Результаты видны на рисунке (синий — первый вариант, оранжевый — второй):

Результат 1. Время, необходимое на завершение одной задачи в «последовательном» варианте в несколько раз меньше, чем в «многозадачном» (обратите внимание на длину оранжевых и синих отрезков)

Этот эффект нашел свое отражение в законе Литтла, который связывает средние значения времени пребывания задачи в системе, число задач в ней и пропускной способности (см рисунок)

Втягивая в систему большее число задач, мы как бы «размазываем» её мощность на большее число элементов и тем самым увеличиваем время выполнения каждого из них.

Результат 2. Время выполнения всей работы в «многозадачном» режиме существенно больше, чем в «последовательном» (обратите внимание на разницу между вертикальными красной и зеленой линиями).

Типичный разброс значений 1.5-3 раза. Это приводит к тому, что как правило заказчик получивший свой продукт в «многозадачном» варианте раньше других все равно проигрывает самому последнему заказчику из «последовательного» сценария

О чем это говорит? В обоих сценариях был проделан один и тот же объем работы — написано одно и тоже количество одинаковых имен. Различия только в способе организации работы. Оказывается, вечная «проблема» менеджеров «мы не можем сделать эту задачу, если у нас не будет новых ресурсов» имеет еще одну неожиданную грань — управляя числом задач, принимаемых в работу (т. е. управляя WIP лимитом), можно добиваться увеличения (и уменьшения) пропускной способности системы в разы.

Стоимость переключения между задачами сама по себе не бесплатна. Для человека она обычно составляет 10-15% при добавлении каждой новой, одновременно выполняемой задачи. Попытка делать 5 задач одновременно скорее приведет не к пятикратному замедлению выполнения задач, а к работе системы практически «в холостую», когда большая часть мощности будет тратиться на переключение контекста, а не на реальную работу.

Оптимальный WIP для рабочей группы

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

От нуля и до момента «насыщения» системы работой, её пропускная способность будет расти с увеличением числа задач. По мере наполнения системы этот рост прекратится, и скорее всего даже сменится снижением (помните еще про стоимость переключения контекста?). Время выполнения задачи наоборот, до этого момента, будет постоянной (помните шутку про то, что девять женщин не родят за 1 месяц ребенка?), а затем начнется увеличиваться в соответствии с законом Литтла и внутренними потерями на переключение контекста.

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

Ждите продолжения и оставайтесь с нами! ))

Продолжение http://kanban.club/all/wip-limit2/