Аналитика данных и BI

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

С чем приходят

Совет директоров просит выручку за прошлый квартал. Финансы приносят одно число, продажи – другое, операции – третье, и каждое посчитано честно: одно после возвратов, другое по отгрузке, третье по оплате. Полдня уходит на спор, чья цифра верна, а решение переносят на неделю.

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

Аналитика данных начинается с определений

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

• Формула метрики словами и в SQL, чтобы её нельзя было прочитать двумя способами.
• Имя человека, к которому идут, когда финансы и продажи принесли два разных числа: без него спор уходит в переписку и остаётся там.
• Источник и время обновления: из какой системы берётся и на какой момент актуальна.
• Что метрика не показывает – это описывается отдельно и спасает от неверных выводов.

Хранилище и потоки данных

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

• Инвентаризация источников: что где лежит, кто владелец системы, какой объём и как часто меняется.
• Загрузка по расписанию с журналом того, что именно загрузилось: без него расхождение не объяснить.
• Слой преобразований, где сырые таблицы превращаются в витрины по согласованным определениям.
• Проверки качества на каждом шаге: пустые ключи, дубли, оборванная загрузка. Сообщение уходит владельцу витрины до утренней планёрки, сбои видны на панели в Grafana поверх метрик Prometheus.

Нагрузку стоит закладывать заранее. На платформе Monolith Plus отчётные запросы соперничали за базу, принимавшую операции, и аналитику пришлось вынести на копию с отставанием. Развилка есть в каждом проекте: копия и потеря свежести или боевая база и риск для её времени ответа.

Дашборды, которыми пользуются

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

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

Прогнозы и аномалии

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

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

Стек

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

Слой	Инструменты
Хранилище	PostgreSQL, BigQuery, Snowflake
Загрузка и преобразование	ETL / ELT (Airbyte, Fivetran), dbt, Apache Kafka
Отчёты и дашборды	Microsoft Power BI, Tableau, Looker Studio
Расчёты и модели	Python, SQL

Чего я не делаю

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

Как устроен проект

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

Дальше работа идёт этапами: хранилище и загрузка, глоссарий и витрины, дашборды, передача команде. Каждый этап заканчивается работающей загрузкой, витриной или экраном, который можно открыть. Типичный срок полного проекта – восемь-двенадцать недель, стоимость – 20 000 $ проектом, без почасового счёта и без открытого объёма.

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

Связанные услуги

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

Часто задаваемые вопросы

Через сколько появится первый работающий дашборд?

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

Что делать, если цифры снова разойдутся?

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

Сколько времени проект займёт у вашей команды?

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

Кто будет добавлять новые метрики после проекта?

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

---

Готовы начать?

Сколько версий выручки за прошлый квартал ходит по вашей почте? Если больше одной, назовите эту метрику на первом разговоре: я пройду её до строки в учётной системе. Записаться на разговор.