Корпоративное хранилище данных (КХД) — это архитектурный слой, в котором данные из ERP, CRM, склада, сайта и десятков баз 1С приводятся к единым правилам: один клиент вместо трёх, один статус заказа, одна выручка. Отчёты и BI строятся на согласованных сущностях, поэтому руководители перестают спорить, «чья цифра правильная». На DATAREON КХД строится поверх интеграционной платформы: данные приходят по маршрутам, нормализуются по пути и хранятся в сервисе «Банк данных» как согласованная модель, а не как склад сырых выгрузок.
Ниже — для руководителей и ИТ-директоров: почему проблема разных цифр архитектурная, как устроено хранилище по слоям, как управлять качеством данных и изменениями и с чего разумно начать.
Когда данные есть, а доверия нет
Знакомая картина: продажи смотрят отчёты из CRM, финансы — из ERP, склад — из своей системы, BI собирает дашборды из всего сразу. На совещании выручка не сходится. Склад видит товар, а в аналитике остаток нулевой, и менеджер отказывает клиенту. Перед встречей с собственником отчёт правят вручную.
Последствия:
- руководители обсуждают не решения, а достоверность цифр;
- аналитики тратят время на сверки и чистку вместо анализа;
- любое изменение в источнике воспринимается как риск: непонятно, что сломается в отчётах.
Корень проблемы обычно в интеграциях «точка-точка». Пока систем две, между ними один «провод». Когда систем пять-десять, проводов столько, что никто не может сказать, какие данные по ним идут, кто их поддерживает и что будет при смене формата.
Почему хранилище само по себе не решает проблему качества
Многие проекты КХД заканчиваются большим складом выгрузок: из каждой системы туда кладут таблицы почти как есть, приводят форматы — и всё. Правила качества живут в разрозненных скриптах или в голове одного аналитика.
Итог: хранилище знает всё обо всех, но не знает, что считать правдой. Дубли, противоречия и пустые значения переезжают в КХД вместе с данными, а любое изменение источника вызывает цепную реакцию в витринах.
Хранилище начинает работать, когда в нём есть три вещи:
- явная модель общих сущностей — клиент, заказ, документ, остаток;
- формализованные правила очистки и сопоставления;
- прозрачное управление изменениями в источниках и показателях.
Как устроено КХД на DATAREON
Единый маршрут данных
Все потоки идут через платформу по описанным маршрутам: из 1С — по событиям изменения, из веб-систем — через REST API. Это убирает ночные выгрузки и ручные запуски: изменение приходит в хранилище тогда, когда оно произошло. Подключение новой системы не требует переделки старых связей.
Банк данных как основа модели
Во встроенном сервисе «Банк данных» описываются типы данных и связи между ними. На этой модели строятся таблицы хранения и витрины. Данные в КХД перестают быть копиями таблиц источников — появляется модель, от которой можно отталкиваться при настройке аналитики.
Правила на уровне маршрутов
Прямо на пути данных фиксируется:
- как приводить идентификаторы к единому виду;
- как сопоставлять справочники и статусы (активен или закрыт, статус заказа, тип документа);
- что делать с пустыми значениями, неверными форматами и «грязными» полями.
Простые сценарии настраиваются средствами low-code, сложная логика и нестандартные проверки пишутся на C#. Правила перестают быть разбросанными скриптами и становятся частью архитектуры.
API для потребителей
Хранилище не только хранит: на платформе публикуется API, через который данные получают BI-системы, внутренние сервисы и внешние приложения. КХД становится активным элементом архитектуры, а не складом.
Слои и домены данных
| Слой | Что в нём | Зачем |
|---|---|---|
| Загрузка (staging) | Данные из источников как есть, с метками времени | Аудит, повторная обработка, разбор инцидентов |
| Ядро (core) | Согласованные сущности: клиент, заказ, документ, остаток | Единые правила, нет дублей |
| Витрины (marts) | Продажи по дням, остатки по складам, финансы | Быстрые отчёты под конкретные задачи |
Разделение даёт управляемость: изменился формат в источнике — правится загрузка и правила перехода в ядро, витрины не трогаем.
Вместо одной огромной модели полезно выделить домены: продажи, склад и логистика, финансы, клиенты. В каждом домене свои ключевые сущности, свои правила качества и свой ответственный со стороны бизнеса. Это главное, что меняет диалог: каждый домен знает, какие данные эталонные и по каким правилам они считаются.
Пример «до и после»: единый клиент
До. В CRM клиент — запись со своим идентификатором и статусом. В ERP — контрагент с другим кодом и признаками. На сайте — пользователь с третьим набором полей. Отчёт по продажам берёт куски из всех трёх, и один человек превращается в трёх клиентов. «Активен» он или нет, зависит от того, куда смотрит аналитик.
После. В модели задаётся единый клиент: туда сводятся идентификаторы и ключевые данные из CRM, ERP и сайта, фиксируется правило, кого считать активным. В ядре дубли склеиваются по понятным правилам, статус считается один раз. Витрины продаж, маркетинга и финансов опираются на одну сущность — сводить клиентов вручную перед презентацией больше не нужно.
Качество данных: узнавать о проблемах раньше бизнеса
КХД — инструмент контроля, а не только хранения. На уровне маршрутов и модели настраиваются проверки:
- полнота: пришли все заказы за день, а не половина;
- целостность связей: у каждого документа есть контрагент, у каждой позиции — номенклатура;
- пороги: доля пустых значений и дублей не выше заданной.
При нарушении система фиксирует инцидент, уведомляет ответственного и может пометить или заблокировать витрину, построенную на некорректных данных. Плюс регулярная сводка по доменам: где проблемы, становится ли лучше после исправлений в источниках. Работа с качеством превращается из пожаротушения в план.
Изменения без паники
Новая версия ERP, изменённый формат поля, новый канал продаж — обычно это «что-то поменяли, отчёты сломались, срочно чиним». С явной моделью данных можно заранее увидеть:
- какие витрины и отчёты зависят от изменяемой сущности или источника;
- где изменение формата создаст риск;
- какие проверки прогнать перед включением.
Добавьте к этому простой регламент согласования изменений модели (кто инициирует, кто утверждает, кто проверяет) и документирование — и изменения перестают ломать отчётность по умолчанию.
С чего начать проект КХД
Чек-лист, по которому я рекомендую двигаться:
- Инвентаризация источников и потоков. Какие системы, какие данные, в каком направлении, кто владелец.
- Выбор пилотного домена. Тот, где споры о цифрах стоят дороже всего — чаще продажи или остатки.
- Модель ключевых сущностей пилота и правила их сопоставления, согласованные с бизнесом.
- Единый маршрут данных вместо точечных интеграций для источников пилота.
- Проверки качества и мониторинг — с самого начала, а не «потом».
- Витрины и подключение BI, сравнение с текущими отчётами, разбор расхождений.
- Расширение на следующие домены по отработанной схеме.
Сроки и бюджет зависят от числа источников и состояния данных. Обследование и проектирование пилота я оцениваю по почасовой ставке 2 500 ₽/ч; итоговый план строится после инвентаризации. Если в компании пока нет интеграционной платформы, начать стоит с интеграционной шины для 1С; если платформа есть, но нет аналитики — с BI-аналитики для 1С. Подключение внешних систем к 1С через API — отдельное направление, о нём на странице интеграции 1С по API.
КХД ценно не объёмом данных, а тем, что им можно доверять и безопасно переиспользовать.
Коротко
- Разные цифры в отчётах — симптом архитектуры «точка-точка», а не плохого BI.
- Хранилище без модели сущностей и правил качества превращается в склад выгрузок.
- На DATAREON КХД строится на едином маршруте данных, «Банке данных» и правилах нормализации на маршрутах.
- Слои staging, core и витрины плюс доменные владельцы дают управляемость изменений.
- Начинайте с пилота на самом болезненном домене и проверок качества с первого дня.
