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

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

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

Запросы приходят в трёх видах, и все три — про доверие к цифре. Совет директоров просит выручку за квартал, а финансы, продажи и операции приносят три разные. Дашборд построили год назад, но решения по-прежнему принимают по выгрузке в таблицу, потому что дашборду не верят. Данных много, а на вопрос «что будет в следующем квартале» отвечают ощущением.

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

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

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

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

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

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

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

Нагрузку стоит закладывать заранее. На платформе Monolith Plus после переработки архитектуры поток вырос с 10 000 до более чем 100 000 операций в день при доступности 99,9 %, и аналитический контур пришлось строить так, чтобы отчётные запросы не мешали основной системе. Развилка тут всегда одна: считать на копии данных или на боевой базе.

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

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

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

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

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

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

Стек

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

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

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

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

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

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

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

До начала работ я смотрю на то, что уже собрано, бесплатно. Если задача решается настройкой выгрузок в существующей системе, я так и скажу.

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

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

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

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

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

Нужен ли доступ к нашим системам?

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

У нас уже куплен Power BI. Вы будете работать в нём?

Да, если он покрывает задачу. Менять платформу ради смены платформы смысла нет: узкое место почти всегда не в BI-инструменте, а в том, что под ним лежит.

Что останется у команды после проекта?

Глоссарий метрик, описанные загрузки, витрины и дашборды в вашем контуре и разбор с теми, кто будет их вести. Ничего из этого не завязано на моё участие.

---

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

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