Рассмотрим пример.
Одного крупного американского поставщика автомобилей привлекла возможность ведения бизнеса в других странах с более низкими издержками, после чего он быстро перевел закупку компонентов в Китай. Хотя это решение на первый взгляд было простым и легким, компания вскоре поняла, что в новых условиях ей приходится гораздо активнее использовать своих партнеров по логистике и доставлять детали из Китая воздушным транспортом. Возникший логистический кошмар свел на нет все выгоды по издержкам, на которые рассчитывала компания, переходя к этому варианту аутсорсинга. Причинами такого результата были ее социальная и техническая архитектуры на момент принятия решения об аутсорсинге.
Проектировщики привыкли сообщать поставщикам об изменениях конструкции детали в последнюю минуту и изменения обязательно вносились. Эта практика неформальных контактов с поставщиками, обеспечивавшая «итеративный» процесс проектирования, никак не отражалась в ИКТ-архитектуре. Кроме того, об этой практике не знали и менеджеры, принявшие решение об аутсорсинге.
Китайский аутсорсинг потребовал другого подхода — намного более четкого процесса передачи производственникам готовых проектно-конструкторских документов. Это изменение повлияло не только на характер контактов между проектировщиками и поставщиками, но и на их контакты в социальной сфере. Китайские поставщики производили продукцию в соответствии с полученными спецификациями. Поэтому к тому времени, когда проектировщики присылали спецификации версии 2.0, китайские поставщики уже произвели продукцию в версии 1.0 и загрузили детали, созданные по предыдущим спецификациям, в контейнеры, которые на момент поступления следующей версии спецификаций уже были на пути в Мичиган.
Из-за этого фирме не оставалось ничего другого, как пойти на дополнительные производственные издержки и дорогостоящий вариант доставки самолетами деталей, изготовленных в соответствии со спецификацией версии 2.0.
Решение использовать дешевые ресурсы и возможности китайского производителя объяснялось реалиями бизнеса. Но техническая и социальная архитектуры компании не были готовы к этому варианту и не имели нужного набора составляющих, способных обеспечить необходимые эффективность и гибкость. Другими словами, системы и возможности не соответствовали стратегии. Системы, применявшиеся в этом бизнесе, от проектирования до закупок у поставщиков, не были прозрачными. Неудивительно, что при принятии решения об аутсорсинге производства итеративный процесс проектирования и взаимодействия разных групп не был учтен. Из-за этого новая офшорная модель потребовала более длительного времени выполнения заказа и более четких формулировок. Процесс перехода от проектирования к производству должен быть выражен в явном виде. Он также потребовал, чтобы проектные команды точнее формулировали условия своих конструкторских процессов и согласились с тем. что они сначала должны закончить свои проекты и только после этого отправлять их поставщикам. Необходимость более глубоко понять природу процессов принятия решений в проектных командах потребовала полной перестройки всех методов.
Противоречие между гибкостью и эффективностью | Пример 2 |