Що зміниться у звітах після оновлення ERP

Data Lineage / Metadata Management / Enterprise Architecture

Чому одна зміна в ERP може вплинути на десятки корпоративних звітів

Сучасне підприємство рідко використовує одну інформаційну систему. Фінансові операції обробляються в ERP, клієнтські дані зберігаються в CRM, документи проходять через систему електронного документообігу, а корпоративна аналітика використовує Data Warehouse та спеціалізовані інформаційні вітрини. Між цими компонентами працюють численні інтеграційні процеси.

Наприклад, інформація про продажі надходить з ERP до staging-зони, проходить через ETL, зіставляється з корпоративним товарним довідником і завантажується до DWH. На основі результатів створюються управлінські панелі, фінансові звіти та прогнози.

Поки архітектура залишається незмінною, така модель може працювати роками. Однак інформаційні системи постійно розвиваються.

Припустімо, підприємство вирішило змінити поле order_status у ERP. Раніше статус «Completed» означав завершення замовлення. Після оновлення ERP він означатиме завершення відвантаження, а фінансове підтвердження відображатиметься окремою характеристикою.

Технічно структура поля може залишитися незмінною. ETL продовжить працювати.

Проте корпоративна звітність може почати неправильно визначати завершені продажі. Інший сценарій — перейменування стовпця або зміна типу даних.

Тут наслідки можуть бути більш очевидними: SQL-запит перестане виконуватися, а нічне завантаження завершиться помилкою. У будь-якому випадку підприємство повинно встановити, які інформаційні ресурси залежать від зміненого об’єкта.

Саме це завдання вирішує Impact Analysis — аналіз наслідків змін, а Data Lineage забезпечує інформаційну основу для такого аналізу.

Головна ідея полягає в тому, щоб розглядати корпоративні дані не як незалежні таблиці, а як взаємопов’язану систему джерел, трансформацій, довідників і бізнесових показників.

Що таке Data Lineage

Data Lineage — це опис походження інформації та її перетворення між системами. Наприклад, корпоративний показник чистої виручки може формуватися на основі кількох таблиць ERP.

Під час ETL застосовуються правила відбору підтверджених документів, валютні перерахунки та зіставлення клієнтів із MDM. Після цього результат потрапляє до аналітичної вітрини.

Lineage дозволяє відобразити такі залежності.

• ERP — документи продажів
• MDM — клієнти й товари
• ETL / ELT
• Відбір · зіставлення · валютні перерахунки
• DWH / FactSales
• Корпоративна таблиця фактів
• Finance Data Mart
• Затверджена методика виручки
• BI — фінансовий звіт

Спрощений Data Lineage. У реальній архітектурі зв’язки можуть містити додаткові джерела, кілька етапів трансформацій і історичні версії.

Lineage може виконувати дві основні функції. Перша — пояснювати, звідки походить конкретний аналітичний результат.

Друга — допомагати визначати, на що вплине зміна початкової системи. Наприклад, якщо змінюється структура таблиці ERP, можна встановити всі залежні ETL-процеси та звіти.

Це особливо важливо під час великих модернізацій.

Три рівні Data Lineage

Не кожне підприємство одразу потребує детального Lineage на рівні всіх полів.

Доцільно розрізняти кілька рівнів.

1. System-Level Lineage

Показує взаємодію між інформаційними системами.

Наприклад:

ERP → ETL → DWH → BI

Такий опис корисний для загального архітектурного аналізу.

Але він не дозволяє встановити, які конкретні SQL-таблиці використовуються.

2. Table-Level Lineage

Показує залежності між таблицями та інформаційними наборами.

Наприклад:

ERP.InvoiceLines → STG.InvoiceLines → DWH.FactSales

Цей рівень корисний для аналізу структурних змін.

Якщо таблицю ERP планують замінити, можна визначити відповідні залежні об’єкти.

3. Column-Level Lineage

