Legacy-ERP-системи в державному секторі стали вузьким місцем для розвитку та адаптації до сучасних вимог. Будь-яка зміна, інтеграція з новими державними сервісами чи оновлення функціоналу займає 3–6 місяців і часто вимагає простою. Це призводить до того, що підрозділи створюють власні «тіньові» IT-рішення, щоб обійти обмеження, а запуск нових електронних послуг чи адаптація до законодавчих змін відбувається значно повільніше, ніж у конкурентів.
Як архітектор інтеграційних рішень з 15-річним досвідом, я вважаю, що замість спроб реанімувати моноліт чи замінити його одним «великим вибухом», шлях до успішної цифрової трансформації лежить через поетапну декомпозицію legacy-ERP. Це означає винесення окремих функцій у мікросервіси з API-доступом, що дозволяє модернізувати систему без зупинки бізнесу та з мінімальними ризиками.
Чому так: архітектурні причини та організаційні виклики
Проблема legacy-ERP не лише в застарілому коді чи технологіях — вона глибоко інтегрована в організаційні процеси. ERP-системи, що створювалися десятиліття тому, були розроблені як монолітні сховища даних та бізнес-логіки. Вони не передбачали гнучкої інтеграції з десятками зовнішніх сервісів, мобільних застосунків чи швидкої адаптації до мінливих регуляторних вимог. Кожна зміна в одному модулі може мати непередбачувані наслідки для інших, перетворюючи розробку на постійний ризик.
Наприклад, у державному органі, що обробляє звернення громадян, ERP може містити інформацію про заявників, фінансові операції та кадровий облік. Якщо для інтеграції з державним порталом е-послуг (наприклад, Дією) потрібен новий API для верифікації даних, це може зачепити десятки внутрішніх процесів, які ніхто не документував. На практиці, найбільші втрати на хмару виникають не через дорогі сервіси, а через ресурси, про які всі забули через 3-4 місяці після запуску, а в контексті ERP — це забуті тестові середовища, що працюють роками.
Типова помилка: «великий вибух» замість еволюції
Найчастіша і найдорожча помилка у проєктах міграції legacy-систем, особливо в держсекторі, — це спроба замінити всю систему одним проєктом. Це стосується не тільки ERP, а й систем управління корпоративним контентом (ECM (системи управління корпоративним контентом)) чи документообігу (DMS (системи управління документами)). Ідея замінити все й одразу здається логічною на папері, але на практиці це призводить до проєктів з високим ризиком, що тривають роками, перевищують бюджети в рази і часто закінчуються провалом або заморожуванням.
Причина проста: монолітна система має тисячі неявних залежностей, які неможливо виявити на етапі планування. Спроба переписати чи замінити все одночасно означає зупинку або параліч бізнес-процесів на невизначений термін. Правильний шлях — це поетапна (phased) міграція. Вона передбачає вибір однієї функціональної області або одного бізнес-процесу, його винесення в нову систему, паралельну роботу legacy та нової системи, а потім поступове переключення користувачів. Це дозволяє контролювати ризики, отримувати швидкі результати та навчатися на кожному етапі.
Декомпозиція ERP: шлях до гнучкості
На прикладі типового сценарію в центральному органі виконавчої влади з регіональними підрозділами, що обробляє громадянські звернення та здійснює міжвідомчу взаємодію, ми бачимо, як працює декомпозиція. Їхній документообіг працює через legacy ECM з обмеженою мобільною підтримкою, а вимоги КСЗІ (комплексної системи захисту інформації) для обробки інформації з обмеженим доступом стають дедалі суворішими. Інтеграція з державним порталом е-послуг (Дія) та системою еСуд (система електронного судочинства) є важливою.
Замість заміни всієї ERP, ми фокусуємося на винесенні окремих функціональних блоків. Наприклад, модуль обробки звернень громадян може бути винесений у нову low-code BPM-платформу (системи автоматизації бізнес-процесів), як-от Scriptum (low-code BPM-платформа на UnityBase від InBase), побудовану на відкритій платформі UnityBase (open-source low-code платформа, розроблена InBase). Це дозволяє швидко створити гнучкі робочі процеси (workflow (робочі процеси)) для обробки звернень, інтегрувати їх з Дією через стандартизовані API та забезпечити мобільний доступ.
Такий підхід дозволяє розробляти нові мікросервіси та функціональні модулі, які можуть працювати паралельно з legacy-системою. Це усуває проблему довгого циклу розробки та залежності від моноліту, дозволяючи швидко виводити на ринок нові цифрові послуги. На практиці команди Softline, що спеціалізуються на системній інтеграції, вже інтегрували Megapolis.DocNet (система електронного документообігу від InBase) з державними реєстрами та системами електронного суду, забезпечуючи відповідність КСЗІ. Це дозволяє не тільки прискорити обробку звернень, а й пройти необхідну сертифікацію для державних інформаційних систем.
Ризики та обмеження: коли декомпозиція не панацея
Хоча поетапна декомпозиція є найбільш ефективним підходом, вона не позбавлена ризиків. По-перше, якщо архітектура legacy-ERP настільки заплутана, що неможливо виділити чіткі функціональні блоки, спроба декомпозиції може перетворитися на «розплутування клубка», що забере більше часу та ресурсів, ніж повна заміна. По-друге, якщо організація не готова до паралельного функціонування двох систем (legacy та нової) протягом перехідного періоду, це може призвести до хаосу та опору користувачів. Не починайте проєкт, якщо немає чіткого плану управління змінами та комунікації з кінцевими користувачами. Проєкти міграції ECM майже ніколи не провалюються через дані — вони провалюються через те, що нові маршрути узгодження виявляються непридатними для реальних щоденних винятків.
Послідовна декомпозиція legacy-ERP перетворює міграцію з високоризикованої операції на керований процес. Це дозволяє запускати нові функції без простоїв монолітної системи, поетапно модернізувати інфраструктуру та бізнес-процеси без зупинки роботи. Перш ніж запускати тендер на повну заміну ERP, зробіть аудит ключових бізнес-процесів та визначте 2-3 найбільш критичні, які можна винести в окремі, гнучкі системи. 80% майбутніх проблем видно вже там, і це нічого вам не коштує.