Как правильно определить масштабы бизнеса?
Какие виды деятельности по разработке, производству и продаже продукта новой компании следует взять на себя, чтобы развиваться максимально успешно и быстро? Какое производство передать поставщику или партнеру? Следует ли заявлять права собственности на весь продукт или стоит пойти на модульное устройство бизнеса и открытые стандарты? Что подталкивает эволюцию от закрытой архитектуры продукта, права на который принадлежат одному собственнику, к открытой? Нужно ли компании стараться сохранить права собственности на весь продукт, когда уже появились открытые стандарты?
Решение о том, что производить самой компании, а что получать от поставщиков и партнеров, во многом определяет шансы на успех нового бизнеса. Все хорошо знают теорию, главными понятиями которой являются «основной бизнес» и «специализация». Если какой-то вид деятельности соответствует вашему основному бизнесу, то занимайтесь им сами, а если он не соответствует и есть фирмы, специализирующиеся на этой деятельности, – передайте им производство[79]. Руководство обычно поступает в соответствии с этой теорией.
Верна ли теория? Проблема в том, что не всегда легко определить, какие виды деятельности относятся к вашему основному бизнесу, а какие нет. Сегодня вам кажется, что то или иное производство не входит в него, а завтра вы поймете, что именно от него зависит успех всей компании и вам просто необходимо включить его в свой процесс.
Рассмотрим, например, решение IBM передать производство микропроцессоров для своих компьютеров компании Intel, а производство операционных систем – компании Microsoft. Эти решения руководство IBM приняло в начале 1980-х годов. Сама же компания должна была сосредоточиться на том, что она умела делать лучше всего, – на разработке, сборке и продвижении на рынок персональных компьютеров. С точки зрения истории развития компании эти решения представлялись вполне мудрыми. И Intel, и Microsoft прежде были никому не известными компаниями с минимальными прибылями, и деловая пресса на все лады расхваливала решение IBM передать им производство компонентов для своих компьютеров. Таким образом, IBM удалось резко сократить время разработки и запуска новых компьютеров. И все-таки, передав часть своего производства, IBM ввела в бизнес две другие компании, которые впоследствии стали получать самые высокие прибыли в отрасли, а ведь их могла бы получать и сама IBM.
Был ли у руководства IBM шанс предугадать, что это мудрое решение так дорого обойдется компании? Поставим вопрос шире: может ли исполнительный директор, который, как глава IBM в начале 1980-х годов, запускает новый перспективный бизнес, заранее знать, какие виды деятельности будут реально необходимы компании в будущем, чтобы оставить соответствующее производство в компании?[80]
Прошлый опыт часто вводит нас в заблуждение относительно будущего, поэтому единственный способ правильно предсказывать будущее – положиться на хорошую теорию. Чтобы описать, как тот или иной род деятельности становится основным или побочным, нам необходима теория, основанная на классификации условий и ситуаций. В пятой и шестой главах мы опишем этот механизм и покажем, как руководитель может использовать нашу теорию.
Интеграция или аутсорсинг?
IBM и другие компании продемонстрировали – по недосмотру, конечно же, – что деление бизнеса на основной и побочный может привести к серьезным, даже фатальным ошибкам. Не всегда надо равняться на то, что у компании получается лучше всего в данный момент. Вместо этого нужно думать, каким производством необходимо овладеть сегодня, и каким – в будущем, чтобы совершенствовать продукт в направлении, важном для потребителей.
Тут нам снова поможет метафора о «найме» товара «на работу»: клиенты купят ваш товар только в том случае, если с его помощью решат важные для себя задачи. Но эти «решения» могут различаться в зависимости от двух представленных на схеме 5.1 условий: товар может быть недостаточно качественным или, наоборот, слишком качественным. Мы пришли к выводу, что, если товар пока недостаточно хорош, компании выгоднее интегрировать все производство у себя. Аутсорсинг – или специализация и дезинтеграция – уместен, наоборот, если продукт стал слишком высокого качества.
Чтобы пояснить это утверждение, мы должны рассмотреть инженерные понятия «взаимозависимость» и «модульность» и показать их важность для архитектуры продукта. Мы еще вернемся к схеме 5.1, чтобы увидеть, как эти понятия соотносятся с «подрывной» стратегией.
Архитектура продукта и контактные зоны
Архитектура продукта определяет его компоненты и их взаимодействие: насколько они подходят друг другу, чтобы в итоге была достигнута функциональность, ради которой продукт и был задуман. Место соприкосновения двух компонентов называется контактной зоной. Контактные зоны, то есть параметры совместимости, существуют как между разными компонентами продукта, так и между стадиями в цепочке создания стоимости (value-added chain). Например, существует контактная зона между разработкой и производством или между производством и реализацией.
Архитектура продукта является взаимозависимой, если хотя бы один его компонент нельзя создать отдельно от других, если его разработка и производство зависят от того, как разработаны и производятся остальные составляющие. Если же компания хочет разрабатывать и создавать какой-либо компонент продукта, а при этом в какой-нибудь из его контактных зон могут появиться непредсказуемые взаимосвязи, то ей нужно одновременно разрабатывать и создавать оба компонента.
Взаимозависимая архитектура оптимизирует свойства продукта в смысле его функциональности и надежности. По определению взаимозависимые архитектуры могут быть только закрытыми: каждая компания разрабатывает свою собственную архитектуру продукта со всем взаимосвязями, чтобы определенным, отличным от других способом оптимизировать его свойства, и при этом она обладает всеми правами на него. Когда мы в этой главе говорим о взаимозависимых архитектурах, этот термин следует понимать как закрытые, патентованные, оптимизированные архитектуры.
Наоборот, в модульной контактной зоне нет непредсказуемых взаимосвязей между компонентами продукта или стадиями в цепочке создания стоимости. Модульные компоненты стыкуются и работают вместе по понятным и четко определенным правилам. Модульная архитектура определяет место и функции каждого компонента в структуре – и определяет всеобъемлюще, настолько, что уже не имеет значения, кто производит компоненты или подсистемы, раз они полностью соответствуют спецификации. Модульные компоненты можно разрабатывать в независимых рабочих группах или в разных компаниях, управляемых из центрального офиса.
Таким образом, модульные архитектуры придают гибкость процессу создания стоимости, но требуют жестких спецификаций всех компонентов продукта и оставляют инженерам меньше свободы при разработке. В результате ради гибкости модульной архитектуры приходится жертвовать качеством продукта – его свойства должны быть жестко определены[81].
Чистые случаи модульных и взаимозависимых архитектур – это две крайние точки на шкале, и большинство продуктов находятся между ними. Мы увидим, что компании скорее добьются успеха, если архитектура их продуктов будет определяться конкурентной ситуацией на рынке.
Когда выгодна взаимозависимая архитектура
Левая часть схемы 5.1 показывает, что, когда представленные на рынке продукты недостаточно функциональны и надежны и потому не удовлетворяют потребителей из определенного сектора рынка, компания должна выпускать товары гораздо лучшего качества, чем у конкурентов. В этой ситуации конкурентное преимущество будет на стороне компаний, которые изберут взаимозависимую, а не модульную архитектуру. Из-за жесткой стандартизации, а это неотъемлемая часть модульной архитектуры, у инженеров не остается свободы при разработке архитектуры продукта, поэтому они не могут оптимизировать его работу и технические характеристики.
Чтобы каждый последующий продукт нового поколения был лучше предыдущих, разработчики вынуждены искать более эффективные способы соединения в одно целое всех частей системы, чтобы максимально использовать достижения технологии. Когда конкуренция разворачивается вокруг качества продукта и побеждает производитель лучшего продукта, компания не может позволить себе просто собирать продукты из стандартных компонентов: ведь с технической точки зрения, стандартизация контактных зон (то есть меньшая свобода архитектуры) – это шаг назад, отказ от достижения самого высокого технологического уровня. Если конкуренция разворачивается вокруг качества продукта, то вы потерпите поражение.
Компании, выходящие на рынок с продуктами взаимозависимой архитектуры, должны быть интегрированными: нужно контролировать производство всех важнейших компонентов системы, чтобы производить любой ее компонент. В качестве иллюстрации рассмотрим пример из компьютерной индустрии. В самом начале, когда функциональность и надежность первых компьютеров еще не достигли высокого уровня и не удовлетворяли полностью запросы потребителей, компания не могла существовать как независимый, работающий по контракту производитель компьютеров: способ разработки первых машин еще слишком зависел от производственного процесса, и наоборот. Не было ярко выраженной контактной зоны между производством и разработкой. Точно так же компания не могла существовать в компьютерной индустрии как независимый поставщик операционных систем, памяти или логических схем, потому что производство этих ключевых подсистем зависело от общей производственной цепочки и в процессе разработки и производства проходили несколько последовательных итераций