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

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

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

Для отладки отдельных составляющих системы было проведено несколько практических семинаров по кайдзен. Среди них были семинары по 5S, в ходе которых на базе произвели перепланировку рабочей зоны, определили для всего свое место и промаркировали стандартные места. Практические семинары по материальному потоку помогли выработать более рациональный подход к демонтажу самолета. Теперь детали самолета укладывались в специальные коробки, и когда они возвращались из хранилища, все они лежали как надо. Опасные материалы размещались на тележках в контейнерах. Запас всех контейнеров, деталей и материалов пополнялся при помощи систем вытягивания по мере использования наличных запасов. Начался медленный и сложный процесс детального анализа каждой операции для разработки процедур стандартизированной работы и приведения темпа работы каждого участка в соответствие со временем такта.

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

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

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

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

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

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