Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
книги / Система разработки продукции в Toyota люди, процессы, технология..pdf
Скачиваний:
11
Добавлен:
19.11.2023
Размер:
30.73 Mб
Скачать

ГЛАВА 8

Создать организационную структуру, которая позволяет сочетать функциональную компетентность

имежфункциональную интеграцию

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

Та КЕСИ УтиЯМАДАу ПЕРВЫЙ ГЛАВНЫЙ ИНЖЕНЕР

ГИБРИДНОГО АВТОМОБИЛЯ PRIUS

Какая структура лучше?

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

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

электриков и механиков, витающих в облаках. И так до бесконечности. В свое время такая структура имела определенные преимущества, поскольку специалисты функциональных подразделений:

общались друг с другом на одном языке;

обменивались информацией о передовых технологиях и методах ра­ боты, что расширяло их кругозор;

посещали одни и те же специализированные конференции, читали одни и те же журналы и продолжали учиться долгие годы после окончания университета;

могли стандартизировать свои подходы и применяемые технологии, что снижало затраты и помогало распространять информацию о ре­ шении проблем;

при необходимости могли оперативно подключиться к выполнению проектов (за работу брался тот, кто был свободен в настоящий момент), что способствовало полноценному использованию инженерно-техни­ ческих ресурсов.

Однако такой подход к организационной структуре был чреват круп­ ной проблемой— узы между специалистами функциональных подразделе­ ний крепли, и их специальность и подразделение становились для них важ­ нее, чем компания, ее продукция и потребители. Люди измеряли свой успех эффективностью работы собственного функционального подразделения и объемами выделенных ему средств. Они считали, что их подразделение могло бы спасти компанию, и если бы последнее слово оставалось за ними, компания добилась бы головокружительных успехов. В результате ни одно подразделение не согласовывало свои действия с другими. Сегодня такие разобщенные функциональные подразделения часто неодобрительно на­ зывают функциональными шахтами или трубами.

Недостатки продуктовой структуры

Альтернатива функциональной организации — организация* ориентирован­ ная на продукт. Она предполагает создание межфункциональных команд, отвечающих за реализацию проекта или создание продуктаПри разверты­ вании очередного проекта по разработке продукции перед командой ставятся четко сформулированные цели и задачи. Все функциональные подразде­ ления, участвующие в разработке продукта и процесса, выделяют своих представителей для работы в проектной команде. Если есть возможность, команды работают под одной крышей, чтобы их члены могли беспрепят­

ственно обмениваться информацией о продукте и потребителе. Иногда этот метод называют параллельным проектированием, поскольку продукт и про­ цесс разрабатываются практически одновременно (Flesher and Liker, 1997). Ориентация на продукт позволяет сломать барьеры между изолированны­ ми подразделениями, сплотить компанию и сосредоточиться на решении важнейшего вопроса — как удовлетворить потребителя, чтобы повысить спрос на продукцию и сделать компанию более рентабельной. Структура, ориентированная на продукт, дает компании ряд преимуществ:

функциональные подразделения работают на общие цели, создавая продукцию, которая удовлетворяет потребителей;

эффективный обмен информацией и координация выполнения работ снижают время выполнения заказа;

решения, касающиеся продукта и процесса, принимаются с учетом разных точек зрения, что позволяет повысить качество продукции;

создание гибких самоуправляемых команд, которые хорошо адапти­ руются к изменению внешних условий.

Однако ориентация на продукт порождает свои проблемы, что подтверж­ дает история использования проектных команд для разработки платформ

вChrysler. Разделив все автомобили по видам платформ — крупногабарит­ ные автомобили, малолитражки, мини-вэны и т.д.,— компания собрала специалистов всех функциональных подразделений, которые участвовали

всоздании соответствующей категории автомобилей, под одной крышей. Такая проектная команда подчинялась генеральному менеджеру, обязан­ ности которого были похожи на обязанности главного инженера Toyota. Однако, как отмечает Собек (Sobek, 1997), реструктуризация вызвала ряд проблем и повлекла определенные издержки. Инженеры Chrysler тратили массу времени на координацию работы и бесконечные заседания, а стандар­ тизации в рамках функциональных подразделений (в том числе использо­ ванию единых комплектующих) не уделялось должного внимания. Вскоре каждая проектная команда превратилась в своеобразную функциональную шахту, которая отличалась от традиционных функциональных подразделе­ ний лишь своей продуктовой направленностью. Члены проектных команд все больше зацикливались на своем продукте, что снижало эффективность распределения ресурсов между платформами. Более того, хотя жизненный цикл проекта предполагает всплески и спады объема работ, генеральный менеджер стремился сохранить число инженеров неизменным, поскольку, дав возможность инженеру поработать в другой проектной команде, он мог потерять специалиста.

Соседние файлы в папке книги