К моей команде обратился застройщик с запросом на аналитику.
У клиента уже была выстроена аналитика в Power BI. Но делалась она несколько лет назад под ту структуру данных и задачи, которые были на тот момент. За это время бизнес вырос, процессов стало больше, источников данных стало больше, и текущие дашборды просто перестали закрывать их нынешние управленческие вопросы.
Они не стали дорабатывать текущие дашборды, потому что решили выстроить аналитику заново уже под текущие задачи и процессы бизнеса. Дополнительно был фактор риска. Power BI — продукт Microsoft, и у клиента были опасения, что со временем могут появиться ограничения по доступу, например, как с Looker Studio от Google.
Они выбрали платформу Apache Superset. Это open-source инструмент, который разворачивается на своей инфраструктуре — данные остаются внутри компании, доступы контролируются самостоятельно, нет зависимости от лицензий и внешних сервисов. По сути, это просто код на сервере, поэтому «отключить» его извне нельзя. Из рисков — сама инфраструктура. Если сервер находится в зарубежном облаке или доступ идёт через внешние сервисы, теоретически могут быть ограничения. Плюс стандартные технические вещи такие, как настройки, доступы, стабильность. Но это уже зона контроля самой компании, а не платформы.
Мы сначала разобрали, как у них вообще устроены данные. Оказалось, что они лежат в нескольких системах: 1С, Google Таблицы, Excel, отдельные выгрузки в XML и внутренняя самописная система, которая частично закрывает функции CRM.
Сначала вместе с клиентом определили, какие дашборды и показатели им реально нужны для работы, и на основе этого составили ТЗ. Дальше мы пошли в источники. Подключили все системы и начали забирать данные через Python-скрипты. Все данные начали складываться в PostgreSQL.
Дальше занялись данными. Привели метрики к единой логике, разобрались, как они считаются и почему где-то не сходятся.
Когда логика расчётов была зафиксирована, мы собрали слой данных. Использовали view и materialized view — это позволило заранее подготовить данные и не нагружать систему при каждом открытии дашборда. Так отчёты стали работать быстрее и стабильнее.
Только после этого мы перешли к дашбордам.
Сначала собрали верхний уровень — ключевые показатели. Это те цифры, на которые чаще всего смотрит руководство (выполнение плана, общая динамика, эффективность). Здесь важно было не перегрузить экран, а оставить только то, что реально используется.
В Superset использовали и обычные, и сводные таблицы. В обычных удобнее сортировка, а в сводных работают кросс-фильтры. Также добавили линейные, столбчатые и комбинированные графики с нужными форматами значений. Дашборд собрали из смысловых блоков (например, «паспорт объекта» и финпоказатели) через группировку, чтобы они двигались как единое целое.
Этот страницу дашборда сделали как операционный инструмент, чтобы быстро видеть эффективность задач и загрузку команды в одном месте.
Эту страницу сделали как быстрый контроль подрядчиков. В одном месте видно, у кого по каким документам и этапам есть проблемы. По сути это чек-лист, где сразу подсвечиваются отклонения (не выполнено, не соответствует и т.д.), чтобы не разбирать каждого подрядчика отдельно, а быстро находить узкие места и принимать решения.
Это сводная таблица по этапам выноса сетей, где по каждому объекту сразу видно статус работ. Цвета показывают отклонения и текущую ситуацию (в срок, просрочка и т.д.), а при наведении на ячейку можно посмотреть детали — план и факт. Условное форматирование и отображение настроены через CSS в Apache Superset.
Это только часть дашбордов, которые были собраны для клиента — в проекте их больше, под разные задачи и уровни управления.
В итоге у клиента появилась единая система аналитики, которой можно пользоваться в работе без дополнительных проверок и ручных сборок. Этого было достаточно, чтобы закрыть основной запрос на понятные и стабильные данные.
У меня есть Telegram-канал — От цифр к делу🔎 | Никита Василевский. Там делюсь кейсами, полезными материалами и в целом рассказываю про бизнес и аналитику.
