Master Data Management / Data Governance / Корпоративна архітектура
Чому корпоративні довідники стають критичною складовою інформаційної системи
Великі підприємства використовують десятки інформаційних систем, кожна з яких вирішує власні функціональні завдання. ERP забезпечують господарський облік, CRM підтримують роботу з клієнтами, системи електронного документообігу управляють договорами, а корпоративні сховища консолідують інформацію для аналітики.
Проте всі ці системи спираються на спільні бізнесові об’єкти: клієнтів, постачальників, товари, працівників, підрозділи, договори та виробничі ресурси.
Проблема виникає тоді, коли кожна інформаційна система створює власне представлення одного й того самого об’єкта. Наприклад, юридична особа може бути зареєстрована в ERP як постачальник, у CRM — як клієнт, а в системі документообігу — як сторона договору.
Усі три записи можуть мати різні внутрішні коди, найменування та контактні реквізити. Доки підрозділи працюють окремо, такі відмінності можуть залишатися непомітними. Але під час інтеграції виникають помилки: документи пов’язуються з неправильним контрагентом, замовлення дублюються, а аналітичні звіти неправильно підсумовують результати.
Для усунення проблеми необхідно створити єдині правила управління основними корпоративними даними. Такий підхід називається Master Data Management (MDM) — системне управління ідентифікацією, якістю, узгодженням і поширенням інформації про ключові бізнес-об’єкти.
MDM не означає обов’язкового перенесення всіх довідників до однієї фізичної бази даних. Його головне призначення — створити узгоджену інформаційну модель і визначити відповідальність за корпоративні об’єкти.
Що належить до Master Data
Основні дані відрізняються від транзакційної інформації. Транзакція відображає подію або операцію: продаж, платіж, відвантаження, закупівлю чи погодження документа.
Master Data описують об’єкти, які беруть участь у цих операціях. Наприклад, замовлення є транзакційним об’єктом, а клієнт, товар і організаційний підрозділ — основними даними.
До типових корпоративних доменів належать:
- контрагенти, клієнти та постачальники;
- товари, матеріали й послуги;
- працівники та організаційні структури;
- виробничі активи й обладнання;
- географічні та адміністративні довідники.
Не кожен довідник має однакову критичність. Наприклад, неправильний код кольору товару може створити помилку в каталозі, тоді як некоректна ідентифікація юридичної особи здатна вплинути на договори та фінансові операції.
Тому MDM необхідно впроваджувати відповідно до бізнесових ризиків, а не лише кількості записів.
Основні архітектурні моделі MDM
Для корпоративних систем використовуються різні підходи до організації MDM.
Registry Style — реєстрова модель
У реєстровій архітектурі дані залишаються у своїх початкових системах. Центральний MDM-компонент зберігає інформацію про відповідність між записами та формує загальний корпоративний ідентифікатор.
Наприклад, ERP містить контрагента ERP-1284, а CRM — CRM-8821. MDM визначає, що обидва записи належать одній організації, та пов’язує їх із корпоративним ідентифікатором CP-00452.
Перевагою такого підходу є можливість створити єдину ідентифікаційну модель без негайної перебудови всіх застосунків.
Однак інформаційні атрибути можуть залишатися розподіленими, тому необхідно враховувати доступність відповідних джерел.
Consolidation Style — консолідаційна модель
У цій моделі MDM отримує дані з кількох систем і формує узгоджене представлення. Наприклад, CRM передає контактні дані, ERP — юридичні реквізити, а система документообігу — додаткові характеристики контрагентів.
Центральний MDM-компонент об’єднує інформацію для аналітики й перевірки якості. Перевагою є формування узгодженого набору без необхідності повністю змінювати процеси створення записів.
Однак виправлення в центральному середовищі не завжди автоматично поширюються до джерел.
Тому необхідно визначати окремі процедури зворотного оновлення.
Coexistence Style — модель співіснування
У цій моделі центральний MDM і початкові системи спільно підтримують інформацію. MDM формує затверджений запис і передає відповідні зміни до корпоративних застосунків.
Наприклад, після перевірки нового контрагента центральний компонент поширює затверджені реквізити до ERP та CRM. Це дозволяє підвищувати узгодженість даних.
Водночас необхідно визначити правила конфліктів і уникати циклічної синхронізації, коли системи постійно перезаписують значення одна одної.
Transactional / Centralized Style — централізована модель
У централізованій моделі створення й редагування основних даних виконується через MDM-платформу або відповідний керований процес. Інші системи використовують затверджені записи.
Наприклад, новий постачальник реєструється через MDM, проходить перевірку, отримує корпоративний ідентифікатор і лише після цього поширюється до ERP. Перевагою є чіткий контроль виникнення нових записів.
Однак така модель потребує змін бізнес-процесів і створює високі вимоги до доступності центрального компонента.
Порівняння моделей MDM
| Модель | Де створюються дані | Основна перевага | Головне обмеження |
|---|---|---|---|
| Registry | У початкових системах | Мінімальні зміни застосунків | Дані залишаються розподіленими |
| Consolidation | У початкових системах | Єдине аналітичне представлення | Не всі виправлення повертаються до джерел |
| Coexistence | У MDM та пов’язаних системах | Двостороннє узгодження | Складність синхронізації |
| Centralized | Через центральний контроль | Єдині правила створення | Залежність від центрального процесу |
Вибір архітектури залежить від організаційної структури підприємства та його технологічних можливостей. Наприклад, для холдингу з кількома незалежними ERP реєстрова або консолідаційна модель може бути реалістичним першим кроком.
Для підприємства, яке створює нову інтегровану ERP, доцільно розглядати більш централізоване управління основними даними.
Golden Record: як визначити правильний корпоративний запис
Одним із ключових понять MDM є Golden Record. Це узгоджене представлення бізнес-об’єкта, сформоване за затвердженими правилами.
Однак Golden Record не обов’язково створюється шляхом вибору одного повного запису з наявних джерел. Часто для різних атрибутів визначаються різні авторитетні системи.
Наприклад:
| Атрибут контрагента | Авторитетне джерело |
|---|---|
| Юридичне найменування | ERP / фінансовий реєстр |
| Реєстраційний код | Контрольований корпоративний реєстр |
| Контактний телефон | CRM |
| Основна контактна особа | CRM |
| Договірний статус | СЕД / ERP за затвердженим правилом |
| Корпоративний ID | MDM |
Це умовна модель, а не універсальний розподіл.
Важливо, щоб підприємство документувало правила вибору значень.
Survivorship Rules
Правила вибору атрибутів називаються Survivorship Rules. Наприклад, для юридичного найменування пріоритет може мати запис, підтверджений фінансовим підрозділом.
Для контактного телефону — останнє перевірене значення CRM. Однак правило «завжди брати найновіший запис» не є універсальним.
Пізніший запис може містити помилку.
Тому важливо враховувати авторитетність джерела, дату перевірки та особливості бізнесового об’єкта.
Історичні значення
Узгодження актуального запису не означає, що необхідно перезаписати всі попередні документи. Наприклад, контрагент міг змінити юридичне найменування.
Нові договори повинні використовувати відповідні актуальні реквізити, але підписані історичні документи мають зберігати свій первинний зміст.
Тому MDM повинен розрізняти поточний стан об’єкта та історичні відомості.
Data Matching: пошук однакових бізнес-об’єктів
Одна з найбільш складних функцій MDM — виявлення дублікатів. У великих корпоративних реєстрах одна організація може мати кілька представлень.
Наприклад:
ТОВ "Альфа Трейд"
Альфа-Трейд, ТОВ
ALFA TRADE LLC
Товариство з обмеженою відповідальністю "Альфа Трейд"
Такі записи можуть описувати одну юридичну особу. Однак схожість назв не гарантує ідентичності.
Можуть існувати різні підприємства зі схожими найменуваннями.
Детерміноване зіставлення
Для зіставлення використовуються точні ідентифікатори. Наприклад, перевірений код ЄДРПОУ може бути важливою ознакою юридичної особи.
Але потрібно враховувати тип контрагента, країну реєстрації та інші обставини.
Нечітке зіставлення
Для пошуку потенційних дублікатів можуть використовуватися методи нормалізації рядків і порівняння схожості. Наприклад, Levenshtein Distance дозволяє оцінювати кількість змін символів між двома текстами.
Інші підходи використовують фонетичні правила, токенізацію та комбінації атрибутів.
Рішення про об’єднання
Для високодостовірних збігів можуть застосовуватися автоматичні правила. Неоднозначні випадки повинні проходити ручну перевірку.
Особливо це важливо, якщо об’єднання впливає на фінансову історію, договори та інші юридично значущі записи.
Data Governance та відповідальність за MDM
MDM не може ефективно працювати лише як ІТ-проєкт. Програмна платформа здатна виконувати перевірки й синхронізацію, але не повинна самостійно визначати всі бізнесові правила.
Для цього необхідно розподілити відповідальність. Data Owner затверджує правила управління певним інформаційним доменом.
Data Steward перевіряє складні записи, контролює якість та координує виправлення. Data Architect визначає структуру корпоративних ідентифікаторів і правила інтеграції.
ІТ-служба забезпечує експлуатацію, доступність, безпеку та технічну реалізацію.
Для великих підприємств може створюватися Data Governance Council. Він дозволяє узгоджувати правила, які зачіпають кілька підрозділів.
Наприклад, фінансова служба й відділ продажів можуть використовувати різні поняття активного контрагента.
Завдання полягає не в механічному об’єднанні всіх визначень, а в їхньому правильному документуванні.
MDM-платформи станом на травень 2017 року
Для великих корпоративних середовищ доступні кілька промислових рішень.
IBM InfoSphere Master Data Management 11.6
IBM InfoSphere MDM 11.6 стала загальнодоступною 16 грудня 2016 року. Отже, у травні 2017 року вона вже може розглядатися для корпоративних проєктів.
Платформа орієнтована на управління основними даними та підтримку відповідних процесів у складних інформаційних середовищах.
Конкретний набір функцій залежить від редакції, конфігурації та ліцензій.
Informatica MDM Multidomain Edition 10.2
Informatica MDM Multidomain Edition 10.2 має документацію випуску, датовану жовтнем—листопадом 2016 року. Вона може використовуватися як орієнтир для проєктів 2017 року.
Важливо розрізняти цей продукт і ширшу Informatica Intelligent Data Platform Release 10.2, загальну доступність якої компанія оголосить лише у вересні 2017 року.
Для історичної оцінки необхідно перевіряти саме відповідну продуктову лінійку.
SAP Master Data Governance 9.0
SAP MDG 9.0 уже представлена в документації 2016 року. Вона орієнтована на керування корпоративними основними даними та організацію процесів їх створення й зміни.
Для підприємств, які використовують SAP, важливим є поєднання MDM із відповідними бізнесовими процесами. Однак вибір платформи не повинен визначатися лише наявністю тієї чи іншої ERP.
Необхідно враховувати кількість інформаційних доменів, організаційну структуру, інтеграційні потреби та сукупну вартість експлуатації.
Практичний сценарій: єдиний реєстр контрагентів холдингу
Розглянемо умовний промисловий холдинг, який має три підприємства.
Кожне використовує власну ERP та власні довідники постачальників.
Центральний офіс хоче формувати консолідовану звітність щодо закупівель.
Етап 1. Інвентаризація
Команда отримує структури й характеристики трьох довідників.
Встановлюються локальні ідентифікатори, обов’язкові поля та правила реєстрації контрагентів.
Етап 2. Data Profiling
Виявляються дублікати, неповні юридичні реквізити та відмінності форматів.
Проблемні записи класифікуються.
Етап 3. Корпоративна модель
Підприємство затверджує набір основних атрибутів і корпоративний ідентифікатор.
Етап 4. Matching
На основі перевірених кодів і додаткових характеристик формуються потенційні відповідності.
Неоднозначні випадки передаються Data Steward.
Етап 5. Golden Record
Для кожного підтвердженого контрагента формується узгоджений запис.
Етап 6. Інтеграція
Початкові ERP отримують таблиці відповідностей і необхідні оновлення.
Етап 7. Аналітика
DWH використовує корпоративні ідентифікатори для консолідації закупівель.
Завдяки цьому підприємство може аналізувати загальний обсяг роботи з одним постачальником, навіть якщо операції здійснювалися через різні юридичні особи групи.
Показники ефективності MDM
Результат MDM необхідно оцінювати кількісно.
Наприклад:
| Показник | Що вимірює |
|---|---|
| Duplicate Rate | Частку потенційно дубльованих записів |
| Completeness | Повноту обов’язкових атрибутів |
| Matching Accuracy | Якість зіставлення |
| Approval Time | Тривалість затвердження нового запису |
| Synchronization Delay | Затримку поширення змін |
| Rejected Updates | Кількість відхилених оновлень |
| Manual Corrections | Обсяг ручного виправлення |
Для кожного показника необхідно визначити методику.
Наприклад, зменшення кількості дублікатів не повинно досягатися шляхом помилкового об’єднання різних юридичних осіб.
Тому важливо контролювати не лише обсяг очищення, а й правильність рішень.
Компетенції Intecracy Group у корпоративному MDM
Побудова системи управління основними даними потребує поєднання кількох компетенцій. Data Management IG спеціалізується на ETL, MDM, Data Quality, DWH та управлінні корпоративними даними. Ці напрями безпосередньо пов’язані з формуванням Golden Record, узгодженням довідників, профілюванням і контролем якості.
IQusion IT працює у сферах системної інтеграції, електронного документообігу та BPM. Відповідні компетенції важливі для автоматизації процесів створення, погодження та зміни основних даних. Softline IT спеціалізується на серверній, мережевій інфраструктурі й системах зберігання. Вони забезпечують продуктивність і доступність корпоративної MDM-платформи.
Водночас рішення щодо бізнесового змісту довідників повинні ухвалюватися відповідальними підрозділами підприємства.
Практичні орієнтири для впровадження
Master Data Management є важливою складовою розвитку корпоративної інформаційної архітектури.
Воно дозволяє узгоджувати ключові бізнес-об’єкти між ERP, CRM, системами документообігу та аналітичними сховищами.
При цьому централізація не завжди означає фізичне перенесення всіх записів до однієї СУБД.
Підприємство може використовувати реєстрову, консолідаційну, розподілену або централізовану модель залежно від своїх потреб.
Особливе значення мають Golden Record, правила зіставлення, контроль історичних змін та корпоративна відповідальність за якість інформації.
Проте сама MDM-платформа не замінює Data Governance.
Єдиний корпоративний довідник виникає не тоді, коли всі дані зібрано в одній базі, а тоді, коли підприємство встановило спільні правила ідентифікації, перевірки та використання основних бізнес-об’єктів.
Автор матеріалу