Модуль 1. Роль бизнес-аналитика и жизненный цикл решений

Зачем нужен BA и где границы ответственности

Коротко: BA превращает «хотелки» в реализуемое решение, которое приносит измеримую ценность.
BA НЕ является владельцем продукта (решает что важно), разработчиком (создает как), проектным менеджером (управляет сроками и ресурсами) или тестировщиком (ищет дефекты). Но BA связует всех, чтобы бизнес-ценность случилась.

Зона ответственности BA:

Понять проблему и контекст (зачем).
Согласовать целевые результаты и метрики успеха (что будет считаться эффектом).
Сформулировать и структурировать требования (что именно делаем).
Обеспечить трассируемость «цель → требование → реализация → метрика».
Поддержать команду на delivery и adoption, чтобы эффект проявился.

Границы с соседними ролями (часто путают):

Product Owner/Заказчик: приоритизирует ценность, принимает ключевые решения. BA готовит основу для решений и фиксирует договорённости.
PM: следит за сроками/рисками проекта. BA поставляет вход (оценки, объем, зависимости) и освещает риск требований.
Системный аналитик/Архитектор: прорабатывает интеграции/модели данных/ограничения платформ. BA формулирует бизнес-смысл и критерии.
BI/DWH разработчики, Data Engineers: реализуют; BA уточняет требования, согласует компромиссы.
QA: BA формирует приемочные критерии и UAT-сценарии; QA — тест-дизайн и исполнение.
Data Steward/Owner: владелец данных, описывает источники, правила качества; BA обеспечивает включение этих правил в требования.

Жизненный цикл: discovery → delivery → adoption

Discovery: от «боли» к проверяемым целям

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

Картирование стейкхолдеров, интервью, воркшопы.
Формулировка Problem Statement (одним абзацем, конкретика + последствия).
Определение SMART-целей и целевых метрик (lead/lag).
Предварительный value case: гипотезы эффекта, кому и как станет лучше.
Высокоуровневый scope: что точно «внутри/вне», риски и допущения.
Черновик RACI для ключевых шагов.
Черновой бэклог (эпики/крупные задачи) и MVP.

Выходные артефакты discovery: Problem Statement, карта стейкхолдеров, матрица влияния/интереса, SMART-цели + метрики, value case, scope & допущения, черновик RACI, бэклог эпиков, план следующего этапа.

Пример (ритейл/финансы):
Проблема — «У CFO нет единого достоверного отчета о маржинальности по сегментам и каналам; на сверки уходит 2–3 дня ежемесячно; решения по ассортименту и промо запаздывают».
Цели — «Сократить цикл закрытия по марже с 3 до 1 дня к Q4; повысить точность маржи на 1 п.п.; дать категориям дашборд по каналам/SKU с обновлением раз в 4 часа».

Delivery: от требований к работающей системе

Цель: преобразовать цели в реализуемые требования и артефакты, поддерживать команду при разработке.
Ключевые активности BA:

Детализация требований: бизнес/функц./нефункц./ограничения.
Словарь метрик и правила расчета KPI (формулы, источник, фильтры).
Source-to-Target (совместно с системным аналитиком/инженером данных): откуда берем поля, как трансформируем, как считаем агрегаты.
NFR: частота обновления, SLA, доступность, безопасность, аудит, хранение историчности, производительность запросов.
Acceptance Criteria и UAT-план: как поймем, что «готово».
Поддержка при компромиссах: «или точнее, или быстрее» — выбор с заказчиком.

Выходные артефакты delivery: SRS/спецификация требований, словарь данных/метрик, STT-мэппинги, NFR, прототипы/макеты дашбордов, критерии приемки, план UAT, матрица трассируемости.

Пример (дашборд маржинальности):
Требование: «Показывать GM% по каналу/категории/SKU за период с фильтрами регионы, промо/непромо; формула GM% = (Выручка – Себестоимость – Логистика) / Выручка; исключать возвраты, если дата возврата вне периода — отражать корректировкой текущего».
NFR: «Обновление витрины — каждые 4 часа; дашборд должен открываться < 5 сек на выборке до 12 мес; аудит изменений формул — версионирование в Confluence + в BI».

Adoption: чтобы «взлетело» и приносило эффект

Цель: обеспечить использование, измеримый эффект и устойчивость решения.
Ключевые активности BA:

План коммуникаций: кому и что показываем, демо, рассылки.
Обучение: гайды, видео, «первые шаги», FAQ.
Мониторинг: цели → фактические метрики (принятие, активные пользователи, сниженный цикл, финансовый эффект).
Сбор обратной связи, управление улучшениями (release notes, backlog).
Оценка value case vs. факта, корректировка.

