Как собрать данные, разбросанные по разным системам
Не переносить всё сразу: карта источников, бизнес-объекты, идентификаторы, владельцы, качество и минимальный контур под одно решение.
Коротко: Разбросанные данные не требуют немедленного хранилища. Сначала выберите одно решение, перечислите нужные факты, их владельцев и ключи связи. Минимальная интеграция должна подтверждать конкретный показатель или процесс.
Карта источников и безопасное правило сопоставления
Учебная карта использует только вымышленные идентификаторы. Цель — определить владельца факта, ключи связи, свежесть и обработку неоднозначности до построения общего отчёта.
Инвентаризируйте не системы, а факты
CRM владеет стадией сделки, учёт — актом, сервис-деск — обращением. Для каждого факта фиксируют таблицу или API, поле времени, владельца, период хранения и ограничение доступа.
Стройте ключи по надёжности
Внутренний неизменяемый ID лучше телефона или названия компании. Если общего ключа нет, правило сопоставления использует нормализованный ИНН и номер договора; несколько совпадений не выбираются автоматически.
Показывайте свежесть
В итоговом наборе хранится время источника и время загрузки. Просроченный источник не маскируется общим временем обновления отчёта; пользователь видит, какой слой данных отстал.
Карта DEMO-DATA-MAP
Учебный образец. Перенесите структуру в рабочий документ и замените исходные условия своими.
- Объект
- Контрагент DEMO-C17; без названия и персональных данных.
- Основной ключ
- master_company_id.
- Резервное правило
- Нормализованный ИНН + номер договора; только однозначное совпадение.
- Исключение
- 0 или >1 совпадения — очередь владельцу справочника.
| Факт | Источник | Ключ | Свежесть/владелец |
|---|---|---|---|
| Стадия сделки | CRM-DEMO | deal_id | 15 мин / продажи |
| Принятый акт | ERP-DEMO | act_id + contract_id | 1 час / учёт |
| Обращение | HELP-DEMO | ticket_id + company_id | 5 мин / поддержка |
| Справочник | MDM-DEMO | master_company_id | сутки / владелец данных |
Определение
Карта данных — реестр бизнес-фактов, систем-источников, полей, идентификаторов, владельцев, частоты обновления, ограничений доступа и проверок качества.
Когда это важно
- Один объект имеет разные названия и идентификаторы.
- Отчёт собирается экспортами из нескольких кабинетов.
- Неясно, кто отвечает за полноту и исправление источника.
Как принять решение
| Ситуация | Что проверяем | Решение |
|---|---|---|
| Нужен один показатель | Минимальные факты и устойчивые ключи | Точечная интеграция |
| Нужны многие сценарии | Повторяемые сущности, история и нагрузка | Общий слой данных |
| Нет ключа связи | Допустимость правил сопоставления и ошибки | Нормализация справочника до автоматизации |
Порядок работы
- Вопрос. Зафиксировать решение и минимальный набор фактов.
- Карта. Описать источник, владельца, поле, свежесть и доступ.
- Связи. Определить ключи, дубли и правила сопоставления.
- Контроль. Проверить полноту, точность и маршрут исправления.
Типичные ошибки
- Начинать с миграции всех данных.
- Считать экспорт стабильным API.
- Склеивать объекты вероятностно без видимого качества.
Практические рекомендации
- Выбирайте один процесс и один период.
- Назначайте владельца бизнес-факта, не только системы.
- Храните историю правил сопоставления.
Вывод: Архитектура данных начинается с управленческого вопроса и проверяемой связи фактов, а не с объёма скопированной информации.
Частые вопросы
Нужно ли data warehouse?
Только если повторное использование, история и нагрузка оправдывают общий слой.
Кто владелец данных?
Бизнес-роль, которая отвечает за смысл и качество факта; IT поддерживает технический контур.
Можно начать с CSV?
Да, как временный источник с контролем версии, полноты и срока замены.