Запрос на новый отчёт часто звучит просто: нужно собрать основные показатели, добавить фильтры и показать сравнение подразделений. После этого легко сразу перейти к данным, выбрать диаграммы и начать собирать дашборд.
На практике именно здесь можно заложить основную ошибку. Заказчик получит аккуратный интерфейс с цифрами, но не сможет ответить на главный вопрос: что нужно сделать после просмотра отчёта?
В одном из проектов я работал над BI-дашбордом, который должен был использоваться для сравнения подразделений организации. Отчёт был внедрён и используется, но самым важным этапом оказалась не визуализация. Сначала нужно было определить, какое решение должен поддерживать отчёт, какие объекты вообще можно сравнивать и что пользователь должен увидеть до того, как начнёт изучать отдельные показатели.
Ниже не попытка восстановить всю работу над проектом по дням, а структура подхода, к которой я пришёл на практике.
Список показателей ещё не является требованием
На старте заказчик обычно уже представляет будущий отчёт. Он может перечислить показатели, предложить диаграммы и попросить несколько фильтров. Такая информация полезна, но она описывает интерфейс, а не задачу.
Предположим, в требованиях указано:
показать значения по подразделениям;
добавить динамику по периодам;
вывести общее значение по организации;
сделать фильтры;
выделить лучшие и худшие результаты.
Формально по этому списку уже можно начинать разработку. Но остаются вопросы, от которых зависит смысл всего отчёта:
зачем подразделения сравнивают между собой;
кто будет смотреть результат;
какое отклонение требует внимания;
можно ли сравнивать абсолютные значения;
с каким периодом или ориентиром сопоставляется результат;
какое действие последует после обнаружения отклонения.
Без этих ответов аналитик сам заполняет пробелы. Один и тот же запрос можно превратить в рейтинг, мониторинг динамики, контроль выполнения плана или инструмент поиска проблемных участков. Данные могут быть одинаковыми, но логика отчёта будет разной.
Сначала решение, потом метрика
Для своего кейса я сформулировал назначение отчёта так: пользователь должен сравнить подразделения по единой методике и определить, какие из них требуют дополнительного внимания.
Эта формулировка намного полезнее требования «отобразить показатели по подразделениям». В ней уже есть:
пользователь отчёта;
сравниваемые объекты;
необходимость единой методики;
ожидаемый результат просмотра;
возможное последующее действие.
После этого каждый элемент дашборда можно проверить простым вопросом: помогает ли он определить отклонение и понять, где требуется внимание?
Если элемент не помогает принять решение, у него должно быть другое понятное назначение. Например, он может объяснять причину отклонения, показывать качество данных или давать детализацию. Если назначения нет, показатель, скорее всего, попал в отчёт только потому, что его можно рассчитать.
Я использую для такой проверки небольшую карточку решения:
Вопрос | Что нужно зафиксировать |
|---|---|
Кто смотрит отчёт | Конкретная роль или группа пользователей |
Что сравнивает | Подразделения, периоды, категории или другие объекты |
Какое отклонение ищет | От плана, среднего, прошлого периода или заданного порога |
Что делает дальше | Проверяет причину, запрашивает пояснение, меняет приоритет или принимает другое решение |
Когда нужен отчёт | Регулярный контроль, отчётная дата или конкретное событие |
Это ещё не техническое задание. Но без такой карточки техническое задание быстро превращается в перечень экранов и полей, смысл которых каждый участник понимает по-своему.
Сравнение требует общей базы
Когда цель отчёта состоит в сравнении подразделений, самая заметная диаграмма не решает проблему сопоставимости. До визуализации необходимо определить правила расчёта.
1. Единица наблюдения
Нужно понимать, что представляет одна строка исходных данных: событие, документ, пользователь, операция, период или агрегированное значение. Если в источниках используются разные уровни детализации, простое объединение может создать дубли или изменить итог.
2. Границы показателя
Одинаковое название ещё не означает одинаковый состав данных. В одном источнике показатель может учитывать все записи, в другом только завершённые, а в третьем исключать отдельные категории. До сравнения необходимо зафиксировать числитель, знаменатель и правила исключения.
3. Период
Подразделения должны сравниваться за одинаковый интервал и на одну дату обновления. Иначе отчёт покажет различие в состоянии данных, а пользователь воспримет его как различие результатов.
4. Масштаб
Абсолютные значения не всегда сопоставимы. Если подразделения отличаются по размеру или объёму операций, первое место в рейтинге может отражать только масштаб. Тогда дополнительно нужен относительный показатель с понятным знаменателем.
5. Пропуски и неполные данные
Ноль и отсутствие данных имеют разный смысл. Ноль может быть результатом расчёта, а пропуск может означать, что источник ещё не обновился или значение не было передано. Если визуально объединить эти состояния, пользователь получит ложное сравнение.
Таблица раньше диаграммы
Один из полезных приёмов при работе с новым отчётом - сначала проверить показатели в простой таблице.
Для каждой строки должны быть видны:
подразделение;
период;
исходные составляющие показателя;
рассчитанное значение;
признак отсутствующих или неполных данных;
дата обновления.
На этом этапе легче обнаружить дубли, неожиданные пропуски, расхождение итогов и ошибочную детализацию. Визуализация, наоборот, может скрыть проблему за агрегацией. Столбец выглядит убедительно даже тогда, когда под ним неверно объединены записи.
Проверку я бы строил в несколько проходов:
Сверить общий итог с исходным источником.
Выбрать несколько подразделений и пересчитать результат вручную.
Проверить периоды на границах выбранного диапазона.
Отдельно посмотреть нулевые значения и пропуски.
Проверить, меняется ли итог ожидаемым образом при применении каждого фильтра.
Убедиться, что детализация объясняет агрегированное значение.
Только после этого имеет смысл выбирать способ визуального представления.
Прототип нужен для проверки логики
Первый вариант дашборда не стоит воспринимать как почти готовый продукт. Его задача - проверить, одинаково ли аналитик и будущий пользователь понимают отчёт.
На встрече по прототипу полезнее спрашивать не «нравится ли вам диаграмма», а предлагать конкретный сценарий:
Найдите подразделение, которое требует внимания.
Объясните, по какому признаку вы его выбрали.
Перейдите к детализации.
Определите, что именно повлияло на результат.
Скажите, какое действие вы предпримете после просмотра.
Если пользователь не может пройти этот путь, проблема может быть не в цвете или расположении карточек. Возможно, в отчёте нет ориентира для сравнения, показатели не объясняют отклонение или детализация не связана с верхним уровнем.
Структура отчёта должна повторять ход решения
После проверки методики сам дашборд можно строить от общего к частному.
Первый уровень: где требуется внимание
Пользователь видит общую ситуацию, сравнение подразделений и заметные отклонения. На этом уровне не нужна вся доступная детализация. Его задача - выбрать объект для дальнейшего анализа.
Второй уровень: почему возникло отклонение
Здесь показатель раскладывается по категориям, периодам или другим значимым разрезам. Пользователь проверяет, является ли изменение устойчивым и какой компонент сильнее всего повлиял на итог.
Третий уровень: на каких данных построен вывод
Если права доступа и назначение системы это позволяют, пользователь переходит к записям или более подробным агрегатам, из которых рассчитан показатель. Это повышает проверяемость отчёта и упрощает разбор расхождений.
Отдельно стоит показывать дату обновления и предупреждения о неполных данных. Это часть аналитического результата, а не техническая подпись внизу экрана.
Что удалось подтвердить результатом
В описываемом кейсе отчёт был внедрён и используется для сравнения подразделений. Это подтверждает, что сценарий оказался применимым в работе.
При этом я не измерял, насколько сократилось время подготовки решений, как изменилась скорость реакции на отклонения или сколько ручных операций удалось исключить. Поэтому было бы неправильно заявлять об эффективности в процентах или часах.
Сам факт использования тоже не является полной оценкой качества. Для следующего этапа я бы добавил несколько измеримых показателей:
долю пользователей, которые регулярно открывают отчёт;
время от открытия до перехода к нужной детализации;
количество найденных расхождений в данных;
долю вопросов, для которых пользователю потребовалась дополнительная ручная выгрузка;
перечень решений, при подготовке которых использовался отчёт.
Так можно отделить технический факт публикации дашборда от его реального участия в процессе.
Чек-лист перед созданием дашборда
Перед переходом к визуализации я бы проверил следующие вопросы:
Кто будет пользоваться отчётом?
Какое решение пользователь принимает после просмотра?
Какие объекты он сравнивает?
Что считается отклонением?
Сопоставимы ли объекты по периоду, составу и масштабу?
Где зафиксированы формулы показателей?
Чем ноль отличается от отсутствия данных?
Можно ли перейти от результата к его составляющим?
Как пользователь узнает дату и полноту обновления?
По какому сценарию будет проверяться прототип?
Как будет подтверждено, что отчёт действительно используется для решения задачи?
Если на эти вопросы нет ответов, выбор диаграмм стоит отложить. Иначе дашборд может оказаться технически корректным, визуально аккуратным и при этом бесполезным для работы.
Итог
Дашборд является последним видимым слоем аналитической работы. До него необходимо определить пользователя, решение, правила сравнения, состав показателей, качество данных и путь от общего отклонения к деталям.
Поэтому я бы начинал новый отчёт не с вопроса «что показать?», а с вопроса «что пользователь должен решить?». Первый приводит к списку графиков. Второй помогает построить аналитический инструмент, в котором каждый показатель и каждый переход имеют понятное назначение.
