Этот дисбаланс выглядит нездоровым, хотя он и не должен нас удивлять. Такие финансовые инструменты для оценки перспективных проектов, как анализ дисконтированных денежных потоков, обычно дают негативную оценку отложенному получению выручки и уровню неопределенности, присущим инновациям «с большой И». Помимо этого, проекты «с маленькой и» обычно забирают немалую долю бюджетов на исследования и разработки, поскольку компании пытаются постоянно соответствовать требованиям клиентов и отделов продаж, желающих видеть постоянно и постепенно улучшающиеся продукты. Матрица риска создает визуальную начальную точку для постоянного диалога о правильном ассортименте проектов компании и степени их соответствия стратегии и готовности к риску. На следующем шаге нам нужно внимательно изучить перспективы каждого проекта на рынке.
Процедура работы с R-W-W
R-W-W – это простой, но мощный инструмент, основанный на серии вопросов об инновационной концепции или продукте, потенциале его рынка, а также о возможностях и конкурентоспособности компании (см. врезку «Оценка возможного успеха»). Это, скорее, не алгоритм для принятия решений «делать» или «не делать», а следующий четкой дисциплине процесс, который может применяться на различных этапах разработки продукта и выявлять неверные предположения, пробелы в знании и потенциальные источники риска, а также убедиться в том, что компания изучила все пути для усовершенствования. Инструмент R-W-W может применяться для выявления и помощи в фиксации проблем, способных мешать проекту, снижения степени риска и определения проблем, которые не поддаются решению и, следовательно, могут привести к прекращению работы над проектом.
Инновация по своей сути – процесс беспорядочный, нелинейный и итеративный. Для простоты эта статья рассказывает об использовании R-W-W на ранних этапах работы для тестирования жизнеспособности концепций продуктов. В реальности продукт должен подвергаться подобной оценке постоянно и на различных этапах разработки: формулирования концепции, создания прототипа и планирования запуска в производство. Постоянно повторяющаяся оценка позволяет принимать во внимание все новые детали, связанные с продуктом, рынком и финансами. А это позволяет получить более точные ответы на вопросы.
Метод R-W-W заставляет команду разработчиков глубже погрузиться в анализ шести фундаментальных вопросов: Реален ли рынок? Реален ли продукт? Может ли продукт быть конкурентоспособным? Может ли наша компания быть конкурентоспособной? Будет ли продукт прибыльным при допустимом уровне риска? Имеет ли запуск продукта стратегический смысл?
Оценка возможного успеха
Концепция каждого продукта в портфеле инноваций вашей компании требует оценки командой по развитию с помощью инструмента R-W-W, описанного ниже. Для того чтобы дать четкий ответ «да» или «нет» на вопросы из первой колонки «Насколько это реально?», «Можем ли мы выиграть?» и «Стоит ли этим заниматься?», требуется найти ответы на поддерживающие вопросы во второй и третьей колонках. Команда может дать на те или иные вопросы ответ «возможно»; ее цель состоит в изучении всех возможных путей к превращению «нет» в «может быть» или «да». Четкий ответ «нет» на любой вопрос из второй колонки обычно ведет к прекращению проекта, поскольку в этом случае неудача практически гарантирована. Четкий ответ «нет» на любой вопрос из третьей колонки также свидетельствует о необходимости остановки дальнейшей работы. (Полный набор вопросов в колонках 2 и 3 основан на данных оценки более 50 неудачных продуктов в двух компаниях, с которыми я работал в составе аудиторской команды. Мы просили сотрудников компаний ответить: «Какие вовремя заданные вопросы могли бы предотвратить неудачу?»)
Команда для тестирования
КОМАНДЫ ПО ТЕСТИРОВАНИЮ ПРОЕКТА могут различаться в зависимости от компании, типа проекта и этапа его развития. В процессе тестирования в команды обычно добавляются представители различных функциональных направлений, включая исследования и разработки, маркетинг и производство. Они должны сотрудничать с представителями высшего руководства, которые знакомы с инструментом и обладают достаточным опытом и инстинктами для того, чтобы бесстрастно требовать точных ответов, в особенности в процессе практической реализации. При этом менеджеры должны быть готовы активно сотрудничать с командой и обеспечивать ее ресурсами, необходимыми для закрытия пробелов в информации.
В процессе управления работой с R-W-W критически важно, чтобы команды не воспринимали этот инструмент как препятствие, которое нужно преодолевать или обходить. Также важно, чтобы команда не воспринимала инструмент как потенциальную угрозу для своего проекта. Его цель состоит совсем не в том, чтобы дать руководству возможность сказать проекту «да» или «нет». Подобное неверное понимание сути работы не позволит использовать этот инструмент для обучения, выявления сомнительных предположений, формулирования проблем и их решений.
Поскольку участники команды разработчиков одновременно выполняют две роли – оценщиков концепции и ее защитников, в процессе работы возможны случаи неправильного использования и даже манипуляций. Убежденность участников команды в достоинствах проекта может привести к поверхностной оценке – особенно если они боятся, что проект может пострадать в случае проведения глубокой оценки и откровенного высказывания сомнений. Один из путей избегания этой проблемы состоит в привлечении к работе внушающего доверие модератора (возможно, представителя другого подразделения компании), имеющего опыт в выводе на рынок новых продуктов или заинтересованного в положительном исходе. Работа этого человека должна состоять в выявлении всех ключевых неопределенностей, пробелов в информации, различий во мнениях и в помощи в достижении компромисса.
Команда разработчиков отвечает на эти вопросы с помощью изучения еще более детального набора поддерживающих вопросов. Команда определяет, как выглядит наиболее точный ответ на каждый вопрос в диапазоне от «определенно да» до «определенно нет». Ответ «определенно нет» на любой из первых пяти фундаментальных вопросов обычно ведет по вполне очевидным причинам к прекращению дальнейшей работы над проектом. К примеру, если команда договаривается, что ответ на вопрос «Может ли продукт быть конкурентоспособным?» – это «определенно нет», и команда не может понять, каким образом превратить ответ в «да» (или хотя бы «может быть»), то продолжение дальнейшей работы не имеет никакого рационального смысла. Однако если проект успешно преодолел все остальные тесты и, таким образом, команда считает, что на него можно сделать ставку, то порой имеет смысл менее жестко отнестись к ответу на шестой вопрос: Имеет ли запуск продукта стратегический смысл?
Эта статья описывает процесс оценки и демонстрирует всю глубину зондирования, необходимого для получения осмысленных ответов. Разумеется, мы не пытаемся дать вам исчерпывающее руководство по всем ситуациям, которые могут возникнуть при изучении каждого вопроса. При необходимости команды разработчиков могут изучать тот или иной вопрос с разной степенью глубины (больше деталей о процессе командной работы приведено во врезке «Команда для тестирования»).
Насколько это реально?
Первые шаги в оценке концепции продукта – это выяснение того, существует ли рынок и возможно ли создать продукт для его удовлетворения. Именно эти шаги продемонстрируют степени возможностей для любой фирмы, рассматривающей потенциальный рынок, и в процессе изучения компания сможет оценить, насколько конкурентной может оказаться среда с самого начала.
Конечно, вы можете предположить, что вопрос о том, возможно ли создать нужный продукт в принципе, стоит изучать еще перед тем, как вы начнете изучать потенциальный рынок. Однако понимание степени реальности рынка важно по двум причинам. Во-первых, мы гораздо хуже представляем себе реальное состояние рынка, чем свою технологическую способность что-то сделать. Именно в этом и заключается одно из посланий матрицы риска. Она показывает, что вероятность неудачи с продуктом растет гораздо быстрее, когда компании незнаком рынок, чем когда ей незнакомы продукт или технология. Способность компании кристаллизовать концепцию рынка – определить целевой сегмент и то, каким наилучшим образом продукт может удовлетворить его потребности, – важна намного больше, чем то, каким образом компания умеет использовать принципиально новый продукт или технологию. Более того, проведенное компанией Procter & Gamble исследование показывает, что 70 % неудач с продуктами во множестве категорий связано с тем, что компании неправильно трактуют свой рынок. «Новая кола» – типичный пример неправильного понимания концепции рынка; а Netflix – пример правильного. В каждом случае исход определялся пониманием компанией сути рынка, а не ее способностями к использованию тех или иных технологий.
Во-вторых, понимание природы рынка способно предотвратить возникновение довольно дорогостоящего «технологического толчка». Этот синдром часто поражает компании, которые слишком много думают над тем, как решить технологическую задачу, а не над тем, какая именно проблема требует решения или какие потребности это решение должно удовлетворить. Примерами технологического толчка могут служить Segway со своим устройством Personal Transporter и Motorola с мобильным телефоном Iridium. Personal Transporter Segway представлял собой гениальный способ гироскопической стабилизации платформы на двух колесах, однако у него не было никакого целевого рынка, для которого он мог бы решать проблемы мобильности. Причины неудачи Iridium обсуждаются до сих пор, однако одна из них может быть связана с тем, что мобильная спутниковая связь оказалась менее выгодным решением для большинства путешественников, чем услуги по наземному беспроводному роумингу.
Вопрос о реальности рынка и продукта должен доминировать на первых этапах процесса разработки, особенно для инноваций «с большой И». В случае инноваций «с маленькой и» определенные альтернативы будущему продукту уже будут иметься на рынке, т. е. будет понятно, что и продукт, и рынок реальны.