Дозволяє встановлювати походження конкретних атрибутів. Наприклад, показник net_revenue може використовувати суму документа, знижку, повернення та валютний курс.

Цей рівень особливо важливий для фінансових показників. Проте його автоматизація складніша.

Наприклад, SQL може використовувати вкладені підзапити, тимчасові таблиці, динамічно сформовані запити та користувацькі функції. Не кожний інструмент метаданих здатний правильно відтворити всю відповідну семантику.

Тому для критичних бізнесових показників автоматичний Lineage потрібно доповнювати затвердженими описами правил.

Технічне походження не дорівнює бізнесовому змісту

Розглянемо SQL-запит:

SELECT
    customer_id,
    SUM(amount) AS total_amount
FROM sales_documents
WHERE status = 'POSTED'
GROUP BY customer_id;

Технічний аналіз дозволяє встановити, що total_amount залежить від поля amount таблиці sales_documents. Однак цього недостатньо для бізнесового пояснення.

Наприклад, чи включає amount ПДВ? Чи враховуються повернення?

Що означає статус POSTED? Яка дата визначає звітний період?

Для відповіді потрібен Business Glossary. Отже, повноцінний корпоративний Lineage повинен поєднувати технічну структуру та бізнесові метадані.

Це особливо важливо під час модернізації ERP. Зміна значення статусу може не порушувати SQL-синтаксис, але змінити фінансову семантику.

Тому Impact Analysis не повинен обмежуватися пошуком назв таблиць і полів.

Apache Atlas 1.1: графова модель корпоративних метаданих

Станом на лютий 2019 року одним із доступних відкритих інструментів управління метаданими є Apache Atlas 1.1.0. Ця версія вийшла 17 вересня 2018 року.

Новіші основні випуски Atlas 2.0 і 1.2 ще не доступні: вони будуть оприлюднені лише у травні та червні 2019 року відповідно.

Apache Atlas дозволяє описувати інформаційні об’єкти, їхні атрибути, класифікації та зв’язки.

Для корпоративної архітектури це створює можливість представити інформаційні ресурси у вигляді графа.

Entities

Окремі таблиці, файли або інші ресурси можуть бути представлені відповідними сутностями.

Relationships

Зв’язки дозволяють описувати залежності між інформаційними об’єктами.

Наприклад, процес може отримувати таблицю джерела й формувати іншу таблицю.

Classifications

Для ресурсів можуть визначатися відповідні класифікації.

Наприклад, певний набір може бути позначений як такий, що містить персональні дані.

Business Glossary

Дозволяє пов’язувати технічні ресурси з бізнесовими поняттями.

Lineage

Допомагає візуалізувати інформаційні залежності. Проте важливо розуміти обмеження.

Atlas 1.1 не є універсальним автоматичним аналізатором будь-якого SQL, Python, SSIS або ERP. Для частини джерел існують відповідні механізми інтеграції.

Для інших необхідно розробляти додаткові конектори чи процедури передавання метаданих. Тому перед впровадженням потрібно визначити, які системи підтримуються та який рівень Lineage реально можна отримати.

Як автоматично збирати метадані

Одним із напрямів автоматизації є отримання технічних метаданих безпосередньо з корпоративних систем. Наприклад, SQL Server містить системні представлення, які дозволяють аналізувати структури таблиць, представлень та визначені залежності.

PostgreSQL має власні системні каталоги. Apache Hive використовує Metastore для опису таблиць і відповідних структур.

Database Metadata

Із СУБД можна отримувати перелік таблиць, стовпців, типів, ключів та інших характеристик.

ETL Metadata

Для підтримуваних інтеграційних платформ можна отримувати описи джерел і цільових наборів.

Execution Metadata

Системи оркестрації можуть зберігати інформацію про виконання процесів.

Business Metadata

Потребують додаткових визначень і затвердження відповідальними особами. Для автоматизації важливо встановити єдині правила ідентифікації ресурсів.

