Телеком-кейс о том, как управленческая аналитика помогла руководителям увидеть потери в процессах, сократить издержки и вернуть бизнес к положительному финансовому результату

Последние несколько лет телеком-бизнес все больше похож на белку в колесе.

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

Издержки растут быстрее выручки. Увеличивается ФОТ, сеть требует новых инвестиций, новые услуги создают новые бизнес-процессы, а каждый новый процесс почти неизбежно приносит с собой дополнительные затраты. Чем сложнее становится компания, тем больше внутри нее мест, где деньги незаметно застревают, расползаются или теряются.

Для телеком-рынка это особенно болезненно.

Закон Яровой, СОРМ-2, СОРМ-3, антифрод — для человека со стороны это просто набор отраслевых аббревиатур. Для тех, кто работает в телекоме, за каждой из них стоят новые обязательные расходы. Это не инвестиции в рост и не развитие продукта, а затраты, которые нужно нести просто для того, чтобы продолжать работать.

В итоге многие телеком-компании попадают в неприятную ловушку: абонентская база растет, выручка растет, продукты развиваются, а прибыль не появляется. Иногда компания формально становится больше, но финансово чувствует себя хуже. Рост базы, репрайсинг и выручка от новых услуг не перекрывают рост издержек.

Два года назад мы оказались ровно в такой точке.

Финансовая ситуация была, мягко говоря, плохой. Уже было понятно, что надеяться на “в следующем году станет легче” бессмысленно. Само не станет. Рынок не откатится назад, обязательные расходы не исчезнут, сеть не перестанет требовать инвестиций, а новые процессы не начнут внезапно обходиться бесплатно.

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

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

А нам нужно было не смотреть на P&L после факта, а найти места, где на него еще можно повлиять.

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

Спойлер: мы справились.

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

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

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

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

Почему мы начали не с BI-системы, а с руководителей

Когда компания решает “внедрить управление по цифрам”, очень хочется начать с инструмента. Выбрать BI-платформу, собрать витрины, нарисовать дашборды, раздать доступы, провести презентацию и объявить, что теперь мы управляем по данным.

Но в реальности такой путь часто не работает.

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

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

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

Это были инноваторы — руководители и специалисты, которым уже было интересно разбираться с данными, SQL, дашбордами и управлением по цифрам. Они не воспринимали аналитику как угрозу или дополнительную отчетную нагрузку. Наоборот, им было любопытно: можно ли через данные увидеть свой процесс глубже, чем в обычном ежемесячном отчете?

Это было принципиально.

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

Почему нельзя просто заставить всех управлять по цифрам

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

Но массовый запуск через “теперь все обязаны” часто превращается в сопротивление.

Один руководитель говорит, что у него и так много отчетов. Другой считает, что аналитика — это задача аналитиков. Третий боится, что прозрачность данных покажет проблемы в его зоне ответственности. Кто-то формально посещает обучение, но не применяет результат в работе. Кто-то просто ждет, когда очередная инициатива закончится.

Поэтому мы пошли не через давление, а через распространение изменений.

Сначала в программу вошли инноваторы — люди, которые уже были готовы пробовать. Именно они создали первые примеры, первые результаты и первые внутренние истории успеха. Затем появилась вторая группа: те, кто проявил интерес, но не попал в первую волну. Они уже видели, что это не абстрактная “цифровизация”, а инструмент, который реально помогает руководителю лучше понимать свой процесс. И только после этого подключилась третья группа — линейные руководители, которых направили директора направлений. Для них обучение становилось уже не факультативом, а частью управленческой роли.

Так изменение заходило в компанию не как приказ, а как новая практика.

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

Роль топ-менеджера: не контролер, а спонсор изменений

Отдельный важный элемент — кто ведет такую программу.

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

Здесь не так важно, чтобы этот человек лучше всех писал SQL. Гораздо важнее, чтобы у него был достаточный авторитет в коллективе.

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

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

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

Почему первым навыком стал SQL

На первом этапе мы начали с SQL.

Для руководителей это звучит странно. SQL обычно воспринимается как язык аналитиков, разработчиков и BI-специалистов, а не коммерческих, операционных или линейных руководителей.

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

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

Как это выглядит в телекоме: один и тот же бизнес-объект в разных системах имеет различное наименование и может являться разной сущностью: в 1С — это юридическое лицо или документ, в биллинге — лицевой счет или договор, в CRM — лид, контакт или заявка, а в системе управления выездными работами — адрес/ слот/ мастер/ статус или история выполнения.

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

Он начинает понимать, что управленческий показатель не просто показывается.

Он собирается.

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

Именно поэтому SQL в этой программе был не про программирование. Он был про управленческую грамотность.

Красиво не всегда эффективно

Следующим этапом стала визуализация данных.

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

Поэтому мы шли от реальных кейсов.

Один из первых живых разборов был по утилизации выездных инженеров. На дашборде у части сотрудников показатель получался больше 100%, и на первый взгляд это выглядело как ошибка. Если у техника рабочий день ограничен, как он может быть загружен больше чем на 100%?

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

