Перед загрузкой данных в BI важно убедиться, что им можно доверять. Если в исходных данных есть ошибки, пропуски, дубли или разные правила расчёта показателей, эти проблемы попадут в витрины и отчеты.
Особенно это важно по мере роста бизнеса. Небольшой компанией ещё можно во многом управлять «на ощущениях», но с появлением новых сотрудников, подразделений и уровней управления руководителю всё больше приходится опираться на измеримые показатели. И если данные для них недостоверны, решения тоже будут строиться на неверной картине бизнеса.
Привести в порядок сразу все данные компании практически невозможно. Поэтому начинать лучше с одного вопроса, на который должен ответить будущий отчёт, — он сужает объём работы до нескольких показателей.
Дальше эти показатели стоит проверить по пяти пунктам.
Например, руководитель производства хочет понять, почему одна смена выпускает 10 тысяч единиц продукции, а другая — 8 тысяч. Для этого недостаточно сравнить только объём выпуска. Понадобятся данные о времени работы линии, простоях, скорости оборудования и количестве брака.
После этого нужно определить, где фиксируется каждый показатель. Выпуск может учитываться в 1С или MES-системе, простои — в журнале оператора, а брак — в отдельной Excel-таблице. Может оказаться, что часть необходимых данных компания вообще не собирает.
Тогда сначала нужно организовать их регистрацию: установить датчики, внедрить штрихкодирование, добавить обязательное поле в рабочую систему или предусмотреть другой способ фиксации операции. Иначе BI покажет отклонение, но не поможет понять его причину.
Когда компания определила, какие данные ей нужны и где они фиксируются, следующий шаг — проверить, как эта информация передаётся из источников в аналитическую систему.
Один из основных источников ошибок — ручной ввод и перенос информации.
Причём проблема не ограничивается техническими ошибками. Чем больше людей участвует в подготовке и передаче цифр, тем выше риск получить данные с опозданием, потерять часть информации или по-разному интерпретировать её на разных уровнях управления.
Например, сотрудник выгружает данные из 1С, копирует их в Excel, объединяет с таблицей другого подразделения и направляет итоговый файл руководителю. На каждом этапе можно пропустить строку, перепутать столбцы, неверно перенести значение — вариантов ошибок масса.
Чем больше людей участвует в подготовке и передаче цифр, тем выше риск ошибок, задержек и потери информации.
Снизить количество таких ошибок помогает автоматизация ввода и передачи данных. Для этого используют коннекторы — программные модули, которые подключаются к 1С, CRM, базе данных или другой системе, автоматически получают нужную информацию и передают её дальше без ручного копирования.
Важно сохранить прослеживаемость данных, потому что если показатель вызывает вопрос, аналитик должен понимать, из какой системы он поступил, какие записи вошли в расчёт и какие преобразования были выполнены.
Например, «Экстрактор 1С» от «Денвик Аналитика» автоматически получает данные из 1С и передаёт их во внешний аналитический контур. Уже на первом этапе аналитик видит происхождение данных и может проверить, какие записи попали в витрину.
Автоматически собрать данные недостаточно. Один и тот же товар, клиент или контрагент в разных системах может быть записан по-разному.
Например, один вид йогурта может называться «Йогурт клубничный», «Йогурт, клубника» и «Йогурт 2,5% клуб.». Для человека это один товар, а для системы — три разных.
Чтобы объединить такие записи, нужен единый признак. Для контрагентов это могут быть ИНН и КПП, для товаров — штрихкод, артикул или внутренний код. Если универсального идентификатора нет, компания должна установить собственные правила сопоставления.
Различаться может и уровень детализации данных. Например, в одной системе продажи учитываются по каждой товарной позиции, а для анализа нужны товарные группы. Или в CRM хранится информация по холдингу, а в учётной системе — по отдельным юридическим лицам.
Поэтому перед загрузкой данных в BI важно убедиться, что одинаковые объекты будут объединяться по единым правилам.
Даже правильно собранные и сопоставленные данные не дадут достоверного отчёта, если подразделения по-разному понимают показатели.
Скажем, маркетинг может считать сделкой лид, переданный в отдел продаж. Отдел продаж — заявку, принятую в работу. Финансовый директор — оплаченный заказ. Склад — уже отгруженный заказ.
Во всех случаях используется слово «сделка», но фактически речь идёт о разных событиях. По этой же причине могут расходиться показатели выручки, прибыли, себестоимости и остатков в понимании разных сотрудников и подразделений.
Поэтому до загрузки данных в BI стоит определить, какие операции входят в расчёт каждого показателя, в какой момент учитывается каждая из них и из каких систем поступают исходные данные.
После появления первого отчёта почти всегда возникает желание что-то изменить: подключить новый источник, добавить показатель или пересмотреть формулу расчёта.
Поддерживать данные в порядке не обязательно должна целая команда разработчиков. Этим может заниматься один специалист, например аналитик или финансовый директор, который понимает бизнес-процессы компании и логику показателей.
Упростить работу помогают low-code-инструменты. Они позволяют собрать процесс подготовки данных из готовых блоков: подключить источник, настроить фильтрацию, сопоставить справочники, рассчитать показатель и передать результат в витрину. Это помогает быстрее проверять новые аналитические гипотезы без постоянного привлечения разработчиков.
На скриншоте ниже показан пример проекта в DVT (Data Transformer) от «Денвик Аналитика».
Это визуальная схема подготовки данных для аналитики, где весь процесс представлен в виде связанных между собой блоков. Каждый блок отвечает за определенную операцию: получение данных, фильтрацию, преобразование, объединение нескольких потоков или подготовку результата для дальнейшей загрузки.
Линии между блоками показывают, как данные проходят от одного этапа к другому. Благодаря такому представлению специалист видит всю последовательность обработки, может понять, на каком этапе применяются те или иные правила, и при необходимости изменить отдельную операцию.
Вместо разработки и поддержки сложного самописного решения аналитик может собирать и корректировать процесс из готовых компонентов. Это упрощает сопровождение витрин данных, делает логику преобразований наглядной и позволяет быстрее адаптировать аналитику к новым задачам бизнеса.
Для бизнеса это снижает зависимость от ИТ-команды и интегратора, а сотрудникам позволяет быстрее вносить изменения, не разбираясь в сложных самописных системах.
С одной конкретной аналитической задачи — например, с поиска причин отклонения выпуска от плана. На ней проще выстроить основу для доверия к BI: проследить путь информации от источника до отчёта, договориться о правилах расчета и автоматизировать передачу там, где это возможно.
Если первому отчету можно доверять и он помогает принимать решения, дальше аналитику можно постепенно расширять: добавлять новые источники и метрики.
© КСЛ Экспо, 2026
