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