Цифровий двійник ланцюга поставок Національного рівня. Як впровадження Data Governance дозволяє змінити правила гри

Author: Pavlo Palinichak

LOGOS.

Античні філософи називали так силу, що перетворює первісний Хаос на впорядкований Космос.

У сучасному державному управлінні таким Логосом є дані.

Але є проблема: дані без управління є чистим хаосом. Це шум.

Шум у тисячах Excel-таблиць, де кожен підрозділ має свою правду, свій формат і своє бачення реальності.

Сьогодні я хочу розповісти вам історію про наш шлях до цього порядку. Це історія про те, як ми в «Медичних закупівлях України» побудували систему інтегрованого планування (IBP) - систему, яка об'єднує фінанси, закупівлі, логістику та облік забезпечення лікарськими засобами та медичними виробами на Національному рівні в єдиний живий цифровий організм.

І цей шлях не про потоки даних чи дашборди. Це про Data Governance.

Крок 0. Що таке IBP і навіщо воно нам? 

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

У контексті державних закупівель ліків IBP - це про перетворення закупівлі з "процесу придбання" на "процес гарантування наявності”. Це єдина цифрова модель, яка автоматично перераховує план поставок, якщо змінюється бюджет, або сигналізує про потенційну затримку логістики, якщо виникають проблеми на етапі тендеру.  

IBP - це ядро, яке об’єднує три головні домени: 

• Домен фінансів - бюджетні програми, графіки платежів. 

• Домен закупівель - тендерні процедури, контрактування, терміни виробництва. 

• Домен логістики - складські залишки, споживання в лікарнях, терміни придатності. 

Рис. 1, IBP як ядро, що поєднує домени даних.   Зображення створене за допомогою моделі Nano Banana 2 

Проблемою є те, що ці частини часто живуть окремим життям. Фінансисти планують гроші в Excel №1, закупівельники моніторять договори в Excel №2, а логісти дивляться на склади в системі №3. Це класична модель з відокремленими силосами даних.  

Задача IBP - “склеїти” ці звіти в єдину версію правди, яка дасть відповідь на головне питання:  

“Чи буде необхідна таблетка в руках у пацієнта  15 жовтня 2027 року?” 

Ми маємо прорахувати ланцюгову реакцію. Якщо сьогодні тендер затримався на 10 днів - як це вплине на залишки в лікарні через півтора року? 

IBP - це цифровий двійник ланцюга постачання. Це інструмент, який перетворює стратегію закупівлі на оперативний план дій. 

І здавалося б, задача зрозуміла: з’єднай таблиці - і маєш інтегроване планування! Але тут ми почали знімати перший шар… і побачили прірву. 

Крок 1. Пастка красивих звітів. 

На початку завжди виникає спокуса: давайте просто зберемо дані до купи та намалюємо (якісь) гарні графіки. Всі ж люблять графіки, так? 

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

І це не важко. Треба мати історію, натхнення та достатньо часу на реалізацію бажаного.  

Але без Data Governance (управління даними) будь-який прогноз та будь-який дашборд - це лише гарна картинка. Ви бачите на екрані, що ліків вистачить на 5 місяців, але за тиждень виявляється, що в одному регіоні надлишок, а в іншому - дефіцит, бо хтось вніс назву препарату з помилкою, а хтось забув оновити статус поставки. 

Дашборд без управління - це ілюзія, запакована в гарний інтерфейс. Якщо ви не можете пояснити походження кожної цифри та не впевнені в її якості, вам ніхто не повірить. А без довіри не буває планування. 

Крок 2. Суспільний договір 

Тож ми почали з Конституції. Дані - це стратегічний актив підприємства.  

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

Нашою Конституцією стала Політика управління даними. 

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

Зокрема Політика має визначити такі поняття, як Власник даних, Стюард даних, Комітет управління даними та Chief Data Officer. 

Власник даних - це обов’язково не ІТ. Це керівник закупівлі, начальник відділу логістики, тощо. Їх процеси - це робота з даними (будь-які процеси це робота з даними, якщо дивитись під правильним кутом), і ті дані, які вони створюють в межах своїх процесів, належать їм. І вони відповідають за їх чистоту так само, як відповідають за виконання безпосередніх обов’язків. 