Например, технику могли открыть 10 часов расписания, а по факту он выполнял заявок больше чем на 12 часов. Это возможно, если заявка выполняется и закрывается, слот освобождается, и в этот же день туда попадает следующая работа. Формально открытого расписания было 10 часов, а фактически через него прошло больше объема.

Но это была только первая версия объяснения. Дальше нужно было понять: перед нами особенность процесса, ошибка расчета или реальный перекос в данных?

И здесь уже начиналась настоящая аналитика.

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

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

Почему визуализация оказалась сложнее, чем казалось

На словах всё просто: есть данные — строим график.

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

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

То же самое с числами. Человек глазами видит “1000” и воспринимает это как число, а система может хранить его как текст. Пока поле не приведено к числовому формату, нормального расчета не получится.

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

Самое интересное: мы стали превращать данные в симптомы

После SQL и визуализации началась самая интересная часть — метрики здоровья бизнес-процессов.

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

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

Для совещания этого часто хватает. Есть отклонение — можно обсуждать.

Но для управления P&L этого мало.

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

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

Но если смотреть глубже, это еще не метрика здоровья. Это просто сообщение: “У нас есть проблема”.

Метрика здоровья начинается тогда, когда мы проваливаемся на следующий уровень и спрашиваем, почему поставка не была выполнена в срок. Грузоперевозчик не приехал вовремя на заявленный слот? Или он приехал, но склад не подготовил отгрузку? Склад не подготовил отгрузку по своей вине или потому, что товара не было в достаточном количестве? Товар был, но заявка поздно попала в работу? Слот был назначен без учета реальной загрузки?

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

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

Как руководители начали находить деньги в своих процессах

Финальной работой каждого руководителя был не экзамен по SQL и не отчет о прохождении курса.

Каждый должен был сделать проект по цифровизации своего подразделения или своего бизнес-процесса. И не в формате информационного дашборда “чтобы было видно показатели”, а в формате дашборда здоровья процесса.

Это важное отличие.

Информационный дашборд отвечает на вопрос: “Что у нас произошло?” Дашборд здоровья процесса отвечает на другой вопрос: “Где процесс влияет на деньги и что с этим можно сделать?”

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

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

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

Для операционного блока — узкие места, очереди, ручные операции, переделки и ошибки передачи данных между системами.

У каждого руководителя появились свои вопросы к данным. Где у меня зависают деньги? Где процесс тормозит выручку? Где затраты растут из-за плохой организации? Где ресурс простаивает? Где качество процесса влияет на будущий доход? Где я вижу проблему слишком поздно?

Именно в этот момент обучение перестало быть обучением. Оно стало инструментом изменения управления.

Личный дашборд как результат изменения

По итогам обучения каждый руководитель получил личный дашборд.

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

Это оказалось принципиально важным.

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

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

Одна эта итерация дала улучшение показателей в среднем на 12% по подразделениям.

Не потому что SQL сам по себе приносит деньги, графики управляют бизнесом или BI-система принимает решения за руководителя. А потому что руководители начали видеть свои процессы через данные и быстрее находить точки влияния на P&L.

Что было нужно технически

Для запуска этого подхода не потребовалось начинать с огромного BI-проекта.

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

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

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

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

Когда руководители понимают, что цифровые навыки важны на уровне первого лица, отношение к программе меняется.

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

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

Почему расходы на цифровизацию — не главный вопрос

Если посмотреть на P&L средне-крупной компании, там часто видна знакомая картина: 1–2–3 миллиарда рублей выручки и сопоставимый объем операционных затрат.

На этом фоне расходы на внедрение управления по цифрам выглядят совсем иначе.

Да, проект по данным, обучению и первичным управленческим дашбордам может стоить 1–2 миллиона рублей. Но для компании с миллиардными оборотами это небольшая доля операционного контура.

Главный вопрос не в том, сколько стоит дашборд. Главный вопрос — помогает ли он руководителям улучшать P&L.

Если дашборд просто показывает отчетность, он может быть красивым, но слабым управленческим инструментом. Если он помогает находить деньги в процессах — в скорости, марже, загрузке, документах, SLA, повторных операциях, закрытии работ, движении сделок — тогда это уже не расход на “цифровизацию”. Это инвестиция в управляемость.

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

Что я бы повторила в следующем проекте

Если бы я запускала такой проект еще раз, я бы сохранила эту логику.

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

Обязательно нужен топ-спонсор. Это может быть не генеральный директор, но это должен быть человек с высоким авторитетом, который показывает: управление по данным — не проект аналитиков, а управленческий стандарт.

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

И обязательно нужен финальный прикладной результат — личный дашборд руководителя. Без него обучение остается обучением. С ним оно превращается в изменение управленческой практики.

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

Дашборд не управляет бизнесом.

Бизнесом управляет руководитель, который понимает, что стоит за цифрой, где в процессе возникает отклонение и какое действие может повлиять на P&L.

BI становится полезным не тогда, когда показывает много графиков, а тогда, когда помогает увидеть место, где деньги создаются, зависают или теряются.

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

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

Именно в этот момент дашборд перестает быть отчетностью.

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