Сорок дашбордов и сорок определений выручки
Коммерческий отдел считает выручку по закрытым сделкам, финансы — по оплатам, маркетинг — по заказам из рекламных кабинетов. На совещании обсуждают не решение, а чей отчёт правильный.
Выберите тему — соберём контекст
Внедряем отчётность, встроенную в работу: определения метрик согласованы, данные обновляются по расписанию, а руководитель и аналитик видят один и тот же срез без ручной сборки файлов.
Или сразу: +7 (962) 368-39-51 Telegram
Дашборды обычно строятся быстро, а пользу приносят редко. Причина — не в инструменте визуализации.
Коммерческий отдел считает выручку по закрытым сделкам, финансы — по оплатам, маркетинг — по заказам из рекламных кабинетов. На совещании обсуждают не решение, а чей отчёт правильный.
Ключевая отчётность держится на Excel-файле аналитика с ручными связями. Он уходит в отпуск — отчётность останавливается, он увольняется — восстанавливать логику приходится по формулам.
Пока данные соберут, проверят и сведут, решения принимаются по прошлому месяцу. Для управленческих решений такая задержка делает отчёт историческим документом, а не инструментом.
Аналитик не может добавить измерение или изменить фильтр самостоятельно: каждый срез требует разработчика. В результате люди возвращаются к выгрузкам в Excel, где свободы больше.
Либо дашборд с маржинальностью открыт всему штату, либо региональный руководитель не видит своих цифр без письменного запроса. Разграничение по ролям не настроено.
Отчётность запустили, показали на презентации, а через месяц ей пользуются два человека. Причина в том, что дашборд не отвечает на ежедневный вопрос и не встроен в процесс.
Работу делим на содержательную часть — метрики и отчёты — и на инфраструктуру, которая удерживает порядок.
Согласуем единые определения показателей и закрепляем их в модели данных, а не в инструкции на словах.
Собираем отчёты под конкретные решения, а не «общий дашборд для всех».
Даём команде возможность собирать срезы самостоятельно, но в управляемых границах.
Отдельно занимаемся тем, чтобы отчётностью действительно пользовались.
Начинаем с вопросов, на которые бизнес не может ответить сегодня, а не с выбора инструмента визуализации.
Разбираем решения по ролям: что руководитель смотрит ежедневно, еженедельно и ежемесячно. Согласуем определения показателей и источники.
Собираем один отчёт верхнего уровня на готовых или минимально доработанных витринах, показываем на реальных цифрах и правим формулировки.
Добавляем разрезы для коммерческого, операционного и финансового блока, настраиваем роли, подписки и рассылки по расписанию.
Обучаем аналитиков self-service, вводим регламент изменений, раз в квартал чистим неиспользуемые дашборды и уточняем метрики.
Выбор инструмента вторичен по отношению к данным, но влияет на скорость внедрения. Metabase быстрее всего запускается и хорошо подходит для отчётности, где важны простота и самостоятельная работа аналитиков. Apache Superset даёт больше контроля над оформлением и работает с SQL-движками вроде ClickHouse и Trino, но требует больше настройки. Power BI удобен там, где компания уже работает в экосистеме Microsoft, а Yandex DataLens — если инфраструктура размещена в облаке Яндекса.
Мы обычно рекомендуем выбирать по двум критериям: какие источники нужно подключить и кто будет поддерживать отчётность внутри компании. Если BI-система уже используется, разумнее расширять её, чем запускать параллельный инструмент. Главное, чтобы источником данных были витрины хранилища, а не рабочая база операционной системы.
Определение метрики должно быть записано формально: название, формула, гранулярность, источник, период, условия исключения, владелец. Например, выручка — сумма оплат по счетам без НДС за календарный месяц, исключая возвраты и внутренние перемещения между юрлицами. Пока это не зафиксировано, любые два отчёта будут расходиться, потому что каждый автор подставит своё понимание.
Дальше определение переносится в код: макрос или модель, которая считается один раз и используется всеми дашбордами. Так изменение бизнес-правила меняет цифру сразу во всех отчётах, а не через месяц, когда кто-то заметит расхождение. Рядом мы храним журнал изменений: кто, когда и почему изменил формулу, чтобы можно было объяснить разницу с прошлым периодом.
Отчётность умирает, когда она не отвечает на регулярный вопрос. Поэтому мы начинаем с решений: какой выбор делается каждую неделю и какой информации для него не хватает. Отчёт, привязанный к такому решению, живёт годами; отчёт «обо всём» не открывают после презентации.
Второе условие — скорость. Дашборд должен открываться за секунды, иначе им перестанут пользоваться и вернутся к выгрузке. Это задача уровня витрин и хранилища, а не визуализации. Третье — доступность отчёта в момент принятия решения: подписка в мессенджере, письмо по расписанию или ссылка в интерфейсе рабочей системы работают лучше, чем отдельный портал, куда нужно специально зайти.
Технически да: BI-инструмент подключится напрямую к рабочей базе или к выгрузкам. Но тогда отчёты будут конкурировать за ресурсы с операционной системой, а метрики останутся разными в каждом дашборде. Мы обычно предлагаем минимальный промежуточный слой: несколько витрин в отдельной схеме или на отдельной базе. Это небольшая работа, которая снимает основные проблемы.
Стоимость определяется числом источников, количеством метрик и состоянием данных, а не лицензией инструмента — многие из них бесплатны при самостоятельном размещении. Первый рабочий дашборд на готовых данных делается за две-три недели. Полноценная отчётность с разделами для руководства и отделов, разграничением доступа и подписками занимает от полутора до трёх месяцев.
Да, и это одна из целей проекта. Мы настраиваем self-service так, чтобы аналитик собирал срезы из готовых витрин, не обращаясь к разработчикам: готовые наборы данных, шаблоны, понятные названия полей и короткая инструкция. При этом изменения в определениях метрик проходят через согласование, чтобы самостоятельность не превратилась в новые расхождения.
Разграничение настраивается на уровне инструмента и хранилища: роли по подразделениям, ограничение строк по филиалу или менеджеру, отдельные дашборды для финансов с маржинальностью и себестоимостью. Персональные данные в отчётность не выводятся: там, где нужен разрез по клиентам, используется обезличенный идентификатор или агрегированные срезы.
Смежные задачи, которые обычно решаются в одном проекте с этой.
Расскажите, какие показатели нужны руководству и отделам, — предложим состав дашбордов и план внедрения.
Cookie и аналитика
Мы используем необходимые cookie для работы сайта и форм. Аналитические cookie (Яндекс.Метрика, включая запись сессий) подключаем только с вашего согласия — от него можно отказаться. Подробнее: Политика использования cookie и обработка персональных данных.