Також ми створили Комітет управління даними (КУД). Це вищий колегіальний орган, який приймає рішення, наприклад щодо того як мають рахуватись залишки, або як класифікувати новий тип контракту, тощо. 

Але не думайте що впровадження Data Governance це легко і просто. Просто взяти DAMA DMBOK® і написати гарну політику - недостатньо. Політика має задавати ритм всьому процесу управління даними як активом. 

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

А коли ви скажете людям що до їх обов’язків тепер належить ще й якість даних - з’явиться багато питань. І це нормально. Через це треба пройти.  Рухайтесь поступово та генеруйте цінність для стейкхолдерів на кожному кроці. І все вийде. 

Крок 3. Механіка довіри до даних. 

Коли з’являються правила - мають з’явитись і ті, хто контролює їх виконання. 

В класичному варіанті має існувати така роль як Data Steward. Але з огляду на обмеженість ресурсів та прагнення до ефективних Lean-процесів, ми не роздмухували штат. Натомість ми зробили ставку на “сильний центр”: роль корпоративного стюарда даних виконує відділ аналітики та управління даними. Це ядро, яке детально розуміється на процесах та потоках даних та налаштовує моніторинги та сповіщення.  

Тож ми розробили систему моніторингу якості даних, про неї я писав в попередній статті (LINK). Ця система перевіряє дані в централізованому сховищі (куди вони стікаються з усіх ІТ-систем) та щодня автоматично сповіщає відповідальних працівників відповідно до визначених бізнес-правил якості даних. 

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

Поступово наявність якісних даних в центральному сховищі даних збільшує можливості побудови різних продуктів даних. Коли люди знають що дані нормальні - люди самі переходять з одноразових ексель-файлів на сталі продукти даних та self-service аналітику. А це трансформує діяльність аналітичної функції та переводить її з функції підтримки процесів на функцію R&D. 

Крок 4. IBP 

І ось тут виникає магія. Майстер-дані, довідкові дані, нормалізація, потоки, і ще багато процесів, які можуть виглядати як непотрібні інвестиції ресурсів підприємства, в один момент “вистрілюють” можливостями та дають предиктивну силу. 

Рецепт простий: 

• Якісно спроектоване сховище даних, навіть на найпростіших технологіях,  

• Оточене оркестрованими скриптами, які здійснюють прогноз та моделювання, 

• Підключене до будь-якого BI-інструменту з правильно налаштованими дашбордами. 

  
  

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

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

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

3. Коли система бачить, що залишки на складі будуть вичерпані (з урахуванням часу на логістику та виробництво) - вона генерує задачу на закупівлю. 

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

5. Задача на закупівлю опрацьовується з урахуванням інформації від ринку (отриманої на ринкових консультаціях, що проводяться в SAP Ariba) та наявного фінансування (накази Міністерства Охорони Здоров’я). Це етап планування, результати якого незабаром стануть публічними даними у вигляді плану оголошень. 

6. Затверджений план повертається в систему. Він формує план руху коштів та план руху товару. 

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

Крім того, на кожному з цих етапів система генерує планові транзакції для відповідальних підрозділів та моніторить їх виконання. Якщо закупівля чи поставка не відбулася у визначений термін - IBP виявляє потенційний дефіцит та сигналізує стейкхолдерам. 

Наприклад: Ми бачимо в системі конкретний онкопрепарат. По факту склади повні, споживання стале і ситуація виглядає контрольованою.  

Але IBP дивиться вглиб: вона бачить, що на етапі конкретного тендеру виникла затримка. Система миттєво прокидає цю затримку через ланцюг поставок і показує що через 10 місяців ми вийдемо в дефіцит. 

Рис. 2, Приклад результату роботи моделі.  а) Прогноз запасів на Національному рівні, візуалізований на одному з дашбордів. б) Прогноз запасів на Національному рівні з поясненнями. 

Коли мова йде про 1000 номенклатурних позицій, людський мозок не здатний прорахувати всі нюанси. Система ж робить це за секунди. 

В умовах обмежених ресурсів критично важливо мати час на реакцію та маневр. 

Без якісного прогнозування неможливо отримати розкіш у вигляді часу. Без якісних даних неможливо прогнозувати. 

Висновки 

IBP в “Медичних закупівлях України” - це про стан організації, де рішення приймаються на основі даних. 

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

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

Це точка, де алгоритми рятують життя, а хаос остаточно поступається місцем порядку.