Читаем Практика дао Toyota полностью

При освоении бережливого производства многие считают сокращение запасов первоочередной задачей. Есть множество способов достижения этой цели, включая разного рода хитрости. Однако лучше поставить задачу создать связанный поток и использовать объем запасов как критерий успеха. Для управления запасами используется канбан, регулируя число карточек канбан, несложно оценить эффективность процесса. Управление запасами с помощью канбан стандартизировано, и возможность недобросовестной манипуляции запасами снижается.

запасов и снижает размеры рабочей зоны и объем потерь. Как ни странно, предпочтительно иметь «в системе» больше единиц канбан. Например, если общий уровень запасов составляет 2000 штук, лучше иметь 20 канбан — по одному на 100 изделий, чем 2 канбан — по одному на 1000 изделий. Очень трудно чувствовать спрос, если в системе только две карточки канбан, и каждый раз, когда карточка возвращается, приходится немедленно поставлять следующую партию изделий.

ВЫРОВНЕННЫЙ ГРАФИК ОПРЕДЕЛЯЕТ ПОРЯДОК ПОПОЛНЕНИЯ

Хейдзунка не только выравнивает все процессы, но и определяет продолжительность питча. Поскольку в течение заданного питча материалы расходуются со стандартной скоростью, можно определить характеристики процесса пополнения запаса материалов. Пополнение запаса материалов подчиняется основной работе, добавляющей ценность, а значит, не следует заниматься определением «траектории» или методов подачи материалов до базовой стандартизации основного процесса.

Приведенный далее пример показывает, как выровненный график определяет процедуру пополнения материальных запасов. Это позволяет стандартизировать работу рабочих, в том числе траекторию их перемещения в течение питча или серии питчей. Общее количество материала стандартизируется, а количество материала в контейнере может регулироваться в зависимости от длительности питча. Для иллюстративных целей мы предполагаем, что в рассматриваемом процессе обеспечен высокий уровень хейдзунка, все изделия изготавливаются в строго определенной последовательности, а общая продолжительность рабочего времени составляет восемь часов. Спрос составляет 400 изделий, а весовые показатели количества каждого вида изделий показаны в таблице 7-4.

Таблица 7-4. Количество деталей как относительный показатель
Наименование деталиКоличество в течение 8 часовВеса (по количеству)
А2004
В1002
С501
D501
Всего400

ПОДСКАЗКА

Установите питч исходя из имеющихся условий

Если у вас уже есть определенный опыт освоения бережливого ~ производства, скорее всего, вы не станете устанавливать питч

продолжительностью в один час. Мы рекомендуем продвигаться вперед, сокращая питч каждый раз наполовину. Если сейчас вы перемещаете материал ежедневно (или питч не определен), начните с питча продолжительностью в одну смену. Когда воспроизводимость процесса улучшится, сократите питч вдвое.

С учетом требуемого количества и весовых показателей количества повторяющаяся структура хейдзунка (которая позволяет свести к минимуму размер партии) такова: ABACABAD — ABACABAD — ABACABAD.

Чтобы определить питч для регулярной работы согласно данной модели, разделим 8 часов на объем спроса (400 изделий) и умножим на количество изделий в модели выравнивания (питч):

28 800 секунд (8 часов) в день / 400 изделий =

= 72 секунды на одно изделие

Тогда:

72 секунды на одно изделие X 8 изделий в течение питча =

= 576 секунд на питч (9 минут 36 секунд), или 6,25 питч-циклов в час.

Предположим, мы хотим, чтобы рабочий занимался подачей материала ежечасно (питч пополнения запаса материала). В таблице 7-5 показаны расчеты количества контейнеров, которое понадобится перемещать, если цикл пополнения запасов будет составлять один час.

Таблица 7-5. Расчеты количества контейнеров, перемещаемых в течение питча
Наименование деталиВеса (по количеству)Повторений модели выравнивания в часПотребность в часКоличество в контейнереКонтейнеров на питч
А46,254 X 6,25 = 25102,5
В26,252 X 6,25 = 12,552,5
С16,251 X 6,25 = 6,2551,25
D16,251 X 6,25 = 6,2551,25
Перейти на страницу:

Похожие книги

Философия DevOps
Философия DevOps

IT-принцип «agile» стал мантрой цифровой эпохи. С ростом проектов, переходом от монолитных приложений к системе микросервисов, увеличением и накоплением продуктов возникают вопросы, которые требуют совершенно иного подхода. Теперь наибольший интерес вызывает находящаяся на стыке разработки и операционного управления методология DevOps.DevOps – это не просто набор техник, это философия. Разработчики, зацикленные на пользователях, должны уделять внимание поддержке и ее запросам. Сисадмины должны сообщать о проблемах продукта и вносить свой вклад в улучшение процесса работы. Но налаживание связей внутри компании – это лишь первый шаг. Чтобы продукт стал простым и удобным, придется вложить время и ресурсы в его доработку. Конфигурация через центральную службу, внедрение простым копированием, отсутствие внешних зависимостей, обдуманные метрики вместо мусора в логах – вот лишь часть задач, которые придется решать на этом пути.Книга «Философия DevOps» познакомит вас с техническими, культурными и управленческими аспектами devops-культуры и позволит организовать работу так, чтобы вы получали удовольствие от разработки, поддержки и использования программного обеспечения.

Дженнифер Энн Дэвис , Кэтрин Дэниелс

Деловая литература