Выходные артефакты adoption: руководство пользователя, сценарии обучения, чек-лист внедрения, дашборд пост-метрик, отчёт по эффекту (value realization), backlog улучшений.

Stakeholders & RACI: как договориться «кто за что»

Картирование стейкхолдеров

Категории: спонсор (CFO/коммерческий директор), владельцы процессов (продажи, маркетинг, логистика), ИТ (архитектор, инженеры, BI), безопасность/юридический, Data Owners/Stewards, ключевые пользователи, внешние вендоры.
Матрица влияние/интерес:
- Высокое влияние + высокий интерес — вовлекать глубоко, включать в решения.
- Высокое влияние + низкий интерес — обеспечивать регулярные апдейты «по делу».
- Низкое влияние + высокий интерес — давать прозрачность и каналы обратной связи.
- Низкое влияние + низкий интерес — информировать по вехам.

RACI (пример для дашборда маржинальности)

Define KPI и формулы: R – BA, A – CFO, C – Data Steward/BI Lead, I – PM.
Источники и STT: R – Системный аналитик/Data Engineer, A – Архитектор, C – BA/BI Dev, I – Безопасность.
Дизайн визуализаций: R – BI Dev, A – Product Owner (финконтролер), C – BA/маркетинг, I – IT Ops.
UAT и приемка: R – BA, A – CFO/PO, C – Key Users, I – PM/QA.
Роллаут и обучение: R – BA, A – PO, C – HR/Comms, I – Все.

Артефакты BA: минимум бюрократии, максимум пользы

Problem Statement: что болит, для кого, чем грозит (1 абзац).
Цели и метрики (SMART + OKR-логика): и lag (итоговые — GM%, цикл закрытия), и lead (ранние — % покрытых SKU, доля пользователей с привычным поведением).
Value Case vs Business Case:
- Value case — что именно улучшится, как мы это измерим, какие поведенческие/процессные изменения ждём.
- Business case — финмодель (TCO, OPEX/CAPEX, ROI, NPV, окупаемость, сценарный анализ).
Backlog + приоритизация (MoSCoW/WSJF): что войдёт в MVP.
Словарь метрик и данных: поле → описание → источник → правила расчёта → фильтры/исключения → владелец.
NFR: частоты обновлений, RTO/RPO, аудит/логирование, доступы, производительность.
Acceptance Criteria и UAT-сценарии: набор проверок «по метрикам и по поведению».
Матрица трассируемости: цель → требование → реализация → тест → метрика.

Метрики успеха: продуктовые и проектные

Продуктовые (ценность):

Сокращение времени цикла (напр., закрытие маржи 3→1 день).
Рост точности KPI (ошибка маржи ≤ 1 п.п.).
Принятие пользователями (MAU, DAU, глубина использования).
Бизнес-эффект (доп. маржа, экономия FTE/часов, снижение OOS и пр.).

Проектные (здоровье поставки):

Доля требований с четкими критериями приемки.
Дефекты UAT по критичным кейсам.
Своевременность согласований.
Процент реализованных «Must» в релизе.

Практика (выполняем шаг за шагом)

A. Карта стейкхолдеров (30–60 мин)

Список ролей/ФИО, ожидания, опасения.
Матрица влияние×интерес.
План вовлечения по группам.
Выход: таблица + схема; договоренность «кого/когда/зачем».

B. Problem Statement (15–30 мин)

Шаблон:
«У [кто] есть [проблема], которая приводит к [последствия/стоимость].
Мы предлагаем [решение/подход], чтобы [измеримое изменение] к [дата].»

Пример:
«У финансовой службы нет единого достоверного отчета по маржинальности, из-за чего цикл закрытия занимает 3 дня и решения по промо запаздывают. Создадим витрину и дашборд с обновлением 4 часа, чтобы сократить цикл до 1 дня и повысить точность на 1 п.п. к 31.12.»

C. SMART-цели (20–30 мин)

S: «Сократить цикл закрытия маржи».
M: «с 3 до 1 дня; точность ±1 п.п.»
A: договорённости по ресурсам/данным.
R: корректная маржа влияет на решения по ассортименту/промо.
T: «до 31.12».
Выход: список целей с метриками lead/lag и владельцами.

Риски и как их предотвратить

