Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?»

Если бизнес-анализ — это искусство превращать потребность заказчика в приносящее ценность решение, то его основа — не методологии и не инструменты, а 6 базовых понятий, заложенных в BABOK (Business Analysis Body of Knowledge):

Эти понятия — фундамент. Без их применения в работе бизнес‑аналитика не будет результата. К сожалению, многие аналитики работают «по памяти», по привычке, по шаблонам. Они собирают требования, разрабатывают процессы, согласовывают и передают их дальше в реализацию. Проект идёт, но решение не удовлетворяет потребностям, цели не достигаются, заказчик остается недовольным. В чем причина? Потеря связи с основой. Бизнес‑аналитик не проверил:

• Кому это по-настоящему нужно? – Заинтересованные стороны

• Что на самом деле нужно бизнесу? – Потребность

• Какие перемены произойдут в процессах, системах, работе? – Изменение

• Какие варианты реализации? – Решение

• Как новое решение повлияет на дальнейшую работу? – Контекст

• Какова реальная польза? – Ценность

Именно поэтому мы запускаем цикл статей — «Шесть основ бизнес-анализа». В данных статьях мы разберем каждое из 6 базовых понятий отдельно: дадим определение, разберем типовые ловушки, рабочие техники, примеры «из жизни» и то, как применять BABOK прагматично, а не «по учебнику».

Я — Станислав Харьков, руководитель управления бизнес-анализа компании «БКС Мир инвестиций», и на собственном опыте знаю, насколько критично не упустить ключевых участников на ранних этапах. Поэтому начнём с понятия, которое чаще всего «ломает» проекты ещё до формулирования требований: заинтересованные стороны (ЗСт) или стейкхолдер.

Почему первое базовое понятие именно «заинтересованные стороны»?

Каждая история начинается с «кто». Каждый проект начинается с «кто в игре?». Почему первым? Потому что все остальные понятия начинаются с него.

• Потребность — Кто её ощущает? Кто страдает от отсутствия решения?

• Ценность — Кто её получает? Кто оценит результат?

• Контекст — Кто сейчас влияет и, кто будет влиять на процесс?

• Решение — Кто будет его использовать?

• Изменение — На кого повлияют данные изменения? Кто может сопротивляться, а кто станет промоутером изменений?

Если вы не знаете, кто в игре, то вы не знаете, что делаете и для кого делаете. А если вы не знаете, что и для кого делаете, значит вы строите «воздушный замок». Ошибки здесь почти всегда выглядят как «мелочь» в начале и как «катастрофа» в конце.

Приведу реальный пример одного из проектов.

Бизнес‑заказчик инвестиционной компании предложил новую схему торговой сделки и поручил команде её разработать и внедрить. Требования были собраны, проанализированы, разработаны и протестированы. Инструкции для пользователей и рабочие документы — написаны. На всё ушло четыре спринта по две недели. Наступила долгожданная дата проведения демо и выхода в релиз. Но вместо успеха — шок: внутренний регулятор запретил запуск сделки из‑за выявленных критических регуляторных нарушений. Причина оказалась проста, но фатальна: бизнес‑аналитик не включил внутреннего регулятора в процесс согласования. Маленький упущенный этап, и вся работа оказалась напрасной. Тот, кто в начале проигнорировал эту «мелочь», в конце потерял восемь недель, усилия, а самое главное — доверие.

И этот пример не редкость. По данным Standish Group (CHAOS)* в 30% проваленных проектов основной причиной стала ошибка в идентификации заинтересованных сторон. Среди ключевых факторов провалов регулярно фигурируют неполные/неясные требования и недостаточная вовлеченность заинтересованных сторон, а обе причины часто упираются в то, что «не тех» людей спросили и «не тем» людям объяснили.

_{*Standish Group CHAOS Report — это авторитетное периодическое исследование (отчет), публикуемое исследовательской компанией The Standish Group с 1994 года раз в 2 года. Оно анализирует успешность IT-проектов, причины провалов и факторы эффективности разработки ПО. Отчет считается стандартом в оценке ИТ-рисков и успешности проектов.}

Кто такие «заинтересованные стороны»?

Согласно BABOK 3.0: «Заинтересованная сторона (часто используется сокращенное значение — ЗСт) — это физическое лицо или группа лиц, с которыми бизнес-аналитик, вероятно, будет взаимодействовать прямо или косвенно. Любая заинтересованная сторона может быть источником требований, допущений или ограничений».

Звучит просто? Да. Но в этом и кроется подвох. Потому что почти каждый по определению — потенциально заинтересованная сторона.

Ключевая мысль: заинтересованная сторона — это не «участник проекта по организационной структуре», а носитель интереса и/или влияния.

«Невидимые игроки»: кого чаще всего забывают

По моему опыту, бизнес-аналитики обычно называют заказчика, владельца продукта и ИТ команду. И чаще всего забывают:

1. Операционных пользователей (те, кто делает работу «руками»)

   Часто именно они знают реальные обходные пути, исключения и «как работает на самом деле».

2. Поддержку и обучение

   Эти команды будут «держать» решение после релиза.

3. Риск/комплаенс/безопасность/юристов

   Их позднее подключение превращает релиз в бесконечный цикл пересогласований и доработок.

4. Смежные подразделения и владельцев данных

   Особенно в интеграционных проектах: владелец справочника/данных может фактически решать судьбу функциональности.

5. Внешних участников

Партнёры, поставщики, регуляторы. Их требования часто появляются «не кстати», но, на самом деле, они были предсказуемы.

Четыре группы заинтересованных сторон

BABOK выделяет 11 ролей, которые участвуют в различных задачах бизнес-анализа в качестве источника требований, допущений, ограничений и другой информации:

