Модуль 6. BI/DWH для аналитика требований
Картина целиком: из чего состоит аналитический контур
Цепочка ценности: Источники → Интеграция (ETL/ELT/CDC/стрим) → DWH (RAW/CORE/MARTS) → Семантический слой → BI/дашборды → Принятие решений → Эффект.
Задача BA: зафиксировать что и зачем нужно бизнесу; какие данные и с какой свежестью; как проверяем корректность и производительность; как принимаем результат (UAT/acceptance).
Витрины данных (Data Marts): назначение и устройство
Назначение: предоставить «готовые к ответу» представления под конкретные решения (финансы, продажи, операции).
Типовые формы витрин:
- Факты (транзакции, снапшоты): fact_sales, fact_inventory_snapshot, fact_margin.
- Измерения (справочники с историей): dim_product (SCD), dim_store, dim_customer.
- Агрегаты/своды (ускорители): agg_sales_week_sku, agg_margin_month_channel.
Ключевые решения BA по витрине:
- Гранулярность (SKU×канал×день? заказ-строка? чек?).
- Временная модель: события vs снимки (для остатков/активных пользователей).
- Историчность: SCD1/2/4 (перезапись vs версионирование).
- Ключи/стыковка: стабильные идентификаторы, валюта, TZ.
- DQ и допуски: правила полноты/валидности/согласованности.
- SLA/latency: когда данные считаются «готовы к решениям».
Семантический слой: единый смысл метрик
Что это: слой, где живут определения метрик, иерархий, ролей и правил фильтрации. Может находиться в BI-инструменте, в «headless»-слое или в базе (представления/функции).
Зачем BA: остановить «ползучее разночтение» показателей.
Состав семантики:
- Measures (меры): GM, GM%, Revenue, ARPU, OOS rate — с формулами, единицами, форматами.
- Dimensions (измерения): иерархии (Год→Квартал→Месяц→День; Категория→SKU).
- Правила фильтров: исключения (возвраты, трансферы), дефолтные периоды (последние 12 мес).
- RLS/области видимости: «Региональный менеджер видит только Region=X».
- Версионирование методологии: «Методика GM% v1.3 от 2025-05-15».
Решение «где считать метрики»:
- В DWH (SQL/материализованные витрины): + скорость, + единый смысл; − гибкость ад-hoc.
-
В BI (слой мер/калькуляций): + гибкость; − риск расхождений и нагрузки.
Оптимально: базовая логика и согласованные KPI в DWH, слабосвязанные витрины/эксплор — в BI.
Источники и обновления: режимы, latency, SLA
Режимы:
-
Batch (час/день), micro-batch (15–60 мин), stream (Kafka/CDC), CDC-инкремент (логические журналы).
Выбор зависит от решений: для GM/закрытия — D-1 к 10:00; для мониторинга OOS — 15–60 мин; для кассового фрода — минуты.
Latency-бюджет (пример):
- Продажи/маржинальность: готово к 10:00 по D-1; 4 обновления/сутки.
- Запасы/OOS: каждые 30–60 мин, но «грубая» точность допустима в off-peak.
- Маркетинг/промо: по событиям, но не позднее D+1 09:30.
SLA формулируется BA в SRS/NFR:
- Свежесть: «Данные доступны к 10:00 D-1; KPI Freshness ≥ 98%».
- Отклик: «Страницы открываются ≤ 5 сек на 95-м перцентиле при 12 мес истории».
- Доступность: «BI сервис ≥ 99,5% в раб. время; окно обслуживания — вс. 01:00–03:00».
- Реакция на срыв: баннер «черновик», блок экспорта, алерт владельцам.
Типовые дашборды и решения, ради которых их делают
Финансы
Цели: видеть GM/GM%, P&L, кэш-позицию, план-факт, отклонения.
KPI: Revenue, COGS, Logistics, GM%, OPEX, EBITDA, DSO/DPO.
Решения: корректировки ассортимента/промо, контроль затрат, закрытие месяца.
Особенности: мультивалюта, НДС, поздние возвраты, консолидация юрлиц.
Продажи/коммерция
Цели: рост выручки и маржи, эффективность промо, LFL, каналы.
KPI: LFL YoY, GM% по SKU/каналам, промо-uplift, KVI, конверсия воронки.
Решения: ассортиментные/ценовые изменения, промо-календарь.
Особенности: признак промо, эластичности, сегменты клиентов.
Операции/запасы/логистика
Цели: снижение OOS и излишков, SLA поставок, оборачиваемость.
KPI: OOS rate, Service level, Days of Inventory, Lead time, OTIF.
Решения: перераспределение запасов, корректировки заказов, транспортные окна.
Особенности: снапшоты остатков, временные лаги, масса/объем, партии.
Исполнительная панель (Exec)
Цели: стратегические тренды и риски.
KPI: «пучок» из 8–12 ключевых показателей + алерты.
Решения: фокус инициатив, бюджетные корректировки.
Особенности: стабильный storytelling, минимум интерактива, максимум ясности.
Роль BA в приемке (acceptance) дашбордов
BA отвечает за:
- Смысл и корректность метрик (сверка с эталоном, допуски).
- Покрытие сценариев (use cases, негативные ветки: «неполные данные», «нет доступа»).
- NFR (время отклика, стабильность фильтров, RLS).
- UX-критерии (читабельность, сортировки, подсказки, недопущение двусмысленности).
- Обучение и «паспорт дашборда» (назначение, владельцы, версия методологии, связь с решениями).
Acceptance-чек-лист (фрагмент):
- Метрики сходятся с эталоном (GM% ±0,2 п.п. по 10 SKU).
- Фильтры работают совместно (регион×канал×дата), пустых таблиц нет.
- RLS: пользователь «Регион X» не видит «Регион Y».
- Отклик ≤ 5 сек при 12 мес истории (95-й перцентиль).
- При нарушении DQ-порога: баннер «черновик», блок экспорта, алерт.
- Паспорт дашборда заполнен; в шапке — версия методологии и дата свежести.
Практика для BA: «Бриф на дашборд»
Цель и решения:
-
«Сократить цикл закрытия GM% 3→1 день; в 10:00 D-1 принимать решения по промо/ассортименту».
2. Аудитория: финконтролеры, категорийные менеджеры, директор по коммерции.
3. KPI: GM, GM%, Revenue, промо-uplift, LFL.
4. Гранулярность: SKU×канал×неделя; детализация до дня.
5. Источники/латентность: ERP продажи D-1; логистика D+2 (fallback-режим).
6. DQ-правила: полнота продаж ≥ 99,5%; логистика ≥ 98% к 09:30.
7. NFR: отклик ≤ 5 сек; экспорт только при DQ-ОК; RLS по региону.
8. Макет (wireframe): - верх — KPI-плашки (GM%, Revenue, GM),
- центр — «тепловая карта» канал×категория,
- низ — таблица SKU из топ-отклонений,
-
бок — фильтры (дата, канал, регион, промо).
9. Приемка: 10 сценариев Given/When/Then, список эталонных сверок.
10. Паспорт дашборда: владелец, методология vX.Y, дата/время свежести, ссылка на словарь метрик.
Критерии качества визуализаций (гайд для приемки)
- Титул и аннотация объясняют вопрос и единицы измерения.
- Ось и шкалы подписаны; для столбиков — нулевая линия; для процентных — 0–100%.
- Сортировка по смыслу (по величине/по времени), а не «как попало».
- Легенда читаема, не перекрывает данные.
- Единицы/форматы: %, ₽/€, шт., дни — единообразно; разрядность/знаки после запятой оправданы.
- Цвет по назначению: акцент/сигналы (не «радуга»). Цветовая слепота — учтена.
- Никаких dual-axis злоупотреблений; если два масштаба — явное обоснование.
- Выбросы не «съедают» тренд — используйте лог-шкалу/подсказки.
- Подсказки (tooltips) информативны: формула, дата, источник, DQ-статус.
- Навигация: фильтры логичны, drill-down возвращаем; «сброс фильтров» виден.
- Таблицы: условное форматирование, заморозка заголовков, постраничность осмысленна.
- Недопустимые состояния: пустые ответы объясняются («данные не загружены»).
- Адаптация под экран/печать: ключ — в первый экран; печатная версия без интерактива.
- Методология в шапке (версия/дата изменений).
- Performance-budget выдержан: <5 сек первая отрисовка, <2 сек фильтры (95-й перцентиль).
Теория «ровно сколько нужно» для рамок и ограничений
- Star vs Snowflake: звезда — проще и быстрее для BI; снежинка — экономит дубликаты, но усложняет запросы.
- Факт-таблицы: транзакции (grain = событие) vs снапшоты (grain = состояние на момент времени).
- SCD типы: 1 — перезапись; 2 — история в строках с периодами; 4 — история отдельно.
- Event time vs Processing time: отчёты по времени события; задержку загрузки показываем отдельным индикатором.
- Кэширование BI и экстракты: ускоряют чтение; риск устаревания; BA указывает freshness-индикаторы.
- Федерация запросов vs ETL: федерация быстра в пилоте, но нестабильна по SLA; «боевые» KPI — в витринах.
- Мультивалюта и НДС: фиксируйте политику конвертации (курс на дату события/закрытия) и «с НДС/без НДС».
Риски и как их снимать
|
Риск |
Симптом |
Меры BA |
|---|---|---|
|
Метрики расходятся между отделами |
«GM% другой» |
Единый словарь, владельцы показателей, версия методологии в шапке |
|
Срыв SLA/latency |
«К 10:00 данных нет» |
Fallback-режим (черновик, запрет экспорта), алерты, post-mortem, пересмотр источника |
|
Падение производительности |
>10 сек загрузка |
Агрегаты, предфильтры, ограничение горизонта по умолчанию, индексы/партиции (совместно с ИТ) |
|
Промо-флаг недостоверен |
Нельзя разделить promo/non-promo |
Временный прокси-признак + маркировка точности, план донасыщения |
|
RLS ломает суммы |
Пользователи видят разные итоги |
Тест-сценарии на роли, агрегаты с учётом RLS |
|
Excel-зомби |
«Выгружают и считают сами» |
Эквивалент функций в BI, удобные выгрузки, обучение, фаза поддержки |
|
Методология меняется без следа |
«Почему тренд сломался?» |
Версионирование, баннер «изменена методика», release notes |
|
Договоры по данным нестабильны |
«Поля пропали/переименованы» |
Data Contracts с источниками, мониторинг схемы, строгая эскалация |
Вопрос–ответ (FAQ)
Q: Где лучше считать GM% — в базе или в BI?
A: Базовая формула и фильтры — в витрине (SQL) для единообразия; лёгкие «сценарные» расчёты — в BI. Так вы удержите смысл и скорость.
Q: Что делать, если логистика приходит D+2, а отчёт нужен D-1 к 10:00?
A: Ввести «черновой» режим без логистики с пометкой, блоком экспорта и виджетом DQ; при поступлении логистики — пересчёт и снятие баннера.
Q: Как обосновать, что дашборд «успешен»?
A: Метрики принятия (MAU/ретеншн), скорость решений (цикл закрытия), финансовый эффект (экономия FTE, +GM). Это фиксируется в value case.
Q: Когда делать агрегаты?
A: Если 95-й перцентиль >5 сек при «боевом» горизонте/фильтрах, а оптимизация запросов исчерпана — вводим агрегаты (неделя/месяц, топ-N, pre-join измерений).
Q: Как жить с мультивалютой и НДС?
A: В словаре метрик фиксируем «Gross/Net», дату курса, базовую валюту, метод пересчёта. Дашборд — с явным переключателем валюты и подсказками.
Q: Что делать, если бизнес просит realtime «потому что красиво»?
A: Пройти 5 Why до решения («какой риск/решение не успеваем?»). Часто хватает часовых обновлений. Realtime дорог и шумен.
Практика (что сдать по итогу модуля)
A. Бриф на дашборд (1–2 стр.)
Цель/решения, аудитория, KPI, гранулярность, источники и latency, DQ-правила и пороги, NFR, макет (скетч), сценарии приемки (минимум 10), паспорт дашборда.
B. Мини-SRS для витрины (3–5 стр.)
Формулы KPI, STT на ключевые поля, SCD/снапшоты, SLA и реакции, DQ-правила, RLS-модель.
C. Чек-лист качества визуализаций (ваша адаптация, 15–20 пунктов)
Приложить к UAT.
D. План теста производительности
Набор «тяжелых» выборок, перцентильные целевые значения, критерии «прошёл/не прошёл».
Чек-листы готовности
Витрина готова:
- Гранулярность, ключи, SCD/снапшоты определены
- Формулы KPI и источники утверждены
- SLA и реакции (fallback/баннер/алерт) описаны
- DQ-правила и пороги A/B заданы
- RLS/маскирование согласованы
Дашборд готов к UAT:
- Макет соответствует брифу; UX-критерии пройдены
- Эталонные сверки по 10–20 «маякам»
- Отклик ≤ 5 сек (95-й перцентиль)
- Паспорт дашборда заполнен (владелец/версия/свежесть)
- Release notes и сценарий обучения готовы
Вы задаёте рамки и ограничения: какие витрины и с какой гранулярностью нужны, где живут официальные метрики, каким должен быть SLA/latency, как выглядит приемка дашборда, и какие DQ-реакции включаются при сбоях. Это резко снижает споры на UAT, поднимает производительность и «приземляет» BI к реальным решениям бизнеса. Если нужно, соберу для вашего кейса готовые брифы на 2–3 дашборда (финансы/продажи/операции) и мини-SRS к соответствующим витринам.
