BI-система: откуда берётся цифра в отчёте и что придётся построить

Термин размыт до предела, поэтому полезно разложить его на четыре разные вещи.

Платформа визуализации — то, что обычно и называют BI: конструктор дашбордов, срезы, фильтры, доступы.

Слой данных — источники, загрузка, хранилище, витрины. Невидимая и самая дорогая часть.

Модель показателей — словарь метрик: что такое выручка, когда считается заказ, как учитывать возвраты и внутренние перемещения.

Процесс работы с данными — кто отвечает за отчёт, как часто пересматриваются метрики, что делают, когда цифра разошлась.

Проект «внедрим BI» обычно означает первый пункт, а результат зависит от трёх остальных.

Путь от операции до графика на экране проходит через несколько слоёв, и у каждого своя роль.

Хранилище — место, где данные лежат в исторической форме и не меняются задним числом. Витрина — подготовленный срез под задачу: продажи по дням и точкам, воронка заявок, движение товара.

Разделение даёт три вещи. Скорость: витрина считается заранее, отчёт открывается мгновенно. Повторяемость: цифра за прошлый месяц не меняется от того, что кто-то поправил документ. Независимость: продукт можно менять, не ломая отчётность.

Технически для среднего бизнеса это обычно колоночная база под аналитику плюс регулярные задания загрузки. Заводить тяжёлую платформу с полноценным озером данных ради десятка отчётов не нужно — стоимость сопровождения быстро превысит пользу.

Отдельный вопрос — глубина истории. Часто хватает двух-трёх лет в быстром доступе и архива для остального: аналитика за пределами этого горизонта нужна редко, а хранение стоит денег.

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

Место, где чаще всего рождаются «разные цифры». Выручка бывает по отгрузке и по оплате, с НДС и без, с возвратами и без, с внутренними перемещениями и без них. Каждая версия по-своему правильная.

Лечится словарём показателей: название, формула словами, источник, период, владелец. Документ на несколько страниц, который согласуют финансы, коммерция и ИТ. Дальше все отчёты считают метрику одним способом, а если кому-то нужен другой разрез — он получает новое имя, а не альтернативную выручку.

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

Второй элемент словаря — правила пересчёта. Метрики со временем меняются: добавился новый канал продаж, изменился порядок учёта возвратов. Нужно заранее договориться, пересчитывается ли история под новое определение или новая версия метрики начинает жить с конкретной даты. Оба варианта рабочие, невыносим только третий — когда никто не помнит, что и когда поменялось.

Отчёт не бывает лучше, чем данные под ним. Четыре проблемы повторяются в каждом проекте.

Дубли справочников. Один контрагент под тремя названиями — продажи разъезжаются на три строки. Это задача управления мастер-данными, и решать её приходится до отчётности, а не после.

Поздние документы. Документ провели задним числом — цифра за закрытый период поменялась. Нужны правила: до какого момента период открыт, как показывать пересчёт.

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

Разные единицы и валюты. Килограммы против штук, курс на дату операции против курса на дату отчёта. Мелочь, которая ломает сравнение периодов.

Два разных мира, и путать их дорого.

Оперативная отчётность нужна сегодня: продажи за час, остатки, заявки в работе, скорость сборки. Требование — свежесть; допустима погрешность и неполные данные.

Регламентная отчётность нужна точной: итоги месяца, отчёты для собственника и внешних сторон. Требование — сходимость с учётом до копейки; задержка в сутки приемлема.

Технически это разные конвейеры: первый работает почти в реальном времени и часто прямо в продукте, второй — по расписанию, после закрытия периода, со сверками. Попытка сделать один универсальный отчёт обычно заканчивается тем, что он не годится ни для оперативной работы, ни для отчётности.

Отдельный сценарий, о котором обзоры BI-платформ обычно не пишут: отчёты нужны не вашим сотрудникам, а вашим клиентам — в личном кабинете или в приложении.

Примеры: кабинет поставщика с продажами и остатками по его товарам, панель арендатора с расходами, статистика использования сервиса для B2B-клиента, отчёты для партнёров сети. Требования здесь другие: данные каждого клиента строго изолированы, отчёт открывается за доли секунды, оформление — часть продукта, а не чужой инструмент внутри вашего интерфейса.

Такое почти никогда не делается встраиванием корпоративной BI-платформы: лицензии считаются по пользователям, а пользователей — тысячи. Вместо этого строится витрина под сценарий и собственные экраны отчётов. Если продукт при этом собирает и поведенческие данные, они объединяются в одном контуре с продуктовыми метриками — про их сбор есть отдельный материал про продуктовую аналитику.

После ухода западных вендоров рынок перестроился: компании мигрировали с привычных платформ на отечественные, а требования реестра российского ПО закрыли вопрос для госсектора и значимых объектов инфраструктуры.

Сегодня в проектах встречаются Visiology, «Полиматика», Modus BI, Luxms BI, «Форсайт», Yandex DataLens, из открытых решений — Apache Superset. Функционально базовые сценарии закрыты у всех: подключение источников, модель данных, дашборды, доступы.

Что стоит проверять при выборе: как платформа работает на ваших объёмах и на вашем типе хранилища, есть ли нужные способы подключения к источникам, как устроены права доступа (особенно построчные ограничения), можно ли встроить отчёт во внешний продукт и что входит в лицензию при росте числа пользователей.

Миграция — отдельный проект. Переносятся не дашборды, а логика: расчёты, права, регламент обновления. Практика показывает, что половина старых отчётов при переносе просто не нужна — их никто не открывал год.

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

Без этого самообслуживание превращается в новую версию Excel-хаоса: десять сотрудников строят десять отчётов по одной теме с разными фильтрами и получают десять разных чисел. Дальше начинается спор о том, чей отчёт правильный, — ровно то, ради чего внедряли BI.

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

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

Начали с выбора платформы. Полгода сравнения вендоров, потом выясняется, что данные не готовы и метрики не согласованы.

Построили дашборды на боевой базе. Отчётность работает, пока данных немного; на закрытии месяца тормозит и продукт, и отчёты.

Перенесли все старые отчёты. Половина из них не открывалась год, но каждый нужно поддерживать.

Не назначили владельцев метрик. Через полгода никто не может объяснить, почему в двух отчётах разная маржа, и доверие к системе теряется.

Не проверили данные перед запуском. Красивый дашборд с неверными числами хуже отсутствия дашборда: на его основании принимают решения. Если контур уже собран и вызывает сомнения, помогает аудит кода и архитектуры — обычно проблема в загрузке и справочниках, а не в платформе.

Первое — выбрать один отчёт, который сейчас собирается руками дольше всего, и описать его: какие поля, из каких систем, по какой формуле, кому нужен и как часто.

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

Третье — довести этот отчёт до конца: загрузка, витрина, дашборд, проверка сходимости с учётом. Один законченный отчёт, которому доверяют, полезнее двадцати наполовину готовых.