Когда конкурируют модульные продукты, поставка отдельных компонентов продукта или сборка продукта из производимых на стороне компонентов – вполне удачное, оправданное решение. Если же функциональность продукта далека от нужд потребителей, а на рынке преобладают продукты взаимозависимой архитектуры, никто не заинтересуется поставками на рынок отдельных подсистем или фрагментов систем. Зная это, можно предсказать, ждет новый бизнес успех или неудача, – учитывая, какую архитектуру продукта выбирает руководство, если обстоятельства требуют модульной или, наоборот, взаимозависимой архитектуры.
Может ли развиваться неинтегрированный бизнес, если продукт не соответствует потребностям рынка?
Очень соблазнительно порой думать, что можно развивать новый бизнес, поставляя один из компонентов в модульной цепочке создания стоимости. Руководителям часто кажется. что специализация – самый надежный путь выхода на рынок, что это не столь опасно, как производство целого системного продукта. Более дешевое производство отдельных компонентов позволяет компании-новичку сосредоточиться на том, что у нее получается лучше всего, и оставить все прочие компоненты партнерам. Но эта логика работает только в ситуации, изображенной в нижней правой части диаграммы «подрывного» процесса (см. схему 2.1). Когда же продукты на рынке недостаточно хороши в смысле функциональности и надежности, а партнерство или аутсорсинг кажутся более легким вариантом, нужно помнить, что эта легкость иллюзорна и подобное рассуждение уже стало причиной неуспеха многих компаний. На самых ранних стадиях «подрывного» вытеснения модульность невозможна по технологическим причинам и по условиям конкурентной борьбы.
Чтобы преуспеть, избрав стратегию дезинтеграции и специализации, получая отдельные компоненты от производителя-партнера или продавая потребителям отдельные подсистемы, вы должны быть уверены, что конкуренция благоприятствует модульности. Во-первых, и поставщики, и потребители должны знать, какие параметры того или иного компонента являются решающими для деятельности всей системы, всего продукта, а какие – второстепенными. Во-вторых, они должны уметь измерить эти параметры и убедиться, что требования спецификации выполнены. В-третьих, в контактной зоне поставщика и потребителя не должно быть неясных, непредвиденных взаимосвязей. Потребитель должен понимать, как каждая подсистема будет взаимодействовать с техническими характеристиками остальных фрагментов подсистемы: эффект использования всей системы должен быть абсолютно предсказуемым. Если эти три условия выполнены, вы можете быть уверены, что в мире модульных продуктов вам удастся эффективно взаимодействовать с партнерами и потребителями.
Когда же технические характеристики представленных на рынке продуктов не очень высоки, конкуренция вынуждает компании создавать продукты с нестандартной архитектурой на базе новых технологий, чтобы таким образом максимально поднять технический уровень продукта. В этой ситуации три условия, о которых говорилось выше, часто не выполняются. Если в системе существуют сложные, циклические взаимосвязи, отдельная компания должна брать на себя ответственность за все возможные контактные зоны. Люди не в состоянии грамотно решать проблемы, возникающие по причине сложных взаимосвязей в системе, если они работают далеко друг от друга – в разных организациях[94].
Почему нельзя выбирать модульную стратегию, когда рынок требует взаимозависимой архитектуры
В 1996 г. правительство США издало закон, стимулирующий конкуренцию среди компаний, предоставляющих услуги местной телефонной связи. По этому закону право продавать свои услуги юридическим и физическим лицам получали и независимые телефонные компании, а для этого они должны были иметь возможность встраиваться в инфраструктуру подключений ведущих телефонных компаний. В ответ на это многие независимые поставщики коммуникационных услуг, такие как, например, Northpoint Communications, стали предлагать высокоскоростной DSL-доступ в интернет. Корпорации и венчурные предприниматели вкладывали в эти компании миллиарды долларов, однако подавляющее их большинство потерпело крах – в первую очередь потому, что на нашей схеме 5.1 услуги DSL-доступа находились бы в левой части как требующие взаимозависимой архитектуры.