Зачем нужна карта влияния, как она связана с причинно-следственным анализом и пользовательскими историями. Разбираем простые и эффективные техники поиска решений для бизнес-аналитика: строим диаграмму Исикавы и Impact Map, смотрим шаблоны формулировки и паттерны декомпозиции User Story на примере интернет-магазина.
Еще раз про причинно-следственный анализ с диаграммой Исикавы на примере онлайн-торговли
Карты ассоциаций – отличная техника, которая позволяет аналитику исследовать цели, задачи и ограничения исследуемой ситуации, чтобы прийти к решению. Этот простой, но очень эффективный подход к визуализации связанных понятий используется в популярном методе причинно-следственного анализа под названием диаграмма Исикавы, а также в технике поиска решений, известной как Карта влияния (Impact Map). Также идеи картирования ситуации лежат в основе Event Storming – легковесной, но очень мощной техники исследования процессов и проектирования информационных систем. О ней я расскажу в следующий раз, а в этой статье посмотрим, как построить карту влияния на основе диаграммы Исикавы и получить из этого пользовательские требования в виде User Story.
Чтобы не повторять теорию по методу диаграмма Исикавы, которую я ранее описывала здесь, сразу перейдем к демонстрации возможностей этой техники. В качестве демо-примера, как обычно, возьмем интернет-магазин. Владеющая им торговая компания столкнулась с проблемой падения прибыли: фактические значения этого показателя на протяжении 6-ти месяцев подряд оказываются на 20-45% ниже плановых. Такие несоответствия критичны для бизнеса, поэтому нужно понять причину и устранить ее или, хотя бы, смягчить так, чтобы последствия для бизнеса были не такими болезненными. Поскольку прибыль – это производный показатель от доходов и затрат, для определения корневой причины исследуемой проблемы необходимо проанализировать источники этих финансовых статей.
Составим возможные причины снижения доходов:
- снизилась частота продаж
- повысилась сумма заказа с бесплатной доставкой
- введен штраф за возврат товаров
- уменьшился средний чек
- недостаточно широкий товарный ассортимент
- нет популярных товаров
- нет альтернативных товаров
- нет системы рекомендаций по товарам-субститутам или
комплементарным
- недостаточно широкий товарный ассортимент
- снизилось количество продаж
- вырос отток клиентов
- неэффективные программы лояльности для текущих клиентов
- нет регулярных мер по привлечению внимания текущих клиентов
- недостаточно новых клиентов
- нет промо-программ для новых клиентов
- неэффективная реклама
- не тот рекламный канал
- не тот рекламный креатив
- вырос отток клиентов
Аналогично, с помощью мозгового штурма и техники 5Why составим перечень причин роста затрат:
- увеличилась закупочная стоимость товаров
- изменился курс валют
- выросла инфляция
- увеличились накладные расходы
- повысилась стоимость доставки
- повысилась стоимость хранения
- повысилась стоимость сопровождения
Визуализируем это на диаграмме Исикавы, добавим несколько комментариев.
Выявленные причины роста затрат в основном обусловлены внешними причинами (экономические и политические факторы), повлиять на которые компания не в силах. Поэтому сосредоточимся на причинах падения доходов. Некоторые из них явно указывают на дополнительные возможности. Например, можно повысить средний чек, увеличив ассортимент предлагаемых товаров от разных поставщиков и ввести систему рекомендаций по комплементарным и замещающим товарам, которые интересуют клиента. Также можно повысить количество продаж, улучшив программы лояльности для текущих клиентов за счет аналитики данных по их заказам и обратной связи. Именно эти направления будем рассматривать далее на карте влияния.
Основы бизнес-анализа: вход в профессию для начинающих
Код курса
INTRO
Ближайшая дата курса
28 июня, 2024
Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.
Карта влияния (Imapct Map): что это такое и как ее составить
Карта влияния представляет собой древовидную диаграмму, которая показывает варианты достижения поставленной цели: какие влияния надо оказать на каких акторов и через какие действия или компоненты системы. Корневым узлом Impact Map является желаемая цель. В нашем примере необходимо повысить средний доход от клиента, что определено на основе причинно-следственного анализа проблем с падению прибыли. Привлечение новых клиентов обходится в несколько раз дороже удержания прежних, поэтому решено повысить средний чек и количество продаж. Однако, чтобы цель стала целью, а не просто намерением, ее необходимо сформулировать по шаблону SMART:
- Specific – конкретно;
- Measurable – измеримо;
- Assignable – назначаемо;
- Realistic – реалистично;
- Time related – с привязкой ко времени.
В рассматриваемом примере SMART-цель будет звучать так:
повысить среднюю LTV (Life Time Value) клиентов на 20% к 01.03.2024.
Таким образом, цель отвечает на вопрос: ЗАЧЕМ, для чего выполняется поиск решения?
Следующими узлами карты влияния являются Акторы (КТО?), на которых надо оказать влияния, чтобы достичь обозначенной цели. В нашем примере с магазином это Клиент (потребитель) и Менеджер по товарам.
Акторы могут помогать или, наоборот, препятствовать достижению цели. Поэтому следующий уровень – это определение влияний (КАК?), которые надо оказать на этих акторов. Определение влияний считается самым сложным этапом разработки Imapct Map. В нашем примере можно информировать клиента информировать о пользе и назначении товаров по его потребностям, чтобы повысить продажи. А менеджеру по продажам может адаптировать товарный ассортимент под потребности и возможности клиентов, чтобы увеличить средний чек и количество продаж.
Наконец, в последнюю очередь специфицируются объекты поставки: действия, задачи, компоненты системы, т.е. то, ЧТО поможет реализовать нужное влияние на конкретного актора для достижения поставленной цели. Например, чтобы менеджер по продажам мог адаптировать товарный ассортимент под потребности и возможности клиентов, ему необходимы инструменты и способы анализа данных о заказах, товарах, клиентах и поставщиках, а также возможности управления товарами и поставщиками.
Получается, в последних узлах карты влияния перечисляются будущие элементы бэклога — пользовательские требования к информационной системе, которые можно сформулировать в любой прижившейся в вашей команде форме: Use Case или User Story, что мы и посмотрим далее. А практическую реализацию этих требований в виде проекта, а затем в виде прогаммного кода смотрите в новой статье.
Справедливости ради стоит отметить, что далеко не все листья Impact Map напрямую будут реализованы с помощью ИТ. Некоторые объекты поставки представляют собой фактические действия, которые необходимо выполнить людям без всякой автоматизации. Это дает дополнительную ценность технике Impact Map, позволяя применять ее к поиску решений в более широком смысле, включая организационные аспекты, поскольку под решением в бизнес-анализе понимается не только ИТ-продукт. Например, наладить взаимодействие с новыми поставщиками товаров – это не только наладить интеграцию с их системами и реализовать функции CRUD-операций над этим объектами в своей ИС. Намного больше времени и сил уйдет на организацию коммуникаций с контрагентами, что до сих пор остается ответственностью людей и не может быть автоматизировано. Впрочем, этот вопрос уже больше лежит в плоскости проектного управления, а не бизнес-анализа.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
3 июня, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
Story по INVEST: формулирование и уточнение пользовательских историй
Таким образом, техника Impact Map – это быстрый и наглядный способ разработки концепции решения, который отлично подходит для Agile-проектов, где Заказчик является владельцем продукта (PO, Product Owner). Он понимает особенности и ограничения домена, а потому поможет аналитику четко сформулировать цель, определить причастных акторов и влияния, которые необходимо на них оказать. Затем аналитик сможет определить, каким образом реализовать эти влияния, специфицировав необходимые объекты поставки в виде пользовательских историй. Например, из разработанной карты можно выделить историю для менеджера по товарам, специфицировав ее в каноническом виде:
US 1. Я, как менеджер по товарам, хочу иметь наглядные аналитические отчеты с данными о заказах, товарах, поставщиках и клиентах, чтобы адаптировать товарный ассортимент магазина под потребности и возможности клиентов.
В представленном виде эту User Story еще нельзя отдать в реализацию, поскольку она недостаточно конкретна и понятна. Например, что значит иметь: смотреть дэшборд, формировать отчетный файл, получать по электронной почте раз в день или по запросу? Какие именно нужны данные, за какой период? Верифицировать пользовательскую историю, чтобы она прошла первичный контроль по форме представления и получила статус готовой к реализации (Definition of Ready), помогает набор критериев под аббревиатурой INVEST. Считается, что история должна быть:
- Independent – независима от других, т.е. атомарна и самостоятельна сама по себе, как всякое требование к решению;
- Negotiated – обсуждена с Заказчиком (PO);
- Valueable – имеет ценность для продукта/проекта, что напрямую следует из предыдущего пункта;
- Estimated – ее стоимость реализации может быть оценена в измеримых единицах (story points, человеко-часы), что достигается за счет детализации и точной формулировки;
- Small – достаточно маленькая, чтобы реализация уложилась в итерацию поставки, например, 2-х недельный спринт в Scrum;
- Testable – проверяема, т.е. имеет критерии приемки (Acceptance Criteria), по которым можно составить тест-кейсы и понять, что реализация требования соответствует изначальной постановке.
Если пользовательская история не соответствует этим критериям, например, она слишком большая или неконкретная, ее необходимо разделить. Для разделения историй используются определенные шаблоны (приемы) декомпозиции: по данным, операциям, интерфейсам, бизнес-правилам, шагам бизнес-процесса, влиянию на бизнес, сложности реализации. Например, эту историю можно разделить на набор более мелких историй:
US 1. Я, как менеджер по товарам, хочу иметь наглядные аналитические отчеты с данными о заказах, товарах, поставщиках и клиентах, чтобы адаптировать товарный ассортимент магазина под потребности и возможности клиентов.
- Я, как менеджер по товарам, хочу видеть агрегированные по товарам, клиентам или поставщикам данные в виде графических диаграм и гистограмм на наглядном дэшборде;
- Я, как менеджер по товарам, хочу сам задавать параметры агрегации данных по товарам, клиентам или поставщикам для визуализации на графических диаграмах и гистограммах дэшборда;
- Я, как менеджер по товарам, хочу задавать периоды отчетности и другие условия фильтрации данных по товарам, клиентам и поставщикам для их графической визуализации на дэшборде;
- Я, как менеджер по товарам, хочу иметь список типовых аналитических шаблонов, которые включают все параметры фильтрации и агрегации, нужные для конкретного аналитического кейса, например, показать поставщиков, товары которых ни разу не продавались, показать самые популярные товары и пр.
Разумеется, каждую историю можно сформулировать еще точнее и сопроводить критериями приемки в виде пошаговых сценариев или итогового чек-листа. Примеры таких артефактов я покажу в следующий раз, а пока отмечу, что история 1.4 получилась довольно громоздкой. Она слишком большая и требует уточнений по определению типовых аналитических задач, которые решает Менеджер по товарам. Работы по выяснению этих задач и спецификации необходимых для их решения данных называются спайками (spike). В продуктовых проектах подобных исследовательских задач бывает довольно много. Впрочем, в заказной разработке они тоже встречаются, поскольку редкий заказчик формулирует ТЗ четко и внятно, ведь разработка требований – это ответственность аналитика, независимо от применяемого подхода: Agile или строгий waterfall.
Возвращаясь к рассмотренным техникам, еще раз отмечу, что любое картирование предполагает взаимодействие с экспертом домена: PO или представитель Заказчика. Для диаграммы Исикавы и карты влияния это особенно характерно. Поэтому искренне рекомендую пользоваться этими простыми, но наглядными и эффективными приемами структурирования проблемы и поиска решений, обсуждая результаты своего мозгового штурма с коллегами-аналитиками и экспертами предметной области.
От процессов к продуктам: Product Ownership и Agile-практики для бизнес-аналитика
Код курса
POAP
Ближайшая дата курса
11 июля, 2024
Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.
Освоить все эти и другие техники и приемы практической работы аналитика вам помогут мои курсы в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
