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

Коротко

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

• Начинайте с бизнес-решения, а не со списка графиков.
• Зафиксируйте владельца каждой ключевой метрики.
• Разделяйте источник данных, расчёт и визуальный слой.
• Соберите MVP на одном процессе и проверьте, пользуются ли им.
• Добавьте контроль качества и дату последнего обновления.

Шаг 1. Назвать решения, которые должна поддержать аналитика

Фраза «хотим видеть всё» не помогает определить объём работ. Спросите, какие решения повторяются каждую неделю: сколько закупать, какой канал масштабировать, где теряются заявки, какие клиенты рискуют уйти, почему выросли возвраты. У каждого решения есть пользователь, периодичность, допустимая задержка и действие после сигнала.

На старте лучше выбрать один контур. Например, для интернет-магазина это может быть контроль воронки от визита до оплаты и причин отмены. Для сервисного бизнеса — очередь лидов, скорость ответа и конверсия по менеджерам. Для SaaS — новые аккаунты, activation, MRR и churn. Это не ограничивает будущую платформу, а помогает проверить, что аналитика действительно меняет работу.

Шаг 2. Провести аудит источников

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

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

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

Шаг 3. Создать словарь метрик

Словарь метрик — это не формальный документ ради документа. Он предотвращает ситуацию, когда два отчёта используют одинаковое слово «выручка», но один показывает gross, второй net, а третий только оплаченные заказы. Для каждой метрики зафиксируйте определение, формулу, зерно, фильтры, период, источник, owner и дату изменения.

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

Шаг 4. Собрать минимальный слой данных

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

Для MVP часто достаточно понятных витрин: orders, customers, marketing_spend, support_tickets или events. Каждая витрина должна иметь документированное зерно и несколько контрольных полей. Сырые источники сохраняйте отдельно, чтобы можно было объяснить, откуда взялось число и когда оно изменилось.

Шаг 5. Запустить один рабочий дашборд

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

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

• Верхний слой: 3–5 KPI и явный период.
• Диагностика: разрез по сегменту, каналу, продукту или менеджеру.
• Действие: ссылка на список объектов или следующий процесс.
• Контекст: дата обновления, фильтры и ограничение данных.
• Контроль: ссылка на методологию и сверку.

Шаг 6. Назначить процесс после запуска

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

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

Из 10 000 лидов до денег доходят 410, и три отдела называют три разные конверсии

Контур сервисного бизнеса из первого шага — очередь лидов, скорость ответа и конверсия по менеджерам — выглядит простым, пока его не сведёте в одну таблицу. За квартал компания получила 10 000 обращений, провела 2 800 встреч, подписала 620 договоров и получила деньги по 410 из них. Маркетинг докладывает конверсию 28%, продажи — 22,1%, финансы называют 410 оплат. Все три числа посчитаны правильно, и ни одно из них не является конверсией воронки: она равна 410 / 10 000 = 4,1%, и проверяется произведением 0,28 × 0,221 × 0,661.

Первое, что ломает такую таблицу, — разное зерно на каждом уровне. Лид это обращение, сделка это договор, оплата это платёж. Один клиент способен оставить три заявки, подписать один договор и заплатить двумя платежами: аванс и остаток. Если считать «оплаты / лиды» прямо на сырых таблицах, в числителе окажутся платежи, в знаменателе обращения, и результат не будет означать ничего. Каждый уровень сводится к своему зерну до соединения — так же, как витрины из четвёртого шага.

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

Третье — период режет когорты. Медианный путь от обращения до денег здесь 45 дней, а у 210 подписанных договоров оплаты ещё нет. Часть из них подписана в последние три недели квартала и просто не дошла до счёта. Если делить оплаты квартала на лиды квартала, каждый свежий месяц выглядит провалом. Честный расчёт берёт когорту по дате обращения и фиксированное окно наблюдения: 90 дней для всех каналов, включая те, где цикл короче.

