Панель показателей вместо разрозненных отчётов: как она собирается
Панель показателей - один экран, на котором собраны ключевые цифры отдела или бизнеса из нескольких систем: CRM, телефонии, учётной системы и рекламы. Каждая цифра на ней посчитана по заранее согласованной формуле и отмечена статусом «норма» или «риск», поэтому руководитель не сводит отчёты руками, а сразу видит, где вмешаться.
Без панели цифры отдела продаж живут в разных местах: сделки и этапы - в CRM, звонки - в телефонии, счета и оплаты - в 1С, расходы - в рекламных кабинетах. Руководитель открывает четыре отчёта, сводит их в таблицу и к пятнице получает картину, в которой выручка из CRM не совпадает с бухгалтерией. Ниже - не о том, какие плитки поставить на экран, а о том, что лежит под ним: откуда приходит каждая цифра, по какому ключу сводятся сделка, звонок и оплата, что можно посчитать в самой CRM, где хранится порог и почему панель иногда врёт.
Панель показателей и набор отчётов: в чём разница
Отчёт отвечает на один вопрос по данным одной системы: сколько сделок на этапе, сколько звонков пропущено, сколько оплат пришло за неделю. Панель показателей отвечает на вопрос руководителя целиком - например, «почему в этом месяце выручка ниже плана» - и для этого берёт цифры из нескольких систем сразу. Отличий три.
- Один экран вместо нескольких отчётов. Руководитель не переключается между CRM, кабинетом телефонии и выгрузкой из 1С.
- Единые формулы. «Конверсия» на панели посчитана одним способом для всех менеджеров и всех периодов, и этот способ записан.
- Сведённые источники. Сделка из CRM, звонок из телефонии и оплата из учётной системы связаны между собой, а не лежат рядом тремя несвязанными числами.
Набор показателей собирается под задачи конкретного руководителя, а не «всё, что есть в системе». Показатель нужен на панели, только если по нему принимают решение: заранее понятно, что делать, когда цифра ушла в риск. Какие метрики обычно смотрит руководитель продаж, разобрано в статье «Какие метрики продаж стоит отслеживать руководителю каждую неделю». Что ставить на экран руководителя отдела продаж, кто задаёт пороги и как читать сигнальные цвета - в материале «Панель РОПа: что должно быть на одном экране». Здесь речь об устройстве панели под экраном.
Это устройство удобно представить слоями. Внизу источники. Над ними общее хранилище, где записи из разных систем связаны общими ключами. Выше - слой расчёта: формулы из словаря показателей и пороги. Экран - только верхний слой, и он показывает ровно то, что посчитано ниже. Если нижние слои не собраны, экран не поможет: панель полезна только на достоверных данных.
Из каких систем собирается панель: CRM, телефония, 1С, реклама
Типичная панель отдела продаж берёт данные из четырёх систем. У каждой своя зона ответственности, свои идентификаторы записей и свой ритм обновления. Таблица ниже - условный пример для компании, которая продаёт через менеджеров и выставляет счета в 1С.
| Источник | Какие показатели даёт | Общий ключ для сведения | Как обновляется |
|---|---|---|---|
| CRM | Заявки, сделки по этапам, суммы в работе, причины отказов, просроченные задачи | ID сделки, ID контакта, телефон | Экраны CRM пересчитываются по мере работы |
| Телефония | Входящие и исходящие звонки, пропущенные, время до перезвона | Номер телефона, привязка звонка к карточке | После передачи данных от телефонии в CRM |
| Учётная система (1С) | Счета, оплаты, отгрузки, возвраты | Номер счёта, ID сделки в поле документа, ИНН контрагента | По расписанию выгрузки |
| Рекламные кабинеты и аналитика сайта | Расходы, заявки по каналам | Метка источника, ID заявки | По расписанию выгрузки |
Самое важное в таблице - третья колонка. Чтобы на панели появилась «конверсия заявки в оплату», заявка, сделка и оплата должны быть связаны одним ключом. Если в 1С счёт выставлен на компанию, а в CRM сделка заведена на контактное лицо без ИНН и без номера счёта, оплату не к чему привязать: в бухгалтерии она есть, а на панели её нет. Какая система главная и как записи переносятся между ними, разобрано в статье «Сквозной обмен данными между CRM, сайтом и учётной системой». Для панели достаточно, чтобы ключи сопоставления были выбраны заранее и заполнялись всегда, а не «когда менеджер вспомнит».
Здесь же проходит ограничение, о котором редко пишут в обзорах BI-сервисов: Яндекс DataLens сам источники в одном наборе данных не сводит. В его документации прямо сказано, что объединить данные из разных источников на уровне одного набора данных нельзя. Таблицы связывают внутри одного подключения, а разные подключения соединяют уже на уровне отдельного графика или экрана. Поэтому, если оплата из 1С и сделка из CRM должны оказаться в одной строке, их сводят заранее: в общем хранилище (базе данных, куда по расписанию выгружаются оба источника) или в подготовленной таблице. Общий ключ и хранилище проектируют до того, как рисуют экран.
Внутри одного подключения связка тоже требует внимания. DataLens предлагает связь таблиц автоматически, по первому совпадению имени и типа поля, и такую связь надо проверять: одинаковое название ещё не значит, что в полях лежит одно и то же. Звонки и оплаты в общую картину приходят через интеграцию телефонии и интеграцию с 1С. Реклама на панели - ещё один источник цифр; как связать рекламный канал с оплатой на уровне пути клиента, разобрано в статье о сквозной аналитике для отдела продаж.
Что считать в самой CRM, а что во внешнем инструменте
Граница проходит по задаче. Пока вопрос касается данных одной системы, его разумно решать в CRM: штатные отчёты уже знают этапы, менеджеров и даты, их не нужно собирать заново. Когда нужно объединить источники, считать нестандартные формулы или хранить пороги руководителя, нужен внешний слой.
| Задача | Где делать | Ограничение |
|---|---|---|
| Сделки по этапам, конверсия воронки, нагрузка менеджеров | В отчётах CRM | Формулы задаёт система, своя формула возможна не всегда |
| Звонки по менеджерам | В CRM, если звонки привязаны к карточкам | В аналитику amoCRM попадают только звонки, привязанные к карточкам |
| Сделки вместе с оплатами из 1С | Во внешнем инструменте или во встроенном BI-слое CRM на старших тарифах | Нужен общий ключ и место, где записи соединяются |
| Расходы на рекламу против оплат | Во внешнем инструменте или в сквозной аналитике | Нужна единая метка источника от заявки до оплаты |
| Статус «норма/риск» по порогам руководителя | В слое расчёта внешнего инструмента | Порог хранится как данные, а не вписывается в формулу числом |
amoCRM. Штатно здесь сводится только то, что лежит в самой amoCRM. Рабочий стол собирается из фильтров по данным системы: число, диаграмма, список, график по времени. Есть «собственный виджет» - внешняя страница, которую показывают на рабочем столе по ссылке, но считать для неё цифры нужно где-то снаружи. Экспорт аналитики, по справке amoCRM, пока недоступен, а готового подключения amoCRM в списке источников DataLens нет. Значит, для панели из нескольких систем нужен промежуточный слой: данные выгружаются в хранилище через интерфейс программирования (API) - канал, по которому программы обмениваются данными. У этого канала есть лимиты: не больше 7 запросов в секунду на интеграцию и 50 на аккаунт, большинство методов отдаёт до 250 записей за запрос, при повторных превышениях аккаунт блокируется. Поэтому выгрузку проектируют с запасом по лимитам. На рынке есть и сторонние коннекторы, их надёжность и частоту обновления оценивают отдельно. Подробнее - в статье «Почему стандартных отчётов amoCRM обычно недостаточно руководителю».
Битрикс24. Здесь путь ступенчатый, и каждая ступень привязана к тарифу. CRM-аналитика - воронка, динамика, эффективность менеджеров - есть с «Базового», с лимитом 100 000 элементов для построения отчётов на «Базовом», «Стандартном» и «Профессиональном». Встроенный BI Конструктор по данным портала появляется со «Стандартного», данные в нём обновляются раз в час. Внешние источники - 1С, рекламные кабинеты, CSV-файлы - подключаются в BI Конструкторе с «Профессионального», базы MySQL и PostgreSQL - только в «Энтерпрайз». Данные 1С туда передаёт модуль на сервере 1С: по справке он рассчитан на небольшие объёмы и коробочную 1С, а типы колонок после загрузки не меняются. Не путайте его с коннектором к 1С в самой CRM: тот есть с «Базового», но отвечает за обмен данными, а не за аналитику. Как читать штатные отчёты, разобрано в статье «Отчёты и аналитика в Битрикс24 для руководителя отдела продаж».
| Ступень | amoCRM | Битрикс24 |
|---|---|---|
| Отчёты внутри CRM | Рабочий стол и отчёты только по данным amoCRM, экспорта аналитики нет | CRM-аналитика с «Базового», лимит 100 000 элементов для отчётов |
| Встроенный BI-слой | Отдельного BI-слоя с внешними источниками не предусмотрено: конструктор отчётов строит виджеты только по данным amoCRM, «собственный виджет» показывает внешнюю страницу по ссылке | BI Конструктор со «Стандартного», обновление данных раз в час |
| Внешние источники (1С, реклама) | Через выгрузку по API в своё хранилище или сторонний коннектор | В BI Конструкторе с «Профессионального»; MySQL и PostgreSQL - в «Энтерпрайз» |
| Подключение к DataLens | Готового подключения в списке источников нет | Есть партнёрское подключение «Битрикс24» |
Условия меняются - перед работой сверяйте со справкой разработчика. Какой внешний сервис выбрать, здесь не сравниваем: критерии выбора - в статье «DataLens и AW BI для отдела продаж». Для устройства панели важнее другое: любой сервис покажет только то, что сведено и посчитано ниже экрана.
Словарь показателей: договориться о формулах до сборки
Самая частая причина, по которой панели перестают доверять, не техническая. Руководитель продаж и бухгалтерия называют «продажей» разное: один - успешную сделку, другая - поступление денег. Пока это не записано, две правильные цифры спорят друг с другом, и обе стороны правы. Словарь показателей фиксирует для каждой цифры на панели четыре вещи:
- формулу - что делим на что и какие записи исключаем (дубли, спам, тестовые сделки);
- источник - из какой системы и какого поля берётся каждое слагаемое;
- дату отнесения - по какой дате цифра попадает в период: создание заявки, выставление счёта или оплата;
- владельца - кто отвечает за формулу и за то, чтобы данные под ней были полными.
| Показатель | Формула | Источник | Дата отнесения | Владелец |
|---|---|---|---|---|
| Выручка за период | Сумма оплат по счетам, связанным со сделками отдела продаж | 1С: оплаты; CRM: ID сделки в счёте | Дата поступления оплаты | Руководитель отдела продаж вместе с бухгалтером |
| Конверсия заявки в оплату | Заявки, дошедшие до оплаты, делённые на все заявки периода без дублей и спама | CRM: заявки; 1С: оплаты | Дата создания заявки | Руководитель отдела продаж |
Обратите внимание на вторую строку: заявку относят к месяцу, когда она пришла, даже если оплата случилась позже. Если этого не записать, конверсия прошлого месяца будет «расти» задним числом, и на совещании это выглядит как ошибка панели. Полная форма паспорта одного показателя с полями и примером заполнения - в статье «План-факт по продажам в CRM», а как не перегрузить набор показателей менеджеров - в материале о KPI отдела продаж. Словарь согласуют до сборки: переделывать формулу на готовой панели сложнее, чем записать её заранее.
Статус «норма/риск»: где хранится порог и где он считается
Статус на панели появляется из двух чисел: факта и порога. Факт приходит из хранилища, порог задаёт руководитель. Технически важно, где порог живёт. Если вписать его прямо в формулу графика, через полгода никто не вспомнит, почему риск начинается с 20 %, а поменять его сможет только тот, кто собирал панель. Надёжнее хранить порог как данные: отдельная таблица «показатель - порог - кто утвердил - с какой даты действует», а статус считает слой расчёта.
В штатных отчётах CRM такой механики нет. В amoCRM статус цветом по плану есть у «Целей»: зелёный или красный считается по выполнению цели, а не по порогам, которые руководитель задаёт к любому показателю. Во внешнем BI-сервисе статус - обычное вычисляемое поле. В DataLens для этого есть функция IF, которая проверяет условия по очереди и возвращает результат первого выполненного. В условном примере формула выглядит как IF [факт] < [порог] THEN "риск" ELSE "норма" END, где порог приходит из таблицы порогов, а не вписан числом. Кто устанавливает пороги и как читать сигнальные цвета на экране, разобрано в упомянутой выше статье о панели РОПа.
Почему панель врёт: расхождения между системами и грязные данные
Панель, собранная из нескольких систем, наследует ошибки каждой из них. Ниже пять частых причин расхождений.
| Причина | Как проявляется | Где проверить |
|---|---|---|
| Разные даты | CRM считает продажу по дате закрытия сделки, 1С - по дате оплаты; месяц на панели не совпадает с бухгалтерией | Словарь показателей: какая дата отнесения записана |
| Дубли | Один клиент заведён дважды, заявки удваиваются, конверсия падает | Правила поиска дублей при создании записи в CRM |
| Пустые поля | У части сделок нет источника или номера счёта, оплата ни к чему не привязывается | Доля пустых ключевых полей за период |
| Разная свежесть | Сделки уже обновились, а оплаты придут со следующей выгрузкой | Время последнего обновления у каждого источника |
| Разные отчёты одной системы | В amoCRM «Отчёт по сотрудникам» учитывает сделки, созданные пользователем, а «Анализ продаж» - ещё и переданные ему | Справка по отчёту: что именно в него попадает |
Отдельно о свежести. Панель «в реальном времени» не бывает: свежесть - свойство каждого источника, а не экрана. Экраны CRM пересчитываются по мере работы. BI Конструктор Битрикс24 держит данные в кеше час с первого открытия отчёта: в примере из справки сделка, созданная в 14:10, появится в отчёте в 15:00, при этом есть ручное обновление. В DataLens кеш подключения к базе данных по умолчанию 5 минут, его можно увеличить до суток. Звонки в аналитике amoCRM обновляются после того, как телефония передала данные. Выгрузка из 1С идёт по тому расписанию, которое настроили. Поэтому у каждого блока панели полезна подпись «данные на такое-то время», а в словаре - ожидаемый ритм обновления источника.
Механика грязных данных подробно разобрана в статьях «Почему цифры в CRM, рекламе и учётной системе расходятся между собой» и «Аналитика без чистых данных не работает». Принцип короткий: красивая панель не исправляет недостоверные данные, она лишь делает ошибку убедительнее.
Порядок сборки: от вопросов к экрану
Панель собирают снизу вверх, хотя обсуждать её хочется с экрана. Последовательность ниже держит работу в правильном порядке.
- Вопросы. Записать вопросы, на которые руководитель хочет отвечать по панели, и решения, которые он будет принимать по ответам.
- Показатели. Для каждого вопроса выбрать один-два показателя. Показатель без решения за ним на панель не идёт.
- Словарь. Для каждого показателя записать формулу, источник, дату отнесения, владельца и порог.
- Источники и ключи. Для каждого слагаемого указать систему, поле и общий ключ. Решить, где записи сводятся: в отчётах CRM, во встроенном BI-слое CRM или во внешнем хранилище.
- Проверка данных. Посмотреть долю пустых ключевых полей, дубли и расхождение сумм с первичными документами на выборке. Если ключи не заполняются, сначала наводят порядок в правилах работы в CRM, потом строят панель.
- Прототип на реальных цифрах. Не на тестовых данных: пробелы в ключах и датах видны только на настоящих записях.
- Приёмка сверкой. Цифры панели за закрытый период сверяют с первичкой и бухгалтерией. Каждое расхождение либо объяснено и записано в словарь, либо исправлено в источнике.
- Ритм пересмотра. Договориться, кто и когда пересматривает пороги и состав показателей и что делать, если источник перестал обновляться.
Первые пять шагов не требуют BI-сервиса и выполняются до выбора инструмента. Если на четвёртом шаге выясняется, что нужного обмена между системами нет, его проектируют отдельно: оцениваем обмен, проверяем готовые решения для интеграции и только при необходимости делаем индивидуальную. Идея единой панели управления бизнесом складывается так же, по шагам: сначала панель продаж на проверенных данных, затем следующие источники, когда по ним действительно принимают решения.
Частые вопросы
Чем панель показателей отличается от отчёта в CRM?
Отчёт показывает данные одной системы по её правилам. Панель собирает цифры нескольких систем, считает их по согласованным формулам из словаря и показывает статус «норма» или «риск» по порогам руководителя.
Можно ли собрать панель показателей только средствами amoCRM или Битрикс24?
Если все нужные данные лежат в CRM, во многом да. В amoCRM штатно сводится только то, что есть в amoCRM. В Битрикс24 внешние источники в BI Конструкторе доступны с «Профессионального» тарифа. Для данных из нескольких систем нужен слой, где записи соединяются по общему ключу.
Как свести на одной панели данные CRM и 1С, если сделки и оплаты живут в разных системах?
Нужны общий ключ (ID сделки в документе 1С, номер счёта или ИНН) и место, где записи соединяются: общее хранилище или BI-слой, который умеет принимать данные 1С. DataLens, например, разные подключения в один набор данных не объединяет.
Сколько показателей ставить на одну панель?
Столько, по скольким принимают решения. Универсального числа нет: если по показателю никто не действует, когда он уходит в риск, его место в отчёте, а не на панели.
Как часто должна обновляться панель и почему цифры в разных блоках могут быть «из разного времени»?
Каждый источник обновляется в своём ритме: экраны CRM - по мере работы, BI Конструктор Битрикс24 - с кешем на час, выгрузка из 1С - по расписанию. Ритм выбирают по тому, как часто принимают решения, а подпись «данные на такое-то время» у каждого блока снимает вопрос о расхождении.
Кто должен отвечать за панель после запуска: РОП, маркетолог или подрядчик?
Ответственность делят по слоям. За формулу отвечает владелец показателя из словаря, за полноту данных в CRM - руководитель отдела продаж, за работу выгрузок и хранилища - тот, кто их сопровождает: своя команда или подрядчик. Главное, чтобы роли были записаны.
Что делать, если цифры на панели не совпадают с бухгалтерией?
Сначала сравнить дату отнесения и формулу в словаре, затем проверить пустые ключи и дубли на выборке за закрытый месяц. Если расхождение объяснимо, его фиксируют в словаре. Если нет, исправляют источник, а не экран.
Вывод
Панель показателей - это не экран, а четыре слоя под ним: источники, хранилище с общими ключами, слой расчёта с формулами и порогами и только потом экран. CRM хорошо считает свои данные. Как только на панели нужны оплаты из 1С, звонки и реклама, нужно место, где записи соединяются, и словарь, который объясняет каждую цифру. Свежесть у каждого источника своя, а доверие к панели появляется после сверки с первичкой.
До сборки стоит договориться о словаре показателей и проверить данные: это задача диагностики, которая показывает, заполняются ли ключи и где цифры расходятся уже сейчас. Сборка панели и её развитие входят в направление «Аналитика и управление по цифрам».
Источники
- Яндекс DataLens: объединение данных из разных источников
- Яндекс DataLens: модель данных и связи таблиц
- Яндекс DataLens: типы подключений
- Яндекс DataLens: кеширование
- Яндекс DataLens: функция IF
- amoCRM: блоки рабочего стола
- amoCRM: настройка элементов рабочего стола
- amoCRM: вопросы по аналитике
- amoCRM: аналитика звонков
- amoCRM: цели
- amoCRM: ограничения интерфейса программирования (API)
- amoCRM: тарифы
- Битрикс24: сравнение тарифов
- Битрикс24: ограничения CRM-аналитики
- Битрикс24: данные из 1С в BI Конструкторе
- Битрикс24: обновление данных в BI Конструкторе
Сквозная аналитика и управление по цифрам — как мы помогаем с этим на практике.
Читайте также
Термины из статьи
Поможем навести порядок в продажах
Начнём с диагностики: покажем, где теряются заявки и что даст CRM именно в вашем случае — без обещаний «роста в разы».
