Содержание:
1. Барабан-буфер-канат. Наш план атаки
1.1. Найдите ограничения системы
1.2. Используйте ограничения системы
1.3. Подчинение – защита ограничений системы
1.3.1. Правило первоначального определения размера буфера
1.3.2. Почему размер и активность буфера ограничений определяются временем?
1.3.3. Путешествие во времени
1.3.4. Подчиним все остальное
1.3.5. Альтернативное правило первоначального размера буфера
1.4. Расширьте ограничение системы
1.5. Если ограничение расширено, вернитесь назад
1.6. Некоторые тонкости определений
2. Управление буфером – производство на заказ
2.1. Локальный контроль – статус (состояние) буфера
2.2. Локальный контроль – статус заказа-наряда
2.3. Локальный контроль – приоритет запуска нового заказа-наряда
2.4. Локальный контроль / глобальная обратная связь – проникновение заказа-наряда в красную зону буфера
2.5. Локальный контроль / глобальная обратная связь – показатели выполнения заказов-нарядов
2.6. Глобальная обратная связь – изменение размера буфера заказа-наряда
2.7. Рыночное ограничение
Однако «барабан-буфер-канат» на самом деле является лишь одним из двух необходимых этапов. Нам нужны оба этапа, чтобы сделать действительно хорошую работу. Если барабан-буфер-канат – двигатель производства, то управление буфером – это второй этап – контроль. Мы используем управление буфером, чтобы настраивать двигатель для достижения максимальной производительности.
В старом понятии планирования и контроля первый этап – барабан-буфер-канат – это этап планирования подхода, по сути, общее соглашение о том, как мы будем управлять системой. Второй этап, управление буферами, представляет собой систему контроля, которая позволяет нам постоянно контролировать эффективность системы. Однако я хочу зарезервировать слово «планирование» и слово «контроль» для вполне конкретных и устоявшихся функций в рамках решения, функций, которые мы будем исследовать дальше на этой странице.
Я хочу предложить выйти на новый уровень и вместо этого использовать термины «конфигурация» и «мониторинг». Используя эту терминологию, конфигурация представляет собой барабан-буфер-канат, а мониторинг – управление буфером. Давайте нарисуем это.
То, как мы настраиваем решение, то, как мы настраиваем барабан, буфер и канат будут определять характеристики и поведение системы в целом. Управление буфером позволяет нам отслеживать это поведение. Использование терминов «конфигурация» и «мониторинг» позволит провести более важное различие, как только мы представим концепции планирования и контроля. Я надеюсь, что это также прояснит некоторую путаницу, которая может существовать по поводу двойной роли управления буфером.
Имейте эту модель в виду, когда мы к ней вернемся. Однако теперь мы должны вернуться к нашему плану атаки и заняться разработкой решения.
Интересно? Тогда вперед.
Управление производством по ТОС
На онлайн-курсе вы познакомитесь с подходом Теории ограничений и сможете управлять своим предприятием более эффективно. Инструменты ТОС, такие как Барабан-буфер-канат, сокращают производственный цикл и незавершенное наполовину, а уровень выполнения заказов в срок достигает более 95%.
Тренер: В.В. Вальчук. Старт: Февраль 2025.
ПОДРОБНЕЕ1. Наш план атаки
На странице показателей мы представили концепцию наших «правил взаимодействия», которые должны определять систему, цель, необходимые условия, фундаментальные показатели и роль ограничений. Затем на странице процесса изменений мы представили концепцию нашего «плана атаки» – 5 фокусирующих шагов, которые позволяют нам определить роль ограничений. Давайте еще раз напомним о пяти фокусирующих шагах, определяющих процесс изменений:
- Найти ограничения системы.
- Решить, как использовать ограничения системы.
- Подчинить все остальное вышеуказанному решению.
- Расширить ограничения системы.
- Если на предыдущих шагах ограничение было устранено, вернуться к шагу 1, но не позволять инерции стать ограничением системы. Другими словами, не останавливаться.
Давайте также вернемся к нашей простой системной модели, которую мы до сих пор использовали в гораздо более общих терминах, и применим ее к барабану-буферу-канату. Как вы помните, в нем есть 4 раздела; начало, середина, приближение к концу и конец.
Наша система должна взаимодействовать с внешним миром, поэтому давайте нарисуем вход и выход. Сырье поступает на входе, а готовая продукция вытекает на выходе. В коммерческой среде входят продажи, а затраты вытекают, разница – прибыль – фиксируется системой. Эти потоки мы показывали ранее в разделе о показателях.
Теперь мы готовы к следующему этапу, первому шагу пятиэтапного метода фокусировки – поиску ограничения.
1.1. Найдите ограничения системы
Фактически мы знаем, где находится ограничение в нашей простой системе, представленной здесь, основываясь на обсуждении измерений в предыдущем разделе. Оно расположено ближе к концу процесса. Это совсем не необычное место для поиска ограничения. Подумайте об этом на мгновение. Если бы ограничение располагалось в начале, то все последующие этапы всегда были бы в ожидании работы. В этой ситуации руководство, скорее всего, будет закупать дополнительные мощности до тех пор, пока ограничение не будет перемещено дальше по процессу, а затем спрячет его в незавершенном производстве, чтобы оно больше не было видно.
Давайте нарисуем ограничение.
Как мы знаем, ограничение, самый медленный этап, определяет скорость, с которой может работать весь процесс. Поэтому ограничение становится «барабаном» барабана-буфера-каната.
Конечно, мы кое-что забыли – незавершенное производство (НЗП). Если наша модельная система должна быть чем-то похожа на нашу собственную реальность, то она, вероятно, до отказа заполнена незавершенным производством. Нам лучше добавить его и в нашу модель.
Незавершенное производство, конечно, служит полезной цели в такой системе; оно отделяет каждый этап от этапов до и после. Если вы не знаете, что защищать, то вы можете защитить все. Однако есть вероятность, что даже при всей этой защите работа, которая требовалась в тот момент, не была той работой, которая ждала в куче незавершенного производства. И, конечно же, это означает, что время, необходимое для прохождения любого задания по системе, намного больше, чем необходимо. В любом случае, нам больше не нужна вся эта незавершенное производство, если мы собираемся использовать барабан-буфер-канат.
Итак, мы завершили Шаг 1 – нашли ограничение. Следующий шаг, второй, – решить, как использовать это ограничение.
1.2. Используйте ограничения системы
Чтобы убедиться, что ограничение работает как можно лучше для задачи производства или создания прохода системы, мы должны убедиться, что мы используем его в полной мере – по сути, мы используем систему на полную мощность ограничения. Это означает не только обеспечить его полное использование, но и обеспечить всю возможную прибыль. Если вы вспомните задачу Голдратта P&Q или аналогию с авиакомпанией, вполне возможно использовать ограничение полностью, но не получить всю возможную прибыль.
Если мы увеличим выход ограничения, то увеличится и выход системы в целом. Одна из наиболее эффективных тактик использования однажды выявленного ограничения и улучшения его результатов – составить подробный график для этого конкретного ресурса и только для этого конкретного ресурса, а затем придерживаться этого графика. Это «план» в данном контексте. Наше ежедневное планирование «выпадает» из-за решений, которые мы принимаем при настройке внедрения. Давайте добавим это в нашу модель.
Теперь у нас есть локальный план только для одной точки, самой важной точки – барабана. Если в то же время мы сохраняем вход постоянным, то дополнительный выход от продолжения использования должен поступать из незавершенного производства, уже находящегося в системе. Тогда незавершенное производство и, следовательно, время выполнения заказов должны сократиться. Фактически мы начинаем осушать систему. Давайте это покажем.
Однако давайте внесем ясность: незавершенное производство не обязательно должно уменьшаться при использовании барабана-буфер-каната, но обычно для этого есть веские причины – сокращение времени выполнения заказов, повышение качества и увеличение производительности. Мы рассмотрим все это позже, в разделе запасов. Однако основная цель Теории ограничений всегда состоит в том, чтобы продвинуть систему к цели, и обычно это означает в первую очередь увеличение прохода. Сокращение запасов является вторичным и часто является следствием увеличения прохода.
Если мы продолжим работать таким образом, мы сможем значительно сократить незавершенное производство. Давайте покажем это, прежде чем представить некоторые дальнейшие концепции барабана-буфер-каната.
Фактически мы завершили второй шаг; мы решили, как использовать это ограничение. Мы использовали простой пример составления графика. Существует множество других способов использования ограничения, и некоторые из них упомянуты на следующей странице, посвященной деталям внедрения. Однако нам необходимо перейти к третьему шагу – подчинению ресурсов, не являющихся ограничениями.
1.3. Подчинение – защита ограничений системы
Иногда использование слова «защищать» облегчает понимание этого шага, по сравнению с использованием правильного термина «подчинять». Фактически мы подчиняем ресурсы не-ограничения, чтобы защитить ограничение и систему в целом. Давайте рассмотрим это немного подробнее.
На странице процесса изменения мы описали подчинение как избежание отклонения от нашего плана, и план в данном случае – это наш график использования ограничений на предыдущем шаге. Мы описали отклонение от плана как (2):
- Не делать того, что должно быть сделано.
- Делать то, чего делать не следует.
Поэтому мы можем описать подчинение как:
- Делать то, что должно быть сделано.
- Не делать того, чего не следует делать.
Делая то, что должно быть сделано в соответствии с нашим планом, мы защищаем ограничение и систему в целом. Более того, не делая того, что не следует делать в соответствии с нашим планом, мы также защищаем ограничение и систему в целом. Давайте рассмотрим это на нашей простой модели.
Поскольку мы израсходуем запас избыточного незавершенного производства, вполне вероятно, что ограничения начнут время от времени «голодать». Работа не будет доставлена вовремя, чтобы прибыть на ограничение по графику. Нам необходимо повсюду заменить нашу локальную безопасность (наше избыточное незавершенное производство) некоторой глобальной безопасностью именно там, где она необходима, т.е. перед ограничениями. Нам нужно буферизовать ограничение. Нам нужно сделать то, что должно быть сделано, чтобы защитить ограничение от дефицита.
Фактически, мы принимали бы решения о буферизации еще до того, как начали, и, следовательно, сокращали незавершенное производство и время выполнения заказов в соответствии с этими заранее определенными целями.
1.3.1. Правило первоначального определения размера буфера
Давайте на мгновение предположим, что время выполнения работы от начала процесса до начала ограничения составило 18 дней до внедрения. На самом деле, это может быть 18 часов для электроники или оформления страхового возмещения, или 18 недель для тяжелого машиностроения. Но давайте в этом примере воспользуемся днями. Эмпирическое правило состоит в том, чтобы сократить вдвое существующее время выполнения заказа (3). Таким образом, новое время выполнения заказа составляет 9 дней. Если сокращение вдвое времени выполнения заказа вам кажется слишком радикальным, это не так. Большую часть времени текущее незавершенное производство находится в очередях, где ничего не делается. Вы можете легко убедиться в этом сами: достаньте и пометьте какую-нибудь работу флажком, воздушным шариком или ярким цветом, а затем следите за ней. Она будет стоять. Этот 9-дневный период становится длиной нашего буфера.
К этому 9-дневному буферу мы применим второе практическое правило и разделим буфер на три равные зоны по одной трети каждая (4). Мы ожидаем, что большая часть работы будет завершена в течение первых двух третей и будет ждать перед ограничением в течение последней трети буферного времени. Таким образом, мы ожидаем, что наша работа займет около 6 дней обработки (и ожидания обработки) и 3 дня ожидания перед барабаном.
Если 3 дня ожидания перед ограничением вам кажется слишком долгим, то помните, что до внедрения ББК система позволяла работе ждать еще как минимум 9 дней. Девять плюс три – 12 дней ожидания. Что бы вы предпочли: 12 дней или 3 дня? Что еще более важно, что предпочтет ваш клиент?
Теперь мы можем защитить ограничение нашей системы, гарантируя, что для него всегда есть работа. Таким образом, мы обеспечиваем его эффективное использование – и с гораздо меньшими затратами материалов и сроком выполнения заказа, чем раньше.
Давайте добавим буфер на нашу диаграмму.
Давайте удостоверимся, что нам понятно определение буфера. «Для всех практических целей БУФЕР ВРЕМЕНИ – это интервал времени, на который мы запускаем работу раньше, относительно даты, на которую запланировано поступление этой работы на соответствующее ограничение (5)».
Будьте внимательны: на диаграмме выше мы нарисовали единицы времени – зоны и буфер – как пространство на нашей диаграмме. Не позволяйте этому сбить вас с толку. Зоны соответствуют времени, отведенному на предприятии для защиты операции, положение и функции которой имеют решающее значение для своевременности и выхода всего процесса. Зоны не соответствуют месту работы на заводе. Фактически, мы вскоре вернемся к этому и попытаемся нарисовать диаграмму более реалистично для представления времени.
Почему весь этот период от запуска материала до поступления на ограничения считается буфером? Шрагенхайм и Деттмер считают, что это один из двух уникальных аспектов буферизации в Теории ограничений. «Причина, по которой буферы определяются как все время выполнения заказа, а не только часть безопасности, заключается в том, что в большинстве производственных сред существует огромная разница между суммой чистого времени машинной обработки и общим временем выполнения заказа. Когда мы анализируем чистое время машинной обработки большинства продуктов, мы обнаруживаем, что оно занимает от нескольких минут до часа на единицу. Но время выполнения заказа может составлять несколько недель, а в лучших условиях – несколько дней. Следовательно, каждая единица продукта ожидает внимания где-то в цехе гораздо дольше, чем на самом деле требуется для работы над ней». «Поэтому имеет смысл не выделять чистое время машинной обработки, а рассматривать все время выполнения заказа как буфер – время, необходимое цеху для обработки всех заказов, которые он должен обработать (6)».
Другой уникальный момент заключается в том, что буферы, как мы уже упоминали, измеряются во времени. Компании, не использующие барабан-буфер-канат, рассматривают буфер как меру физических запасов; 6 работ, или 6 заказов, или 10 партий, или 4000 штук, или что угодно. В инструменте барабан-буфер-канат буфер ограничения является мерой времени; часы или дни работы на скорости ограничения, расположенной между входной операцией (запуском материала) и ограничением. Фактически, есть два способа взглянуть на буфер: либо с точки зрения отдельной работы, либо с точки зрения системы в целом. Давайте рассмотрим это на мгновение.
Предположим, для простоты, что все наши работы имеют одинаковую длину. Давайте предположим, что каждая из них занимает 1 день времени ограничения. В этом случае каждая работа имеет 9-дневный буфер для ограничения. То есть она запускается за 9 дней до запланированной даты поступления на ограничение. Это взгляд на одну работу. Если оглянуться назад, ограничение увидит 9 однодневных работ на разных этапах процесса; это точка зрения системы в целом.
Что будет, при прочих равных условиях, если все наши работы теперь занимают полдня на ограничении? Каждая работа имеет 9-дневный буфер, если вернуться назад, мы увидим 18 работ на полдня на разных этапах процесса, но совокупная нагрузка по-прежнему составляет 9 дней, это перспектива системы в целом.
Давайте проделаем это еще раз. Каждая работа теперь занимает четверть дня на ограничении. Каждая работа по-прежнему имеет 9-дневный буфер, ограничение, оглядываясь назад, увидит 36 работ по четверти дня на различных этапах процесса, но совокупная нагрузка по-прежнему составляет 9 дней с точки зрения системы в целом. Время является мерой буфера.
1.3.2. Почему размер и активность буфера ограничений определяются временем?
Давайте на мгновение задумаемся над этим вопросом, потому что это очень важно. Измерение буфера ограничений в единицах времени уникально для барабана-буфер-каната, поскольку признание существования единственного ограничения внутри процесса уникально для барабана-буфер-каната. Мы можем применить это как к размеру (или длине) буфера ограничений, так и к активности буфера ограничений.
Давайте сначала посмотрим на активность буфера ограничений.
Рассматривая только одну рабочую станцию, этап или процедуру, нам нужно знать только один набор средних значений времени для этого места или действия для всех различных типов единиц материалов, которые проходят через него. Мы могли бы посмотреть на это следующим образом:
На производственном ограничении час равен часу, но количество единиц может отличаться.
Количество физических единиц может отличаться, поскольку разные типы материала, использующие одно и то же ограничение, могут использовать разное количество времени ограничения. Фактически, даже один и тот же тип материала будет демонстрировать некоторую изменчивость, если только ограничение не является полностью автоматизированной процедурой, но они в основном будут усредняться.
А что насчет размера буфера ограничений?
Уникальная перспектива, возникающая благодаря обозначению единственного ограничения, позволяет нам также определить длину буфера во времени. По сути, размер буфера определяется, и он «видит» продолжительность от операции запуска до даты поступления на ограничение. Более того, буфер «видит» подтвержденный спрос – работу, которая уже была передана в систему. Буферы ограничений, расходящиеся/сходящиеся буферы контрольных точек, буферы сборки и буферы отгрузки имеют одинаковую базовую природу.
Может быть, так сказать гораздо проще:
Мы защищаем время (срок выполнения заказа) с помощью буфера времени.
Однако есть еще один тип буфера, с которым мы, вероятно, столкнемся в производстве – буфер запаса. На производстве эти буферы находятся в двух местах; на складе сырья/входящих товаров во всех производственных средах и на складе готовой продукции в среде производства на склад. На самом деле это буферы цепи поставок; они представляют собой два места, в которых цепь поставок должна взаимодействовать с производством – до начала процесса и после его завершения. Нам необходимо убедиться, что у нас всегда есть достаточный запас сырья до начала процесса для удовлетворения питания ограничения, а также нам необходимо убедиться, что у нас всегда есть достаточный запас готовой продукции после производства для удовлетворения спроса. Мы рассмотрим эти типы буферов ниже на этой странице. Они также более подробно рассматриваются на страницах цепи поставок, особенно на странице пополнения запасов. Однако давайте пока ограничимся буферами ограничений. Нам нужно разобраться с тем, что буфер ограничений является мерой времени. Давайте сделаем это.
1.3.3. Путешествие во времени
Многие люди говорят, что понимают определение буфера барабана или буфера ограничения, хотя на самом деле они этого не понимают. Слишком часто наш предыдущий опыт заставляет нас думать о буферах с точки зрения физических запасов, и слишком часто мы рассматриваем красную зону как «буфер». Давайте посмотрим.
Буфер – это вся продолжительность (3 зоны) той части системы, которую защищает буфер.
Я переусердствовал? Я так не думаю. Здесь можно найти дополнительную информацию о постоянном неправильном понимании буферов в инструменте барабан-буфер-канат.
Частично это связано с нашим предыдущим опытом производства с системами MRP II и выталкиванием продукции, которое имеет тенденцию закрывать глаза на нашу интерпретацию (см. разделы «Буфер ограничения» и «Аргумент локальной безопасности» на следующей странице – Детали внедрения – для дальнейшего развития этого аспекта.) Частично проблема заключается также в том, как мы пытаемся изобразить время как пространство на наших простых схематических представлениях. Единственный способ нарисовать время — это нарисовать последовательность диаграмм. Давайте сделаем это.
Мы проследим часть работы – по одному дню – через процесс до барабана. Мы будем использовать наш 9-дневный буфер, поэтому этот фрагмент работы представляет собой работу барабана в течение одного дня, находящегося в 10 днях от запланированной даты обработки. В нашем срезе 5 продуктов (единиц, работ, партий и т.д.). Продукты у нас «сиреневый», «красный», «зеленый», «синий» и «оранжевый». Временной интервал, для ясности в этом примере, представляет собой дни, а не более точное значение часов или минут, которое мы могли бы ожидать в реальности.
Представьте себе, что внутри подразделений («начала» и «середины») нашего общего процесса у нас есть инструменты конкретной профессии: столы для работы с документами; или приемное отделение, койки, клинические отделения в больнице; или рабочие центры в производственной системе. Эти 5 продуктов могут в любой момент находиться в ожидании, перемещаться между работами или быть в обработке. Эти подробности здесь для нас не важны.
Вероятно, накануне даты запуска планировщик знает, что будет запущено. Планировщик может даже видеть и ожидающие, но не запущенные заказы (и, надеюсь, о них не известно в цеху – чтобы люди не начали работать раньше времени). Давайте нарисуем это.
Заказы могут существовать в плане, но они еще не запущены. Мы рисуем наши продукты за пределами начала системы, даже если в настоящее время они физически не присутствуют, кроме как на бумаге или в виде записи в графике.
Мы также нарисовали временную шкалу. Она окрашена в соответствии с буферными зонами: зеленая зона, оранжевая или желтая зона, красная зона.
В первый день графика все продукты запускаются (как запланировано) и находятся в зеленой зоне нашего временного буфера. Их физическое расположение в конце дня выглядит следующим образом.
Сиреневая работа может быть маленькой партией или простым процессом, который завершается быстро, она продвигается дальше (а может быть, и быстрее), чем остальные.
Спустя еще один день мы достигли дня 2, но мы все еще в зеленой зоне буфера, и процесс выглядит следующим образом.
Мы видим, что красная работа переместилась сравнительно быстро относительно остальных, а синяя вообще не сдвинулась. Как это произошло? Разные работы проходят по разным маршрутам и имеют разное время ожидания (из-за других работ перед ними) и разное время обработки (либо из-за разного размера партии, либо из-за разной работы). И, конечно, иногда дела идут не так, как планировалось; у нас простои, люди прогуливают, и «всякое случается».
В четвертый день, через день после начала желтой зоны буфера, мы видим, что работа развивалась следующим образом.
Синяя работа до сих пор не сдвинулась с места, однако остальные прогрессируют хорошо.
На следующий день, день 5 (желтая зона буфера), работа выглядит так.
Зеленая и красная работы завершены, сиреневая и оранжевая работы продвигаются хорошо, а синяя, наконец, продвигается вперед.
В конце 6-го дня – последнего дня желтой зоны буфер мы видим следующее.
Три из пяти работ завершены к концу буферной зоны 2, а две отстают. Поскольку конец 6-го дня – это начало 7-го дня и первого дня красной зоны, мы имеем проникновение в буфер. Две работы, которые должны были завершиться к настоящему времени, еще не завершены. Их необходимо обнаружить и оценить, чтобы гарантировать, что они достигнут ограничения в оставшееся время.
Давайте подойдем к концу седьмого дня и посмотрим, что произошло.
Сейчас выполнено 4 работы. Сиреневая работа была завершена где-то на 7-й день. Синяя работа будет обнаружена и проверена на предмет соответствия графику и доступности на барабане к концу 9-го дня – последнего дня красной зоны – или, желательно, раньше. Мы бы предпочли, чтобы большинство заданий было завершено к концу шестого дня, но иногда «всякое случается», и не все задания выполняются к этому моменту. Синяя работа может потребовать некоторой «помощи» или «экспедирования» для ее завершения.
Давайте теперь посмотрим на ситуацию на 8-й день.
Уф! В конце 8-го дня (остался всего один день) мы обнаруживаем, что все задания завершены и ожидают обработки на ограничении в соответствии с его графиком на 10-й день. Красная зона буфера пронизана на целых 2 дня синей и на 1 день сиреневой работой. Однако теперь барабан полностью защищен, и график работы барабана не будет нарушен, наши стратегии использования полностью защищены за счет адекватного подчинения других ресурсов.
Итак, давайте повторим еще раз:
Буферные зоны соответствуют времени, отведенному на заводе для защиты операций, положение и функции которых имеют решающее значение для своевременности и производительности всего процесса, буферные зоны не представляют собой физическое место работы на заводе.
Мы знаем, как защитить ограничение, теперь давайте посмотрим, как защитить все остальное.
1.3.4. Подчинение – защитим все остальное
Итак, теперь мы знаем, как защитить ограничение с помощью буфера, поэтому мы знаем, как выполнить первую часть подчинения – сделать то, что мы должны сделать, чтобы защитить ограничение. Теперь нам нужно рассмотреть вторую часть подчинения – не делать того, чего не следует делать.
Для начала давайте повторим диаграмму, которую мы впервые нарисовали перед путешествием по буферу.
Барабан, входная операция и отгрузка стабильны. То есть теперь все они работают в одном темпе, в ритме барабана. Если нам удалось использовать это ограничение и увеличить скорость и выход ограничения, а спрос увеличился вследствие сокращения времени выполнения заказа, то на этом этапе необходимо также увеличить скорость входа, чтобы она соответствовала ритму барабана, тогда незавершенное производство и буфер остаются стабильными.
Чтобы поддерживать стабильность в этой системе, скорость, с которой входная операция позволяет запускать в систему новую работу, должна быть такой же, как скорость потребления на барабане. Что произойдет, если наше ограничение на короткое время остановится? У него нет резервной мощности, поэтому мы не можем ускорить его (позволить ему работать дольше), чтобы снова наверстать упущенное. Если мы продолжим запускать работу так, как будто ничего не произошло, незавершенное производство немного увеличится. Вероятно, недостаточно, чтобы это заметить, но через пару подобных случаев оно начало бы накапливаться. Таким образом, нам необходимо убедиться, что мы запускаем новую работу в систему с той же скоростью, с которой ее потребляет ограничение. Ограничение, как мы знаем, – это «барабан» нашей системы, отбивающий скорость, с которой работает вся система, включая операцию запуска. Скорость сообщается на вход системы или первой операции с помощью «каната». Нам нужно добавить это на нашу диаграмму.
Если угодно, график работы «шлюза» – входной операции – это график смещения барабана на длину каната. Длина каната равна продолжительности буфера; скорость входа такая же, как и скорость барабана. «Привязывание» каната между барабаном и входом гарантирует, что ненужная работа не будет запущена, или нужная работа не будет запущена слишком рано. Это неделание того, чего не следует делать, чтобы защитить систему от избыточного незавершенного производства. Избыточное незавершенное производство приводит к увеличению срока выполнения заказов больше, чем необходимо, и снижению качества. В конечном итоге избыточное незавершенное производство также влияет на проход ограничения.
Другой способ взглянуть на канат – рассматривать его как петлю обратной связи в реальном времени между барабаном и входной операцией.
Хотя ограничение не может восстановиться после простоя, следовательно, необходимо использовать и защищать его, не-ограничения могут восстановиться после простоя. Обычно части нашей системы, не являющиеся ограничениями, не работают с той же скоростью, что и вся система – по крайней мере, в течение коротких периодов времени. У не-ограничений есть способность к спринту. Они могут выполняют больше работы, когда это необходимо, чтобы наверстать упущенное после «удара» в системе, работая с нормальной скоростью в течение более длительных периодов времени. Они также могут делать меньше работы, когда в ней нет необходимости, работая с нормальной скоростью в течение более коротких периодов времени.
Мы могли бы рассматривать увеличение продолжительности работы не-ограничений (чтобы наверстать упущенное) как первую часть подчинения «делать то, что необходимо», а сокращение продолжительности работы не-ограничений (чтобы избежать перепроизводства) как вторую часть подчинения «не делать то, что не нужно». Крайне важно, чтобы мы это сделали.
В производственной системе Toyota канбан выполняет обе эти функции. В инструменте барабан-буфер-канат это реализуется по концепции «эстафетчика». Когда у нас есть эстафетная палочка (работа), мы бежим (делаем). Когда у нас нет работы, мы ее не делаем. Мы видели это в виде аналогии со светофором ранее на странице, посвященной процессу изменений. Не-ограничения никогда не должны «замедляться», они должны быть либо полностью включенными, либо полностью выключенными (возможно, это должно быть нормально включенное или нормально выключенное состояние). Либо создание прохода, либо его защита. Мы вернемся к этой теме на следующей странице о внедрении.
Мы видели, что в нашем примере теперь у нас есть 9 дней незавершенного производства – по сравнению с первоначальными 18 днями. В зеленой и желтой зонах не завершены 6 дней, а в красной зоне – три дня. Но можно подумать и по-другому. Сократив вдвое незавершенное производство, мы удалили из системы 3/6 работы. У нас есть еще одна шестая часть, ожидающая перед ограничением, так что, по сути, у нас есть только 2/6 или 1/3 нашего предыдущего незавершенного производства, которое фактически находится в цеху и активно обрабатывается или ожидает в очередях. Представьте себе, что ваш процесс существует сегодня, но только 1/3 работы активно выполняется не-ограничениями или находится в стадии ожидания; разве в такой ситуации дела не начнут идти своим чередом?
Тем не менее, для того чтобы поток работы шел, критически важно защитить «спринтерские» мощности за счет правильного подчинения. Спринтерские мощности зависят от общего размера буфера и, следовательно, от срока выполнения производственного заказа. В следующем разделе мы подробнее рассмотрим спринтерские мощности. Защита спринтерской мощности означает, что мы никогда не запускаем работу в процесс только для того, чтобы люди были заняты – никогда.
Конечно, вы заметили, что до сих пор мы использовали «локальную» версию нашей системной модели. В какой-то степени это было сделано намеренно, потому что, когда вы впервые приступаете к внедрению барабана-буфер-каната, процесс будет разделен по подразделениям. Однако то, что нам хотелось бы увидеть через некоторое время, – это лучшее понимание системы в целом.
Концептуально это должно выглядеть примерно так:
До сих пор мы игнорировали часть процесса после ограничения – обычно от ограничения до отгрузки при производстве на заказ или на склад при производстве на склад. Эта часть процесса привязана к дате отгрузки вторым канатом, который чаще всего называют «канатом отгрузки». Именно этим канатом барабан привязан к рыночному спросу. Таким образом, теперь мы можем быть уверены, что в систему поступает ровно столько нового материала, сколько необходимо для защиты и удовлетворения потребление барабана, что, в свою очередь, удовлетворяет рыночный спрос. Мы не позволяем работу, на которую нет спроса. Поэтому мы действительно подчинили все остальное ограничению.
Для буфера отгрузки мы снова применяем те же практические правила, которые мы использовали для буфера ограничения. Предположим, ради простоты математических вычислений, что процесс от ограничения до отгрузки в настоящее время занимает 6 дней. Мы сократим эту цифру вдвое, чтобы получить новое время выполнения заказа – 3 дня. А затем мы разделяем это время на буферные зоны по трети и ожидаем, что почти все работы будут завершены через 2 дня и либо будут ждать отгрузки, либо уже будут отправлены за 1 день до даты отгрузки.
Вот к чему мы приходим:
Теперь наша дата отгрузки или дата поставки защищены так же хорошо, как и ограничение. Поэтому нам следует ожидать очень хороших своевременных поставок или исполнения обязательств в установленные сроки. Это, конечно, особенно важно для компаний, производящих продукцию на заказ, и чаще всего является определенным конкурентным преимуществом.
Таким образом, наш первоначальный 24-дневный процесс становится 12-дневным. Система должна быть в состоянии производить больше, потому что мы приложим все усилия, чтобы использовать ограничение, а не-ограничений работают только с материалом, который необходим для поддержки графика ограничений.
Итак, подведем итог: подчинение – это инструкция не-ограничениям. Он состоит из двух основных компонентов.
Во-первых, чтобы защитить систему в целом, ограничения не должны голодать – мы не должны недогружать систему. Это обеспечит максимальный выход в соответствии со стратегией использования ограничения. Конечно, мы могли бы сделать буфер достаточно большим и никогда не беспокоиться об истощении ограничения, но именно в этом сегодня находится большинство систем (и они по-прежнему истощают ограничение). Поэтому нам нужно сделать и что-то еще.
Во-вторых, чтобы защитить систему в целом, мы не должны заполнять не-ограничения – мы не должны перегружать систему. Это обеспечит достаточную спринтерскую мощность для обеспечения максимального выхода в соответствии со стратегией использования ограничения и выполнения сроков выполнения заказов. Это также позволит значительно сократить срок выполнения заказа.
Таким образом, мы рассмотрели все три аспекта: барабан, буфер и канат. Мы также рассмотрели первые три шага из 5 фокусирующих шагов: найти, использовать и подчинить.
Если мы полностью воспользовались рычагом воздействия и подчинили все остальное, то следующее, что нужно сделать, – это расширить ограничение. Но сначала давайте рассмотрим альтернативное правило определения первоначального размера буфера.
1.3.5. Альтернативное правило первоначального размера буфера
До сих пор мы определяли первоначальные размеры буфера как 50% от существующего срока выполнения заказа для той части системы, которую мы хотели защитить. Есть еще одно менее известное правило, которое мы также можем использовать. Мы можем установить 3 времени бэк-то-бэк для выполнения работы по пересечению той части системы, которую мы хотим защитить. (We can take 3 times the back-to-back time for a job to transverse that part of the system that we wish to protect.)
Время от времени выполнение работ ускоряется по ряду причин, поэтому люди будут знать на собственном опыте или иметь хорошую интуицию о времени бэк-то-бэк, и на основе этого можно получить продолжительность буфера.
1.4. Расширьте ограничения системы
Расширение может потребовать некоторых дополнительных инвестиций для приобретения дополнительных мощностей, которые обеспечат дополнительный проход, желательно более чем пропорционально. Помните, что мы пытаемся отделить проход от операционных затрат, тем самым повышая продуктивность и прибыльность:
Мы также знаем, что расширение чаще всего является тем местом, с которого начинают сторонники редукционистского подхода / локальной оптимизации, однако расширение – это то место, где сторонники системного подхода / глобальной оптимизации доходят до конца. Поступая таким образом, вы потратите меньше, конечно, вам придется подумать – но тогда это просто здравый смысл – и вы заработаете больше денег или увеличите выпуск продукции. Если мы не отделим проход в коммерческих организациях и выход в некоммерческих организациях от операционных затрат и инвестиций, то мы просто не сделаем хорошо свою работу.
1.5. Если ограничение устранено, вернитесь назад
Если в какой-то момент ограничение устранено, мы должны искать следующее ограничение. На самом деле мы должны знать из управления буфером, где оно будет, еще до того, как доберемся туда. Однако во многих случаях первоначальные физические ограничения устраняются, и их место занимают политические проблемы. Предостережение Голдратта – не позволять инерции становиться ограничением системы – это призыв посмотреть, какая политика мешает нам двигаться вперед. На самом деле это призыв: «Не останавливаться!».
1.6. Некоторые тонкости определений
Для новичков есть несколько ловушек. Некоторые определения со временем изменились. В данном случае быть предупрежденным значит быть вооруженным, давайте так и сделаем. Здесь мы использовали термин «барабан» для описания объекта, определяющего скорость работы всей системы – будь то внутреннее ограничение или, как мы увидим, внешний рыночный спрос. Однако термин «барабан» также используется для описания графика барабана, и некоторые настаивают на том, что барабан – это график. Очевидно, когда ограничением является рынок, это определение имеет смысл. Оба определения используются, и некоторые могут утверждать, что эти разные определения являются просто разными проявлениями одной и той же концепции. Если мы примем это, то это должно сделать всех счастливыми.
Аналогичным образом, здесь используется «канат» для описания смещения между барабаном и входным процессом; однако на него также распространяется более строгое определение «график входа». Опять же, это разные проявления одной и той же концепции. Они не являются критически важными.
2. Управление буфером – производство на заказ
На данный момент мы рассмотрели разработку решения «барабан-буфер-канат» – нашего двигателя производства – и сделали это в рамках нашего пятиэтапного фокусирующего процесса. Мы также представили модель настройки и мониторинга этого решения, к этому мы добавили аспект локального планирования – наш график использования барабана. Давайте повторим здесь модель и отметим, что мы рассматриваем конкретный случай производства на заказ.
Теперь нам нужно разработать часть мониторинга модели; нам нужно заняться управлением буфером. Теперь мы знаем, что такое буферы, и знаем их назначение, однако нам все еще нужно лучше знать, как интерпретировать и использовать информацию, которую они могут предоставить. Для этого, я считаю, мы должны разделить их воздействие на две отдельные функции. Они заключаются в следующем:
- Локальный контроль: ежедневные отчеты об исключениях, которые указывают, когда может произойти потенциальное нарушение срока выполнения заказа.
- Глобальная обратная связь: отчеты о долгосрочных тенденциях, которые предполагают, что размер определенного буфера необходимо изменить, чтобы он стал полностью эффективным.
Управление буфером имеет решающее значение; оно фильтрует важные сигналы из повседневного шума системы, тем самым предупреждая нас о потенциальных проблемах до того, как они станут реальными, и обеспечивает самодиагностику того, что в каждом случае не предоставляется ни слишком большая, ни слишком малая защита. Самодиагностика учитывает нашу конфигурацию и помогает улучшить общую динамику внедрения.
Давайте изменим нашу модель, чтобы включить все это.
Таким образом, у нас все еще есть планирование и контроль, но они локальны и находятся в контексте общего плана внедрения. Шрагенхайм и Деттмер дали важное определение контроля, давайте повторим его здесь (7):
«Реагирующий механизм, который справляется с неопределенностью, отслеживая информацию, указывающую на угрожающую ситуацию, и предпринимая соответствующие корректирующие действия до того, как угроза будет реализована».
Я надеюсь, что разделение управления буферами на локальный контроль и глобальную обратную связь облегчит понимание этой важной концепции.
Давайте теперь исследуем различные этапы локального контроля, а затем глобальную обратную связь в среде производства на заказ.
2.1. Локальный контроль – статус (состояние) буфера
Мы запускаем работу на длину каната раньше установленного срока в той точке, которую защищает буфер. В большинстве случаев этого более чем достаточно, чтобы гарантировать своевременную доставку работы. Но, как мы знаем, всякое случается. Нам нужен некоторый локальный контроль, чтобы гарантировать, что, когда что-то произойдет, мы знаем правильный приоритет, чтобы вернуть систему в состояние стабильности. Нам необходимо знать статус текущих заказов производства на заказ, которые уже переданы в систему для работы.
Шрагенхайм определяет статус буфера следующим образом (8):
Статус буфера = (Продолжительность буфера – Оставшаяся продолжительность) / Продолжительность буфера
Статус буфера является синонимом потребления буфера.
Давайте посмотрим на пример. Здесь у нас есть статус буфера для 6 работ, которые должны быть выполнены в течение следующих 5 дней.
Работы 1, 3 и 5 на сегодняшний день завершены. Для работ 3 и 5 это означает, что они были завершены своевременно, а состояние их буфера на момент завершения составляет менее 66%. Работа 1, хотя и завершена, видимо, была проблематичной день или около того назад, поскольку ее статус буфера достиг 78%, однако теперь она завершена и больше не является проблемой.
Из текущих работ, работа 6 со статусом буфера 44% не является проблемой, мы должны оставить ее в покое. Однако работы 2 и 4 имеют статус буфера 89% и 66%. Они обе начали проникать в красную зону. Которая из этих двух является более приоритетной? Очевидно, это работа 2; она имеет большее значение статуса буфера, и именно на ней нам следует в первую очередь сфокусировать свое внимание.
Таким образом, статус буфера определяет статус заказа-наряда после того, как работа была передана в систему. Поэтому мы осуществляем локальный контроль в порядке исключения для достижения наших глобальных целей. Статус буфера рассматривается с точки зрения отдельного задания.
Хорошо, но у нас есть короткие канаты и длинные канаты.
Что же, если у нас есть короткие и длинные канаты, это, конечно, все усложняет? Опять же, статус буфера позволяет напрямую сравнивать заказы-наряды, имеющие разную длину буфера в рамках одного и того же процесса. Давайте посмотрим.
У нас в системе есть работы с тремя разными длинами канатов – 9, 6 и 3 дня. Более короткие работы обычно требуют гораздо меньше процессов, чем более длительные. Некоторые короткие работы, например работа 4, будут запущены позже и закончатся раньше, чем более длинные работы, например работы 5 или 6. Тем не менее, мы знаем, какие работы требуют внимания; те, которые потребили первые две зоны и проникли в красную зону буфера. Тем, кто находится в желтой зоне, может потребоваться наблюдение, но мы оставляем их в покое, чтобы не вмешиваться в процесс – а мы бы не хотели этого делать.
Не путайте короткие и длительные работы со «срочными» и «стандартными» заказами. Эта конкретная приоритезация происходит в очереди заказов, а не во время выполнения заказа.
2.2. Локальный контроль – статус заказа-наряда
Тогда в системе производства на заказ, где существует обязательство уложиться в срок:
Текущий статус заказа-наряда = Статус буфера
Это утверждение может показаться излишним, однако оно станет яснее, когда мы будем иметь дело с производством на склад. В условиях производства на склад статус заказа на складе может меняться с течением времени из-за естественной вариабельности самого процесса, а также из-за изменения рыночного спроса. Этот дополнительный фактор отсутствует в сфере производства на заказ, здесь у нас есть обязательства, и мы должны их выполнить.
2.3. Локальный контроль – приоритет запуска нового заказа-наряда
Вы когда-нибудь были в ситуации, когда у вас есть хороший работоспособный график – все критические места удовлетворены (все «скрипящие колеса» смазаны), а затем кто-то объявляет: «Знаете, материал, который должны были отгрузить сегодня утром, на самом деле не отгрузили!». Чем вы теперь планируете заняться? Сегодня утром эта работа приостановлена на входе, у вас ее нет, а сегодня пятница перед длинными выходными. Звучит невероятно? Нисколько.
Официально можно подождать. Вы можете подождать, пока не будет использовано до 50% буфера для следующего этапа. До тех пор работу еще можно запустить, после этого ее необходимо перенести в графике.
Фактически, та же логика может быть применена при обратном планировании от даты отгрузки. Иногда обязательства перед разными клиентами и/или разная длина канатов приводит к конфликту, когда более чем одна работа одновременно требуют ограниченного ресурса.
Одно из решений – начать работу на ограничении даже раньше, чем требуется. Если конфликт все еще существует, то некоторые работы, возможно, придется начать позже, чем нам хотелось бы; по сути, поздний запуск выталкивает эту работу, и она начинает потреблять часть своего буфера отгрузки. Опять же, пока израсходовано не более 50% буфера отгрузки, работа может быть продолжена, в противном случае обязательства перед клиентом должны быть пересмотрены – срок выполнения заказа должен быть перенесен дальше (9).
Сделав еще один шаг назад, та же логика применяется, в свою очередь, при обратном планировании от даты барабана до запуска материала, теперь по другой причине, чем задержка материала; мы можем применять те же правила, что и раньше. На самом деле это скорее локальное планирование, чем локальный контроль, но сейчас это легче понять, чем раньше.
2.4. Локальный контроль / глобальная обратная связь – проникновение заказа-наряда в красную зону буфера
Мы хотим оградить наших клиентов от вариабельности и зависимости внутри нашей системы. Мы можем сделать это двумя способами:
- правильное подчинение, чтобы не-ограничения имели адекватную спринтерскую мощность,
- буферизацию, чтобы даже когда спринтерские мощности по какой-либо причине исчерпаны (иногда такое случается), у нас все еще было некоторое время для безопасности в запасе.
Конечно, мы перенесли нашу локальную безопасность отовсюду в несколько отдельных и важных мест, где она принесет максимальную пользу.
Статус заказа-наряда (наш статус буфера) сообщает нам в режиме реального времени, когда необходимо помочь заказу и в каком приоритете мы должны это делать, если одновременно требуется помощь более чем одному заказу-наряду. Это локальное, немедленное и упреждающее действие. Когда состояние буфера превышает 66%, израсходовало более 2/3 буфера, обычно мы говорим, что работа проникла в красную зону.
Пока заказ не выполнен и не поступил на вход буфера, мы не знаем, на какую «глубину» он проник в красную зону. Однако, как только заказ выполнен и известна степень проникновения, мы можем назвать эту степень проникновения «дырой в буфере». Давайте нарисуем это.
Дыры в буфере – это наш показатель стабильности системы. Они глобальны, совокупны и историчны. Тенденции в поведении буферных дыр предупреждают нас об изменениях в динамике системы. Каспари и Каспари особенно хорошо рассматривают этот аспект (10).
Какова тогда приемлемая частота появления дыр в буфере? В относительном смысле дыры в буфере не должны быть ни слишком частыми, ни слишком редкими (8). Более конкретное предположение – что-то менее 10% (11). Очевидно, что дыры в красной зоне буфера работают только в ограниченном числе случаев. Это прекрасный пример отчета об исключениях. В конце концов, нам нужна надежная система, а не та, с которой нужно нянчиться каждый час.
Если мы возьмем наш пример с 9-дневным буфером ограничения, мы ожидаем, что большинство заданий будут завершены до истечения 6 дней и будут ожидать перед ограничением за 3 дня до запланированной даты работы. Что касается немногих оставшихся, мы должны пойти и поискать их на предыдущих операциях, чтобы гарантировать, что они достигнут ограничения до запланированной даты работы. Если мы затем посмотрим на совокупные данные, скажем, для 25 рабочих мест с уровнем возникновения дыр в буфере примерно 5%, то эти данные могут выглядеть примерно так:
Мы обнаружим, что большинство заказов-нарядов прибыло в желтую зону буфера, а некоторые даже прибыли в зеленую зону. Однако в данном случае 2 заказа-наряда проникли в красную зону. Именно проникновения в красную зону и есть наши дыры в буфере.
Дыры в буфере рассматриваются с точки зрения системы в целом.
2.5. Локальный контроль / глобальная обратная связь – показатели выполнения заказов-нарядов
На основе данных дыр в буфере мы можем построить более значимый показатель. В разделе показателей мы обсудили два локальных показателя эффективности: единиц-дни опоздания и единиц-дни ожидания. В коммерческой среде они известны как «долларо-дни прохода» (опоздание) и «долларо-дни запасов» (ожидание). Я предпочитаю добавлять к этим показателям «опоздание» и «ождание», потому что тем, кто незнаком с этими терминами, трудно понять, что они означают или их значение. И эти два показателя настолько важны для общего успеха системы «барабан-буфер-канат», что мы не можем позволить себе терять людей из-за неясной терминологии.
Непосредственным последствием дыры в буфере является отправка «менеджера буфера» на поиск нарушающей работы и обеспечение того, чтобы она действительно была выполнена на ограничении в нужный момент. В первую очередь нас действительно интересует только одно: возникла ли проблема – дыра в буфере – и требует ли эта проблема помощи или нет. Однако нам необходимо лучше оценить эту ситуацию количественно, как только она будет исправлена: была ли она сокращена на 1 день, или на 2 дня, или на сколько дней. И была ли эта работа ценной для компании или нет. Другими словами, был ли это большой или ценный заказ-наряд, который опоздал очень сильно, или маленькая работа, которая лишь немного опоздала в красную зону буфера. Умножение конечного опоздания в красной зоне на проход дает нам правильный ответ – опоздание в долларо-днях прохода. Это дает нам представление о серьезности проблемы.
Теперь давайте рассмотрим другую сторону уравнения – запасы. Вы когда-нибудь отправляли материал аутсорсерам, который, похоже, не хотел возвращаться? «Я знаю, что мы говорили об этой неделе, но один из парней ушел, и теперь ваш заказ будет готов на следующей неделе». Даже небольшие работы у аутсорсера могут иметь серьезные последствия, если они препятствуют отгрузке выполненной во всем остальном работы. Конечно, мы учтем это в наших буферных дырах и с точки зрения показателя опоздания в долларах-днях прохода. Однако иногда ответом является добавление дополнительной работы на всякий случай, чтобы защититься от этого в будущем. Иногда люди соглашаются на новую работу, чтобы держать определенный рабочий центр «занятым». Иногда области после ограничений не всегда стараются продолжать работу. Мы можем защититься от такого рода инцидентов с помощью другого нашего локального показателя – ожидания в долларо-днях запасов. С помощью этого показателя эффективно фиксируются добавление или выполнение работ, которые все еще могут быть выполнены вовремя. Более того, его можно применять к подразделам всего процесса. Это помогает не дать «белкам» в бизнесе хранить запасы на всякий случай.
Опоздание в долларо-днях прохода и ожидание в долларо-днях запасов – это два показателя, которые эффективно позволяют нам контролировать стабильность системы. Это локальные показатели, имеющие последствия для глобальной обратной связи. Всего два показателя. Вы не могли бы желать лучшего, не так ли? Хорошо, некоторые пожелали бы одного показателя, и они могут быть недовольны, но нам придется потерпеть два.
2.6. Глобальная обратная связь – изменение размера буфера заказа-наряда
Если дыры в буфере начнут возникать в красной зоне значительно чаще или реже, чем наш целевой уровень, мы должны сделать одно из двух: отрегулировать буфер или отрегулировать спринтерскую мощность. Из этих двух настроек настройка буфера является наиболее быстрой и простой. Мы просто меняем политику в отношении размера буфера и соглашаемся на небольшое увеличение/уменьшение общего объема незавершенного производства и срока выполнения производственного заказа. Мы также можем использовать эквивалентный показатель задержки в долларо-днях прохода, чтобы отслеживать эту потребность.
Если тенденция к появлению дыры в буфере начинает «появляться», но еще не слишком беспокоит, то это может указывать на снижение спринтерской мощности в системе и область этого снижения, или это может указывать на какую-то особую причину – машину, качество или операционную систему. Причину проблемы следует выявить, отследить и по возможности устранить. Определенно бывают случаи, когда дыры в буфере возникают из-за какого-то безобидного изменения в процессе: «мы использовали другой клей, потому что он был дешевле», что имеет неожиданные последствия в дальнейшем, «но теперь мы тратим больше времени на удаление следов клея». Возникающие дыры в буфере также указывают на потенциальные будущие точки ограничения. Мы рассмотрим эти факторы более подробно на странице, посвященной деталям внедрения.
Управление буфером – это аспект мониторинга нашей модели внедрения и мониторинга. Он обеспечивает как локальный контроль, так и, что, что более важно, обратную связь на глобальном уровне в нашей базовой конфигурации барабан-буфер-канат. Мы «настраиваем» базовые параметры только тогда, когда поведение системы говорит нам, что нам нужно это сделать. Мы делаем только то, что должны делать, и не делаем того, чего не должны делать.
Если мы продолжим применять наш план атаки, наши 5 фокусирующих шагов, то неизбежно на каком-то этапе мы расширим ограничение нашей системы, так что оно переместится на рынок. Что нам делать потом? Давайте посмотрим.
2.7. Рыночное ограничение
Если узким местом системы является рынок, то мы должны относиться к рынку как к ограничению и подчинить наш процесс рынку-ограничению (теперь его лучше всего называть контрольной точкой). Это означает производить только то, что нужно рынку, и не производить то, в чем рынок не нуждается (перепроизводство). По сути, барабан сейчас находится на рынке, но мы можем визуализировать это, разместив барабан на отгрузке – желаемый срок поставки для клиентов.
На самом деле это своего рода «старомодное» мышление. Подождите немного, я постараюсь объяснить вам более подробно.
Видите ли, контрольная точка, наше внутреннее самое слабое звено, на самом деле уже не так уж важна, фактически в следующем разделе мы увидим, как вообще работать без явного планирования контрольной точки. Хотя самое слабое внутреннее звено больше не является критическим, оно по-прежнему играет центральную роль в нашей работе. Это становится нашей точкой опоры.
Конечно, соблазнительно предположить, что наша точка воздействия должна находиться там, где мы поставили барабан; то есть срок, требуемый заказчиком. В конце концов, это точка взаимодействия внутренней системы и внешнего рынка. Это, безусловно, то место, где мы можем максимизировать рычаги воздействия. Мы можем легко проверить это в отрицательном смысле, просрочив несколько заказов. Мы знаем, какой будет реакция рынка. Возможно, было бы лучше рассматривать этот интерфейс между внутренней системой и внешним рынком как точку перехода. Мы еще раз рассмотрим точки перехода на странице введения к цепи поставок.
Если мы вернемся к нашей логике, то обнаружим, что характеристики нашего соблюдения даты исполнения обязательств по-прежнему определяются нашим внутренним самым слабым звеном. Чем больше разница между дополнительной мощностью внутреннего слабого звена и рыночным спросом (величина, на которую внутренние мощности превышают внешний спрос), тем меньше буфер и тем короче время производственного цикла. И наоборот, чем меньше разница, тем больше буфер и дольше время производственного цикла. Важна характеристика своевременности системы; этот аспект мы рассмотрим более подробно позже на странице парадигм. А пока будем уверены, что именно взаимодействие внутреннего слабого звена всей системы определяет эту характеристику. Именно здесь мы используем всю систему.
Как только на рынок станет ограничением, мы должны сделать все возможное, чтобы постоянно увеличивать рыночный спрос, одновременно увеличивая внутренние мощности – чтобы сохранить ограничение внутри рынка и иметь возможность обеспечить этому рынку очень высокий уровень обслуживания. На самом деле наш уровень обслуживания должен быть намного лучше, чем у кого-либо еще – и так оно и будет!
В условиях рыночных ограничений мы можем продолжать использовать барабан-буфер-канат с рыночным барабаном и внутренней запланированной контрольной точкой, называемый традиционным барабан-буфер-канатом, или мы можем начать использовать более позднюю разработку, называемую «упрощенным барабан-буфер-канатом» или УББК (12). Упрощенный барабан-буфер-канат лежит в основе решения Теории ограничений для производства на склад – и именно к этому мы движемся дальше – поэтому давайте сначала исследуем упрощенный барабан-буфер-канат в нашей более знакомой среде производства на заказ.
Продолжение следует…
Литература
1. Newbold, R. C., (1998) Project management in the fast lane: applying the Theory of Constraints. St. Lucie Press, p. 149.
2. Goldratt, E. M., (1990) The haystack syndrome: sifting information out of the data ocean. North River Press, p. 146.
3. Goldratt, E. M., (1997) Critical chain. The North River Press, p. 149.
4. Stein, R. E., (1996) Re-engineering the manufacturing system: applying the theory of constraints (TOC). Marcel Dekker, p. 143.
5. Goldratt, E. M., (1990) The haystack syndrome: sifting information out of the data ocean. North River Press, p. 128.
6. Schragenheim, E., and Dettmer, H. W., (2000) Manufacturing at warp speed: optimizing supply chain financial performance. The St. Lucie Press, pp. 123-135.
7. Schragenheim, E., and Dettmer, H. W., (2000) Manufacturing at warp speed: optimizing supply chain financial performance. The St. Lucie Press, p. 176.
8. Schragenheim, E., (2002) Make-to-stock under drum-buffer-rope and buffer management methodology. APICS International Conference Proceedings, Session I-09, 5 pp.
9. Goldratt, E. M., (1990) The haystack syndrome: sifting information out of the data ocean. North River Press, pp. 206, 209, 241.
10. Caspari, J. A., and Caspari, P., (2004) Management Dynamics: merging constraints accounting to drive improvement. John Wiley & Sons Inc., p. 180.
11. Goldratt, E. M., (1990) The haystack syndrome: sifting information out of the data ocean. North River Press, p. 136.
12. Schragenheim, E., and Dettmer, H. W., (2000) Manufacturing at warp speed: optimizing supply chain financial performance. The St. Lucie Press, 342 pp.
13. Dettmer, H. W., (1997) Goldratt’s Theory of Constraints: a systems approach to continuous improvement. ASQC Quality Press, p. 67.
14. Schragenheim, E., and Dettmer, H. W., (2000) Manufacturing at warp speed: optimizing supply chain financial performance. The St. Lucie Press, p. 177.
15. Goldratt, E. M., and Fox, R. E., (1986) The Race. North River Press, pp. 36-67.
16. Goldratt, E. M., and Fox, R. E., (1986) The Race. North River Press, pp. 96-105.
17. Cox, J. F., and Spencer, M. S., (1997) The constraints management handbook. St Lucie Press, pp. 101-128.
18. Umble, M. M., and Srikanth, M L., (1997) Synchronous management: profit-based manufacturing for the 21st Century. Volume 2 implementation issues and case studies. The Spectrum Publishing Company, 234 pp.
19. Goldratt, E. M., (2003) Production the TOC way (revised edition). North River Press.
20. Tripp, J., (2005) TOC Executive Challenge: a goal game. The North River Press Publishing Corporation, 56 pp.
21. Stein, R. E., (1996) Re-engineering the manufacturing system: applying the theory of constraints (TOC). Marcel Dekker, p. 190.
22. Schragenheim, E., and Dettmer, H. W., (2000) Manufacturing at warp speed: optimizing supply chain financial performance. The St. Lucie Press, 342 pp.
Автор: Кельвин Янгман
Источник
Книга в подарок
Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!
Похожие статьи
(Kelvyn Youngman)
Integral Systemisist