Почему BI-дашборд не работает: 12 ошибок от данных до решений

Коротко

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

• Расхождение с источником — повод проверить зерно и статусы, а не округление.
• Нет действий после KPI — вероятно, не определён пользовательский сценарий.
• Медленный экран часто указывает на плохой слой данных, а не только на BI.
• Пустой график и нулевое значение должны выглядеть по-разному.
• Каждый KPI должен иметь owner и способ сверки.

1–3. Цифры не сходятся

Первая группа проблем связана с достоверностью. Найдите конкретный период и конкретное число, которое оспаривают. Сравните одинаковые фильтры, дату, валюту, статусы и зерно. Сверка общей суммы без проверки количества сущностей часто скрывает дубли и компенсации.

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

4–5. Метрика называется понятно, но считает не то

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

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

6–7. На экране много цифр, но нет ответа

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

Проверьте заголовки. «Продажи по регионам» описывает поле, но не помогает понять вывод. «Падение net revenue сосредоточено в Северо-Западном регионе» уже формулирует наблюдение, если оно действительно подтверждено. Заголовок не должен подменять анализ, но может сократить путь к нему.

• Один главный вопрос на экран.
• Не больше нескольких KPI без явного приоритета.
• График сопровождается единицами, периодом и baseline.
• Есть переход от сигнала к разрезу и списку объектов.
• Второстепенные детали не конкурируют с действием.

8–9. Данные устарели или обновляются непредсказуемо

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

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

10. Дашборд слишком медленный

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

Скорость должна быть частью требований. Укажите целевое время первого meaningful результата, допустимую задержку фильтра и поведение при длинном периоде. Если пользователю нужна недельная динамика, не заставляйте его при каждом клике сканировать годы сырых данных.

• Проверить план и объём сканируемых строк.
• Сократить набор по умолчанию до рабочего периода.
• Вынести повторяемые расчёты в витрины.
• Разделить summary и drill-down.
• Показывать состояние загрузки без layout shift.

11–12. Нет владельца и следующего шага

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

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

Мультивалютность включили во вторник, дашборд не сломался, а net revenue потеряла 1,4 млн

12 августа отдел продаж начал принимать заказы в евро. Ни один виджет не упал, загрузка прошла по расписанию, строки пришли в обычном объёме. За август экран показал net revenue 12,1 млн рублей вместо 13,5 млн. Причина в одной колонке: 184 заказа приехали с суммой в евро, а отчёт по-прежнему складывал amount как рубли. Вместо 1,41 млн рублей (14 352 евро по курсу 98) в итог попало 14 352 — меньше одной сотой от настоящей суммы. Расхождение нашли через девять дней, когда финансы закрывали месяц.

Шесть проверок из диагностики выше здесь молчат по очереди. Количество строк совпало с CRM, ключи уникальны, дата заказа в нужном периоде, pipeline отработал вовремя, формула не менялась неделями. Изменилась не форма данных, а смысл колонки: amount перестал означать рубли. Такие поломки не видны ни тесту на дубли, ни контролю свежести — их ловит только заранее записанная договорённость о том, что поле означает и кто предупреждает об изменении.

Эта договорённость и есть data contract. В нём четыре слоя: структура (какие поля приходят и какого типа), смысл (что означает значение и в каких единицах), качество (какие условия обязаны выполняться на каждой загрузке) и владелец со сроком обновления и каналом предупреждения. Разница с чеклистом проверок в адресате: проверка отвечает на вопрос «данные соответствуют правилу», контракт — на вопрос «кто обязан сообщить, когда правило меняется, и что произойдёт, если он не сообщит».

Для заказа договариваются не про таблицу целиком, а про пять вещей: закрытый список статусов, момент заполнения даты оплаты и её часовой пояс, дату и правило возврата, валюту вместе с источником курса, правило отмены. Формулировка «таблица orders выгружается ночью» контрактом не является: она описывает расписание, а не содержание. Полезная формулировка выглядит иначе — «amount всегда в валюте заказа, валюта в колонке currency, курс на дату оплаты приходит отдельной таблицей rates».

Самое ценное в контракте — закрытый список допустимых значений. Новое значение статуса не должно тихо попадать в группу «прочее»: строка уходит в карантин, на дашборде появляется предупреждение, владелец источника получает сообщение. Точно так же и с валютой: вторая валюта в колонке currency — это нарушение контракта, а не новая возможность отчёта. В августовском случае одна такая проверка превратила бы девять дней тишины в письмо утром 13 августа.

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

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

select
  count(*) filter (where status not in ('new', 'meeting', 'won', 'paid', 'refunded', 'canceled')) as unknown_status,
  count(*) filter (where currency is distinct from 'RUB')                                         as non_rub_rows,
  count(*) filter (where status = 'paid' and paid_at is null)                                     as paid_without_date,
  count(*) filter (where paid_at < won_at)                                                       as impossible_order
from orders
where created_at >= current_date - interval '1 day';

Диагностический порядок

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