1. Заказчик (клиент)

2. Спонсор

3. Бизнес-аналитик

4. Руководитель проекта

5. Разработчик

6. Тестировщик

7. Специалист предметной области

8. Конечный пользователь

9. Операционная поддержка (саппорт)

10. Регулятор

11. Поставщик

Для простоты выявления и взаимодействия с заинтересованными сторонами я разделяю их на 4 группы

Вот, что получится, если разложить 11 ролей из BABOK на данные 4 группы:

Работа с заинтересованными сторонами

Работа с заинтересованными сторонами — это не просто процесс выявления и включения в рабочую группу всех, кто «может быть важен». Это гораздо более тонкая и ответственная задача, т.к. одновременно с определением ключевых участников, нужно исключить тех, кто, несмотря на формальное влияние, может искажать направление проекта.

Некоторые участники могут прийти с собственными интересами, которые не совпадают с целями бизнеса или с реальной потребностью конечного пользователя. Их активное участие без контроля может отвлечь команду на второстепенные или даже деструктивные требования.

Поэтому эффективный бизнес-аналитик не просто «включает всех», а разделяет заинтересованные стороны по стратегии взаимодействия. Он не только определяет, кого вовлекать, но и устанавливает границы: кто должен принимать непосредственное участие в работе, кого только проинформировать, а кто должен быть исключён из процесса, чтобы избежать дезориентации, парадоксальных требований и смещения фокуса проекта.

В конечном счёте, правильная работа с заинтересованными сторонами — это не про охват, а про качество вовлечения. Иногда самое важное — не включить кого-то, а чётко понимать, что его участие может быть вредным.

На сегодняшний день существует множество способов работы с заинтересованными сторонами, но с моей точки зрения самые эффективные следующие два:

1. Матрица заинтересованности

2. Матрица RACI

Матрица заинтересованности (Stakeholder Engagement Matrix) из BABOK — инструмент, который помогает видеть, кто на самом деле важен.

Быстрый способ расставить приоритеты:

• Высокое влияние + высокий интерес: ключевые — управлять ожиданиями, вовлекать регулярно

• Высокое влияние + низкий интерес: держать удовлетворёнными, подключать точечно

• Низкое влияние + высокий интерес: информировать, собирать обратную связь

• Низкое влияние + низкий интерес: мониторить

Важно: матрица — не про «важность человека», а про стратегию работы с ним.

Матрица RACI – инструмент, распределяющий роли и обязанности между заинтересованными сторонами.

RACI:

• R — Responsible: делает работу (исполнитель)

• A — Accountable: несёт конечную ответственность и принимает результат

• C — Consulted: даёт консультации/экспертизу (двусторонняя коммуникация)

• I — Informed: должен быть в курсе (односторонняя коммуникация)

Практическое правило: на одну активность лучше иметь одного A, иначе ответственность размывается.

Пример RACI для проекта внедрения ИТ системы (упрощённо)

Активности:

• Сбор и уточнение требований

• Приоритизация и согласование (scope)

• Проектирование

• Разработка и интеграция (DEV)

• UAT (приёмочное тестирование)

• Запуск и обучение

• Поддержка после релиза

Что данная матрица даёт бизнес-аналитику:

• видно, кто должен дать старт и, кто принимает итог (A);

• снижается риск «поздних сюрпризов» от инфобеза/комплаенса;

• поддержка и обучение становятся не «потом как‑нибудь», а частью поставки.

Мини-чеклист: «Не пропустил ли я заинтересованную сторону?»

• Я знаю, кто получит ценность и кто понесёт издержки от изменения?

• Есть ли «скрытые пользователи» (те, кто реально работает, но не ходит на встречи)?

• Есть ли «лишние участники»?

• Подключены ли владельцы данных и интеграций?

• Задействованы ли у нас роли комплаенс/инфобеза/юристов с понятным форматом участия?

• Включены ли поддержка и обучение в план запуска?

Опыт «БКС Мир инвестиций»

Мы в компании «БКС Мир инвестиций» разработали и поддерживаем матрицу коммуникаций — это матрица, в которой отражаются подразделения и заинтересованные стороны для выявления/обсуждения/согласования требований и ограничений при разработке, описании и автоматизации бизнес‑процессов.

Для чего служит: Целью матрицы является формализация и упрощение взаимодействия между всеми участниками процесса/проекта. В ней отражены:

• границы ответственности подразделения (за что отвечает);

• руководители и ключевые контакты;

• способы коммуникации и согласования (письменно/устно/служебная записка/корпоративная электронная почта/иное);

• системы, сервисы и программное обеспечение, за работу которого отвечает подразделение или в котором исполняет свои трудовые обязанности.

Создание матрицы коммуникаций — это инвестиция в понятность и устойчивость системы. Вначале это кажется затратным, но уже через пару недель использования вы поймёте, что избавились от 80% неопределённости в коммуникациях. Потраченное время окупается в разы: сокращаются конфликты, ускоряется принятие решений, упрощается взаимодействие.

Итог: Заинтересованные стороны — первое базовое понятие не потому, что оно «первое в BABOK», а потому что оно первое в причинно‑следственной цепочке:

нет правильных заинтересованных сторон → нет правильной потребности → нет правильных требований → нет ценности → решение не соответствует.

Матрица коммуникаций в этой логике — мост от «мы всех знаем» к «мы договорились, кто что делает и кто принимает решения».

Что дальше в цикле

Следующая статья будет про Need (Потребность): как отличать реальную бизнес-нужду от «хотелки», как задавать вопросы, как проверять измеримость и ценность. Подпишитесь на наш блог, чтобы не пропустить.