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

Я предпочитаю начать с другого вопроса: какое решение человек примет, увидев этот экран? Если ответа нет, можно потратить много времени на аккуратное представление цифр, которые ничего не меняют в работе.
Для меня хороший дашборд помогает заметить конкретное отклонение, понять его границы и выбрать следующий шаг. Он не обязан вмещать всю информацию компании.
Разбираю одно решение
Возьмём условную ситуацию: собственник хочет понимать, нужно ли усиливать обработку входящих обращений.
Для решения недостаточно общего количества заявок. Важно, сколько обращений ещё не разобрано, как давно они ждут, хватает ли в них данных и у какого сотрудника образуется очередь. Возможно, нужна дополнительная смена. Возможно, проблема в отсутствии информации о товаре. Возможно, часть обращений вообще не относится к выбранному процессу.
Я сначала описываю допустимые действия: перераспределить нагрузку, убрать конкретное препятствие, изменить график или пока наблюдать. После этого проще выбрать показатели, которые различают эти ситуации.
Это не означает, что любая цифра обязана запускать действие немедленно. Иногда решение — не вмешиваться. Но основание для него тоже должно быть понятным.
Договариваюсь о смысле показателя
Названия могут совпадать, а расчёты — различаться. «Продажи» у одного участника означают оплаченные заказы, у другого — подписанные договоры, у третьего — отгрузки. Пока это не выяснено, спор о правильной цифре будет повторяться.
Поэтому у показателя нужен короткий паспорт:
- какой вопрос он помогает решить;
- что входит в расчёт и что исключено;
- за какой период берутся события;
- какая дата определяет попадание в период;
- как учитываются отмены, возвраты и дубли;
- откуда поступают данные и когда они обновлялись.
Например, для очереди обращений следует определить, что именно считается необработанной заявкой. Если сотрудник отправил уточняющий вопрос, заявка завершена или ожидает ответа? Разные ответы дают разные графики загрузки.
Проверяю цифру на нескольких строках
До сложной визуализации мне полезно пройти небольшой набор записей вручную. Условно: два обычных обращения, одно повторное, одно отменённое и одно переданное в другой отдел.
Если участники не могут объяснить, почему эти пять строк дали конкретный итог, автоматическая агрегация тысяч строк пока не заслуживает доверия.
Такая проверка помогает обнаружить разницу между событием и текущим состоянием. Количество заявок, созданных за неделю, не равно числу заявок, которые остаются открытыми в конце недели. Оба показателя могут быть нужны, но отвечают на разные вопросы.
Я хочу, чтобы из итогового числа можно было перейти к основаниям расчёта в пределах разрешённого доступа. Иначе каждое отклонение потребует отдельной переписки с аналитиком.
Показываю свежесть и ограничения рядом с результатом
Если источник не обновился, на экране не должна оставаться прежняя зелёная отметка без пояснения. Читатель должен видеть, за какой момент показаны данные и есть ли пропуски.
Для важных показателей я предпочитаю отдельное состояние «данные неполные» или «обновление задерживается». Это помогает не путать отсутствие новых событий с отсутствием связи с источником.
Также полезно отделять факт от оценки. Если часть значения рассчитана по предположению, это должно быть заметно. Точность оформления не делает предположение подтверждённой цифрой.

Связываю отклонение с ответственным
Представим, что очередь выросла. Кто должен открыть её состав? За какой срок? Какой результат он должен принести на обсуждение?
Если такого порядка нет, дашборд становится местом коллективного наблюдения. Все видят проблему, но каждый предполагает, что ею занимается кто-то другой.
Я предлагаю для ключевых сигналов фиксировать не только порог, но и следующий шаг. Например: руководитель проверяет состав просроченной очереди, выделяет причину и выбирает действие. Конкретный порог компания устанавливает по своему процессу; универсального числа здесь нет.
Сначала такой порядок можно проверить вручную. Автоматические оповещения стоит добавлять, когда понятно, кому они нужны и чем отличаются от обычного информационного шума.
Оставляю на первом экране только необходимое
Подробные данные нужны для анализа. Но собственнику в регулярном обзоре часто важнее несколько решений, чем десятки одинаково заметных графиков.
Я разделяю общий экран и разбор причины. На первом — состояние, значимое отклонение, свежесть данных и путь к деталям. В деталях — состав записей, определения и сравнения.
Проверка готовности проста: человек смотрит на экран и может объяснить, что требует внимания, какие данные это подтверждают и кто сделает следующий шаг. Если он лишь пересказывает цвета и проценты, работу над управленческой частью ещё стоит продолжить.