# Дашборд для руководителя: какие показатели помогают управлять бизнесом
Редакция SGI24. Материал основан на проектировании управленческих пультов и интеграции рабочих систем. [О бюро](/company).
Плохой дашборд очень убедителен на презентации. Там много цветов, проценты движутся вверх, а на вопрос директора «что мне сделать сегодня?» экран не отвечает.
Рабочий дашборд начинается с решений руководителя. Какие отклонения требуют вмешательства? Где деньги или заявка могут потеряться? Как понять, что команда не успевает выполнить регламент? Уже после этого выбираются показатели и графики.
Спроектировать дашборд руководителя
Сначала выпишите решения, потом показатели
Один и тот же показатель может быть полезным или бесполезным. Количество заявок за месяц интересно само по себе, но почти ничего не говорит о следующем действии. Картина меняется, если рядом видны заявки без ответственного, время первого ответа, просроченные задачи и источник обращения.
Мы задаём руководителю простой вопрос: «Какое решение вы примете, если число станет красным?» Если ответа нет, показатель, скорее всего, не нужен на первом экране.
Управленческий дашборд обычно помогает принимать решения четырёх типов:
- вмешаться в просроченный процесс;
- перераспределить людей или нагрузку;
- проверить причину отклонения;
- изменить план на ближайший период.
Остальные данные можно оставить в отчётах второго уровня.
У каждого числа должно быть одно определение
Самая неприятная проблема возникает не в дизайне. Директор видит одну выручку, бухгалтер другую, а CRM показывает третью. У каждого отдела своя дата, статус и набор исключений.
До разработки фиксируются определения. Что считается заявкой? Когда она становится продажей? Какая дата относится к оплате? Как учитывать возврат? Что делать с дублем?
Эти правила становятся словарём показателей. В нём указаны источник, формула, период обновления и ответственный за качество данных. Без такого словаря любой красивый экран быстро превращается в повод спорить о цифрах.
Три уровня вместо одной перегруженной страницы
Первый уровень отвечает на вопрос «всё ли идёт по плану». Руководитель видит несколько показателей, отклонения и точки, где требуется решение.
Второй уровень объясняет причину. Например, общая конверсия снизилась из-за одного канала или просроченных ответов конкретной группы.
Третий уровень ведёт к факту: заявке, задаче, документу или записи в рабочей системе. Не нужно просить аналитика прислать таблицу. Руководитель может открыть источник и понять, что произошло.
Такой переход от сигнала к факту важнее количества диаграмм.
Что стоит показывать собственнику
Набор зависит от бизнеса, но логика повторяется. Обычно собственнику важны деньги, загрузка, обязательства, потери и прогноз.
В стоматологии это может быть путь от обращения до подтверждённой записи, загрузка врачей, отмены и незакрытые задачи рецепции. Частной школе полезно видеть обращения семей, экскурсии, договоры, оплаты и заполнение классов. Для конференционного проекта важны регистрации, оплаты, документы участников и работа менеджеров.
Мы не переносим эти примеры в другой бизнес автоматически. Сначала выясняется, где принимаются решения и что считается потерей именно у заказчика.
Сигнал должен приходить вовремя
Месячный отчёт хорошо объясняет прошлое. Для оперативного управления он часто запаздывает.
Если заявка должна получить ответ за час, руководителю нужен сигнал после нарушения срока, а не в конце месяца. Если резервная копия не прошла ночью, об этом надо узнать утром. Если врачебная запись требует проверки, событие должно попасть ответственному до закрытия периода.
У сигнала задаются владелец, срок и действие. Уведомление без задачи быстро становится фоновым шумом.
Прогноз полезен только с объяснением
Прогноз загрузки или поступлений можно построить на истории. Но одно число без диапазона и факторов создаёт ложную уверенность.
На экране лучше показать базовый сценарий, допущения и причины изменения. Если прогноз ухудшился из-за снижения входящих обращений, это одна управленческая задача. Если из-за роста отказов после первого контакта, совсем другая.
ИИ может помочь найти закономерность и подсветить необычное отклонение. Решение всё равно принимает человек, который понимает контекст бизнеса.
Откуда берутся данные
Дашборд редко работает с одной системой. Источниками становятся сайт, CRM, 1С, медицинская или образовательная программа, телефония, сервис оплаты и рабочие таблицы.
Нельзя молча склеить всё по номеру телефона или названию организации. Для обмена определяются идентификаторы, правила дублей, задержки и основная система. Ошибка интеграции должна быть видна, иначе руководитель примет неполные данные за реальность.
Как проектируется интеграция сайта, CRM и 1С
Первый этап разработки
Начинать с большого технического задания не обязательно. Сначала можно сделать прототип одного экрана руководителя на реальных данных и проверить его пользу.
На этом этапе SGI24:
- фиксирует решения и роли пользователей;
- определяет показатели и их владельцев;
- проверяет источники и качество данных;
- собирает прототип и сценарии перехода к фактам;
- описывает интеграции и следующий этап.
Результат можно оценить до полноценной разработки. Видно, отвечает ли экран на вопросы руководителя и какие данные придётся привести в порядок.
Первый этап без обязательного комплекса
Для запуска не требуется одновременно переделывать сайт, CRM и всю инфраструктуру. Дашборд можно заказать отдельно; его результат и цена фиксируются до начала работы.
Если данные уже доступны, мы подключаем их. Если часть показателей пока собирается вручную, это честно отмечается в архитектуре. Последующие интеграции можно добавлять по очереди.
Комплекс нужен только там, где разрывы между системами мешают получить достоверную картину. Решение об этом принимается после разбора, а не заранее.
Как понять, что дашборд получился
Попросите руководителя открыть экран без презентации разработчика. Он должен за несколько минут ответить:
- что требует внимания сейчас;
- почему возникло отклонение;
- кто отвечает за действие;
- где находится исходный факт;
- что изменится, если ничего не делать.
Если вместо ответов начинается экскурсия по фильтрам, проект ещё не закончен.
Кто отвечает за каждый показатель
У показателя должен быть владелец. Это не разработчик дашборда, а человек в организации, который понимает смысл цифры и может объяснить отклонение. Финансовый показатель обычно подтверждает бухгалтерия или финансовый руководитель. За движение заявок отвечает руководитель продаж или сервиса, за полноту медицинских данных — уполномоченный сотрудник клиники.
Разработчик отвечает за то, что данные забираются по согласованному правилу, преобразуются без скрытых допущений и вовремя появляются на экране. Такое разделение снимает опасную иллюзию, будто программа сама устанавливает истину.
Если определение меняется, версия правила фиксируется. Иначе две части одного годового графика будут рассчитаны по-разному, а пользователь об этом не узнает.
Как принимать работу
Приёмка начинается не с цвета диаграмм. Для нескольких контрольных дат берутся исходные записи и вручную пересчитывается результат. Проверяются дубли, возвраты, отмены, переход через границу месяца и запоздавшие данные.
Затем разыгрываются рабочие ситуации: показатель вышел за предел, источник перестал обновляться, у пользователя нет доступа к деталям. Экран должен различать бизнес-отклонение и техническую неполноту. Нельзя показывать спокойный зелёный статус, если часть источников недоступна.
Последняя проверка — управленческая. Руководитель называет решение, которое он принял бы по сигналу. Если у карточки нет возможного действия, возможно, она занимает место зря.
Что требуется от заказчика
Нужен владелец проекта, доступ к согласованным источникам и несколько часов руководителя на формулировку решений. Готовая идеальная база не обязательна. Но ограничения данных должны быть названы честно.
Мы не просим передать все системы без разбора. Сначала составляется минимальный перечень полей и прав. Тестовый контур отделяется от рабочего, а чувствительные сведения по возможности заменяются обезличенными примерами.
Спроектировать дашборд руководителя