Наприклад, таблиця може бути представлена повним іменем, що включає сервер, базу, схему та назву. Якщо використовувати лише назву Customers, різні таблиці з кількох ERP можуть помилково вважатися одним ресурсом.

Тому каталог повинен забезпечувати коректну технічну ідентичність.

SQL Server та аналіз залежностей

Для Microsoft SQL Server можна використовувати системні механізми аналізу SQL-об’єктів. Наприклад, sys.sql_expression_dependencies містить визначені залежності SQL-виразів.

Спрощений діагностичний запит:

SELECT
    OBJECT_SCHEMA_NAME(
        referencing_id
    ) AS referencing_schema,
    OBJECT_NAME(
        referencing_id
    ) AS referencing_object,
    referenced_schema_name,
    referenced_entity_name
FROM sys.sql_expression_dependencies;

Це приклад доступного механізму SQL Server 2016 і 2017. Він може допомогти визначати залежності між збереженими SQL-об’єктами.

Проте результати не є повним корпоративним Lineage. Наприклад, динамічний SQL або зовнішній Python-процес може не відображатися як звичайна статична залежність.

Аналогічно SQL Server не обов’язково знає, що результат таблиці використовується в зовнішній BI-системі. Тому для повної картини потрібні додаткові інтеграції.

Практична модель

Підприємство може регулярно отримувати системні метадані, доповнювати їх інформацією ETL і передавати до корпоративного каталогу.

При цьому необхідно контролювати видалені, перейменовані та новостворені об’єкти.

Також потрібно розрізняти відсутність залежності й неможливість її автоматично визначити.

PostgreSQL і метадані інформаційних структур

PostgreSQL також підтримує системні каталоги й відповідні представлення для аналізу структури.

Наприклад, information_schema.columns дозволяє отримувати відомості про стовпці.

SELECT
    table_schema,
    table_name,
    column_name,
    data_type
FROM information_schema.columns
WHERE table_schema NOT IN (
    'pg_catalog',
    'information_schema'
);

Це дозволяє створювати технічний інвентар.

Однак перелік стовпців не показує автоматично, які SQL-трансформації використовують ці атрибути.

Для повного Lineage потрібно аналізувати відповідні представлення, функції, ETL-скрипти та зовнішні процеси.

Особливо складною є ситуація, коли SQL формується динамічно.

Наприклад, назва таблиці визначається параметром програми.

Тому автоматичний аналіз повинен мати механізм позначення неповних або непідтверджених залежностей.

Для великих підприємств це важливо: каталог не повинен створювати помилкову впевненість у повноті інформаційної карти.

Impact Analysis: як оцінювати наслідки змін

• Impact Analysis використовує інформаційні залежності для визначення потенційного впливу.
• Наприклад, підприємство планує змінити структуру таблиці ERP.Sales.
• Вона використовується в кількох ETL-процесах.
• Один формує фінансове DWH.
• Інший створює оперативну аналітичну вітрину.
• Третій передає визначені події до Kafka.
• За наявності Lineage можна встановити відповідні залежні компоненти.

• Важливо розрізняти технічний і бізнесовий вплив.
• Наприклад, SQL-процедура може продовжувати виконуватися після зміни довідника, але результат стане іншим.
• Тому аналіз повинен включати не лише структури, а й правила перетворення.

Data Lineage та CI/CD

Одним із перспективних напрямів DataOps є інтеграція аналізу залежностей із процесом впровадження змін.

Наприклад, розробник створює SQL-міграцію.

Після цього система може визначити, які об’єкти потенційно зачеплені.

На основі результату формуються необхідні тести.

Структурні зміни

Якщо змінюється таблиця, потрібно перевірити залежні SQL-об’єкти.

Аналітичні зміни

Якщо змінюється формула показника, потрібно виконати відповідні Regression Tests.

MDM

