В Toyota управление запасами осуществляется с помощью карточек канбан, перемещение которых легко отслеживается. Физическая инвентаризация запасов осуществляется дважды в год, и для ее проведения производство приостанавливается самое большее на несколько часов (на складе на эту работу обычно уходит весь день, поскольку здесь хранится значительное количество изделий). В основном система управления запасами использует старомодные карточки, которые дешевле и эффективнее компьютерных систем. Недавно в Toyota начали использовать электронные канбан, которые посылают сигналы вытягивания поставщикам и даже используются для пополнения запасов в пределах сборочного завода. Однако на сборочных заводах все равно сохраняется дублирующая неавтоматизированная система, которая обеспечивает визуальную индикацию.
контейнер помещалось строго определенное количество деталей, а объем запасов предполагал строго определенное число контейнеров. Количество карточек канбан соответствовало числу контейнеров. Нет карточки — нет производства — нет наращивания запасов. Toyota занималась повышением надежности оборудования, встраиванием качества и обучением операторов. Благодаря непрерывному совершенствованию здесь так мало запасов, что сбор информации о запасах на каждом этапе процесса в режиме реального времени не представляет особой ценности — это всего лишь потери. Иными словами, в Toyota работают над разработкой процесса производства как такового и связывают производственные процессы с помощью несложных средств коммуникации и стандартных процедур. Здесь не слишком заинтересованы в не добавляющих ценности «бизнес-процессах», нацеленных на ввод данных в компьютер. Любопытно, что, совершенствуя свои неавтоматизированные системы, Toyota пришла к электронным канбан. Впрочем, они используются параллельно с традиционной системой канбан, что позволяет сочетать визуальный контроль с преимуществами современной компьютерной технологии.
Традиционное программное обеспечение цепочки поставок, которое обещает сделать запасы зримыми, на самом деле опирается на принцип управления сверху вниз. Исходная посылка состоит в том, что, если высшему менеджменту будет доступна вся необходимая информация, он сможет контролировать систему. В основе системы канбан лежит принцип контроля на местах. При таком подходе совокупность взаимосвязей пос-
Следует всегда самостоятельно проверять состояние дел
Как-то раз мы занимались стабилизацией и проблемами операционной готовности одного процесса и начальник планово-производственного отдела, включенный в команду, то и дело замечал, что процесс «запаздывает». Мы осмотрели цех и не нашли незавершенного производства, ожидающего обработки. Сточки зрения подхода Toyota нельзя считать, что процесс «запаздывает», если все, что поступило с предыдущей операции, обработано, а потребитель не требует пополнения. Все это легко выявить, наблюдая за происходящим в рабочей зоне и за связями между операциями. Озадаченные, мы спросили начальника планово-производственного отдела, как станок может «запаздывать». «Так говорит система!» — ответил тот, имея в виду систему планирования потребностей в материалах. Такое использование информации системы — без учета фактического состояния процесса — может ввести в заблуждение и заставить решать проблему, которой нет.
тавщик-потребитель сходится на рабочем месте. Потребители определяют, что и когда им нужно, с помощью канбан. Высшее руководство проверяет функционирование системы своими глазами, приходя в цех (рис. 9-4).
Как в случае с программным обеспечением Agillence, о котором рассказывалось в этой главе, новым ИТ в Toyota приходится преодолевать значительные препятствия. Процесс освоения программного обеспечения Agillence типичен для Toyota и соответствует алгоритму, представленному на рис. 9-4. Недостаточно теоретически доказать, что данная ИТ позволяет автоматизировать процесс или обеспечить большее количество достоверной информации. Следует уяснить, каким образом ИТ будет способствовать добавлению ценности в ходе тщательно продуманного, испытанного временем процесса. Как правило, автоматизации процесса предшествует его отработка вручную. Технология должна помогать принимать решения, не заменяя человека, но поддерживая его. Технология — не повод прекратить думать и заниматься непрерывным совершенствованием. Напротив, назначение технологии — помогать людям сокращать потери.
Toyota — организация инженеров, опирающихся на технологию. Основа успеха Toyota — передовые процессы и инновационная продукция. Однако решающую роль в разработке и внедрении продукции и процессов играют люди.
Ситуация, описанная ниже, показывает, что ценность технологии определяется людьми и процессами. В данном случае конкуренту Toyota, компании, которую мы будем называть AmCar, удалось заметно опередить Toyota в автоматизации процессов и разработки продукции. Демонстрация нашумевших достижений, на которые была не способна Toyota, вызвала у нее некоторое беспокойство. Однако на деле эти успехи оказались дутыми. AmCar использовала новую технологию неэффективно и отставала от Toyota по срокам разработок и качеству, а запуск новой продукции в производство порождал множество проблем. Лишь после того как AmCar наняла несколько бывших сотрудников Toyota, которые помогли применить принципы Toyota к освоению данной технологии, в компании произошел ряд позитивных сдвигов.
Технология играет в Toyota огромную роль, но следует также учитывать условия ее внедрения. Технология — важная составляющая системы, но система — это не просто комбинация технологий. Система включает определенный метод выполнения работы и людей, использующих этот метод.
Дело не только в том, какая технология выбрана, но и в том, как задумана и реализована система в целом. Решая, как вести дела, важно уделить надлежащее внимание планированию и анализу с учетом философии бизнеса в более широком аспекте.
Конкретная ситуация: ценность технологии определяют процесс и люди
В начале 1990-х годов одна из автомобилестроительных компаний США (назовем ее AmCar) энергично взялась за компьютерное моделирование при разработке продукции. Целью компании было освоение технологии, которая поможет проектировать продукцию, обеспечивая оптимизацию производственной системы. На тот момент рассматривалось несколько пакетов программного обеспечения. В области САПР лидировала Delmia с программным пакетом CATIA, и AmCar остановила свой выбор на ней. Набор программных модулей, которые предлагала Delmia, был довольно велик, и AmCar выбрала пакет программ, позволяющий повысить точность проработки стыкуемых деталей. Что касается производства, основное внимание уделялось общей планировке завода. Разработка специального оборудования для процесса была поручена внешним поставщикам, которые не поддерживали тесных контактов с разработчиками продукции.
Надежды на создание комплексной системы проектирования и производства не оправдались. Основные функциональные группы (включая отдел закупок и снабжения — подавляющее большинство поставщиков комплектующих были также ответственными разработчиками компонентов/систем) почти не взаимодействовали между собой. Часто команды анализировали проблемы, связанные с программным обеспечением, в рамках отдельного функционального подразделения (например, в отделе разработки кузова) и приступали к разработке с большим опозданием (спустя долгое время после окончательного утверждения проекта). В результате многое обнаруживалось слишком поздно, изменения в процесс и компоненты вносились задним числом, что приводило к задержкам в запуске продукции в производство и затягивало вывод оборудования на рабочий режим. Кроме того, недостаточное внимание уделялось развитию интегрированного межфункционального анализа проектов (параллельного проектирования). Приоритетным направлением стала разработка технологии, и движение вперед застопорилось, несмотря на успехи в сфере программного обеспечения.
В 2000 году AmCar наняла команду специалистов с предприятий Toyota в Северной Америке. Среди прочего новым сотрудникам предстояло заняться повышением качества. В ту пору компания терпела убытки, имела проблемы с качеством продукции и высокие затраты на гарантийный ремонт. Один из сотрудников Toyota, у которого был опыт руководства запуском продукции в производство, сразу заметил,
что компьютерное моделирование почти не используется для предупреждения производственных проблем на этапе разработки. В Toyota это называется моделированием «виртуальной конструкции». При помощи компьютера создается визуализированная электронная модель автомобиля, а межфункциональные команды оценивают проблемы при производстве и сборке данного автомобиля и решают их с помощью стандартной методологии решения проблем.
В конце 2001 года представители Технического центра Toyota в Анн-Арбор и AmCar участвовали в совместном заседании по обмену опытом в сфере технологий. Представители Toyota были удивлены отсутствием прогресса в сфере компьютерного проектирования — совещание в конце 1990-х годов убедило Toyota, что в этой сфере AmCar стремительно продвигается вперед. Toyota подчеркнула, что данная деятельность была ключевым фактором снижения времени выполнения заказа при осуществлении разработок.
В начале 2002 года в результате очередного более детального анализа высший менеджмент AmCar рекомендовал заняться параллельным проектированием и процессом виртуальной сборки. Этому должно было способствовать внедрение более строгого метода решения проблем, а также насущная потребность ускорить процедуры утверждения, окончательного принятия конструкции/процесса и внесения изменений в продукцию/процесс. Все перечисленные виды деятельности осуществлялись с применением методов Toyota. Был заложен фундамент для повышения уровня дисциплины — необходимого условия параллельного проектирования и виртуальной сборки.