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

Надежды на создание комплексной системы проектирования и производства не оправдались. Основные функциональные группы (включая отдел закупок и снабжения — подавляющее большинство поставщиков комплектующих были также ответственными разработчиками компонентов/систем) почти не взаимодействовали между собой. Часто команды анализировали проблемы, связанные с программным обеспечением, в рамках отдельного функционального подразделения (например, в отделе разработки кузова) и приступали к разработке с большим опозданием (спустя долгое время после окончательного утверждения проекта). В результате многое обнаруживалось слишком поздно, изменения в процесс и компоненты вносились задним числом, что приводило к задержкам в запуске продукции в производство и затягивало вывод оборудования на рабочий режим. Кроме того, недостаточное внимание уделялось развитию интегрированного межфункционального анализа проектов (параллельного проектирования). Приоритетным направлением стала разработка технологии, и движение вперед застопорилось, несмотря на успехи в сфере программного обеспечения.

В 2000 году AmCar наняла команду специалистов с предприятий Toyota в Северной Америке. Среди прочего новым сотрудникам предстояло заняться повышением качества. В ту пору компания терпела убытки, имела проблемы с качеством продукции и высокие затраты на гарантийный ремонт. Один из сотрудников Toyota, у которого был опыт руководства запуском продукции в производство, сразу заметил,

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

В конце 2001 года представители Технического центра Toyota в Анн-Арбор и AmCar участвовали в совместном заседании по обмену опытом в сфере технологий. Представители Toyota были удивлены отсутствием прогресса в сфере компьютерного проектирования — совещание в конце 1990-х годов убедило Toyota, что в этой сфере AmCar стремительно продвигается вперед. Toyota подчеркнула, что данная деятельность была ключевым фактором снижения времени выполнения заказа при осуществлении разработок.

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

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

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

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

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

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