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

Когда была составлена карта процесса, стало видно, что это классический случай обработки партиями и выталкивания по графику (см. рис. 5-10). Сначала полностью разрабатывалась конструкторская документация на все сиденья — сиденья с подогревом, сиденья без подогрева, многоместные сиденья, сиденья для водителя, электрический привод сиденья и т.д. На основании разработанной документации заказывались комплектующие. Комплектующие поступали от поставщиков в разное время. Группа, которая изготавливала опытный образец, ждала поступления комплектующих сколько могла, после чего приступала к изготовлению тех сидений, которые можно было сделать из имеющихся комплектующих. После этого сиденья огромными партиями отправлялись на испытания. Если сиденья не проходили испытания, их отправляли на доработку для устранения проблем.

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

треугольников. На этапе конструирования сидений это были запасы информации — проекты, накопление которых предшествовало этапу заказа комплектующих. Решение: создать систему последовательного вытягивания. Но как добиться этого применительно к информационному процессу, который представляет собой проектирование?

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

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

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

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

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

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

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