Назад
Максимальная отдача BI обычно возникает на переходах между процессами: продажи передают сигнал закупкам, закупки влияют на доступность товара, склад - на исполнение заказа, логистика - на себестоимость и срок, а коммерческое событие позже отражается в финансах.
Именно на таких переходах руководителю сложнее всего восстановить причинную цепочку. Данные распределены между подразделениями и системами, события происходят в разное время, а один и тот же объект может иметь разные состояния в CRM, 1С, ERP, DWH и BI.
Поэтому зрелая аналитика должна отвечать на три последовательных вопроса:
где возникло отклонение → что его вызвало → какие следующие этапы оно затронуло.
Почему эффект возникает на стыках
От цепочки создания стоимости к данным
Концепция value chain Майкла Портера рассматривает компанию как набор взаимосвязанных видов деятельности, через которые создается ценность для клиента. При этом значение имеют сами операции и связи между ними: решения на одном участке способны менять стоимость, скорость и результат на другом.
Для BI этот принцип особенно важен.
Компания редко управляет всей цепочкой в одной информационной системе. Продажи могут работать в CRM, учет и запасы - в 1С, производство - в ERP, планы - в Excel, обращения клиентов - в сервисной системе, а аналитика - в отдельном DWH и BI.
Поэтому прикладную цепочку для конкретного бизнеса приходится собирать отдельно.
Например:
спрос → планирование → закупка → производство → склад → продажа → доставка → оплата → сервис
Это уже операционная модель компании. Она показывает, где возникает событие, куда передается его контекст и в какой системе появляется следующий факт.
Самые ценные сценарии аналитики обычно находятся на границах функций.
Отчет по продажам показывает спрос.
Отчет по складу показывает остаток.
Руководителю нужен следующий уровень:
какая часть спроса может быть выполнена в требуемый срок?
Для ответа приходится поставить рядом:
заказ → свободный остаток → резерв → ожидаемое поступление → срок поставки
После этого BI показывает состояние заказа в контексте способности бизнеса его исполнить.
Минимальная закупочная цена сама по себе еще не описывает качество решения.
Партия может оказаться дешевой и прийти после пика спроса.
Тогда для анализа требуется связать:
потребность → заказ поставщику → срок → поступление → продажи → остаток
Управленческий вопрос меняется: какой результат конкретное решение закупщика создало дальше по цепочке?
Производственный план и коммерческий прогноз существуют в разных логиках.
Если между ними появляется разрыв, бизнес получает два типовых последствия:
лишний запас или дефицит.
Для расследования BI должен соединить по общей номенклатуре и периоду:
прогноз → план выпуска → фактический выпуск → заказы → продажи → остаток
В этом случае отклонение становится трассируемым.
Рост выручки еще не описывает итоговую экономику операции.
На маржу могут повлиять скидка, закупочная стоимость, логистика, возвраты и дополнительные затраты на исполнение.
Полезная цепочка выглядит так:
заказ → продажа → скидка → себестоимость → логистика → маржа → оплата
Тогда коммерческий результат связывается с финансовым последствием.
После отгрузки данные продолжают создавать ценность.
Появляются обращения, возвраты, претензии и повторные покупки.
Если сервисная система изолирована, служба поддержки видит проблему клиента, а коммерческий блок теряет связь с исходным товаром, заказом, партией или доставкой.
IBM относит подобные изолированные наборы к хранилищам данных: разные подразделения начинают работать с фрагментированными, несовпадающими или устаревшими представлениями данных.
Среди характерных признаков IBM называет дублирование, задержки доступа, разные определения и ситуации, когда системы плохо обмениваются информацией.
Сквозную аналитику удобнее проектировать от управленческого вопроса.
Допустим:
Почему снизилась прибыльность товарной группы?
Дальше восстанавливается дерево причин:
маржа
↓
выручка + себестоимость
↓
цена + скидка + закупочная стоимость
↓
поставщик + партия + логистика
После этого каждому звену назначается источник.
Например:
Так из бизнес-вопроса появляется техническая карта данных.
Чтобы связать процесс, нужна сущность, которая проходит через несколько его этапов.
Это может быть:
заказ, клиент, SKU, договор, документ, проект, партия, подразделение или период.
Если в двух системах отсутствует общий ключ, появляется отдельная задача сопоставления.
Иногда достаточно идентификатора.
Иногда требуется master data.
Иногда строится mapping-таблица.
Иногда достоверная связь вообще отсутствует - и тогда BI не должен создавать ее предположением.
В этом месте проходит одна из ключевых границ аналитики:
качество модели определяется тем, насколько уверенно можно пройти от агрегированного показателя к исходным объектам.
Отдельный класс проблем появляется при передаче объекта между системами.
Документ мог:
Если BI хранит только финальный результат, часть причин исчезает.
Показательный сценарий описан в опубликованном кейсе Денвик Аналитика по контролю 1С и 1С:Бухгалтерии.
Контроль строился вокруг цепочки:
ERP → зарегистрированное изменение → выгрузка → приемник → запись → итоговое состояние.
Экстрактор 1С использовался как контрольная точка источника, Инжектор - на стороне приемника. Это позволяло переходить от факта расхождения к конкретному этапу движения объекта.
Короткая формула из этого сценария хорошо описывает проблему:
«Дошло» еще не означает «записалось».
Для аналитической архитектуры этот принцип шире одного обмена 1С. Событие нужно отслеживать до следующего подтвержденного состояния.
Когда каждый BI-отчет самостоятельно подключает источники, сопоставляет справочники и рассчитывает показатели, постепенно появляются разные версии одной логики.
Поэтому устойчивый корпоративный контур обычно разделяет роли:
источник → получение данных → подготовка → витрина → семантическая модель → BI
Microsoft отдельно подчеркивает проблему фрагментации метрик: множество независимых моделей приводит к дублированию и повторному определению показателей, а стандартизированные и проверенные KPI повышают согласованность отчетности.
Витрина в такой архитектуре становится местом, где закреплены бизнес-правила и связи между сущностями.
Для компаний с крупным контуром 1С техническая задача начинается с получения данных из транзакционной системы и вывода аналитической нагрузки во внешний контур.
Базовый поток можно представить так:
1С → Экстрактор 1С → Raw / Staging → DVT → DWH / витрины → BI
Внешние источники подключаются к слою подготовки:
CRM / API / файлы / СУБД → DVT
Если обработанный результат требуется вернуть в учетную систему:
подготовленные данные → Инжектор 1С → 1С
DCC располагается рядом с этим конвейером как технический слой мониторинга и управления компонентами Denvic Tools.
Экстрактор 1С отвечает за получение данных из 1С и передачу их во внешний аналитический контур.
В документации предусмотрена инкрементальная выгрузка: Экстрактор регистрирует изменения объектов, определяет затронутые сегменты и при следующем запуске обрабатывает изменившиеся части вместо повторного чтения всего набора. Для крупных выгрузок используется сегментирование и многопоточность.
Это особенно важно для BI, где одна и та же витрина регулярно обновляется новыми операционными событиями.
При этом сложную бизнес-логику разумно отделять от слоя извлечения. В документации Экстрактора для трансформаций прямо рекомендуется последующий ETL-процесс.
Роль Экстрактора в этой архитектуре можно сформулировать коротко:
получить актуальные данные из 1С и передать их наружу.
Когда цепочка проходит через несколько систем, требуется слой подготовки.
Denvic Visual Transformer работает как low-code ETL-сервис: подключает разные источники, преобразует данные и формирует подготовленные витрины. В актуальной документации DVT указана работа с PostgreSQL, ClickHouse, Oracle, MySQL, Microsoft SQL, Excel, CSV, Parquet, S3 и другими источниками; доступны трансформации Join, Union, GroupBy, фильтрация, преобразование типов и другие операции.
Здесь можно привести к общей модели:
клиента из CRM → контрагента из 1С → заказ → номенклатуру → подразделение → финансовый результат.
Разделение ролей уже используется в материалах как архитектура:
Экстрактор 1С → Промежуточный слой → DVT → аналитические витрины → BI.
В ней Экстрактор получает актуальные данные, а DVT выполняет очистку, типизацию, Join/Union, фильтрацию, агрегации, расчетные поля и бизнес-правила.
BI-процесс часто заканчивается решением пользователя: руководитель увидел отклонение и предпринял действие.
В некоторых сценариях аналитический результат должен вернуться в операционную систему.
Например, во внешнем контуре подготовлен набор данных, после которого требуется создать или обновить объекты 1С.
Для такого обратного направления предназначен Инжектор 1С. Согласно документации, он может извлекать подготовленные данные из ClickHouse, PostgreSQL, MSSQL и Kafka, преобразовывать их и записывать в объекты 1С.
Для обычного BI-дашборда этот компонент не требуется.
Его место появляется, когда архитектура содержит поток: внешний контур → 1С.
Хороший пример перехода от локальных источников к единому аналитическому контуру - опубликованный кейс Хеппивеар Юг.
Компания собирала данные из 1С и Bitrix и передавала их в ClickHouse. В едином контуре были сведены финансовые показатели, заказы, задачи, подразделения, сотрудники и обращения технической поддержки. В публикации указано более 50 связанных таблиц, а объем ClickHouse достиг около 2 ТБ. BI строился в DataLens и дополнительных интерактивных панелях.
Ценность этого примера находится именно в связях.
Источники перестали обслуживать только отдельные отчеты. Их данные начали работать в общей аналитической модели, где можно двигаться от верхнеуровневого показателя до конкретной категории или номенклатуры.
Сквозной дашборд сам по себе не исправляет процесс.
Есть несколько ограничений, которые технология обойти не сможет.
Если продажи и финансы по-разному определяют маржу, техническое объединение таблиц проблему не решит. Сначала требуется единое правило расчета.
Если система не хранит связь между продажей и последующей рекламацией, BI не может достоверно восстановить ее из воздуха.
Нужен идентификатор, таблица соответствий или другой подтвержденный механизм связи.
Если данные поступают раз в сутки, BI физически не сможет достоверно показывать состояние операции каждые пять минут.
Частота аналитики ограничена частотой и полнотой исходных событий.
Можно построить отличный индикатор дефицита.
Если после его появления неизвестно, кто и какое действие выполняет, управленческий цикл остается незамкнутым.
Поэтому архитектура BI должна включать еще один вопрос:
что происходит после обнаружения отклонения?
Получение данных, ETL, витрина и визуализация формируют информационный контур.
Ответственный, правило реакции и контроль результата превращают сигнал в управленческое действие.
Есть простой способ понять, насколько BI действительно охватывает цепочку создания ценности.
Выберите показатель, от которого зависит решение.
Например:
маржа, срок исполнения заказа, дефицит, оборачиваемость или дебиторская задолженность.
Затем попробуйте пройти от итоговой цифры назад.
Для маржи путь может выглядеть так:
маржа → товарная группа → SKU → продажи → конкретный заказ → скидка → себестоимость → закупка → поставщик
Для срока исполнения:
срок → заказ → резерв → склад → отгрузка → перевозка → доставка
Для возврата:
возврат → клиент → продажа → товар → партия → доставка → обращение
Если BI позволяет восстановить этот путь внутри общей аналитической модели, данные действительно связывают процессы.
Если расследование в какой-то момент требует вручную открыть другую систему, выгрузить Excel или обратиться к соседнему подразделению за расшифровкой показателя, именно там находится следующий разрыв аналитического контура.
Перед масштабированием BI стоит проверить:
Эти четыре вопроса обычно дают больше информации о зрелости BI, чем количество дашбордов в компании.
Именно на таких переходах руководителю сложнее всего восстановить причинную цепочку. Данные распределены между подразделениями и системами, события происходят в разное время, а один и тот же объект может иметь разные состояния в CRM, 1С, ERP, DWH и BI.
Поэтому зрелая аналитика должна отвечать на три последовательных вопроса:
где возникло отклонение → что его вызвало → какие следующие этапы оно затронуло.
Почему эффект возникает на стыках
От цепочки создания стоимости к данным
Концепция value chain Майкла Портера рассматривает компанию как набор взаимосвязанных видов деятельности, через которые создается ценность для клиента. При этом значение имеют сами операции и связи между ними: решения на одном участке способны менять стоимость, скорость и результат на другом.
Для BI этот принцип особенно важен.
Компания редко управляет всей цепочкой в одной информационной системе. Продажи могут работать в CRM, учет и запасы - в 1С, производство - в ERP, планы - в Excel, обращения клиентов - в сервисной системе, а аналитика - в отдельном DWH и BI.
Поэтому прикладную цепочку для конкретного бизнеса приходится собирать отдельно.
Например:
спрос → планирование → закупка → производство → склад → продажа → доставка → оплата → сервис
Это уже операционная модель компании. Она показывает, где возникает событие, куда передается его контекст и в какой системе появляется следующий факт.
Самые ценные сценарии аналитики обычно находятся на границах функций.
| Стык | Управленческий вопрос | Что нужно связать |
|---|---|---|
| Продажи → склад | Можно ли исполнить полученный спрос? | заказ, SKU, остаток, резерв, ожидаемое поступление |
| Продажи → закупки | Почему возник дефицит? | спрос, заказ поставщику, срок поставки, остаток |
| Планирование → производство | Почему выпуск расходится со спросом? | прогноз, план, выпуск, продажи, остатки |
| Продажи → финансы | Почему выручка растет, а экономика ухудшается? | продажа, скидка, себестоимость, логистика, маржа |
| Логистика → сервис | Где возникла причина жалобы? | заказ, отгрузка, доставка, обращение |
| Продажа → оплата | Какая часть коммерческого результата превратилась в деньги? | реализация, платеж, задолженность |
| Продажа → сервис | Какие операции приводят к возвратам? | клиент, товар, партия, продажа, обращение, возврат |
Продажи и запасы
Отчет по продажам показывает спрос.
Отчет по складу показывает остаток.
Руководителю нужен следующий уровень:
какая часть спроса может быть выполнена в требуемый срок?
Для ответа приходится поставить рядом:
заказ → свободный остаток → резерв → ожидаемое поступление → срок поставки
После этого BI показывает состояние заказа в контексте способности бизнеса его исполнить.
Закупки и продажи
Минимальная закупочная цена сама по себе еще не описывает качество решения.
Партия может оказаться дешевой и прийти после пика спроса.
Тогда для анализа требуется связать:
потребность → заказ поставщику → срок → поступление → продажи → остаток
Управленческий вопрос меняется: какой результат конкретное решение закупщика создало дальше по цепочке?
Производство и спрос
Производственный план и коммерческий прогноз существуют в разных логиках.
Если между ними появляется разрыв, бизнес получает два типовых последствия:
лишний запас или дефицит.
Для расследования BI должен соединить по общей номенклатуре и периоду:
прогноз → план выпуска → фактический выпуск → заказы → продажи → остаток
В этом случае отклонение становится трассируемым.
Продажи и финансы
Рост выручки еще не описывает итоговую экономику операции.
На маржу могут повлиять скидка, закупочная стоимость, логистика, возвраты и дополнительные затраты на исполнение.
Полезная цепочка выглядит так:
заказ → продажа → скидка → себестоимость → логистика → маржа → оплата
Тогда коммерческий результат связывается с финансовым последствием.
Продажи и сервис
После отгрузки данные продолжают создавать ценность.
Появляются обращения, возвраты, претензии и повторные покупки.
Если сервисная система изолирована, служба поддержки видит проблему клиента, а коммерческий блок теряет связь с исходным товаром, заказом, партией или доставкой.
IBM относит подобные изолированные наборы к хранилищам данных: разные подразделения начинают работать с фрагментированными, несовпадающими или устаревшими представлениями данных.
Среди характерных признаков IBM называет дублирование, задержки доступа, разные определения и ситуации, когда системы плохо обмениваются информацией.
Как строить причинную модель
Сначала вопрос, потом график
Сквозную аналитику удобнее проектировать от управленческого вопроса.
Допустим:
Почему снизилась прибыльность товарной группы?
Дальше восстанавливается дерево причин:
маржа
↓
выручка + себестоимость
↓
цена + скидка + закупочная стоимость
↓
поставщик + партия + логистика
После этого каждому звену назначается источник.
Например:
- реализация и себестоимость - 1С;
- сделки - CRM;
- план - Excel;
- перевозка - логистическая система;
- аналитическая история - DWH.
Так из бизнес-вопроса появляется техническая карта данных.
Общий объект важнее источника
Чтобы связать процесс, нужна сущность, которая проходит через несколько его этапов.
Это может быть:
заказ, клиент, SKU, договор, документ, проект, партия, подразделение или период.
Если в двух системах отсутствует общий ключ, появляется отдельная задача сопоставления.
Иногда достаточно идентификатора.
Иногда требуется master data.
Иногда строится mapping-таблица.
Иногда достоверная связь вообще отсутствует - и тогда BI не должен создавать ее предположением.
В этом месте проходит одна из ключевых границ аналитики:
качество модели определяется тем, насколько уверенно можно пройти от агрегированного показателя к исходным объектам.
Состояния важнее одного снимка
Отдельный класс проблем появляется при передаче объекта между системами.
Документ мог:
- появиться в источнике;
- попасть в регистрацию изменений;
- выгрузиться;
- поступить в промежуточный слой;
- попасть в систему-приемник;
- пройти запись;
- изменить состояние после записи.
Если BI хранит только финальный результат, часть причин исчезает.
Показательный сценарий описан в опубликованном кейсе Денвик Аналитика по контролю 1С и 1С:Бухгалтерии.
Контроль строился вокруг цепочки:
ERP → зарегистрированное изменение → выгрузка → приемник → запись → итоговое состояние.
Экстрактор 1С использовался как контрольная точка источника, Инжектор - на стороне приемника. Это позволяло переходить от факта расхождения к конкретному этапу движения объекта.
Короткая формула из этого сценария хорошо описывает проблему:
«Дошло» еще не означает «записалось».
Для аналитической архитектуры этот принцип шире одного обмена 1С. Событие нужно отслеживать до следующего подтвержденного состояния.
Витрина фиксирует правила
Когда каждый BI-отчет самостоятельно подключает источники, сопоставляет справочники и рассчитывает показатели, постепенно появляются разные версии одной логики.
Поэтому устойчивый корпоративный контур обычно разделяет роли:
источник → получение данных → подготовка → витрина → семантическая модель → BI
Microsoft отдельно подчеркивает проблему фрагментации метрик: множество независимых моделей приводит к дублированию и повторному определению показателей, а стандартизированные и проверенные KPI повышают согласованность отчетности.
Витрина в такой архитектуре становится местом, где закреплены бизнес-правила и связи между сущностями.
Архитектура сквозного BI
Для компаний с крупным контуром 1С техническая задача начинается с получения данных из транзакционной системы и вывода аналитической нагрузки во внешний контур.
Базовый поток можно представить так:
1С → Экстрактор 1С → Raw / Staging → DVT → DWH / витрины → BI
Внешние источники подключаются к слою подготовки:
CRM / API / файлы / СУБД → DVT
Если обработанный результат требуется вернуть в учетную систему:
подготовленные данные → Инжектор 1С → 1С
DCC располагается рядом с этим конвейером как технический слой мониторинга и управления компонентами Denvic Tools.
Экстрактор: данные из 1С
Экстрактор 1С отвечает за получение данных из 1С и передачу их во внешний аналитический контур.
В документации предусмотрена инкрементальная выгрузка: Экстрактор регистрирует изменения объектов, определяет затронутые сегменты и при следующем запуске обрабатывает изменившиеся части вместо повторного чтения всего набора. Для крупных выгрузок используется сегментирование и многопоточность.
Это особенно важно для BI, где одна и та же витрина регулярно обновляется новыми операционными событиями.
При этом сложную бизнес-логику разумно отделять от слоя извлечения. В документации Экстрактора для трансформаций прямо рекомендуется последующий ETL-процесс.
Роль Экстрактора в этой архитектуре можно сформулировать коротко:
получить актуальные данные из 1С и передать их наружу.
DVT: связать источники
Когда цепочка проходит через несколько систем, требуется слой подготовки.
Denvic Visual Transformer работает как low-code ETL-сервис: подключает разные источники, преобразует данные и формирует подготовленные витрины. В актуальной документации DVT указана работа с PostgreSQL, ClickHouse, Oracle, MySQL, Microsoft SQL, Excel, CSV, Parquet, S3 и другими источниками; доступны трансформации Join, Union, GroupBy, фильтрация, преобразование типов и другие операции.
Здесь можно привести к общей модели:
клиента из CRM → контрагента из 1С → заказ → номенклатуру → подразделение → финансовый результат.
Разделение ролей уже используется в материалах как архитектура:
Экстрактор 1С → Промежуточный слой → DVT → аналитические витрины → BI.
В ней Экстрактор получает актуальные данные, а DVT выполняет очистку, типизацию, Join/Union, фильтрацию, агрегации, расчетные поля и бизнес-правила.
Инжектор: вернуть результат
BI-процесс часто заканчивается решением пользователя: руководитель увидел отклонение и предпринял действие.
В некоторых сценариях аналитический результат должен вернуться в операционную систему.
Например, во внешнем контуре подготовлен набор данных, после которого требуется создать или обновить объекты 1С.
Для такого обратного направления предназначен Инжектор 1С. Согласно документации, он может извлекать подготовленные данные из ClickHouse, PostgreSQL, MSSQL и Kafka, преобразовывать их и записывать в объекты 1С.
Для обычного BI-дашборда этот компонент не требуется.
Его место появляется, когда архитектура содержит поток: внешний контур → 1С.
Как это выглядит в проекте
Хороший пример перехода от локальных источников к единому аналитическому контуру - опубликованный кейс Хеппивеар Юг.
Компания собирала данные из 1С и Bitrix и передавала их в ClickHouse. В едином контуре были сведены финансовые показатели, заказы, задачи, подразделения, сотрудники и обращения технической поддержки. В публикации указано более 50 связанных таблиц, а объем ClickHouse достиг около 2 ТБ. BI строился в DataLens и дополнительных интерактивных панелях.
Ценность этого примера находится именно в связях.
Источники перестали обслуживать только отдельные отчеты. Их данные начали работать в общей аналитической модели, где можно двигаться от верхнеуровневого показателя до конкретной категории или номенклатуры.
Где заканчивается BI
Сквозной дашборд сам по себе не исправляет процесс.
Есть несколько ограничений, которые технология обойти не сможет.
Нет общей методики
Если продажи и финансы по-разному определяют маржу, техническое объединение таблиц проблему не решит. Сначала требуется единое правило расчета.
Нет связи между объектами
Если система не хранит связь между продажей и последующей рекламацией, BI не может достоверно восстановить ее из воздуха.
Нужен идентификатор, таблица соответствий или другой подтвержденный механизм связи.
Источник обновляется редко
Если данные поступают раз в сутки, BI физически не сможет достоверно показывать состояние операции каждые пять минут.
Частота аналитики ограничена частотой и полнотой исходных событий.
Никто не отвечает за сигнал
Можно построить отличный индикатор дефицита.
Если после его появления неизвестно, кто и какое действие выполняет, управленческий цикл остается незамкнутым.
Поэтому архитектура BI должна включать еще один вопрос:
что происходит после обнаружения отклонения?
Получение данных, ETL, витрина и визуализация формируют информационный контур.
Ответственный, правило реакции и контроль результата превращают сигнал в управленческое действие.
Как проверить зрелость
Есть простой способ понять, насколько BI действительно охватывает цепочку создания ценности.
Выберите показатель, от которого зависит решение.
Например:
маржа, срок исполнения заказа, дефицит, оборачиваемость или дебиторская задолженность.
Затем попробуйте пройти от итоговой цифры назад.
Для маржи путь может выглядеть так:
маржа → товарная группа → SKU → продажи → конкретный заказ → скидка → себестоимость → закупка → поставщик
Для срока исполнения:
срок → заказ → резерв → склад → отгрузка → перевозка → доставка
Для возврата:
возврат → клиент → продажа → товар → партия → доставка → обращение
Если BI позволяет восстановить этот путь внутри общей аналитической модели, данные действительно связывают процессы.
Если расследование в какой-то момент требует вручную открыть другую систему, выгрузить Excel или обратиться к соседнему подразделению за расшифровкой показателя, именно там находится следующий разрыв аналитического контура.
Четыре контрольных вопроса
Перед масштабированием BI стоит проверить:
- Можно ли пройти от KPI до исходного события?
- Одинаково ли подразделения понимают правила расчета?
- Видны ли переходы объекта между системами и состояниями?
- Определено ли действие после обнаружения отклонения?
Эти четыре вопроса обычно дают больше информации о зрелости BI, чем количество дашбордов в компании.
