Границы DBR

Границы DBR

Барабан-буфер-канат [Drum-Buffer-Rope, DBR] и Упрощенный барабан-буфер-канат [Simplified-Drum-Buffer-Rope, SDBR] являются методологией планирования Теории ограничений (ТОС) для производственных компаний. В этой статье я остановлюсь на DBR / SDBR для производства на заказ (MTO), когда в клиентских заказах указываются продукты, количества и срок поставки. Я посвящу еще одну статью границам производства для обеспечения наличия (MTA). Помимо планирования, существует еще управление буфером, которое используется для определения приоритетов при выполнении заказов.

Я не буду обсуждать здесь детали DBR и различия между DBR и SDBR. Я хотел бы изложить ситуации, в которых применение DBR / SDBR обосновано. Например, Голдратт создал CCPM, когда стало очевидно, что DBR НЕ будет работать для проектов. Читатель, ясно ли вам, что основные исходные посылки, лежащие в основе DBR, недействительны в многопроектной среде и наоборот?

Общая ситуация для MTO – производственные или сервисные организации получают заказы от клиентов, запрашивающих определенные партии точно определенных продуктов или услуг, которые должны быть доставлены в течение определенного времени. Организация-производитель обычно не держит эти продукты на складе, поэтому возникает необходимость их произвести. Организация может потребоваться приобрести сырье и материалы у своих поставщиков, чтобы произвести конкретные заказы для своих клиентов.

Вот основные исходные посылки, когда использование DBR / SDBR обеспечивает надежность поставок:

  1. Чистое время в обработке или «время контакта» (touch time) любого производственного заказа очень мало по сравнению с общим временем выполнения заказа – временем от принятия заказа до его поставки.
    • Голдратт предполагал, что для обработки такого заказа используется менее 10% временного буфера.
    • В остальное время производственный заказ ожидает своей очереди к ресурсам, что означает, что уровень использования многих ресурсов не очень низок.
  2. Уровень статистических колебаний внутри самого цеха не слишком велик.
    • Например, если в среднем переналадка занимает два часа, она вряд ли займет 20 часов.
    • В целом такая среда подвержена гораздо меньшим колебаниям, чем в проектах!
    • Эта исходная посылка также касается уровня брака. Маловероятно, что весь производственный заказ будет отбракован.
    • Это означает, что цех поддерживает достаточно хорошее качество на всех этапах.
  3. Организация поддерживает приемлемый контроль над своими закупками и аутсорсингом.
  4. Все операции производятся в одном и том же месте или достаточно близко, поэтому время транспортировки между операционными центрами короткое по сравнению с временным буфером.
    • Эта исходная посылка может рассматривать как продолжение посылки №1. Мы должны понимать, что транспортировка также является частью «времени контакта».

И одна ключевая исходная посылка для Управления буфером:
Большинство заказов завершаются в «желтой» зоне буфера, либо очень близко к проникновению в «красную» зону.

Когда одна или несколько исходных посылок недействительны, это не означает, что DBR / SDBR бесполезны, но это означает, что необходимы определенные изменения.

Я хочу немного пояснять влияние времени контакта на методологию. На самом деле исходная посылка о малом времени контакта является основным отличием между производством и многопроектной средой. В проектах мы ожидаем, что время, необходимое для обработки задач на критической цепи, равно времени завершения всего проекта. Это резко контрастирует с производством, где заказы между операциями довольно долго ждут своей очереди на обработку. Из-за этого ключевого различия термины «критический путь» или «критическая цепь» не применяются к производству.

Еще рекомендуем:  Практическая реализация производства на вытягивающей основе

Что произойдет, если время контакта определенной операции составляет около 30% временного буфера?

В SDBR временной буфер охватывает весь производственный процесс, от запуска материалов до завершения. Когда одна операция занимает 30% этого времени, мы должны задать два критически важных вопроса:

  1. Достаточно ли временного буфера, чтобы защитить срок выполнения от колебаний всего производственного процесса? Время контакта (30%) не входит в защитное время, поэтому обеспечивают ли оставшиеся 70% достаточную защиту?
  2. В управлении буфером для DBR / SDBR точное местоположение производственного заказа не отражается на состоянии буфера, потому что, когда время контакта незначительно, это не имеет значения. Однако, когда одна конкретная операция занимает целых 30% буфера, очень важно, ожидает ли производственный заказ эту операцию или уже прошел через нее. Если заказ еще не прошел через длительную операцию, оставшийся эффективный буфер значительно короче, чем оставшееся время до срока выполнения заказа.

Поэтому Лизой Шейнкопф, Юджи Киширой и Амиром Шрагенхаймом в 2012 году было разработано и представлено новое приложение для управления буфером в рамках реализации SDBR, сталкивающегося с продолжительным временем контакта. Это пример понимания границ основных исходных посылок и уровня требуемых изменений, когда конкретная посылка более не является действительной.

Важно еще раз подчеркнуть, что вышеупомянутые исходные посылки относятся к производству на заказ (MTO). Критическое различие между MTO и MTA (производство для обеспечения наличия) было признано намного позже, чем разработаны DBR и SDBR. Исходная посылка, что у нас есть определенное количество продукта для поставки на определенную дату, не было четко сформулировано ни в MRP, ни в DBR. Как только значение этой исходной посылки стало ясно, была разработана другая методология – MTA. Урок состоит в том, чтобы сделать все возможное для вербализации основных исходных посылок, определяющих границы, в которых действует конкретная методология. Затем мы можем определить ситуации, которые лежат за этими границами, и найти подходящее решение, которое может быть похожим или сильно отличаться от исходной методологии.

Блог Эли Шрагенхайма

Эли Шрагенхайм
Eli Schragenheim,
CEO of Elyakim Management Systems (1992) Ltd

Давайте обсудим...

Ваш e-mail не будет опубликован. Обязательные поля помечены *