В RuDesktop квартальные планы продаж составляли вручную в таблицах, а затем загружали в аналитическую систему и связывали с текущей воронкой Битрикс24. Выполнение плана можно было смотреть рядом со списком сделок; отдельно выделили карточки, в которых давно не менялась стадия.[1]
Сам по себе план в таблице вполне может устраивать компанию. Сложность появляется в середине квартала: план остался прежним, а сделки уже перенесли, увеличили, проиграли или передали другому менеджеру. Руководителю нужно понять, за счёт чего команда ещё может выполнить обязательства. Для этого приходится сопоставлять план с тем, что происходит в продажах сейчас.
В проекте RuDesktop эта задача появилась на втором этапе развития аналитики — примерно через год после первого запуска.[1] Ниже разберём общую схему такого отчёта. Пример расчёта и предлагаемый состав полей относятся к условной компании; они не воспроизводят точную модель клиента.
План, факт, воронка и прогноз отвечают на разные вопросы
В разговоре о продажах легко назвать фактом любую сумму из CRM. Но у компании может быть несколько разных оснований для выполнения плана: подписанные договоры, отгрузки, поступившие деньги. Каждое отвечает на свой вопрос.
План задаёт целевой результат за период. Факт показывает уже состоявшиеся события, которые компания договорилась учитывать. Воронка содержит текущие сделки с их суммами, стадиями и ожидаемыми сроками. Прогноз оценивает, какая часть этих сделок даст результат к нужной дате.
Различие становится существенным, когда менеджер закрыл продажу в марте, а клиент заплатит в апреле. В квартальном плане по договорам результат уже есть. В плане по поступлению денег он появится позже. Оба отчёта могут быть правильными, хотя показывают разные проценты выполнения.
DataLens показывает подготовленные данные; правило, по которому событие становится фактом, всё равно придётся определить людям. Даже готовое подключение к Битрикс24 само по себе лишь отображает данные CRM.[2]
Сначала договориться, что означает строка плана
Для начала достаточно взять действующую таблицу и разобрать одну строку: кому поставлен план, на какой период, по какому показателю и в какой сумме. Часто уже здесь выясняется, что у разных руководителей разные представления об одном столбце.
Для общей модели обычно нужны:
- период, к которому относится план;
- менеджер, отдел или другое подразделение;
- показатель: договоры, отгрузки, оплаты либо иной согласованный результат;
- плановая сумма и единица измерения;
- версия плана и ответственный за её утверждение.
Если план разбит по продуктам или каналам, эти признаки тоже должны совпадать с тем, как устроены фактические данные. Имена менеджеров лучше связывать через устойчивый идентификатор: написание фамилии в таблице может отличаться от CRM, а сотрудник может сменить отдел.
Пересмотр плана внутри квартала требует отдельного решения. Если просто заменить старое число новым, позднее будет трудно объяснить, почему процент выполнения изменился без новых продаж. Можно хранить исходный и пересмотренный планы, указав дату и причину изменения.
Что брать из Битрикс24 и когда понадобится 1С
Из CRM для такого отчёта могут понадобиться идентификатор сделки, ответственный, сумма, стадия, дата создания и ожидаемая дата завершения. Полезны сведения о следующем действии и сроках движения по стадиям — если они доступны и действительно заполняются.
Состав выгрузки определяется вопросом руководителя. Для контроля договоров могут подойти сведения CRM. Если план считают по поступившим деньгам, нужен источник фактических оплат: например, 1С. Тогда придётся установить, как платёж связан со сделкой, что делать с частичной оплатой, возвратом или одним платежом по нескольким заказам. По одной отметке «успешно» в CRM этого не узнать.
Есть и менее заметная ошибка: квартальный план менеджера записан одной строкой, а сделок у него десятки. Если при объединении данных повторить сумму плана возле каждой сделки и затем сложить её, отчёт завысит цель. План и сделки хранятся с разной подробностью; при расчёте нужно сохранить это различие.
Для учебной модели с планом по оплатам можно разделить данные так:
| Набор | Что означает одна строка | Что проверить |
|---|---|---|
| План | Квартал, менеджер, показатель и версия плана | На это сочетание приходится одна плановая сумма |
| Факт | Часть платежа, отнесённая к конкретной сделке | Есть идентификатор платежа, дата и распределённая сумма; один платёж не посчитан несколько раз |
| Воронка | Одна текущая сделка | Сумма договора не подменяет неоплаченный остаток или ожидаемое поступление |
| Ожидание | Ещё не полученная часть платежа по сделке | Указаны ожидаемая дата, основание оценки и дата проверки |
Сначала стоит отдельно получить итоги плана, оплат и ожиданий за один квартал по одному менеджеру. Затем сопоставить их и проверить детализацию: сумма платежей должна сходиться с фактом, сумма ожидаемых поступлений — с прогнозной добавкой. При переходе к сделкам квартальный план не должен умножаться на число строк. Если отчёт нужен по продуктам, это распределение придётся определить и для плана, и для факта.
Сам способ объединения тоже нужно выбрать заранее. В DataLens нельзя объединить разные источники внутри одного датасета; доступны другие варианты связи данных, в том числе на уровне чарта или селекторов.[3] Поэтому наличие таблицы плана, подключения CRM и данных 1С ещё не означает, что их получится просто соединить перетаскиванием. Для выбранной модели может понадобиться предварительная подготовка в общем источнике. Техническая схема загрузок RuDesktop здесь не описывается.
Другие случаи, когда суммы CRM приходится сопоставлять с учётом и операционными данными, разобраны в статье «В Битрикс24 план выполнен. Почему бизнес всё равно недоволен?».
Почему большая воронка ещё не обещает выполнения плана
Возьмём условную компанию: все числа в этом расчёте учебные и не относятся к RuDesktop. План поступления денег за квартал — 10 млн рублей. Получено 4 млн, а открытых сделок в CRM числится на 12 млн.
Выполнение плана по оплатам составляет 40%. Сумма открытых сделок больше оставшихся 6 млн, но из этого ещё не следует, что квартал закончится успешно. Часть покупателей может перенести решение, часть сделок предполагает оплату уже в следующем периоде.
Допустим, руководитель проверил сделки и выделил ожидаемые поступления ещё на 3 млн до конца квартала. Это только будущие платежи: уже полученные суммы в них не входят, а при частичной оплате учитывается ожидаемая неоплаченная часть. Получается сценарий на 7 млн, или 70% плана. Эти 3 млн нужно показывать отдельно от полученных 4 млн, сохраняя основание оценки и дату её пересмотра. Это сценарий при принятых допущениях, а не гарантированный итог.
Прогноз становится полезнее, когда можно открыть конкретную сделку и понять, почему её включили. Одна сумма с подписью «ожидается» такого разговора не выдерживает.
Как устроить экран для разговора о сделках
На верхнем уровне нужны план, факт и оставшаяся сумма. Рядом можно показать прогноз до конца периода, явно указав способ его получения. Дальше руководитель выбирает отдел или менеджера и переходит к сделкам: сумма, стадия, ожидаемый срок, последнее изменение, следующее действие.
Пример экрана план-факта в опубликованном кейсе RuDesktop показывает план и фактическую выручку по менеджерам. Это демонстрационный экран: названия и суммы синтетические, клиентские данные не показаны.[1] Показатель на нём нельзя автоматически приравнивать к поступлениям денег из учебного расчёта выше.
Список сделок без недавнего изменения стадии даёт повод проверить ситуацию. Долгая пауза может быть нормальной для закупочной процедуры, а может означать, что менеджер давно не обновлял карточку. По одной дате различить эти случаи невозможно.
У отчёта поэтому должен быть человек, который отвечает за актуальность плана и принятые определения показателей. Менеджеры поддерживают сведения о сделках, руководитель разбирает отклонения. Без этой работы даже правильно собранный DataLens постепенно начнёт показывать прошлые ожидания команды.
С какого отчёта начать
Если квартальный план уже есть, а к каждой встрече его приходится заново сводить с Битрикс24, можно начать с одного отдела и одного показателя. На первом обсуждении разберём текущую таблицу, источник факта и вопросы, на которые должен отвечать отчёт. По этому объёму можно оценить состав работ, сроки и стоимость.
Обсудить план-факт на ваших данных.
Источники
[1] Кейс RuDesktop — ручной квартальный план, текущие сделки и синтетические демонстрационные экраны.
[2] Создание подключения к Битрикс24 — официальная документация Yandex DataLens.
[3] Объединение данных Yandex DataLens — доступные способы и ограничения связи источников.