Клейтон Кристенсен - Решение проблемы инноваций в бизнесе. Как создать растущий бизнес и успешно поддерживать его рост
- Название:Решение проблемы инноваций в бизнесе. Как создать растущий бизнес и успешно поддерживать его рост
- Автор:
- Жанр:
- Издательство:Array Литагент «Альпина»
- Год:2014
- Город:Москва
- ISBN:978-5-9614-3259-6
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Клейтон Кристенсен - Решение проблемы инноваций в бизнесе. Как создать растущий бизнес и успешно поддерживать его рост краткое содержание
Книга предназначена для менеджеров, предпринимателей, а также студентов и преподавателей экономических вузов.
Решение проблемы инноваций в бизнесе. Как создать растущий бизнес и успешно поддерживать его рост - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Верна ли теория? Проблема в том, что не всегда легко определить, какие виды деятельности относятся к вашему основному бизнесу, а какие нет. Сегодня вам кажется, что то или иное производство не входит в него, а завтра вы поймете, что именно от него зависит успех всей компании и вам просто необходимо включить его в свой процесс.
Рассмотрим, например, решение 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 показывает, что, когда представленные на рынке продукты недостаточно функциональны и надежны и потому не удовлетворяют потребителей из определенного сектора рынка, компания должна выпускать товары гораздо лучшего качества, чем у конкурентов. В этой ситуации конкурентное преимущество будет на стороне компаний, которые изберут взаимозависимую, а не модульную архитектуру. Из-за жесткой стандартизации, а это неотъемлемая часть модульной архитектуры, у инженеров не остается свободы при разработке архитектуры продукта, поэтому они не могут оптимизировать его работу и технические характеристики.
Читать дальшеИнтервал:
Закладка: