Распределение мощности по классам обслуживания
На рис. 11.3 представлена канбан-система, общий WIP-лимит для которой равен 20. Классы обслуживания обозначены карточками четырех цветов. Белые карточки ускоренного класса не учитываются в общем WIP-лимите, но ограничены одним элементом за раз. Таким образом, они (если есть в наличии) вносят 5 %-ный вклад в общую мощность, доводя реальное количество незавершенных заданий до 21. В этом примере фиолетовые карточки для элементов с фиксированной датой поставки составляют 20 % от общего количества. Это значит, что на доске может быть только четыре фиолетовые карточки в один и тот же момент, однако присутствовать они могут в любом столбце. Желтые элементы стандартного класса составляют 50 % всей мощности, а остальные 30 % отведены зеленым элементам нематериального класса.
Рис. 11.3. Стена карточек, демонстрирующая распределение мощности по классам обслуживания
Сейчас, когда мы распределили мощность по разным классам обслуживания, деятельность по пополнению входящей очереди осложняется, поскольку надо учитывать доступную мощность для каждого класса. На рисунке видно, что есть место для одного элемента с фиксированной датой поставки и трех – нематериального класса. Это порождает множество вопросов. Что если у нас нет сейчас спроса на элемент с фиксированной датой поставки? Как быть? Возможно, заполнить свободное место элементом стандартного класса? Но нужно ли в таком случае переводить этот элемент в класс с фиксированной датой поставки? Или продолжать обрабатывать его как элемент стандартного класса? А не является ли все это нарушением правил распределения мощности?
Эти разумные вопросы отражают повседневные проблемы использования канбан-системы. Более того, на них нет правильных и неправильных ответов, все зависит от конкретной ситуации.
Из выбранного распределения можно понять, что в данной отрасли присутствует существенное количество элементов с фиксированной датой поставки, к тому же серьезные запасы мощности зарезервированы за нематериальными элементами. Возможно, это связано с реализацией каких-то крупных инициатив с более длительными сроками выполнения, например заменой платформы. Или же отрасль связана с существенными рисками. Не исключено, что количество ускоренных запросов или элементов с фиксированной датой поставки растет из-за сезонной природы спроса. Чтобы правильно отреагировать на такой спрос и не вызвать роста неудовлетворенности клиентов, мы и выделяем больше мощности на нематериальные элементы за счет элементов стандартного класса. Тем самым в системе создается больше резерва.
Если же говорить о том, как поступить, когда во входящей очереди образуется место для элемента с фиксированной датой поставки, а их нет, то в первую очередь следует учесть риски, характерные для данной отрасли. Если спрос на элементы с фиксированной датой поставки в целом значителен, а связанные с этим издержки высоки (и риск, соответственно, тоже), то, возможно, лучше оставить место свободным. Разумно также зарезервировать мощность в ожидании поступления следующего элемента с фиксированной датой поставки. Если риски малы, то мы можем заполнить свободное место элементом стандартного класса. Когда же появляется элемент с фиксированной датой поставки, можно либо приостановить работу над элементом стандартного класса, либо временно превысить WIP-лимит. Все эти решения окажут свое влияние на время выполнения, долю выполнения в срок, распространение вариативности времени выполнения, удовлетворенность пользователя и управление рисками. Решения придется принимать самостоятельно, и потребуется время, прежде чем вы накопите достаточно опыта, чтобы делать наилучший выбор для команды, проекта и организации в целом.
Распределение мощности – это еще одна стратегия в канбан-системе. Если вы считаете, что распределение не соответствует спросу, то внесите в него изменения: поменяйте правила и соответствующие WIP-лимиты.