Несколько лет назад я сопровождал декана технологического факультета Мичиганского университета во время его поездки в Японию. Среди тех, кто нас принимал, был Микио Китано, который в то время осуществлял надзор за Motomachi – крупнейшим промышленным комплексом Toyota. Декан задавал множество вопросов об использовании информационных технологий в Toyota. У Китано эти вопросы вызывали легкое раздражение. Он достал типичную блок-схему работы информационной системы со всеми привычными для ИТ обозначениями: поток информации, которая передается с одного компьютера на другой, запоминающие устройства, устройства ввода-вывода и т. п. Эту схему, которая была разработана для сборочного завода Motomachi, дал ему чуть раньше один из специалистов по ИТ, работающих в Toyota. Китано рассказал, что данную блок-схему он отослал назад, сказав ее разработчику: «Toyota не занимается созданием информационных систем. Мы изготавливаем автомобили. Покажите мне процесс изготовления автомобилей и то, как ваша информационная система поддерживает этот процесс». После этого он достал другую большую схему последовательности технологических операций, которую сделал специалист по ИТ в ответ на требование Китано. В верхней части было показано, как происходит изготовление автомобиля: там были представлены технологические линии, на которых изготавливается кузов и производятся покраска и сборка. В нижней части схемы были показаны различные информационные технологии и то, как они будут поддерживать процесс производства автомашин. Как и хотел Китано, на схеме была представлена последовательность технологических операций и ИТ занимали в ней свое место – обеспечивали работу производственных линий.

У Toyota есть опыт и в части применения технологии выталкивания, новейшей и лучшей, о внедрении которой ей пришлось сожалеть. Примером тому является эксперимент, проведенный 10 лет назад в Чикагском центре распределения запчастей [28] , где компания установила автоматизированную систему с поворотными стойками. Пока склад строился, дилеры Toyota заказывали детали раз в неделю. Но вскоре после завершения строительства компания ввела систему ежедневных заказов и поставок, чтобы сократить время выполнения заказа и уменьшить количество запасов у дилеров. Когда цикл отгрузки деталей сократился с пяти дней до одного, оборудование оказалось недостаточно гибким и внезапно устарело, поскольку фиксированная длина конвейера была рассчитана на более крупные заказы. Ежедневные заказы были меньше по объему, и небольшие коробки заполнялись гораздо быстрее, чем более габаритные контейнеры для пятидневного запаса деталей. Теперь работник, который стоял в конце конвейерной линии, был вынужден ждать, пока длинный конвейер доставит небольшое количество деталей. Значительное время этот работник проводил в ожидании – один из восьми видов потерь. Преимущества от такой технологии быстро исчерпались, и предприятие в Чикаго стало одним из самых малоэффективных складов в Toyota. В 2002 году компания вновь инвестировала средства в Чикаго, на сей раз, чтобы демонтировать автоматическую систему и поддерживающую ее компьютерную систему. Нужно отметить, что на самом эффективном региональном оптовом складе в Цинциннати почти нет автоматического оборудования.

Беседа говорит:

В 2002 году в центрах распределения запчастей была завершена двухлетняя работа по внедрению новой системы, которая получила название «Монарх» (Monarch Project), для совершенствования прогнозирования спроса и планирования управления запасами. Объединенная группа экспертов по логистике и специалистов по информационным системам потратила год, определяя, какие элементы прежней системы работают хорошо, какие нуждаются в модернизации или замене и какие функциональные возможности необходимо добавить. Основное назначение системы «Монарх» – незаметно поддерживать визуальную систему на складских площадях, позволяя специалистам в любой момент оценить текущую ситуацию. Беседа рассказывает о ней следующее:

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

Джейн Беседа замечает:

В начале 1980-х годов среди автомобилестроительных компаний сложилась тенденция создавать собственные внутренние системы САПР для разработки деталей на компьютере вместо изготовления чертежей не бумаге. Toyota делала это, как и все остальное, однако и здесь она исходила из собственных принципов решения задач. Создатели новой системы САПР спрашивали: «В чем заключается необходимость именно этого модуля программного обеспечения (например, художественное конструирование, разработка дизайн-форм или разработка деталей)? В каких условиях он будет использоваться? Каковы требования к данному программному обеспечению? Каковы альтернативы? Какая из этих альтернатив является наилучшей?» Часто оказывалось, что наилучшей альтернативой была традиционная технология. Например, при анализе штампов для процесса штамповки технология анализа была недостаточно совершенна, чтобы смоделировать различные варианты штамповки детали и определить лучшую конструкцию штампа с помощью компьютера. Поэтому Toyota нашла более простое решение, позволившее получить цветное изображение, на котором были выделены точки концентрации напряжений на штампе. Конструктор штампов вместе с опытным специалистом по их изготовлению изучил данное изображение и на основании опыта принял решение о том, каким должен быть штамп. Автомобильные компании США, внедряющие системы САПР, напротив, рассчитывали напряжение исключительно с помощью программного обеспечения, после чего давали рекомендации конструктору штампов, не интересуясь его мнением. В результате инженеры часто пренебрегали результатами компьютерного анализа, поскольку его рекомендации были неосуществимы на практике.

В то время как конкуренты Toyota переходили на новейшие системы САПР, имевшиеся на рынке, сама компания продолжала к неудовольствию инженеров и поставщиков придерживаться старой, доморощенной системы. Программное обеспечение было устаревшим, хотя и работало. Наконец, Toyota применила принцип 13, который требовал «взвешенного и обдуманного принятия решений» (немаваси; речь о нем пойдет в главе 19), и после двух лет полемики и размышлений решила перейти на систему CATIA (Computer-Aided Three-Dimensional Interactive Application – компьютеризированный интерактивный анализ трехмерных моделей) – систему САПР мирового класса, которая уже использовалась компаниями Boeing и Chrysler и в автомобилестроительной промышленности считалась эталоном. Toyota внедряла CATIA медленно, потратив много времени на то, чтобы привести ее в соответствие со сложившимся процессом разработки. Между тем компания Ford быстро закупила новую версию другой системы САПР, истратив сотни миллионов долларов на ее развертывание у себя и своих поставщиков, после чего решила, что лучше перейти на CATIA, и истратила на это еще несколько миллионов, чем привела в недоумение множество людей.

Toyota продолжает рационализацию процесса разработки продукции, порой подходя к использованию программного обеспечения весьма нетрадиционно. С момента внедрения программного обеспечения САПР в 1980-е годы процесс разработки нового автомобиля сократился с 48 до 12 месяцев. Toyota называет этот метод «совместная разработка с применением компьютерного проектирования». Эта формулировка говорит сама за себя. Компания сформировала комплекс относительно простых технологий, который поддерживает совместную работу по разработке продукции в рамках подхода Toyota.

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