Якщо змінюються правила зіставлення, необхідно перевірити вплив на історичні звіти.

Безпека

Якщо додається персональний атрибут, потрібно оцінити відповідні права доступу й цілі обробки.

Документація

Після продуктивного впровадження каталог повинен отримати нову версію метаданих.

Проте в лютому 2019 року не слід описувати сучасні стандартизовані OpenLineage-інтеграції як уже наявну універсальну інфраструктуру.

Для цього періоду коректніше говорити про метадані конкретних ETL-платформ, Apache Atlas API та спеціалізовані корпоративні механізми автоматизації.

Зв’язок із Apache Airflow

Apache Airflow може бути джерелом операційної інформації про залежності завдань.

Наприклад, DAG визначає послідовність:

extract_erp → transform_sales → load_dwh

Це корисна частина опису інформаційного процесу.

Однак сам граф завдань не пояснює, як конкретне поле ERP перетворюється на показник DWH.

Наприклад, transform_sales може запускати SQL-скрипт із десятками перетворень.

Тому потрібно поєднувати опис DAG із відповідними метаданими SQL і бізнесовими правилами.

Станом на лютий 2019 року Apache Airflow уже став Top-Level Project Apache Software Foundation — відповідне рішення було оголошено 8 січня.

Версія 1.10.2 доступна з січня 2019 року й може розглядатися для відповідних середовищ.

Проте її не слід ототожнювати з майбутніми поколіннями Airflow 2.x або 3.x.

Контроль версій DAG

Python-код потрібно зберігати в Git.

Опис джерел і результатів

Для критичних завдань доцільно документувати вхідні й вихідні набори.

Ідентифікатори запусків

Допомагають встановлювати, яка версія процесу формувала конкретний результат.

Data Lineage

Може будуватися на основі сукупності технічних та бізнесових метаданих.

Таким чином, Airflow і Atlas можуть виконувати взаємодоповнювальні функції, але їхню інтеграцію потрібно проєктувати окремо.

Data Lineage та контроль персональних даних

Після початку застосування GDPR у травні 2018 року підприємства, діяльність яких підпадає під регламент, повинні забезпечувати відповідні правила обробки персональних даних.

Data Lineage може допомагати визначати поширення інформації між системами.

Наприклад, контактні реквізити фізичної особи зберігаються в CRM та передаються до DWH.

Каталог може показувати відповідні залежні таблиці.

Однак це не означає, що наявність Lineage автоматично забезпечує нормативну відповідність.

Data Inventory

Потрібно знати, які ресурси обробляють відповідні категорії персональних даних.

Purpose Limitation

Необхідно визначити мету обробки.

Access Control

Каталог метаданих не замінює реальні права доступу до СУБД.

Data Retention

Потрібно контролювати строки зберігання в усіх відповідних середовищах.

Change Impact

Нові інформаційні потоки повинні проходити відповідну оцінку.

Особливо важливо враховувати, що не всі похідні набори з персонального джерела обов’язково залишаються персональними.

Наприклад, належним чином анонімізована агрегована статистика може мати інший правовий статус.

Тому автоматичне поширення класифікацій потребує перевірки.

Практичний сценарій: зміна клієнтського довідника в холдингу

• Розглянемо умовний холдинг із чотирма ERP, центральною CRM, MDM та корпоративним DWH.
• Компанія планує змінити модель клієнтських сегментів.
• Раніше використовувалися три категорії.
• Тепер бізнес хоче запровадити п’ять.

Етап 1. Реєстрація зміни

Створюється відповідний Change Request.

Етап 2. Бізнесове визначення

Data Owner затверджує нові категорії та правила їхнього використання.

Етап 3. Аналіз метаданих

Команда визначає всі таблиці й потоки, які використовують клієнтський сегмент.

Етап 4. Impact Analysis

Формується перелік залежних ETL, Data Marts та звітів.

Етап 5. MDM

Перевіряються зміни корпоративних довідників.

