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

Три года назад я лично выбрал программное обеспечение для системы материально-технического снабжения, чтобы, опробовав его в реальной работе, принять решение о целесообразности его применения в Toyota. Занимаясь этой работой, я столкнулся с активным сопротивлением ТМС (правления компании в Японии). Руководство было против использования программного обеспечения для планирования, поскольку боялось, что, полагаясь на него, американцы забудут о логике и принципах планирования. Кроме того, в Японии считали, что лучшие планы разрабатываются человеком, который при необходимости может проявить гибкость и со временем внести в план необходимые коррективы. Я знал, что мы управляем очень сложной системой и человеку не под силу просчитать все возможные варианты, не отступая от принципов TPS. Испытание программы на реальных данных доказало мою правоту, и ТМС оперативно запустило проект по разработке внутренней системы программного обеспечения. Задачей проекта была оптимизация возможностей системы при соблюдении принципов TPS. В ходе этой работы завязались отношения между разработчиками из ТМС и доктором Шоном Кимом из Alligence. Toyota не удалось превзойти эффективность программного обеспечения Alligence, поэтому ТМС взяла на вооружение механизм оптимизации Alligence и сделала его интегральной частью нашей новой системы планирования маршрутов (SMAP), которая должна начать функционировать через два месяца. В этом году у нас и в Европе проходили ее испытания.

На первый взгляд это рассказ о бюрократической косности руководства, противящегося переменам: «В старые добрые времена мы делали это вручную, почему бы и вам не работать так же?» На самом деле руководство ТМС защищает дао Toyota — основу конкурентного преимущества Toyota. Если бы руководители одобряли любое предложение о внедрении нового программного обеспечения, подкрепленное обоснованием его экономической целесообразности, Toyota очень скоро была бы опутана взаимоувязанными системами программного обеспечения и оправдались бы худшие опасения ее руководства: полагаясь на программное обеспечение сотрудники Toyota забыли бы о логике и принципах самого процесса работы. В итоге Toyota уподобилась бы своим конкурентам.

Руководство попросило Гленна Умингера более четко аргументировать свою позицию, проанализировать проблемы и выработать решение, которое отвечало бы принципам TPS. Гленн так рассказывает о проделанной за три года работе:

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

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

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

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

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

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