От ручного управления отчётностью к автоматизированной системе. И почему пришлось делать это дважды
И, казалось бы, IT-компании должны легко и просто выстраивать собственные аналитические системы. Но далеко не всегда это так.Очень часто в стартапах команда делает отличный технологичный продукт, продажи и маркетинг делают всё возможное для работы на рынке, а заниматься построением единой системы данных просто некому — и это постоянно откладывается в долгий ящик. Сегодня поговорим как раз про такой случай.RuDesktop — платформа для удалённого управления конфигурациями устройств. Компания начала работу в 2022 году, когда с рынка стали уходить иностранные аналоги. У продукта два направления продаж: B2C (SaaS-решение) и B2B (on-premise версия).Компании было всего два года, когда мы взялись за аналитику. Формально всё было в порядке: есть сайт, есть CRM, есть реклама, а с продажами всё отлично — компания очень быстро росла. А по факту — три отдела считали выручку в таблицах каждый по-своему, и ни один из этих подсчётов не сходился с другим.
С чего всё начиналось
Стек на входе был максимально типовым. Облако «Битрикс24», сайт, подключённая к нему «Метрика», «Яндекс.Директ». И довольно большое количество отчётов — все они, поголовно, сводились в Excel вручную.Понятно, что коробочный «Битрикс» всегда более податлив к кастомизации, чем облако. Но, думаю, каждый, кто с ним работал, знает: так или иначе компании создают свои кастомные поля и имеют особенности ведения сделки — так было и в нашем случае.Единого стандарта отчёта перед руководством не было в принципе. Каждая планёрка генерировала какой-то новый вид отчёта. Он менялся от встречи к встрече, но так и не приходил к единому виду — просто потому, что каждый раз его собирали заново, под конкретный вопрос, а не по шаблону.
Каждый отдел считал сам — и цифры не сходились
Отчёты делал каждый отдел отдельно: маркетинг собирал свой, продажи — свой, партнёры — свой.И тут начиналось самое интересное. Между отделом продаж и отделом партнёров почти всегда была разница в цифрах. Они никогда не сходились: партнёры показывали свои цифры, отдел продаж — свои. Кто прав? На основании чего судить, если у каждого своя таблица и своя логика подсчёта? А что показывать руководителю, если в рамках одной встречи — две версии одной и той же выручки?У отдела продаж и у партнёрского отдела всегда были свои отдельные планы продаж. Цена продажи ПО напрямую и через партнёра — одинаковая, но для компании (если продажа партнерская) из неё вычиталась доля агентского вознаграждения — и доля эта была довольно значимой. Справедливости ради: часть сделок без партнёра вообще нельзя было закрыть. Это все принимали как данность.А теперь представим ситуацию. Есть менеджер Иван — прямые продажи. Ему приходит сделка на десять миллионов рублей, вознаграждение с неё — сто тысяч. Иван ведёт эту сделку три месяца, клиент уже почти готов платить.И тут в сделку заходит партнёрский менеджер и говорит: теперь эта сделка идёт через партнёра.Что это значит на практике? Сто тысяч, которые рассчитывал получить Иван, надо делить с менеджером партнёрского отдела. Компания получает меньше маржи — часть придётся отдать партнёру. А сделка, которую три месяца тащил на себе отдел прямых продаж, перестаёт быть на 100% выполнением его плана и частично становится выполнением плана партнёрского отдела.Именно такие ситуации беспокоили руководство сильнее всего. Партнёр правда был нужен в этой сделке — или его просто привели в последний момент, чтобы кто-то закрыл план? Аналитика может показать, кто зашёл в сделку и когда. Но не может сказать, была ли в этом необходимость — тут всегда важен персональный контекст.Теперь про маркетинг. Чтобы собрать один отчёт, приходилось доставать данные из нескольких систем: что-то — из «Битрикса», что-то — из «Метрики», что-то — из «Директа», а какие-то данные — из «1С». По сути, каждый отчёт — это была ручная сверка четырёх источников данных.Отдельная тема — ретроспектива. Её не было вообще, потому что «Битрикс» не хранит историю. Стоило спросить «а как было год назад» — и ответ почти гарантированно оказывался предположением, а не констатацией факта. Не потому, что кто-то врал, а потому что данные физически было неоткуда взять в целостном виде. Картина получалась не объективная.
Что мы хотели получить: не десять отчётов, а единый стандарт
Запрос компании звучал просто: нужна единая система аналитики, которую все возьмут в работу и начнут использовать в одном контексте. Но за простой формулировкой, как всегда бывает, скрывалось очень много подводных камней и работы.Работу начали со спринтов. И уже в первой версии появились дашборды, которые позволили отделу продаж перестать строить отчёты в «Битриксе» руками и начать смотреть в аналитику.Аналитику построили на платформе DataLens. Не потому что она объективно лучше остальных решений на рынке, а потому что нужно было отечественное решение, не зависящее от санкций. Если бы не санкции, это вполне мог быть Power BI или что-то ещё. Но в этих условиях «Яндекс» полностью закрыл задачу компании — и вопрос выбора инструмента снялся сам собой.
Дашборд есть, а стандарта всё ещё нет
Дальше началась немного более простая жизнь: люди стали получать данные из единого источника.Но, несмотря на это, единого стандарта отчётности в компании так и не появилось. Кто-то по старинке продолжал пользоваться отчётами из «Битрикса» — просто по привычке. Хотя основные данные к этому моменту уже поступали из DataLens.
Кто отвечает за отчёт для руководства
Следующий шаг — компания выбрала единого владельца процесса, который должен формировать отчёт для руководства. Им стал маркетинг.Маркетинг стал брать данные из отчётов DataLens и переносить их в форму отчётности компании. И здесь появился первый по-настоящему измеримый результат: время составления отчёта сократилось с нескольких дней до пяти-шести часов рабочего времени.Почему не до нуля? Потому что данным всё равно требовался анализ. DataLens показывает факт. Анализ всегда делает человек. Это тот момент, где инструмент заканчивается и начинается работа аналитика.
Как в отчёт втянулись все остальные
Постепенно в эту систему втянулись сами менеджеры — не потому, что их заставили, а потому что там оказалось удобнее.Менеджеры прямых продаж начали смотреть свои результаты: какой план выполнен за месяц, на какой стадии находятся сделки. Партнёрский отдел смотрел на свои результаты. Маркетинг следил за показателями «Яндекс.Директа» и сайта — и за тем, как это конвертируется в продажи.
А для всей компании и для руководства в первую очередь стало удобно другое: наконец-то в единой системе оказалась представлена выручка компании в едином стандарте, который утверждён всеми сотрудниками. Не десять версий правды, а одна.
Через год стало тесно
С этим отчётом прожили около года. И постепенно стало понятно, что он больше не закрывает все бизнес-задачи компании.Компания выросла, появились новые продукты и тарифы, как селдствие изменились процессы — и потребовалась уже довольно детальная аналитика с большим количеством данных. Сделали следующий спринт.Начиная с этого спринта, каждый отдел формировал ТЗ на свои дашборды сам: отдел продаж — свои изменения и нужные ему дашборды, маркетинг — свою систему, партнёрский отдел — свою. И добавился еще 1 отдел, которому необходимы оперативные данные для управления — отдел внедрения.
Выставки — канал дорогой, но до недавнего времени слепой
В B2B-маркетинге есть канал, который трудно оцифровать напрямую, — офлайн-мероприятия. Для продвижения on-premise версии менеджеры встречались с заказчиками лично на выставках. Канал недешёвый: сами мероприятия обходятся дорого, а значит, по каждому хотелось понимать — а что оно вообще принесло.С мероприятия менеджеры привозили не сделки, а контакты. Их заводили в «Битрикс», по части из них создавали сделки, часть сразу уходило в корзину. Но на уровне цифр не было никакого понимания: сколько лидов заведено по конкретному мероприятию, сколько из них превратилось в сделки и что с этими сделками происходит дальше — зависли они, выиграны или проиграны, а главное что с ними произошло за месяц или квартал.Раньше решение о повторном участии в том или ином мероприятии всегда принималось на основании ощущений прошлого когда — да, лид и сделки были едем еще раз. Но конкретно назвать сумму этих сделок ни кто не мог.
Поэтому под этот канал собрали отдельный дашборд. И здесь важной оказалась именно ретроспектива — не разовый снимок «сколько лидов сейчас», а то, как сделки двигаются по воронке во времени: от заведённого контакта до закрытой сделки.
План — не бумажка раз в квартал, а живой дашборд
Отдел продаж сформировал себе квартальные планы в таблицах — как и раньше, вручную. Разница в том, что случилось с этими планами дальше: их подгрузили в дашборд с возможностью динамического обновления.
Каждый менеджер мог зайти и увидеть факт выполнения своего плана — не в конце квартала, а прямо сейчас. Увидеть сделки, которые у него в работе. Посмотреть на зависшие сделки — те, что стоят на месте и никуда не двигаются.А дальше — уже вместе с руководителем — принимать решение: какого клиента шевелить и продолжать с ним работу, а какого пока стоит отложить.План перестал быть цифрой на бумаге и стал вопросом, на который отвечает менеджер каждый день, а не раз в квартал.
Новый руководитель — и задача, которую «Битрикс» решить не мог
Во время второго спринта в компании поменялся руководитель отдела внедрения.Предыдущий человек оставил довольно большое ТЗ под свой запрос. Новый — пока вливался в работу — формировал собственное видение процесса. И в итоге на втором спринте он сформировал документ, в который частично вошли старые задачи, но появился и ряд новых — таких, которые не решались даже средствами самого "Битрикса«.Нужно было понимать загрузку специалистов отдела внедрения: сколько презентаций они проводят, сколько времени на них тратят. А «Битрикс» отдавал только факт из календаря — причём выгружался этот факт в отчёты только вручную. То есть при каждом формировании отчёта руководителю приходилось заходить в календарь «Битрикса» и вручную делать даже не выгрузку, а фактчекинг. Посчитать так по каждому менеджеру — значит потратить огромное количество времени и сил на рутину, которая в принципе не должна требовать участия человека.Решение оказалось не в перестройке отчёта, а в том, чтобы вообще убрать из процесса руки: составили ТЗ, изучили документацию и поняли, что можно настроить передачу этих данных из «Битрикса» по API, настроили загрузку с обновлением раз в час — и система заработала. После этого отчёты по отделу внедрения стали формироваться очень быстро, руководитель в любой момент мог открыть дашборд и понять, сколько презентаций провёл менеджер за день, неделю, квартал, что стало дальше с клиентом и случилась ли сделка.
Эффект от первой же версии этого спринта был ощутимым. Время формирования отчёта сократилось ещё сильнее. Часть планерок перешла из формата констатации фактов в динамические встречи — на вопрос «а покажите данные» — даже прямо во время совещания — теперь можно было ответить сразу, обратившись к DataLens. Сократилось и само время совещаний с руководством с 2,5 часов до 1 го часа, потому что данные можно было смотреть онлайн и подгружать конкретные цифры по ходу разговора. А отделу продаж на планёрках стало проще разбирать конкретную сделку — потому что в DataLens, помимо цифр, были ссылки на все сделки в «Битриксе».
Итог
Если сжать всю эту историю до цифр, то путь выглядит так: от Excel, который собирали вручную из четырёх систем, — к единому дашборду с выручкой компании в одном стандарте. От нескольких недель на подготовку отчёта — к пяти-шести часам, а затем и к цифрам в реальном времени прямо на совещании.Но было бы неправдой сказать, что аналитика закрыла вообще все вопросы. История Ивана — живой пример: инструмент может показать факт, но не может сам решить, кому эта сделка принадлежит по существу. Это по-прежнему решают люди.Основная стратегическая задача клиента была решена, но теперь аналитика переходит из задачи в операционный процесс, который требует совершенствования, изменений и доработок.
Что если посмотреть на всё это чуть шире
Если отойти от конкретных дашбордов и посмотреть на весь путь целиком, видна одна и та же схема — раз за разом.Сначала — Excel и интуиция. Потом — один дашборд, который наводит хоть какой-то порядок. Потом — второй виток, потому что компания выросла быстрее, чем успела вырасти её отчётность. Это не провал первой версии. Это нормальный жизненный цикл аналитики в растущей компании: систему строят под задачи одного размера, а через год у компании уже другой размер.И каждый раз, когда в этой истории всплывал новый очаг хаоса — Сайт, директ, выставки, календарь «Битрикса», спор за лида, — решение никогда не сводилось к «добавить ещё один график». Приходилось сначала понять, где именно живёт хаос. Иногда — в CRM, которая не всегда хранит историю. Иногда — в голове руководителя, который раз в месяц вручную сверяет календарь. Дашборд появлялся уже вторым шагом, после того как находили источник.Аналитика в этой истории не устраняла организационные конфликты — она их обнажала. Пока каждый отдел считал в своём экселе, спор можно было не доводить до конца: у каждого оставалась своя правда, и с ней можно было жить. Общий дашборд такой роскоши не оставляет. Цифра одна, и спорить приходится не про то, чья таблица точнее, а про то, что на самом деле произошло со сделкой. Это неприятный побочный эффект — и одновременно ровно то, ради чего всё затевалось.Ещё один вывод, который стоит проговорить отдельно: не инструмент сделал компанию управляемой, а то, что все согласились считать одинаково. DataLens можно было заменить на Power BI, «Метрику» — на другую систему аналитики. А вот момент, когда маркетинг, продажи и партнёры перестали задавать вопрос «а чьи цифры вернее» — это перешло в организационное стратегическое решение, а не техническое тушение проблемы.И, пожалуй, главное: система аналитики никогда не «доделана» до конца. Она не заканчивается сдачей дашборда — она переходит в рутину, которую нужно поддерживать, докручивать и иногда пересобирать заново, как это и произошло здесь через год. Вопрос не в том, готова ли аналитика. Вопрос в том, готова ли компания каждый раз, когда вырастает, задавать себе неудобные вопросы заново.