На прошлой неделе в своем блоге Эли Шрагенхайм опубликовал материал посвященный использованию метода Планируемой загрузки. Практически раскрыл «секретные техники кунг-фу» :)
На мой взгляд, это одна из важнейших техник, которая не всегда очевидна, хотя инъекция «Проводится мониторинг мощностей с целью своевременного обнаружения ресурсов с ограниченной мощностью (CCR) и соответствующего управления мощностями» является обязательной частью стандартных решений DTA/MTA/MTO. Может быть потому, что рассматривается как часть POOGI, а не как часть первых шагов внедрения.
По крайней мере, в моей личной практике понимание важности планируемой загрузки пришло далеко не сразу, но, с момента осознания, многое расставило по местам. Поэтому я желаю тем читателям, интересующимся ТОС, этого «сатори» :) Понимание важности учета мощности не только в факте, но и в оперативном планировании — штука супер-полезная.
Мне везет: видимо Эли занят подготовкой к ежегодной конференции TOCICO, где у него ожидается интересные выступления и писать ему некогда, так что переводы догнали оригинал. Жаль, что не попаду на конференцию, очень хочется пообщаться не в письменном виде, а вживую :( У кого есть возможность — не упускайте.
Как обычно, ссылка на оригинал и картинки из поста автора.
Ваш Дмитрий Егоров.
Когда я разработал концепцию Планируемой загрузки[i], я думал, что это было функцией из разряда «неплохо-чтобы-было»[ii] для моего симулятора MICSS. MICSS дал мне возможность проверить различные идеи и политики, относящиеся к управлению производством. Мне понадобились годы, чтобы понять, насколько важна планируемая загрузка.
Действительно, без использования планируемой загрузки невозможно использовать Упрощенный Барабан-Буфер-Канат (S-DBR), который заменил гораздо более сложный Барабан-Буфер-Канат (DBR). Тем не менее, похоже, что большинство людей в мире ТОС, включая тех, кто разрабатывает программное обеспечение для ТОС, не до конца осознают ее важность и, уж точно, ее потенциальную ценность.
Планируемая загрузка критического ресурса – это суммарное время, которое необходимо, чтобы завершить всю работу, которая уже точно запланирована к исполнению[iii]. Задача – помочь нам понять связь между загрузкой, доступной мощностью и временем отклика!
Для примера давайте разберем систему правосудия. Представим, что судья изучает, какую работу ему предстоит сделать: присутствие на уже запланированных заседаниях суда – 160 часов. Кроме того, ему необходимо потратить 80 часов на чтение протоколов предыдущих заседаний и написание решений суда. Для завершения уже существующей известной рабочей загрузки ему необходимо 240 часов.
Если предположить, что судья работает 40 часов в неделю, ему, теоретически, понадобится шесть недель, чтобы завершить все ожидающие судебные дела. Можно ожидать, что новое судебное дело, требующее около 40 часов, будет закончено не позже, чем через десять недель. Я добавил три недели в качестве буфера, на тот случай, если что-то пойдет не так, так как некоторые судебные дела потребуют дополнительных заседаний, или судья может заболеть на несколько дней. Этот буфер необходим, чтобы обосновано предсказать окончание нового судебного дела.
Однако, в реальности мы легко можем обнаружить, что средний цикл рассмотрения[iv] нового судебного дела составляет пятьдесят (50) недель – как можно это объяснить?
Если ожидания, основанные на планируемой загрузке не реализуются, мы приходится предположить одно из следующих объяснений:
- Рассматриваемый ресурс не является ограничением и, поэтому, имеет много незагруженного времени. В случае судьи, реальным бутылочным горлышком могут быть адвокаты, которые запрашивают и получают длительные отсрочки между заседаниями.
- В случае, если ресурс является ограничением, управление этим ресурсом, особенно усилия по максимальному использованию мощности, может быть настолько плохим, что существенная часть мощности теряется впустую.
- Фактический спрос включает большую долю срочных случаев, априори не запланированных и, потому, не включенными в текущую планируемую загрузку. Такие случаи появляются часто и приводят к откладыванию работы, уже зарегистрированной в системе в обычном режиме планирования.
Важность планируемой загрузки «слабого звена» состоит в быстрой, грубой оценке чистого времени очереди производственных заказов и заданий. Когда время очереди относительно велико, планируемая загрузка дает нам оценку фактического производственного цикла, при которой не будет большой потери мощности. Другими словами, планируемая загрузка является мерой потенциального отклика системы на новый спрос.
Взгляните на следующий рисунок, показывающий планируемую загрузку (красная линия) шести различных ресурсов производственной организации. Цифры справа от линии показывают работу в часах, включая средние переналадки.
Предполагая, что каждый ресурс работает 40 часов в неделю, мы видим один ресурс (PK – упаковочная линия), который уже загружен на три недели чистого времени работы.
Зеленые полосы показывают количество запланированной работы, которая уже выполняется на этом ресурсе. Как на производственных линиях, так и в среде, где задания требуют нескольких ресурсов, возможно ситуация, когда определенная работа уже подтверждена[v], но еще не достигла конкретного ресурса. Такая работа является частью планируемой загрузки. Это НЕ ЧАСТЬ зеленой линии. Упаковочная линия – это последняя операция и большинство известных производственных заказов для него находятся на ресурсах выше по потоку или, может быть, даже не запущены в производство.
По настоящему важная информация находится в красных линиях – планируемой загрузки. Чтобы понять, вам нужно еще немного информации: срок, обещаемый клиенту, составляет 6-7 недель.
Этой информации достаточно, чтобы уверенно придти к выводу, что производство очень плохо управляется.
Фактический срок производства должен быть в среднем три недели. Поэтому, объявление о сроке изготовления в четыре недели может дать больше спроса. Конечно, если спрос резко растет, то планируемая загрузка должна быть тщательно перепроверена, чтобы быть уверенным, что срок в четыре недели достаточен.
Просто, чтобы проиллюстрировать силу информации о планируемой загрузки – вот планируемая загрузка той же организации спустя четыре месяца после внесение необходимых изменений в производство:
Время исполнения заказа клиента теперь четыре недели. Спрос вырос на 25%, вследствие чего рабочий центр MB стал ограничением мощности. Так как теперь симуляция правильно использует принципы ТОС, естественно, что большая часть незавершенного производства (НЗП) скопилась у ограничения. У ресурсов-«не-ограниченйя», которые расположены ниже по потоку, объем НЗП очень небольшой.
Самая длинная планируемая загрузка составляет три недели (около 120 часов планируемой работы для ресурса MB). Обещание четырех недель включает в себя буфер времени, который позволит справиться с проблемами на ресурсе MB и прохождения операций дальше по потоку.
Это всего лишь базовое понимание критичности информации о планируемой загрузки. Когда д-р Голдратт осознал скрытую ценность такой информации, он создал алгоритм для расчета «надежных дат»[vi], основываясь на планируемой загрузке и части буфера времени.
График поведения планируемой загрузки во времени может давать опережающую информацию. Если загрузка растет, это значит, что мы имеем больше нового входящего спроса, чем уже исполненного, что означает риск появления бутылочных горлышек. Если график загрузки снижается, это означает, что у нас есть избыток мощности, дающий возможность для более быстрого отклика. В соответствии с этим должны строить свои платы как Продажи, так и Производство.
Другая отличительная особенность – это оценка немедленного влияния планируемой загрузки на надежность исполнения заказов при управлении сверхурочными работами. Здесь горизонт времени равен буферу времени, убедиться, что мощности достаточно для выполнения всех заказов в пределах этого временного горизонта. Она идентифицирует проблемы до того, как управление буфером предупредит о том, что «слишком много в красном». Для управления исполнением необходимо отслеживать ОДНОВРЕМЕННО планируемую загрузку и управление буферами.
Упрощенный барабан-буфер-канат (SDBR) и планируемая загрузка, как его часть, конечно, применяется для производства. Но SDBR, включая как планируемую загрузку, так и управление буфером, должен использоваться для управления своевременным завершением миссий[vii] почти во всех организациях.
В кругах ТОС существует тенденция предполагать, что любая достаточно крупная миссия, для которой требуется несколько ресурсов, является проектом, которым следует управлять в соответствии с решением CCPM. Хотя так можно делать и получать при этом положительные результаты, это — не обязательно наилучший и, конечно, не самый простой способ управления такими миссиями.
Я думаю, что нам следует приложить усилие и четко различать, когда для выполнения миссии можно эффективно использовать SDBR, а когда действительно нужен CCPM. И кстати, мы все можем подумать как мощность ключевых ресурсов должна управляться в мульти-проектной среде. Можно ли использовать планируемую загрузку в качестве ключевого индикатора достаточности мощности для защиты от слишком длинных задержек или наличия неотложной необходимости увеличения мощности?
[i] В тексте «Planned Load» — прим. переводчика
[ii] В тексте «nice-to-have» термин, используемый Эли Шрагенхаймом для различных функций и особенностей продукта, которые не являются обязательными. – прим. переводчика
[iii] В тексте «firmly planned» — буквально «твердо запланирована», т.е. основана на «твердых» заказах. – прим. переводчика
[iv] В тексте «laed-time» — прим. переводчика
[v] В тексте «firm» — прим. переводчика
[vi] В тексте «safe-dates» — прим. переводчика
[vii] В тексте «missions» в том же смысле, что и «миссия выполнима/невыполнима» — прим. переводчика
