Канва стратегии голубого океана – с чего начинать анализ

Когда вам как бизнес аналитику предлагают создать новое решение лучше тех остальных – первое что надо проанализировать – это стратегическую канву. В свое время для меня это стало открытием – и я получил его от большого фана этого инструмента и в целом Стратегии голубого океана – Павла Шеремета. Я был удивлен насколько простая картинка в несколько точек по горизонтали и вертикали все расставляет на места. В течении следующих нескольких лет после знакомства с инструментом – он вошел в практику и стал одним из первых инструментов начала работы на проектом нового продукта. Этот инструмент применялся и при создании новых продуктов (Web решения, мобильные продукты) так и при автоматизации процессов (тут сложнее – если не научится смотреть на бизнес процесс как на внутренний продукт).

Давайте посмотри на инструмент и что важного для аналитика в нем. Сам инструмент был описан в книге Чан Кима и Рене Моборна «Стратегия голубого океана». По своей структуре инструмент прост. Авторы предлагают на оси по горизонтали указать ключевые фичи бизнес модели с точки зрения клиентов а по вертикали – оценку фич с точки зрения клиентов. Вы берете несколько конкурентов и расставляете точки, соединяете линиями точки для каждого конкурента. И потом рисуете свою целевую кривую. Давайте посмотрим на пример этого инструмента из самой книги – канву стратегии вина Yellow Tail которое порвало рынок (да – не софт!)

yellowt

 

Посмотри внимательно на пример вина Yellow Tail. Видно что по рядм параметров – он плох. Справа на кривой – резкий всплеск. Три фичи уходят резко вверх.  Отсутствие оценок по ряду фи может значить что это в принципе инновационные фичи для сегмента. История картинки Yellow Tail закончилось тем что вино “порвало” рынок. Вино “забило” на большую часть классических свойства вина. Его сделали проще и прикольные. И ребята команды Yellow Tail хорошо знали кто устал от миллионов бутылок, мук выбора регионов, сортов вина, марок, наград.  Так, а софт тут при чем?

Построить софтовый продукт – задачка не сильно отличается в своей начальной точки от задачки Yellow Tail. У нас есть профессиональная деформация – что нам стоит дом построить, нарисуем – будем жить. Мы знаем что мы быстро можем построить софт. Мы своими руками и мозгами. Но далеко не всегда у нас хорошо получается подумать о самом важном – нафиг оно кому надо. Думаете так просто? Очень часто начало прорисовки данного инструмента с моей стороны как бизнес аналитика уводило на шаг назад и в глубокие раздумья владельцев продукта и бюджетов софтверных проектов:

  • Далеко не всегда в начале тек кто стартуют продукт хорошо понимают в чем их ключевые отличия – а это значит что вас могут отправить рыть не туда
  • Часто мешают несколько сегментов и незаметно для себя хотят прыгнуть мягким местом software везде – а это значит что вы будете работать не с теми заинтересованными лицами, брать не те профили пользователей
  • Не могу просто сформулировать чем же решение будет лучше 3 конкурентов и двух альтернатив – а это значит что вы можете сильно ошибаться при benchmark анализе
  • Не расставлены приоритеты, не ясно какие планы по развитию фич на пару шагов впереди – удар по планированию работы, по архитектуре

Что важно:

  • Вы определяете набор фич которые замечает клиент. Безусловно важно. Мы должны понимать как видит картинку клиент. Их надо знать все.
  • Вы видите какие наборы фич плохо реализованы конкурентами/аналогами. Вряд ли будет вы собираетесь сделать “еще один Facebook”. У вас появляется мотивация не просто сделать еще один софт Це-Эр-Эм – а нечто нужное, то чего не хватает. Остается понять если ли спрос именно для этих фич.
  • Вы сможете сделать вывод какой микросегмент наиболее болезненно принимает удар по плохо реализованным фичам. Тадааам. Они ваши клиенты. Сегмент из целевого сегмента. Вы знаете точно как бизнес аналитик к кому вам идти.
  • Вы сможете сделать вывод где вам не надо быть лучшими. Быть идеальным по всех фичах – это не реально (долго-дорого-невозможно изза конфликта). Тут вы сознательно делаете проще, вы точно знаете что не будете развивать это направление. Ваши решения будут экономнее, вы просто сможете аргументировать trade-off (привет принципу SAFe)
  • Вы определяете набор приоритетных фич продукта – что определяет вашу ключевую разницу. Это ли не мега важно для вас как бизнес аналитика? Вы теперь знаете что приоритет и где будут отличия.

Как вам как ИТ спецу а особенно как бизнес аналитику можно начать работать с этим инструментом

  • У многих ИТ спецов в мозгу крутятся идеи своих стартапов. Вы уже рисуете эту матрицу?
  • Вы как бизнес аналитик заходите в новый проект. Вам опускают общий расказ о том как вы будете работать. Вам не кажется что там сверху точно не могут выразить отличия и приоритеты? Вам не кажется что там путаются в микросегментах? Спросите у ребят из маркетинга про эту картинку. Если они откажут или скажут что это простая хрень – попросите их тогда на бумажке с вами быстро составить чтобы вы поняли
  • Вы уже работаете над новым решением в вашей компании – внутренний проект. А вы уверены что знаете какие TOP10 фич являются важными для внутренних клиентов. А какие TOp3 для ключевых внутренних клиентов?