Назад
Компании нужен дашборд по продажам, прибыли, остаткам или маржинальности. Но прежде чем на экране появятся графики и показатели, необходимо собрать информацию из CRM, 1С, Excel и других систем, привести ее к единому формату, рассчитать метрики и проверить результаты. Больше всего времени занимает не построение дашборда, а подготовка данных.
Ни одна корпоративная система не хранит всю информацию, которая нужна для управленческой аналитики. Продажи находятся в CRM, финансы — в 1С, производственные показатели — в производственных системах автоматизации, рекламные расходы — в маркетинговых сервисах. Каждая система показывает только свой срез деятельности компании.
Например, рост продаж в CRM еще не означает, что организация стала зарабатывать больше. Чтобы оценить результат, нужно сопоставить продажи с себестоимостью, скидками, расходами и затратами на привлечение клиентов.
Набор данных зависит от задачи анализа:
Проблема в том, что сведения из разных источников не всегда совпадают.
Один и тот же клиент может быть записан в CRM и 1С по-разному, подразделения могут рассчитывать показатели по своим правилам, а информация в системах — обновляться с разной скоростью. Например, CRM уже показывает закрытую сделку, а в 1С еще нет данных об оплате. В итоге один отчет учитывает продажу, а другой — нет.
Чтобы получить достоверную аналитику, компания должна не просто собрать информацию из разных систем, а сопоставить источники, проверить расчеты и подготовить основу для анализа. Иначе отчеты будут показывать разные значения для одних и тех же показателей.
BI-система показывает готовые данные, но не проверяет, насколько корректно они рассчитаны. Если в исходных сведениях есть ошибки, дубли или пропущенная информация, отчет отобразит их так же, как и любые другие значения.
Перед построением дашборда данные необходимо подготовить:
К примеру, прибыль нельзя рассчитать только по сумме продаж. Нужно учитывать себестоимость, скидки, расходы и другие параметры. Если один из них не попадет в отчет, будет некорректен или будет рассчитан по другим правилам, результат окажется неточным.
Отдельная задача — поддержка актуальности данных. Бизнес развивается: появляются новые источники информации, обновляются правила расчета и требования к аналитике. При каждом изменении нужно проверить, как оно влияет на связанные расчеты и отчеты — без автоматизированного процесса такие проверки занимают дополнительное время и усложняют обновление отчетов.
Автоматизация подготовки данных сокращает количество ручных операций: отчеты обновляются регулярно, показатели рассчитываются по единым правилам, а ошибки проще обнаружить.
Когда данные находятся в разных системах, их нужно объединить по единым правилам. На первых этапах компании часто решают эту задачу с помощью привычных инструментов: таблиц, запросов и скриптов.
Например, чтобы сформировать отчет, аналитик выгружает данные из 1С, CRM, рекламных кабинетов и Excel-файлов, а затем объединяет их в одной таблице с помощью ВПР(поиск связанных значений), Power Query или вручную. Но чем больше становится таблиц, тем меньше времени остается на анализ.
Перед каждым обновлением отчета специалист проверяет:
К примеру, при объединении продаж из CRM с финансовыми сведениями из 1С важно сопоставить клиентов, сверить периоды и рассчитать показатели по единым правилам. В противном случае один отчет покажет сделку, а другой — не учтет ее при расчете прибыли.
При большом количестве таблиц аналитик тратит время не на анализ показателей, а на поиск ошибок в выгрузках, формулах и связях между источниками. Кроме того, ручная подготовка часто зависит от знаний конкретного сотрудника: если он уходит в отпуск или увольняется, команде сложно быстро разобраться в логике расчетов и обновить отчет.
Когда источников становится больше, компании автоматизируют обмен информацией между ними. Заказная интеграция — это способ связать разные системы и настроить передачу данных под задачи бизнеса. Как правило, это отдельный проект: сначала собирают требования, затем проектируют решение, разрабатывают и тестируют интеграцию, после чего запускают процесс обмена.
Заказная интеграция связывает системы по заданным сценариям обмена и правилам обработки данных. Однако требования к аналитике меняются постоянно: появляются новые источники, новые показатели, меняются правила расчета, а внешние сервисы обновляют API (интерфейс для обмена данными) и структуру данных. В итоге даже небольшие изменения требуют доработки решения и участия разработчиков.
Это влияет на дальнейшую работу с данными:
При развитии аналитики важно учитывать не только обмен информацией между системами, но и скорость внесения изменений в процесс подготовки данных.
Low-code ETL (Extract, Transform, Load — извлечение, преобразование и загрузка данных) — это подход к подготовке данных, при котором пользователь настраивает обработку через готовые визуальные блоки вместо написания кода для каждой задачи. Такой подход помогает подключать источники, объединять информацию, выполнять расчеты и готовить данные для BI-отчетов и управленческой аналитики.
В визуальном интерфейсе специалист настраивает последовательность операций с помощью отдельных блоков — каждый отвечает за свой этап обработки данных:
Не нужно разрабатывать каждую операцию: достаточно задать параметры и связать готовые элементы в единый процесс, чтобы менять настройки процесса обработки без написания нового кода.
Так, если компании нужно подключить новую CRM, рекламный кабинет или Excel-файл для отчетов, достаточно добавить источник и настроить параметры обработки. Не требуется создавать новую интеграцию или перестраивать весь процесс подготовки информации.
В результате аналитики быстрее подключают источники, проверяют расчеты и добавляют новые показатели в отчеты, а компания меньше зависит от разработчиков при изменении процессов подготовки данных.
Low-code ETL помогает аналитику самостоятельно готовить данные для отчетов и BI-систем. Последовательность действий с данными — от подключения источников до обработки и загрузки — называют пайплайном данных. Он показывает, какие источники участвуют в процессе, какие преобразования выполняются и что передается в витрину или источник данных для BI.
С помощью low-code ETL аналитик:
Приведем пример. В компании из сферы подбора персонала данные из HRM-системы, заявок на подбор и базы резюме можно объединить в один пайплайн. На их основе формируется витрина для BI: руководитель видит воронку найма, сроки закрытия вакансий и KPI рекрутеров, а аналитик может менять правила расчета без отдельного проекта разработки.
Почему BI использует данные из разных систем
Ни одна корпоративная система не хранит всю информацию, которая нужна для управленческой аналитики. Продажи находятся в CRM, финансы — в 1С, производственные показатели — в производственных системах автоматизации, рекламные расходы — в маркетинговых сервисах. Каждая система показывает только свой срез деятельности компании.
Например, рост продаж в CRM еще не означает, что организация стала зарабатывать больше. Чтобы оценить результат, нужно сопоставить продажи с себестоимостью, скидками, расходами и затратами на привлечение клиентов.
Набор данных зависит от задачи анализа:
| Что нужно оценить | Что нужно для расчета |
|---|---|
| Прибыль | продажи, себестоимость, закупки, расходы |
| Маржинальность клиентов и товаров | продажи, себестоимость, скидки |
| Выполнение плана продаж | продажи, остатки, производство |
| Эффективность рекламы | расходы на продвижение, заявки, продажи |
Проблема в том, что сведения из разных источников не всегда совпадают.
Один и тот же клиент может быть записан в CRM и 1С по-разному, подразделения могут рассчитывать показатели по своим правилам, а информация в системах — обновляться с разной скоростью. Например, CRM уже показывает закрытую сделку, а в 1С еще нет данных об оплате. В итоге один отчет учитывает продажу, а другой — нет.
Чтобы получить достоверную аналитику, компания должна не просто собрать информацию из разных систем, а сопоставить источники, проверить расчеты и подготовить основу для анализа. Иначе отчеты будут показывать разные значения для одних и тех же показателей.
Дашборд не заменяет подготовку данных
BI-система показывает готовые данные, но не проверяет, насколько корректно они рассчитаны. Если в исходных сведениях есть ошибки, дубли или пропущенная информация, отчет отобразит их так же, как и любые другие значения.
Перед построением дашборда данные необходимо подготовить:
- определить, какие показатели войдут в расчет;
- настроить правила получения и обновления информации;
- привести справочники к единому виду;
- проверить расчеты и устранить ошибки.
К примеру, прибыль нельзя рассчитать только по сумме продаж. Нужно учитывать себестоимость, скидки, расходы и другие параметры. Если один из них не попадет в отчет, будет некорректен или будет рассчитан по другим правилам, результат окажется неточным.
Отдельная задача — поддержка актуальности данных. Бизнес развивается: появляются новые источники информации, обновляются правила расчета и требования к аналитике. При каждом изменении нужно проверить, как оно влияет на связанные расчеты и отчеты — без автоматизированного процесса такие проверки занимают дополнительное время и усложняют обновление отчетов.
Автоматизация подготовки данных сокращает количество ручных операций: отчеты обновляются регулярно, показатели рассчитываются по единым правилам, а ошибки проще обнаружить.
Что усложняет ручную подготовку данных
Когда данные находятся в разных системах, их нужно объединить по единым правилам. На первых этапах компании часто решают эту задачу с помощью привычных инструментов: таблиц, запросов и скриптов.
Например, чтобы сформировать отчет, аналитик выгружает данные из 1С, CRM, рекламных кабинетов и Excel-файлов, а затем объединяет их в одной таблице с помощью ВПР(поиск связанных значений), Power Query или вручную. Но чем больше становится таблиц, тем меньше времени остается на анализ.
Перед каждым обновлением отчета специалист проверяет:
- совпадают ли форматы дат, названия полей и единицы измерения;
- одинаково ли записаны клиенты, товары и контрагенты в разных источниках;
- нет ли дублей и ошибок в формулах;
- не изменились ли связанные файлы и расчеты;
- не зависит ли подготовка отчета от знаний одного сотрудника.
К примеру, при объединении продаж из CRM с финансовыми сведениями из 1С важно сопоставить клиентов, сверить периоды и рассчитать показатели по единым правилам. В противном случае один отчет покажет сделку, а другой — не учтет ее при расчете прибыли.
При большом количестве таблиц аналитик тратит время не на анализ показателей, а на поиск ошибок в выгрузках, формулах и связях между источниками. Кроме того, ручная подготовка часто зависит от знаний конкретного сотрудника: если он уходит в отпуск или увольняется, команде сложно быстро разобраться в логике расчетов и обновить отчет.
Когда заказная интеграция замедляет аналитику
Когда источников становится больше, компании автоматизируют обмен информацией между ними. Заказная интеграция — это способ связать разные системы и настроить передачу данных под задачи бизнеса. Как правило, это отдельный проект: сначала собирают требования, затем проектируют решение, разрабатывают и тестируют интеграцию, после чего запускают процесс обмена.
Заказная интеграция связывает системы по заданным сценариям обмена и правилам обработки данных. Однако требования к аналитике меняются постоянно: появляются новые источники, новые показатели, меняются правила расчета, а внешние сервисы обновляют API (интерфейс для обмена данными) и структуру данных. В итоге даже небольшие изменения требуют доработки решения и участия разработчиков.
Это влияет на дальнейшую работу с данными:
- Новое подключение или изменение расчета требует участия разработки. Чтобы добавить источник данных, изменить логику обработки или создать новый отчет, нужно поставить задачу, согласовать сроки и дождаться выполнения.
- Логика обработки данных может стать «черным ящиком» для бизнеса. После запуска решение работает, но правила преобразования информации, расчеты и связи между источниками знает только команда разработки. Поэтому при поиске ошибки или изменении логики приходится привлекать разработчиков или интегратора.
-
Источники тоже требуют постоянного контроля. CRM добавляет новые поля, маркетплейсы обновляют API, появляются новые требования к аналитике. Такие изменения необходимо проверять и учитывать в существующем обмене информацией.
При развитии аналитики важно учитывать не только обмен информацией между системами, но и скорость внесения изменений в процесс подготовки данных.
Как работает low-code ETL
Low-code ETL (Extract, Transform, Load — извлечение, преобразование и загрузка данных) — это подход к подготовке данных, при котором пользователь настраивает обработку через готовые визуальные блоки вместо написания кода для каждой задачи. Такой подход помогает подключать источники, объединять информацию, выполнять расчеты и готовить данные для BI-отчетов и управленческой аналитики.
В визуальном интерфейсе специалист настраивает последовательность операций с помощью отдельных блоков — каждый отвечает за свой этап обработки данных:
- подключает источник информации;
- объединяет сведения из разных систем;
- проверяет и очищает данные;
- рассчитывает показатели по заданным правилам;
- передает подготовленные данные в витрину, хранилище или другой источник, который BI-система использует для отчетов.
Не нужно разрабатывать каждую операцию: достаточно задать параметры и связать готовые элементы в единый процесс, чтобы менять настройки процесса обработки без написания нового кода.
Так, если компании нужно подключить новую CRM, рекламный кабинет или Excel-файл для отчетов, достаточно добавить источник и настроить параметры обработки. Не требуется создавать новую интеграцию или перестраивать весь процесс подготовки информации.
В результате аналитики быстрее подключают источники, проверяют расчеты и добавляют новые показатели в отчеты, а компания меньше зависит от разработчиков при изменении процессов подготовки данных.
Где low-code ETL помогает аналитику
Low-code ETL помогает аналитику самостоятельно готовить данные для отчетов и BI-систем. Последовательность действий с данными — от подключения источников до обработки и загрузки — называют пайплайном данных. Он показывает, какие источники участвуют в процессе, какие преобразования выполняются и что передается в витрину или источник данных для BI.
С помощью low-code ETL аналитик:
- Получает сведения из 1С, CRM, Excel-файлов и других источников.
- Объединяет продажи, оплаты и расходы на рекламу для расчета прибыли, ROMI и других показателей.
- Формирует витрины данных для BI-систем, чтобы отчеты рассчитывались по единым правилам.
- Проверяет новые гипотезы без отдельного проекта разработки.
- Меняет правила расчета показателей при изменении требований бизнеса.
- Настраивает автоматическое обновление по расписанию.
- Передает схему подготовки данных другим сотрудникам без потери логики работы.
Приведем пример. В компании из сферы подбора персонала данные из HRM-системы, заявок на подбор и базы резюме можно объединить в один пайплайн. На их основе формируется витрина для BI: руководитель видит воронку найма, сроки закрытия вакансий и KPI рекрутеров, а аналитик может менять правила расчета без отдельного проекта разработки.
