// компетенція

Системна інтеграція та дані

Об'єднуємо ERP, CRM, ECM і десятки внутрішніх систем у керовану архітектуру даних. Без точок одиничного збою, без point-to-point хаосу.

// про практику

Що це і кому потрібно

Системна інтеграція — це не «налаштувати API між двома системами». Це архітектурна дисципліна, яка перетворює зоопарк систем замовника на цілісне середовище з єдиним джерелом істини, передбачуваною доставкою подій і прозорою data lineage.

Master Data Management (MDM) і Data Governance — обов'язкові частини. Без них AI-проєкти, аналітика й цифрові продукти стартують з garbage-in і виходять з garbage-out.

Вам це потрібно, якщо

  • У вас ≥8 enterprise-систем, кожна з власною копією клієнтських/продуктових даних.
  • Запуск нового сервісу/продукту вимагає 3–6 місяців інтеграційної роботи.
  • AI-команда скаржиться на якість даних — дублі, конфлікти, відсутність історії.
  • Регуляторні запити (НБУ, СБУ) забирають тижні замість годин.
  • Жоден аналітичний звіт не збирається без ручного «склейку» даних з 3+ систем.
// наша позиція

Чому ми робимо це інакше

01

У 80% MDM-проєктів технічна частина займає 3 місяці. Узгодження власника даних — 9 місяців і часом не завершується ніколи.

Master Data Management — це насамперед організаційне рішення, а вже потім технологія. Перш ніж запускати тендер на MDM-платформу, ми допомагаємо визначити власника master-даних на стороні бізнесу.

02

ESB виправдовується від 8–10 систем. Нижче — point-to-point дешевший і швидший.

Купівля ESB «на виріст» для організації з 4 системами — це гарантована overengineering. Ми чесно говоримо коли ESB не потрібен.

03

У типовому банку 5–10% записів клієнтів дублюються через різні правила транслітерації між системою лояльності й CRM.

Це не баг — це закономірний наслідок історичного розвитку enterprise-середовищ. Якщо ваші дані виглядають «чистими», ви їх просто не аналізували.

// чесний фільтр

Коли вам це потрібно — і коли ні

Чесніше сказати «вам це поки не треба», ніж продати engagement, який не дасть ROI.

✓ Потрібно

  • ≥8 enterprise-систем у production
  • AI-команда блокована якістю даних
  • Готується ребрендинг/M&A з міграцією даних
  • Регулятор вимагає data lineage
  • Бачите дублі клієнтів між CRM/loyalty/billing

✗ Поки не треба

  • <5 систем — point-to-point швидше
  • Немає визначеного власника master-даних на стороні бізнесу
  • Готові терпіти ще 1–2 роки status quo
// процес

Як ми ведемо проєкт

01

Discovery & data audit · 3–4 тижні

Інвентар систем і потоків даних, виявлення дублів і конфліктів, mapping master-сутностей (customer, product, account), оцінка стану документації.

02

Архітектура цільового стану · 4–6 тижнів

Вибір моделі MDM (registry / consolidate / hub), event-driven архітектура через Kafka або ESB, контракти API, схема governance.

03

Pilot на одній сутності · 2–3 місяці

Реалізація MDM для однієї master-сутності (зазвичай customer) у 2–3 системах. Доводить архітектуру до production-якості без ризику ламати все одразу.

04

Scale-out · 6–12 місяців

Поетапне розширення на решту систем і сутностей. Кожна нова інтеграція — окремий sprint з visible business outcome.

05

Data governance як практика · постійно

Регулярні data quality reviews, моніторинг lineage, ескалація аномалій. Без цього MDM деградує до того ж стану через 2 роки.

Проєкт веде: Data Management IG (MDM, governance, data lineage).
За потреби долучаються: InBase (UnityBase для master-data hub), SL Global Service (інтеграційна інфраструктура).

// антипатерни

Типові помилки, на яких ми вже бачили проєкти

MDM без власника даних

Купують MDM-платформу і доручають IT «впровадити». IT робить технічну частину за 3 місяці. Бізнес ще 9 місяців з'ясовує, чий «правильний» запис клієнта — CRM чи billing.

Що робимо інакше: призначаємо Data Steward на стороні бізнесу до старту технічного впровадження.

ESB для організації з 4 системами

Куплено ESB-платформу «на виріст». 4 системи інтегровано — overengineering видно неозброєним оком. Підтримка коштує більше, ніж економить.

Що робимо інакше: для <5 систем рекомендуємо point-to-point або lightweight integration layer типу n8n/Make.

Міграція даних «за один уїк-енд»