В разрезе по каналам видно, почему спор «лиды против сделок» неразрешим на верхнем уровне. Реферальные обращения дают 9% объёма и 35% выручки, контекст — 42% объёма и 29% выручки. Средний чек во всех каналах около 120 000 рублей, так что разница целиком в конверсии и сроке. Вебинары и исходящие письма отстают не только конверсией: при окне 30 дней они выглядят мёртвыми, потому что их медиана 61 и 74 дня, и половина оплат просто не попала в окно.

Последнее, что стоит зафиксировать до дашборда, — правило атрибуции. First touch отдаёт оплату первому каналу, last touch — последнему, и доля реферальных в выручке меняется на несколько процентных пунктов при смене правила. Сам выбор менее важен, чем то, что он записан и подписан под таблицей: иначе на каждой встрече обсуждается не результат, а версия расчёта. И только после этого разговор про бюджет становится содержательным: 210 неоплаченных договоров нужно разобрать до того, как кто-то перераспределит деньги между каналами.

Воронку считает CRM, а заполняют её руками: 28% сделок не годятся для отчёта

Прежде чем объяснять 210 неоплаченных договоров рыночными причинами, стоит посмотреть на сами записи. Выгрузите 2 800 сделок квартала и разложите их на четыре группы. В типичной CRM сервисной компании получается так: 2 016 сделок (72%) заполнены полностью, 392 (14%) без обязательного поля, 252 (9%) не обновлялись больше 30 дней, 140 (5%) — вторые карточки того же клиента. Это не общая оценка «CRM ведётся плохо», а четыре дефекта с разными последствиями для отчёта.

Дубликаты портят меньше, чем кажется, и не там, где кажется. Если реальных сделок 2 660, конверсия в оплату равна 15,4%, а не 14,6% — расхождение 0,8 процентного пункта, на решение оно не влияет. Хуже то, что история клиента разъезжается по двум карточкам: первая встреча записана в одной, оплата в другой, и медианный срок цикла считается по обрезкам. Дедупликация по телефону и домену рабочей почты в момент создания карточки обходится дешевле, чем склейка руками раз в квартал.

Пропущенные поля ломают не конверсию, а разбор причин. Статус у этих 392 сделок есть, поэтому воронка собирается и выглядит правдоподобно. Но из 180 проигранных за квартал причина проигрыша заполнена у 96, и любой вывод вида «мы теряем из-за цены» опирается на половину случаев, причём на ту половину, где менеджер не поленился написать. Лечится это не напоминаниями, а обязательностью поля на переходе статуса: заполнять сумму и причину при создании карточки незачем, при закрытии — обязательно.

Зависшие сделки превращаются в деньги, которых нет. 252 карточки без активности дольше месяца при среднем чеке 120 000 рублей дают 30,2 млн рублей пайплайна, который руководитель читает как будущую выручку. Правило здесь простое и непопулярное: после N дней без активности сделка уходит в отдельный статус и в прогноз не попадает, пока менеджер не подтвердит, что она жива. Прогноз, построенный на живой части пайплайна, ниже, но по нему можно планировать найм.

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

Два правила, которые легко нарушить по дороге. Нельзя оценивать менеджера по данным из CRM, которую он же заполняет вручную: оценка немедленно улучшает заполнение, а не продажи. И нельзя поднимать процент заполненности удалением старых сделок — доля вырастет, а история цикла исчезнет вместе с ними. Порядок работ обратный привычному: сначала правило ввода и дедупликация на создании, потом обязательные поля на переходах, потом автоматический отчёт о дефектах владельцу процесса, и только потом KPI, посчитанные по этим данным. В четвёртом шаге сказано, что BI не исправляет ввод данных; здесь к этому добавляется цена вопроса — 30,2 млн фантомного пайплайна и половина проигрышей без объяснения.

План на первые 30 дней

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

Такой порядок помогает не перепутать активность с прогрессом. Количество графиков, подключённых таблиц и часов в BI не говорит, стала ли компания лучше принимать решения. Сигналом прогресса является конкретное решение, которое теперь принимается быстрее и с понятным уровнем доверия.