Как внедрить ББК. Часть 3: FIFO и дыры в буфере

Автор: Dr K. J. Youngman

Продолжение. Начало.

Размер партии

Размер партии является важной частью подчинения ограничению. Получение соглашения на изменение размера партии является главной частью большинства реализаций процесса.

Управление запасами

Когда незавершенная работа уменьшается, освобождается множество мест и приспособлений, которые использовались для складирования и перемещения деталей. Уберите их, поскольку они теперь не нужны. Если на рабочем месте есть стеллаж, куда можно сложить детали, люди будут искать работу, чтобы заполнить его. Когда работы недостаточно, чтобы заполнить все «пустые» пространства, людям становится некомфортно. Устраните причину дискомфорта — пустые и ненужные поддоны, тележки и т.д. Уберите их и убедитесь, что люди знают, что они были убраны в определенное место на хранение. Мы-то не ожидаем, что когда-либо будем использовать их снова, но большинство других людей будут ожидать, что они понадобятся снова в ближайшее время.

Принцип «First In, First Out» (FIFO)

Этот метод «Первым вошел, первым вышел» требует терпения, постоянного терпения. Давайте вернемся на шаг или два. Многие реализации Барабан-буфер-канат ранее были своего рода системой планирования MRP на месте, или в ее отсутствии своего рода «практическим» методом экспедирования. Рациональное обоснование компонента планирования MRP в производственном цехе в том, что он способен перепланировать любую стадию процесса путем изменения приоритетов последовательности, когда работа ждет очереди на каждой стадии процесса (21).

Барабан-буфер-канат снимает необходимость в очередях повсюду, но не дурную привычку изменения приоритетов работы в очереди. Некоторые виды работ могут просто откладываться в течение одного-двух дней, пропуская работы, поступившие позже. В культуре, где стаж работы или возраст сотрудников пользуются большим уважением, может быть очень трудно поддерживать FIFO.

Когда материал поступает в систему в той последовательности, в которой он будет обрабатываться на ограничении, в большинстве случаев, FIFO позволит защитить график ограничения. Несоблюдение этого быстро приведет к дыре в буфере. Работа, которая была пропущена в не-ограничение, будет обнаружена как опаздывающая в конце буфера. Работа, которая прошла вне очереди, будет обнаружена необычно рано в буфере.

Для не-ограничения: «Метод определения приоритета — FIFO. Согласно графика ограничения и размера защиты требуется определить дату запуска. Последовательность заказов уже определена и должна поступить в определенную дату/время на не-ограничение. Пока нет проблемы с проникновением заказа в зону 1 буфера — «красную» зону, нет причины изменять это правило (22)».

В условиях большого объема мы должны обратить внимание на следующее для не-ограничений: «В случае с производством, которое имеет много работ, поступающих за день, должна быть разработана процедура для определения последовательности, в которой работы поступают. Это определяет последовательность их обработки. Процедура решает две проблемы — как узнать, кто прибыл первым, и как убедиться, что люди работают в нужной последовательности (23)».

Локальные показатели эффективности — задержки

Даже в самых лучших системах иногда происходят задержки, и мы не всегда можем выполнить заказ в срок или отгрузить со склада, как мы изначально обещали. Дефицит материалов, возможно, является причиной номер один. Заведомо невыполнимые сроки, обещанные непроизводственным персоналом, вероятно, причина номер два. Как следствие, обычно сотрудники ИТ отдела получают задачу сделать количественный учет задержек. Почему ИТ отдел? Потому что эти цифры используются MRP системой, поэтому это должна быть ИТ задача. Конечно, эти ребята сталкиваются с извечной проблемой, нужно ли измерять задержку в единицах времени или в единицах стоимости продаж. Мы измеряем количество дней задержки и занижаем большую работу, которая была просто на день просрочена? Или мы оцениваем объем продаж и занижаем небольшую работу, которая была задержана на несколько недель, пока мы ждали материалы от внешнего поставщика?

Ответ таков: мы измеряем обе эти величины, используя значение долларо-дней прохода или TDD (12). Ежедневно мы умножаем проход для каждого просроченного заказа на количество дней задержки и суммируем все просроченные заказы. Конечно, это значение должно быть равно нулю, но иногда не будет. Для заказов, задержки которых посягают на наших клиентов, мы должны измерять от первоначальной даты поставки (для производства на заказ) либо от даты заказа (для производства на склад, товары должны быть в наличие на складе в момент размещения заказа). Тем не менее, Голдратт полагает, что для того, чтобы избежать этой самой нежелательной ситуации мы должны «связать» опоздание с дырами в буфере (12). «Иногда действия организации вызваны отклонением в одном отделе. Это происходит всякий раз, когда задача не приходит к началу буфера, несмотря на то, что достаточно времени прошло с момента запуска. Достаточно времени, чтобы с довольно высокой вероятностью (скажем, более чем на 90 процентов) ожидать прибытия задачи. Таким образом, мы могли бы начать отсчитывать дни с момента времени, когда задача проникла в зону экспедирования, а не с даты оплаты. Это даст нам время, чтобы исправить ситуацию до того, как ущерб для всей компании станет свершившимся фактом».

