(на примере сервиса, продаж b2b и подключений ШПД)

Мне кажется, у каждого управленца есть любимый дашборд. Лично мой внешне совсем не похож на “красивую BI-аналитику”.

В нем нет сложных графиков, нет круговых диаграмм, нет презентационной магии. Есть несколько карточек с красными цифрами:

— аварии в очереди;
— юридические лица в очереди;
— заявки, по которым не было звонка клиенту;
— незаполненные слоты на 9:00;
— количество техников, загруженных менее чем на 80% сегодня;
— количество техников, загруженных менее чем на 80% завтра.

Это дашборд по координации заявок, в котором можно увидеть актуальную картину по процессу прямо сейчас. Например, сегодня в одном из наших филиалов утром можно было увидеть: 12 аварии в очереди, 151 заявок без звонка, 28 незаполненных слотов на 9:00 и 9 техников, загруженных менее чем на 80% на сегодня. 

С точки зрения “красивого BI” это выглядит очень просто. С точки зрения управления — это один из самых полезных инструментов.

Потому что такие цифры не нужны для отчета по итогам месяца. Они нужны для действия прямо сейчас.

Если на завтра не заполнены утренние слоты, ждать закрытия месяца бессмысленно. Завтра уже наступило в прошлом. Инженеры вышли на смену, часть времени была потеряна, клиенты не получили подключение или сервис вовремя, заявки еще немного повисели в очереди, а потом ушли в отказ, а потом кто-то на итоговом совещании спросил: “Почему у нас просел показатель?”

Но проблема возникла не на итоговом совещании.

Она была видна раньше.

Вопрос только в том, был ли у нас дашборд, который ее показал.

BI часто показывает уже случившийся факт

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

Проблема в том, что большая часть этих цифр — запаздывающие показатели.

Факт уже случился. Месяц закончился. Квартал закрыт. Данные собрали. Где-то еще неделю или две ушло на подготовку отчета. И только после этого руководитель видит некрасивую картинку: план не выполнен, SLA просел, подключений меньше нормы, очередь выросла, отток увеличился.

Формально BI есть. Дашборды есть. Отчеты есть.

Но управляемости нет.

Потому что к моменту, когда руководитель получил отчет, Бобик уже сдох и повлиять на это невозможно. Можно провести разбор, найти виноватых, поменять регламент, запланировать улучшения на следующий период. Но конкретный месяц уже закончился, конкретные клиенты уже ушли, конкретные заявки уже просрочены, конкретные слоты уже сгорели.

Хороший BI должен показать, что у Бобика только началась температура.

То есть хороший BI — это не только отчетность. Это система раннего предупреждения.

Итоговая метрика редко объясняет, где именно болит процесс

Возьмем еще один пример из телекома: приток ШПД на базе умного домофона.

Допустим, по итогам месяца мы подключили 100 абонентов. Это хорошо или плохо?

Само по себе число ничего не говорит.

Если было 102 заявки на подключение, а подключили 100 — инженерная служба отработала почти идеально. Если было 300 заявок, а подключили те же 100 — у нас проблема. Но и количество заявок само по себе не дает ответа.

102 заявки — это хорошо или плохо? Если было 110 лидов, значит, менеджеры или телемаркетинг отлично довели лиды до заявок. А если лидов было 500, то 102 заявки — уже провал на предыдущем этапе.

А 110 лидов — это хорошо или плохо? Зависит от базы умного домофона, новой стройки, проникновения услуги, маркетингового бюджета, времени года и еще десятка факторов.

И вот так, шаг за шагом, приходится спускаться вниз по процессу.

Финальный приток — это не самостоятельная управленческая метрика. Это результат нескольких предыдущих этапов: базы, лидов, обработки, заявок, наличия слотов, выездов, подтверждений, подключений, активаций.

Если смотреть только на финальный результат, мы всегда будем опаздывать. Мы будем видеть, что месяц получился плохим, но не будем понимать, где именно процесс начал ломаться.

А управлять можно только там, где мы видим место поломки.

Продажи: та же проблема, только выглядит приличнее

В B2B-продажах ситуация похожая, просто внешне выглядит более аккуратно.

У большинства компаний есть стандартная витрина воронки: сколько сделок в работе, на какую сумму, на каких этапах, какая вероятность закрытия, какой weighted pipeline. Для руководителя это привычная картина: лиды, КП, переговоры, договор, закрытие.

Но такая воронка часто статична.

Она показывает, что лежит в продажах сейчас, но плохо показывает, что с этой воронкой происходит.

Можно видеть много сделок на этапе “КП” и думать, что все неплохо: pipeline наполнен, менеджеры работают, потенциальная сумма есть. Но если эти КП лежат там уже месяц без следующего действия, это не pipeline, а склад надежд.

Можно видеть много лидов и радоваться активности, но не замечать, что лиды почти не переходят в квалифицированные сделки. Можно видеть крупные сделки на подписании договора и не замечать, что этот этап начал стагнировать. Можно видеть общую сумму воронки и не видеть, что старые сделки создают иллюзию объема.