План — переключити всі системи на новий MDM за production downtime у п'ятницю-неділю. Реальність — у понеділок 30% користувачів не можуть знайти свої дані.

Що робимо інакше: параллельний run старої і нової систем мінімум 30 днів. Переключення — поступове по сегментах користувачів.

Інтеграція без data contracts

Системи інтегровані «як склалося». Зміна формату в одній системі ламає три інших. Кожна зміна — релізний інцидент.

Що робимо інакше: формалізуємо data contracts через schema registry. Зміна контракту проходить через review до релізу, не після.

// досвід

Типові сценарії з нашої практики

Без точних відсотків економії — реальні цифри залежать від стартової точки замовника. Натомість — конкретні архітектурні рішення та організаційні зміни.

Tier-2 банк України · 14 систем

MDM для customer entity з registry-моделлю

Виявили 7% дублів у CRM через різну транслітерацію. Registry-модель з deterministic + probabilistic matching. Pilot на customer — 4 місяці, потім розширення на product і account.

Енергохолдинг · ERP + 8 регіональних систем

Event-driven архітектура на Kafka

Замінили nightly batch-синхронізацію на event-driven через Kafka. Time-to-data в аналітиці впала з 24 годин до <5 хвилин. Headache — налаштувати exactly-once delivery для фінансових подій.

Державний реєстр · міжвідомча інтеграція

API Gateway з versioning і throttling

Реєстр обслуговує 12 відомств. Запровадили API Gateway з обов'язковим versioning, rate limiting per consumer, audit log. Облікова система ескалації на breach.

// поглиблені матеріали

Що писали по темі

Дев'ять свіжих експертних матеріалів — від тематичних оглядів до конкретних архітектурних рішень.

16.05.2026 3 хв Детальніше →
09.05.2026 3 хв Детальніше →
// стек

Технології, з якими ми працюємо

MDM-платформи

Informatica MDM · Reltio · Profisee · UnityBase (InBase) · Talend MDM · IBM InfoSphere

Інтеграційний шар

Apache Kafka · RabbitMQ · MuleSoft · WSO2 · Apache Camel · Tibco BusinessWorks

API Management

Kong · Apigee · AWS API Gateway · Azure API Management · WSO2 API Manager

Data quality & governance

Talend Data Quality · Informatica Data Quality · Collibra · Alation · Atlan

ETL/ELT

Airflow · dbt · Fivetran · Talend · Apache NiFi · Pentaho

Стандарти

ISO/IEC 27001 · DAMA-DMBOK · GDPR · DCAM · ArchiMate

// часті запитання

Поширені запитання

Чим відрізняється MDM від data warehouse?

Data warehouse — для аналітики (read-only, історичні дані). MDM — для operational use (single source of truth, який оновлюється в real-time і повертається в системи). Це різні задачі, не альтернативи.

Скільки часу займає MDM-впровадження?

Pilot на одній master-сутності — 3–4 місяці. Повне впровадження для tier-1 enterprise — 12–18 місяців. Якщо вам обіцяють «MDM за 2 місяці» — це переписування 1С, не MDM.

Kafka чи RabbitMQ для event-driven?

Kafka — коли потрібна історія подій (replay, аудит) і throughput >100k events/sec. RabbitMQ — для класичних queue-сценаріїв з низькою latency. Для більшості enterprise-сценаріїв — Kafka, бо аудит-вимоги регулятора закривають RabbitMQ.

Чи потрібен Data Mesh у нашому випадку?

Data Mesh виправдовується для організацій з 5+ data domains і самостійними product-командами. Якщо у вас централізована аналітика і одна команда — це overengineering.

Як виглядає роль Data Steward?

Це людина з бізнес-сторони (не IT), що відповідає за визначення правил для конкретної master-сутності. Customer Steward вирішує, чий запис «правильний» при конфлікті між CRM і billing. Зазвичай 20–40% часу існуючого employee, не fulltime.

Що робити з legacy-системами без API?

Three options: (1) database-level integration через CDC (Change Data Capture); (2) screen scraping через RPA (тимчасово); (3) faсade-сервіс над legacy. Вибір залежить від ризик-tolerance і часу до запланованого вивода legacy з експлуатації.

// інші компетенції

Суміжні напрямки

Реальні проєкти рідко вписуються в одну компетенцію. Подивіться, з якими ще напрямками ми працюємо.

Розкажіть про ваш системний ландшафт — побачимо, з чого починати

Discovery-розмова на 30 хвилин. Обговоримо вашу архітектуру і чи маємо що запропонувати — без зобов'язань.

Усі контакти