Расчет каждого балла требует глубокого понимания происходящего. К примеру, когда компания McDonald's попыталась предложить в своем ассортименте пиццу, она предположила, что новое предложение достаточно близко к уже имевшемуся ассортименту, и поэтому нацелилась на своих обычных клиентов. При этом предположении пицца была бы знакомым продуктом для уже имевшегося рынка и, соответственно, заняла бы место в левом нижнем углу матрицы риска. Однако проект потерпел неудачу, а последующее изучение причин неудачи показало, что на самом деле проект был намного более рискованным. Поскольку никто не мог понять, как приготовить и подать пиццу менее чем за 30 секунд, выполнение заказов тормозилось, что нарушало принципы модели сервиса, принятые в McDonald's. Также изучение показало, что бренд компании не давал «разрешения» предлагать клиентам пиццу. И хотя основные клиенты этой сети быстрого питания были близки по своим демографическим характеристикам к любителям пиццы, они совершенно не ожидали видеть пиццу в ассортименте McDonald's.
Этот инструмент позволяет увидеть распределение рисков по всему портфелю инноваций компании. Каждая инновация может располагаться на матрице после того, как вы определите значение ее координат – того, насколько знаком компании желаемый рынок (ось x), и того, насколько ей знакомы продукт или технология (ось y), – с помощью сетки «Положение проекта на матрице». Знакомые продукты, нацеленные на уже имеющиеся у компании рынки, окажутся в левой нижней части матрицы, что означает низкую вероятность неудачи. Новые продукты, нацеленные на незнакомые рынки, окажутся в верхнем правом углу, что означает высокую вероятность неудачи.
Каждая точка на этой матрице риска означает одну инновацию в возможном портфеле компании. Размер каждой точки пропорционален оцениваемой выручке от проекта (компании могут также оценивать возможные результаты с помощью величины инвестиций или какого-то другого финансового показателя). Этот портфель, в котором доминируют проекты со сравнительно низкой степенью риска, довольно типичен с точки зрения распределения рисков.
Найдите место для каждого инновационного продукта или концепции. Для этого сопоставьте каждое из заявлений в левой колонке с одним из вариантов в верхней строке, выбрав на их пересечении соответствующее значение от 1 до 5. Для определения координаты x проекта на матрице риска нужно сложить шесть значений в разделе «Желаемый рынок». А для определения координаты для оси y следует сложить семь значений в разделе «Продукт/технология».
После завершения работы над матрицей риска обычно становятся понятными две вещи: то, что у компании имеется больше проектов, чем она может эффективно реализовать, и то, что распределение инноваций «с большой И» и «с маленькой и» довольно неравномерно. Большинство компаний обнаруживает, что значительная доля их продуктов группируется в нижнем левом квадранте матрицы, а меньшинство стремится к правому верхнему.
Этот дисбаланс выглядит нездоровым, хотя он и не должен нас удивлять. Такие финансовые инструменты для оценки перспективных проектов, как анализ дисконтированных денежных потоков, обычно дают негативную оценку отложенному получению выручки и уровню неопределенности, присущим инновациям «с большой И». Помимо этого, проекты «с маленькой и» обычно забирают немалую долю бюджетов на исследования и разработки, поскольку компании пытаются постоянно соответствовать требованиям клиентов и отделов продаж, желающих видеть постоянно и постепенно улучшающиеся продукты. Матрица риска создает визуальную начальную точку для постоянного диалога о правильном ассортименте проектов компании и степени их соответствия стратегии и готовности к риску. На следующем шаге нам нужно внимательно изучить перспективы каждого проекта на рынке.
Процедура работы с R-W-W
R-W-W – это простой, но мощный инструмент, основанный на серии вопросов об инновационной концепции или продукте, потенциале его рынка, а также о возможностях и конкурентоспособности компании (см. врезку «Оценка возможного успеха»). Это, скорее, не алгоритм для принятия решений «делать» или «не делать», а следующий четкой дисциплине процесс, который может применяться на различных этапах разработки продукта и выявлять неверные предположения, пробелы в знании и потенциальные источники риска, а также убедиться в том, что компания изучила все пути для усовершенствования. Инструмент R-W-W может применяться для выявления и помощи в фиксации проблем, способных мешать проекту, снижения степени риска и определения проблем, которые не поддаются решению и, следовательно, могут привести к прекращению работы над проектом.
Инновация по своей сути – процесс беспорядочный, нелинейный и итеративный. Для простоты эта статья рассказывает об использовании R-W-W на ранних этапах работы для тестирования жизнеспособности концепций продуктов. В реальности продукт должен подвергаться подобной оценке постоянно и на различных этапах разработки: формулирования концепции, создания прототипа и планирования запуска в производство. Постоянно повторяющаяся оценка позволяет принимать во внимание все новые детали, связанные с продуктом, рынком и финансами. А это позволяет получить более точные ответы на вопросы.
Метод R-W-W заставляет команду разработчиков глубже погрузиться в анализ шести фундаментальных вопросов: Реален ли рынок? Реален ли продукт? Может ли продукт быть конкурентоспособным? Может ли наша компания быть конкурентоспособной? Будет ли продукт прибыльным при допустимом уровне риска? Имеет ли запуск продукта стратегический смысл?
Концепция каждого продукта в портфеле инноваций вашей компании требует оценки командой по развитию с помощью инструмента R-W-W, описанного ниже. Для того чтобы дать четкий ответ «да» или «нет» на вопросы из первой колонки «Насколько это реально?», «Можем ли мы выиграть?» и «Стоит ли этим заниматься?», требуется найти ответы на поддерживающие вопросы во второй и третьей колонках. Команда может дать на те или иные вопросы ответ «возможно»; ее цель состоит в изучении всех возможных путей к превращению «нет» в «может быть» или «да». Четкий ответ «нет» на любой вопрос из второй колонки обычно ведет к прекращению проекта, поскольку в этом случае неудача практически гарантирована. Четкий ответ «нет» на любой вопрос из третьей колонки также свидетельствует о необходимости остановки дальнейшей работы. (Полный набор вопросов в колонках 2 и 3 основан на данных оценки более 50 неудачных продуктов в двух компаниях, с которыми я работал в составе аудиторской команды. Мы просили сотрудников компаний ответить: «Какие вовремя заданные вопросы могли бы предотвратить неудачу?»)
Команда разработчиков отвечает на эти вопросы с помощью изучения еще более детального набора поддерживающих вопросов. Команда определяет, как выглядит наиболее точный ответ на каждый вопрос в диапазоне от «определенно да» до «определенно нет». Ответ «определенно нет» на любой из первых пяти фундаментальных вопросов обычно ведет по вполне очевидным причинам к прекращению дальнейшей работы над проектом. К примеру, если команда договаривается, что ответ на вопрос «Может ли продукт быть конкурентоспособным?» – это «определенно нет», и команда не может понять, каким образом превратить ответ в «да» (или хотя бы «может быть»), то продолжение дальнейшей работы не имеет никакого рационального смысла. Однако если проект успешно преодолел все остальные тесты и, таким образом, команда считает, что на него можно сделать ставку, то порой имеет смысл менее жестко отнестись к ответу на шестой вопрос: Имеет ли запуск продукта стратегический смысл?
Эта статья описывает процесс оценки и демонстрирует всю глубину зондирования, необходимого для получения осмысленных ответов. Разумеется, мы не пытаемся дать вам исчерпывающее руководство по всем ситуациям, которые могут возникнуть при изучении каждого вопроса. При необходимости команды разработчиков могут изучать тот или иной вопрос с разной степенью глубины (больше деталей о процессе командной работы приведено во врезке «Команда для тестирования»).
Команды по тестированию проекта могут различаться в зависимости от компании, типа проекта и этапа его развития. В процессе тестирования в команды обычно добавляются представители различных функциональных направлений, включая исследования и разработки, маркетинг и производство. Они должны сотрудничать с представителями высшего руководства, которые знакомы с инструментом и обладают достаточным опытом и инстинктами для того, чтобы бесстрастно требовать точных ответов, в особенности в процессе практической реализации. При этом менеджеры должны быть готовы активно сотрудничать с командой и обеспечивать ее ресурсами, необходимыми для закрытия пробелов в информации.
В процессе управления работой с R-W-W критически важно, чтобы команды не воспринимали этот инструмент как препятствие, которое нужно преодолевать или обходить. Также важно, чтобы команда не воспринимала инструмент как потенциальную угрозу для своего проекта. Его цель состоит совсем не в том, чтобы дать руководству возможность сказать проекту «да» или «нет». Подобное неверное понимание сути работы не позволит использовать этот инструмент для обучения, выявления сомнительных предположений, формулирования проблем и их решений.
Поскольку участники команды разработчиков одновременно выполняют две роли – оценщиков концепции и ее защитников, в процессе работы возможны случаи неправильного использования и даже манипуляций. Убежденность участников команды в достоинствах проекта может привести к поверхностной оценке – особенно если они боятся, что проект может пострадать в случае проведения глубокой оценки и откровенного высказывания сомнений. Один из путей избегания этой проблемы состоит в привлечении к работе внушающего доверие модератора (возможно, представителя другого подразделения компании), имеющего опыт в выводе на рынок новых продуктов или заинтересованного в положительном исходе. Работа этого человека должна состоять в выявлении всех ключевых неопределенностей, пробелов в информации, различий во мнениях и в помощи в достижении компромисса.