Когда руководитель чувствует, что продажи проседают, часто включается режим физического контроля: сколько звонков сделал менеджер, сколько писем отправил, сколько КП подготовил, сколько встреч назначил.

В массовых продажах эти показатели действительно могут помогать. Там активность, регулярность касаний и объем действий имеют прямое значение.

Но в системной интеграции, B2B и длинных продажах количество звонков само по себе мало что доказывает. Можно сделать много звонков и плохо проработать сделку. Можно отправить КП и не понять, есть ли бюджет, кто ЛПР, какой pain у клиента и что мешает следующему шагу.

В длинных продажах нужно смотреть не только на активность, а на движение.

Сколько сделок реально перешло на следующий этап? Сколько застряло? Где растут отказы? Где увеличивается срок прохождения этапа? Какие КП отправлены, но по ним нет возврата? Какие договоры находятся на подписании дольше нормы? Какие сделки давно не обновлялись?

Статичная воронка отвечает на вопрос: “что сейчас лежит в продажах?”

Динамическая воронка отвечает на вопрос: “где продажи начали тормозить?”

И для управления это намного важнее.

Дашборд должен начинаться не с графика, а с процесса

Одна из частых ошибок при внедрении BI — начинать с вопроса: “Какие графики хотим видеть?”

На мой взгляд, это неправильная точка входа.

Правильный вопрос: “Каким процессом мы хотим управлять?”

Если процесс не разобран, дашборд почти всегда превращается в набор красивых, но слабо связанных показателей. На нем может быть выручка, количество заявок, конверсия, SLA, загрузка и еще двадцать графиков. Но когда возникает отклонение, руководитель все равно начинает вручную выяснять: кто виноват, где застряло, почему не сработало.

В одном из проектов мы пошли другим путем. Мы начали массово внедрять дашборды по отклонениям.

Логика была простая: сначала описываем процесс, потом раскладываем его на этапы, для каждого этапа задаем норму, привязываем владельца и выводим на дашборд не все подряд, а только красные зоны.

Это сильно меняет поведение руководителя.

Он не смотрит каждый день на двадцать графиков “для общего понимания”. Он открывает дашборд и видит: вот конкретный участок процесса, где сейчас отклонение. Вот подразделение. Вот масштаб. Вот насколько это критично. Вот куда надо идти разбираться.

А самое главное — руководитель начинает “копать” дальше: дорабатывать свой дашборд так, чтобы еще глубже и точечнее видеть проблему.

На хорошей витрине не должно быть ощущения “ну, данные есть, дальше думайте сами”. Хорошая витрина должна подталкивать к управленческому действию.

Как это работало на сервисных инженерах

Служба выездных инженеров — хороший пример, потому что там очень быстро становится видно, где отчетность отличается от управления.

Стандартный дашборд по выездам часто показывает верхний уровень: сколько заявок назначено, сколько выполнено, сколько подключено, сколько закрыто за день, какой процент выполнения.

Это полезно. Но вообще недостаточно.

Можно выполнить норму по закрытым заявкам и при этом плохо управлять ресурсом. Например, часть инженеров будет загружена почти полностью, а часть “свободна как ветер”. Можно закрыть хороший объем сегодня, но оставить пустые слоты на завтра утром. Можно иметь нормальный общий SLA, но держать в очереди аварии, по которым давно надо было реагировать.

А увидеть очередь из абонентов, которым не позвонили ни разу, только в конце месяца — значит потерять подключения, доверие и деньги, уже потраченные на привлечение этих абонентов в компанию.

Поэтому мы стали смотреть не только на итог, а на ранние признаки будущей проблемы.

Нам важно видеть не просто “сколько выполнено”, а что происходит с очередью и ресурсом: сколько аварий висит в очереди, сколько юридических лиц ожидает обработки, сколько заявок без звонка, сколько свободных слотов на ближайшее утро, сколько техников недогружены сегодня и завтра.

На первый взгляд, “количество незаполненных слотов на 9:00” — не самая великая стратегическая метрика. Но если ты управляешь сервисной службой, это очень важный сигнал.

Пустой слот — это не просто пустая ячейка в расписании. Это потерянная производительность инженера, возможное ожидание клиента, сдвиг очереди, просадка в подключениях и потенциальная потеря выручки.

То же самое с недогруженными техниками. Если один инженер забит на 90%, а другой загружен на 30%, общий показатель по подразделению может выглядеть не так страшно. Но внутри процесса уже есть перекос: диспетчеризация, район, тип работ, квалификация, доступность заявок, подтверждения клиентов — где-то в этой цепочке проблема.

И вот здесь BI начинает быть полезным. Он не просто сообщает в конце месяца: “мы недовыполнили план”. Он показывает утром: “завтра у вас пустые слоты, сегодня часть техников недогружена, по этим заявкам не было звонка, аварии копятся”.

Это совсем другой уровень управляемости.

Почему одних аналитиков недостаточно

Здесь есть важный момент, который не всегда любят обсуждать.