Риск	Признаки	Как снизить
Нет единого смысла метрик	«Маржа» считается по-разному в отделах	Ранний словарь метрик, утверждение формул спонсором, версионирование
Скрытые ограничения данных	Нет полей/истории/признака промо	Discovery-профилирование источников, STT с владельцами, план донасыщения
Scope creep	Постоянно «ещё чуть-чуть»	Жесткий scope/MVP, MoSCoW, Change Log с оценкой влияния
NFR забыты	«В отчёте всё есть, но открывается 20 сек»	Ранние NFR, нагрузочные цели, совместные перф-тесты
Отсутствие вовлечения пользователей	Низкое MAU, обходные Excel	Комм-план, демо, ранние прототипы, обучение, поддержка 1–2 релиза
Безопасность/согласования	Блокировки перед релизом	Ранний Security Review, DPIA (если PII), согласование доступов
Нет измерения эффекта	«Сделали красиво, пользы не доказали»	Value case с метриками, пост-дашборд по эффектам, квартальный обзор

Теория — что важно знать BA «про данные» (для BI/DWH)

Стабильные идентификаторы и историчность (SCD): как «правда менялась во времени».
Гранулярность витрины: на каком уровне считаются KPI (SKU-день? чек? канал-месяц?).
Фильтры/исключения: возвраты, пересчеты, промо-периоды, «продажи в минус».
Линейка времени: локальное/фискальное закрытие, лаги данных по системам-источникам.
DQ-правила: полнота, уникальность, допустимые значения, кросс-проверки.
Латентность и SLA: «данные доступны к 10:00 мск, 4 раза в сутки».
Аудит: кто менял формулы, когда и почему; кто имеет доступ к каким уровням.

Вопрос–ответ (FAQ)

Q: Зачем делить на discovery/delivery/adoption, нельзя просто «сделать отчёт»?
A: Без discovery вы не зафиксируете смысл метрик и цели. Без adoption отчёт не будет использоваться и эффекта не будет. Разделение экономит месяцы переделок.

Q: Кто утверждает формулы метрик?
A: Владелец показателя со стороны бизнеса (обычно финконтролер/методолог). BA готовит формулировки и варианты, спонсор (CFO/PO) утверждает.

Q: Как поступать, если данных для цели нет?
A: Фиксируем gap в STT, считаем вариант B (приближение/прокси), оцениваем стоимость донасыщения и принимаем решение на Steering Committee.

Q: BA должен уметь SQL?
A: Базовые SELECT/агрегации нужны. Это ускоряет валидацию метрик и общение с инженерами. Глубокие оптимизации — зона инженера/BI-разработчика.

Q: Как избежать «Excel-теней» после релиза?
A: Дайте эквивалентные сценарии в BI, покажите выгоды (скорость, согласованность), обучите и закройте «дырки», из-за которых Excel удобнее.

Q: Как фиксировать договоренности, чтобы их не «перепридумывали»?
A: Confluence-страницы: «Словарь метрик», «Источники и STT», «Решения и допущения» с датой, владельцем и версией. Все изменения — Pull Request в методологии.

Чек-листы

Discovery-готовность:

Проблема сформулирована, последствия измеримы.
Карта стейкхолдеров и план вовлечения.
SMART-цели и метрики (lead/lag).
Черновой scope (in/out), допущения, риски.
Черновой бэклог и MVP.
Черновой RACI.

Delivery-готовность:

Подтвержденный словарь метрик и формулы.
STT с владельцами данных.
NFR согласованы.
Прототипы/макеты просмотрены с ключевыми пользователями.
Acceptance Criteria и UAT-план.
Матрица трассируемости заведена.

Adoption-готовность:

Руководство пользователя и краткая «шпаргалка».
План обучения + демо-сессии.
Пост-метрики и дашборд эффекта.
Каналы обратной связи и SLA поддержки.

Мини-шаблоны (скопируйте в Confluence/Notion)

Problem Statement (1 абзац):
Кому больно → Что именно болит → Чем это измеримо плохо → Что изменим и к когда → Как поймём, что удалось.

Acceptance Criteria (пример):

Формула GM% соответствует словарю, расхождение тестовой выборки с эталоном ≤ 0.2 п.п.
Время отклика страниц ≤ 5 сек на выборке 12 мес.
Фильтры регион/канал/категория работают совместно, пустых таблиц нет.
Референсный кейс «SKU-123 в регионе X за Q2» совпадает с учетными ведомостями.

Финальный ориентир по модулю

Что вынести: BA — про ценность и точность смысла, а не про «нарисовать график». Три этапа (discovery/delivery/adoption) и набор артефактов — ваш каркас.
Что сделать уже сейчас: составьте карту стейкхолдеров, напишите Problem Statement и SMART-цели, заведите словарь метрик с 1–2 ключевых KPI и согласуйте владельцев.

← Предыдущая статья

Обзор новых книг от O’Reilly: что почитать дата-инженерам, аналитикам и архитекторам

Следующая статья →

Модуль 2. Сбор требований: интервью, воркшопы, фасилитация