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

Последовательность изготовления изделий имела следующий вид: элементы декора — шкаф — двери — шкаф — выдвижные ящики — полки — двери — шкафы — ящики/двери — при необходимости описанная последовательность повторяется — детали общего применения — пустой стеллаж — пустой стеллаж (следующий заказ) элементы декора...

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

В данной ситуации было трудно определить объем производства. Количество деталей, стеллажей и заказов было подвержено вариации. Компания поставила задачу выполнять 25 заказов в день, исходя из этого, мы определили целевой показатель объема, несмотря на то что общий объем работы варьировался. Однако эта вариация не отражалась на равномерности распределения объема работ в течение дня, поскольку с ней можно было справиться, незначительно меняя продолжительность рабочего дня. Структура ассортимента изделий включала два среза — первичная последовательность изделий с учетом типа отделки и вторичная последовательность отдельных видов изделий. Первичная последовательность учитывала тип отделки и соответствовала потребительскому спросу и объему работ, а вторичная последовательность обеспечивала надлежащее распределение объема работ. Таким образом, последовательность выполнения заказов, учитывающая тип отделки и виды изделий, позволила выровнять объем работ.

Эти преобразования стали базисом для стандартизации работы и потока. Выравнивание объема работ сократило количество простоев и сгладило поток на остальных операциях. Дальнейшие мероприятия по связыванию операций позволили уменьшить скопления запасов, которые раньше были обычным делом.

Перейти на страницу:

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

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

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

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

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