Может ли аналитик сам придумать правильные метрики для управленческого дашборда?

Иногда может. Но чаще всего — только частично.

Аналитик хорошо понимает данные: где лежат таблицы, как связаны сущности, как построить запрос, где нужно очистить данные, как собрать витрину, как визуализировать показатель.

Но владелец процесса понимает другое. Он знает, где в реальности возникает узкое место, какой показатель является ранним сигналом, какое отклонение критично, кто должен реагировать и какое действие должно последовать.

Если дашборд делает только аналитик без владельца процесса, получается аккуратная, но часто поверхностная отчетность. Показатели правильные, графики красивые, но управленческого нерва в них нет.

Если дашборд делает только владелец процесса без аналитика, чаще всего получается Excel, ручные выгрузки и несколько версий правды.

На практике я вижу две рабочие модели.

Первая — связка “руководитель процесса + аналитик”. Руководитель формулирует управленческую логику, аналитик помогает корректно превратить ее в данные, витрины и визуализацию.

Вторая — руководитель с цифровыми навыками, который сам умеет формулировать запрос к данным, проверять гипотезы, собирать первые черновики витрин и использовать ИИ-инструменты как помощника для ускорения работы.

Но в обоих случаях владелец процесса остается ключевой фигурой.

Именно он формулирует, что считаем нормой, где красная зона, какой этап влияет на итоговый результат, кто должен реагировать и какое действие должно последовать.

Аналитик, DWH-команда и цифровые инструменты превращают эту логику в данные, историю, витрины и дашборды.

Только в этой связке BI начинает работать как инструмент управления, а не как набор отчетов.

Почему без DWH это быстро упирается в потолок

На первом этапе можно сделать дашборд и на выгрузках. Иногда это нормальный путь: быстро проверить гипотезу, понять, какие показатели нужны, показать пользу.

Но если компания хочет управлять процессами регулярно, без DWH быстро начинаются ограничения.

Данные лежат в разных системах. Показатели считаются по-разному. История изменений теряется. Статусы перезаписываются. Разные отделы показывают разные цифры по одному и тому же процессу. Чтобы собрать отчет, люди снова выгружают Excel, склеивают, проверяют, спорят о методике и в итоге получают данные с задержкой.

Для дашбордов отклонений особенно важна история.

Если мы не храним исторические состояния, мы видим только “сейчас”. А для управления часто важнее изменение.

Было 20 зависших сделок, стало 35. Договоры начали дольше лежать на подписании. Отказы выросли за неделю. Слоты начали пустеть на завтра. Количество заявок без звонка растет третий день. Один район системно проседает по подключению. Одна команда закрывает заявки быстрее другой.

Это невозможно нормально увидеть, если у нас есть только текущая выгрузка.

DWH нужен не потому, что “так правильно по архитектуре”. И не только для хранения данных.

DWH нужен для хранения состояний.

Без истории состояний мы не видим динамику: зависание сделки на этапе КП, рост очереди заявок без звонка, ухудшение загрузки инженеров, замедление подписания договоров, накопление аварий.

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

Что я теперь считаю хорошим BI

После нескольких таких проектов я стала иначе относиться к управленческим дашбордам.

Для меня хороший BI — это не тот, где больше графиков. И не тот, где красивее интерфейс.

Хороший BI отвечает на несколько очень практичных вопросов.

Каким процессом мы управляем? Из каких этапов он состоит? Что является нормой на каждом этапе? Какое отклонение критично? Кто владелец участка? Как быстро надо реагировать? Что должен сделать руководитель, увидев красную зону?

Если этих ответов нет, дашборд может быть красивым, но он не управленческий.

Он может подойти для презентации. Для ежемесячного отчета. Для общего понимания ситуации.

Но он не поможет поймать проблему в моменте.

А бизнесу часто нужен именно этот момент. Когда еще можно переставить ресурс, дозвониться до клиента, заполнить слот, разобрать очередь, ускорить договор, пересобрать маршрут, поднять проблему по аварии, изменить сценарий работы команды.

Управление начинается не тогда, когда мы увидели итог. Управление начинается тогда, когда мы увидели отклонение до того, как оно испортило итог.

Традиционный BI и BI раннего предупреждения

Для наглядности можно сравнить два подхода.

Главный вывод

BI не работает, когда он показывает только закрытые периоды и итоговые цифры.

Такой BI полезен для отчетности, но слаб для управления.

Настоящая ценность BI и DWH не в том, чтобы построить больше графиков. Ценность в том, чтобы владелец процесса начал видеть здоровье процесса в моменте.

Не когда месяц уже закрыт.
Не когда план уже провален.
Не когда клиент уже ушел.
Не когда заявка уже просрочена.

А тогда, когда еще можно вмешаться.

На мой взгляд, именно здесь BI перестает быть отчетностью и становится системой управления.

Он не просто отвечает на вопрос “что произошло”.

Он показывает, где процесс начинает болеть, кто должен на это отреагировать и сколько времени у бизнеса осталось, чтобы исправить ситуацию.