Мы можем рассматривать это как тактическое применение. Таким образом, заказ опаздывающий к красной зоне буфера, должен иметь стоимость для долларо-дней прохода. Давайте нарисуем это.

Место, где мы ожидаем увидеть накопление товара перед ограничением, называется началом буфера (24). Запланированное время старта ограничения также отмечает окончание времени для буфера. Давайте назовем на этот раз именно так — время окончания буфера. Чтобы выяснить, есть ли у нас проблема, мы должны проверить красную зону, присутствует ли физически завершенная работа в начале буфера или нет. Давайте назовем это временем проверки буфера. Если работа не присутствует в начале буфера, мы должны найти, где она, и определить причину задержки. Если вам кажется, что эта работа не достигнет начала буфера без вмешательства, то вы должны «помочь» ей. Когда она в конце концов все же появится в буфере, мы можем вычислить опоздание. Существуют два различных действия здесь. Первое должно быть сделано в режиме реального времени, а второе можно сделать из записей.

Используем пример из раздела Барабан-буфер-канат. Наша длина каната — 9 дней, и каждая буферная зона составляет 3 дня. Поэтому любая работа не в начале буфера (9 — 3 = 6 дней), должна быть определена и очевидная причина задержки записана. Если работа на самом деле занимает 6,5 дня, то дыра в буфере составляет 0,5 дней.

Отметим еще раз, что время окончания буфера, длина зоны, время проверки буфера — все это меры времени, которые мы нарисовали на нашей диаграмме. Просмотр буфера является основным источником путаницы, вызванной ограничениями нашего двумерного представления.

Единственный человек, который должен знать время проверки буфера для работы, это менеджер буфера. Не добавляйте это время в расписание завода, или же оно сразу станет промежуточным расписанием, и люди будут оставлять работу на последнюю минуту — и будет поздно. Дата в графике создает красную зону буфера в умах большинства людей. Это не правильно, буфер простирается от выхода материала до запланированного начала на ограничении.

Используя буфер для управления таким образом, мы не только получаем информацию о вероятном расположении проблемы и частоту заболеваемости, но у нас также есть некоторые измерения с точки зрения системы. Чем больше дней просрочки и больше потеря прохода, тем более серьезные проблемы. Эта информация в настоящее время отсутствует в большинстве отчетов буфера. Стейн защищает именно эту точку зрения при подготовке диаграммы Паретто для дыры в буфере (25, 26). Давайте попробуем изобразить аргумент Стейна графически:

Мы можем представить серьезность проблемы и таким образом: Серьезность = Проход х Опоздание

Например, график может теперь выглядеть следующим образом:

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

Это справедливо для 5-10% заказов, которые мы должны ускорить. Но что, если заказ уже не находится в ресурсе, который вызвал опоздание. Как мы можем знать, что улучшать в этом случае? Ответ: мы должны углубить статистику (27). Более удовлетворительной концепцией может быть расширение «зоны отслеживания», как рекомендует Стейн, на желтую зону (25, 26). В этом случае более вероятно, что заказ будет найден в том месте, которое является причиной опоздания. И также гораздо более вероятно, что возникающие проблемы будут найдены, прежде чем они станут критическими. Мы можем рассматривать это как стратегическое применение управления буфером. Давайте нарисуем это.

Чтобы посмотреть, что происходит в целях отслеживания, мы должны проверить на расстоянии в две зоны от времени окончания буфера, присутствует ли завершенная работа физически в начале буфера или нет. Если нет, мы должны выяснить где работа, и любые причины, которые могли дать задержку. Опять же на примере из раздела Барабан-буфер-канат. Наша длина каната была 9 дней, и каждая буферная зоны составляет 3 дня. Поэтому любая работа не в начале буфера (9 — 3 — 3 = 3 дня), должна быть найдена и ее местонахождение записано. Если работа на самом деле занимает 4,5 суток, то отслеживаемая дыра в буфере составляет 1,5 дня.

Я не думаю, что отслеживание должно осуществляться для каждой работы, даже если наши производственные системы могут быть в состоянии показать нам все дыры в зоне слежения. Маловероятно, однако, что мы будем знать, где находится работа без физической инспекции, и поэтому этот вид анализа данных должны быть периодическим. В лучшем случае — отбор проб производительности системы время от времени.

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!

Получить подарок

---

Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Подписаться

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.