CEO Kitsoft Олександр Єфремов у своїй авторській колонці для GovInsider розповів, чому традиційний проєктний підхід стримує масштабування цифрових державних послуг та як змінити модель їх розробки.
За останні сім років Олександр працював із Міністерством цифрової трансформації України та іншими державними установами над створенням понад 200 цифрових державних послуг у межах екосистеми Дія та з використанням Liquio — low-code платформи з відкритим кодом, розробленої командою Kitsoft.
Спираючись на цей досвід і результати аналізу 28 проєктів, Олександр представив концепцію Digital Public Service Assembly Line — операційну модель, яка дозволяє державам системно створювати й масштабувати цифрові послуги.
Публікуємо головні тези авторської колонки для GovInsider.
Зображення: СЕО Kitsoft Олександр Єфремов
Чому традиційний проєктний підхід не працює в масштабах держави
Уряди вже навчилися створювати цифрові послуги. Проблема виникає, коли потрібно розробити не одну послугу, а сотні.
Якщо кожну послугу замовляти, проєктувати й розробляти окремо та припустити, що її створення займає дев'ять місяців, то для портфеля з 2000 послуг знадобиться 18 000 місяців роботи. Навіть якщо одночасно працюватимуть 100 команд, за такого підходу реалізація портфеля триватиме близько 15 років.
За цей час зміняться законодавство, державні інституції та очікування громадян.
Ми проаналізували 28 проєктів із розробки цифрових державних послуг і виявили шість системних проблем: фрагментованість портфелів послуг, відсутність єдиних підходів до розробки, складні регуляторні процеси, обмежені ресурси та компетенції, технологічну фрагментацію й недостатнє вимірювання результатів.
Головна перешкода полягає у відсутності спільної операційної моделі, яка дозволяє масштабувати розробку цифрових послуг.
Як працює конвеєр створення цифрових державних послуг
У промисловості кожен продукт може відрізнятися від інших, але процес його виробництва залишається стандартизованим. Цей принцип можна застосувати й до цифрових державних послуг.
Кожна послуга має власні законодавчі вимоги, залучені установи та шлях користувача. Проте шлях від ідеї до запуску послуги передбачає однакову послідовність рішень.
Digital Public Service Assembly Line охоплює весь життєвий цикл цифрової послуги: від планування портфеля та дослідження потреб до проєктування, розробки, тестування, запуску, подальшого вдосконалення й завершення роботи.
Водночас паралельно працюють п'ять напрямів: продукт і користувачі, інженерія, юридичні та регуляторні питання, безпека й дані, ресурси та закупівлі.
Це дозволяє синхронізувати технічну розробку, нормативні зміни та організаційну підготовку державних установ.
Наприклад, якщо технічно готова послуга очікує на ухвалення нормативного акта, проблема виникла значно раніше. Юридичну та технічну роботу потрібно було синхронізувати ще на етапі проєктування, щоб послуга та необхідне для її роботи правове регулювання були готові одночасно.
Навіщо потрібні Quality Gates
Ще один важливий елемент моделі — Quality Gates, або контрольні точки між етапами розробки.
На кожній із них ухвалюють рішення, чи може послуга переходити до наступного етапу. При цьому держава зберігає можливість зупинити роботу, якщо необхідні умови не виконані.
Чи справді послугу потрібно включати до портфеля? Чи підтвердило дослідження доцільність її розробки? Чи готовий дизайн до реалізації? Чи відповідає рішення вимогам безпеки? Чи готова бета-версія до використання громадянами?
За результатами нашого аналізу, більшість невдач у реалізації проєктів не були пов'язані з інженерною розробкою. Вони виникали там, де мала бути контрольна точка, але її не було. Робота продовжувалася, оскільки ніхто не мав повноважень її призупинити.
Таким чином, Quality Gates вбудовують контроль і відповідальність безпосередньо в процес створення цифрових державних послуг.
Як повторне використання рішень прискорює цифровізацію
У традиційній проєктній моделі кожна команда значну частину роботи починає з нуля.
Натомість Digital Public Service Assembly Line передбачає повторне використання не лише програмних компонентів, а й готових процесів, інтеграцій, моделей даних, юридичних документів і результатів тестування.
Наприклад, інтеграція з державним реєстром — це не просто програмний код. Вона також включає погоджені правила обміну даними, затверджену модель доступу та пройдену перевірку безпеки. Повторне використання такої інтеграції дозволяє не проходити всі погодження заново.
Так само послуги з реєстрації, отримання дозволів чи подання заявок на гранти можуть використовувати спільну структуру, компоненти та процеси.
Завдяки цьому кожна наступна послуга спирається на результати попередніх розробок.
«З часом питання змінюється: замість “Як нам створити цю послугу?” команди починають запитувати “Що з уже створеного ми можемо використати повторно?”»
Саме такий підхід ми застосовували в екосистемі Дія. Кожна реалізована послуга залишає після себе не лише готові технологічні рішення, а й досвід, який стає частиною спільного процесу розробки наступних послуг.
Чому це важливо для майбутнього GovTech
Спільна цифрова інфраструктура, зокрема системи електронної ідентифікації та обміну даними, є необхідною основою для створення державних онлайн-послуг.
Digital Public Service Assembly Line доповнює цю основу можливістю повторно використовувати не лише технологічні компоненти, а й процеси, готові рішення та накопичений досвід команд.
Кожна реалізована послуга допомагає вдосконалювати спільну модель розробки. Досвід організації юридичної роботи, проведення бета-тестування чи перевірок безпеки стає частиною процесу створення наступних послуг.
Така операційна модель також створює передумови для застосування штучного інтелекту в державному секторі. Як зазначає Олександр, AI складно інтегрувати в сотні розрізнених процесів, натомість повторювані процеси відкривають можливості для його використання.