Етап 6. Schema Evolution

За необхідності коригуються структури й інформаційні контракти.

Етап 7. Тестування

Виконуються перевірки сумісності та регресійні тести.

Етап 8. Історичність

Визначається, чи нові сегменти застосовуються лише до майбутніх операцій, чи також до історії.

Етап 9. Продуктивне впровадження

Зміни переносяться відповідно до затвердженого порядку.

Етап 10. Оновлення каталогу

Lineage й Business Glossary приводяться у відповідність до нової моделі.

Етап 11. Моніторинг

Контролюються результати ETL та аналітичних звітів.

Таким чином, Data Lineage допомагає зробити модернізацію передбачуванішою.

Як вимірювати ефективність автоматизованого Lineage

Для підприємства важливо оцінювати практичну користь.

Необхідно враховувати, що велика кількість автоматично зібраних зв’язків не гарантує їхньої правильності. Наприклад, каталог може містити тисячі залежностей, але пропускати один критичний динамічний SQL-запит.

Тому для важливих бізнесових процесів потрібна додаткова перевірка.

Організаційна відповідальність

Для підтримки Lineage необхідно визначити ролі. Data Owner затверджує бізнесове призначення даних.

Data Steward підтримує відповідні метадані й контролює їхню актуальність. Data Architect визначає інформаційні залежності.

ETL Developer забезпечує технічні описи перетворень. DBA підтримує відповідні метадані СУБД.

Integration Architect визначає взаємодію між корпоративними системами. BI Developer документує залежності аналітичних звітів.

Важливо, щоб каталог оновлювався як частина звичайного Change Management, а не лише під час окремого аудиту.

Компетенції Intecracy Group у Data Lineage та Impact Analysis

Автоматизація метаданих потребує поєднання кількох технологічних напрямів. Data Management IG (dmig.com.ua) спеціалізується на ETL, MDM, Data Quality, DWH та корпоративній аналітиці. Ці компетенції безпосередньо пов’язані з описом інформаційних моделей, Data Lineage, Business Glossary та контролем впливу змін на аналітичні результати.

IQusion IT (iqusion.com) працює у сферах системної інтеграції, електронного документообігу та BPM. Відповідні компетенції важливі для аналізу міжсистемних залежностей, API-контрактів і процесів управління змінами. Softline IT (softline.kiev.ua) має компетенції в серверній, мережевій інфраструктурі та системах зберігання. Вони можуть забезпечувати надійну експлуатацію платформи метаданих та її підключення до корпоративних джерел.

SL Global Service (sgs4business.com) спеціалізується на хмарній інтеграції, віртуалізації та гібридній інфраструктурі. Такі напрями можуть використовуватися для каталогізації інформаційних ресурсів, розподілених між локальними й хмарними середовищами.

При цьому правильність бізнесових визначень і пріоритети аналізу повинні встановлюватися відповідними власниками інформаційних доменів.

Практичні орієнтири для впровадження

Data Lineage стає важливим компонентом корпоративного управління інформаційною архітектурою. Зі зростанням кількості ERP, CRM, ETL, DWH та аналітичних сервісів підприємствам дедалі складніше встановлювати всі залежності вручну.

Apache Atlas, системні метадані СУБД та інформація ETL-платформ можуть використовуватися для автоматизації.

Проте автоматичний збір метаданих не гарантує повного розуміння бізнесової семантики. Тому необхідно поєднувати технічний Lineage із Business Glossary, MDM, Data Governance та відповідними процедурами перевірки.

Особливого значення набуває Impact Analysis, який дозволяє визначати наслідки змін до їхнього продуктивного впровадження.

Головний принцип автоматизованого Data Lineage полягає в тому, що кожна критична корпоративна зміна повинна супроводжуватися зрозумілою інформаційною картою: звідки походять дані, які перетворення вони проходять і які системи та бізнесові показники можуть бути зачеплені.