Почему 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 будет слабым. Иногда лучше начать с короткого отчёта и ссылки на детализацию, чем строить отдельный портал.

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

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