Когда я разработал концепцию планируемой загрузки, я думал, что она будет приятной дополнительной функцией для моего симулятора MICSS. MICSS предоставил мне возможность проверить различные политики и идеи, важные для управления производством. Мне потребовались годы, чтобы понять, насколько важна планируемая загрузка. На самом деле без использования планируемой загрузки невозможно использовать Упрощенный-Барабан-Буфер-Канат (S-DBR), заменивший гораздо более сложный Барабан-Буфер-Канат. Тем не менее, кажется, что большинство людей в мире ТОС, в том числе те, кто разрабатывает программное обеспечение ТОС, не знают о ее важности и, уж конечно, о ее потенциальной ценности.
Планируемая загрузка для критического ресурса – это общее время, необходимое для завершения всей работы, которая уже точно запланирована. Цель состоит в том, чтобы помочь нам понять связь между загрузкой, доступной мощностью и временем реакции!
Давайте рассмотрим в качестве примера систему правосудия. Представьте себе судью, рассматривающего работу, которую он должен выполнить: у него уже запланированы судебные заседания общей продолжительностью 160 часов. Кроме того, он должен потратить 80 часов на чтение протоколов предыдущих заседаний и написать вердикты. Всего выходит 240 часов, необходимых для выполнения существующей известной допустимой загрузки.
Если предположить, что судья работает 40 часов в неделю, то все дела, в настоящее время ожидающие судью, теоретически должны быть завершены в течение шести недель. Мы можем разумно ожидать, что новое дело, требующее около 40 часов работы судьи, будет закончено не позднее чем через десять недель. Я добавил три недели в качестве буфера, если что-то пойдет не так. Например, некоторые дела потребуют дополнительных заседаний, или судья заболеет на несколько дней. Этот буфер необходим для того, чтобы обоснованно спрогнозировать завершение нового суда.
Однако в действительности мы можем легко выяснить, что средний срок завершения нового судебного процесса составляет не 10, а 50 (пятьдесят) недель! Как это возможно?
Когда ожидания, основанные на планировании загрузки, не сбываются, мы должны принять одно из следующих объяснений:
- Рассматриваемый нами ресурс не является ограничением и, таким образом, может простаивать продолжительное время. В случае суда, узким местом могут быть адвокаты, которые просят и получают длительные отсрочки между заседаниями.
- Если рассматриваемый ресурс является ограничением, управление ресурсом, в частности, усилия по использованию ограничения настолько плохи, что существенные мощности расходуются впустую.
- Фактическая нагрузка включает значительную часть срочных работ, не запланированных заранее, и таким образом, не являющихся частью текущей плановой загрузки. Такие случаи возникают часто и задерживают регулярные плановые работы, уже зарегистрированные в системе.
Важность планируемой загрузки «слабого звена» в производстве – быстрая и грубая оценка времени ожидания в очереди производственных заказов и заданий. Когда время ожидания в очереди относительно долгое, планируемая загрузка дает оценку фактического времени выполнения заказа при условии, что нет никаких серьезных потерь мощностей. Другими словами, планирование загрузки является показателем потенциальной отзывчивости системы на изменение спроса.
Посмотрите на следующую картину с изображением планируемой загрузки (красная полоска) шести различных ресурсов производственной компании. Числа справа обозначает время работы в часах, в том числе среднее время переналадки.
Рис. 1
Предположим, что каждый ресурс работает 40 часов в неделю. Мы видим один ресурс (PK – Упаковочная Линия), у которого имеется работа почти на 3 недели.
Зеленые полоски представляют количество запланированной работы для ресурса, которая уже находится на этом ресурсе. В производственных линиях и в средах с задачами, которые требуют участия нескольких ресурсов, может возникнуть ситуация, что определенная работа уже должна была, но, тем не менее, не достигла определенного ресурса. Эта работа является частью планируемой загрузки. Но она не является частью зеленой полоски. Упаковка является последней операцией, и большинство известных ей заказов постоянно находится на ресурсах выше по течению потока или, возможно, даже не запущено в производство.
По-настоящему важная информация содержится в красных полосках – планируемая загрузка. Чтобы понять это сообщение, вам необходима дополнительная информация: срок выполнения заказа для клиента составляет 6-7 недель.
Приведенная выше информация является достаточно уверенно заключить, что производство выше очень плохо управляется.
Срок выполнения заказа должен быть 3 недели в среднем. Тогда сокращение срока до 4 недель может повысить спрос. Конечно, когда спрос резко повышается, планируемая загрузка должна быть тщательно перепроверена, чтобы убедиться, что поставка за 4 недели является надежной.
Просто чтобы проиллюстрировать силу информации о планировании загрузки, ниже показана планируемая загрузка той же организации через четыре месяца после внесения необходимых изменений в производство.
Рис. 2
Срок выполнения заказа клиента в настоящее время составляет 4 недели. Спрос вырос на 25%, в результате чего рабочий центр MB стал ресурсом с ограниченной мощностью. Поскольку моделирование теперь использует правильные принципы ТОС, большая часть незавершенного производства (WIP) теперь естественным образом скопилась на ограничении. Но неограниченных ресурсах, находящихся ниже по течению от ограничения, незавершенного производства очень мало.
Самая продолжительная плановая загрузка составляет 3 недели (около 120 часов плановых работ на MB). Срок 4 недели включает временной буфер, который позволит справиться с проблемами на самом ресурсе MB и обеспечить производство ниже по течению.
Это только базовое понимание важности информации о планируемой загрузке. После того как Голдратт понял скрытую ценность этой информации, он создал алгоритм для расчета надежных сроков выполнения заказа на основе планируемой загрузки плюс использование буфера времени.
График поведения планируемой загрузки во времени может быть показательным. Когда график идет вверх, значит, у нас больше новых заказов, чем отгруженных, что означает риск возникновения внезапного узкого места. Когда график идет вниз, значит, у нас имеются избыточные мощности, что позволяет быстрее реагировать на спрос. И отдел продаж, и производство должны строить свои планы соответствующим образом.
Другая важная особенность заключается в способности немедленного краткосрочного воздействия планируемой загрузки на управление сверхурочной работой, чтобы обеспечить надежность поставки. Временной горизонт равен буферу времени, чтобы убедиться, что мощности достаточны для выполнения всех заказов в пределах этого горизонта. Планируемая загрузка выявит проблемы до того, как вы получите предупреждение от управления буфером «слишком много в красном». Всегда нужно отслеживать и планируемую загрузку, и управление буфером для управления производством.
УББК и планируемая загрузка, безусловно, применяются в производстве. Но УББК, включая планируемую загрузку и управление буфером, должен использоваться для управления своевременным завершением задач практически во всех организациях.
В сообществе ТОС существует тенденция полагать, что любая достаточно большая задача, для выполнения которой требуется несколько ресурсов, это проект, которым должно управлять по методу Критической цепи (ССРМ). В то время как вы вполне можете так поступить и получить положительные результаты, Критическая цепь не обязательно будет лучшим, и уж конечно, не самым простым способом управлять такими задачами.
Я думаю, что мы должны приложить усилия и четко различать, когда для управления задачей можно эффективно использовать УББК, а когда действительно требуется Критическая цепь. И, кстати, все мы можем подумать, как должно осуществляться управление мощностями ключевых ресурсов в многопроектных средах. Можно ли использовать планируемую загрузку в качестве ключевого показателя: достаточно ли мощностей, чтобы предотвратить слишком длительные задержки, или существует острая необходимость увеличения мощностей?
Автор: Эли Шрагенхайм (Eli Schragenheim)