Чому сильні GovTech-продукти застрягають і як цього уникнути

Про ролі, вплив і роботу зі стейкхолдерами в державній системі.

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

На практиці все виглядало так: домовленості тягнулися місяцями, керівники змінювалися, погодження не було. Я буквально ходив по кабінетах, стукав, пояснював — і часто чув щось на кшталт «це не до нас» або «приходьте потім». Результату не було майже рік. Керівництво на мене тиснуло, але це не допомагало.

Тоді я ще не знав слів «stakeholder mapping» і не думав категоріями ролей та ризиків. Я просто намагався «дотиснути» процес, бо іноді це працює.

Перелом стався тоді, коли я перестав триматися за одну роль і зібрав партнерську модель взаємодії, яка пережила кілька змін керівників департаментів.

Люди змінювалися, але проєкт не обнулявся. Скажу більше: компанія і проєкт продовжили працювати, навіть коли я вже там не працював.

Зараз я вже знаю: це був кейс публічно-приватного партнерства.

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

Спойлер: це проблема не тільки в Україні. Коли писав цю статтю, я спеціально подивився, як це описують на глобальному рівні: така ж сама проблема, бо це механіка будь-якої великої системи.

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

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

Саме тому сильний продукт може застрягти «на рівному місці». Не тому що він поганий.

А тому що команда дивиться на систему як на просту воронку: «написали лист → отримали відповідь → підписали → запустили».

У GovTech так не працює. І це не якась унікальна «українська» проблема.

Ця стаття — продовження моєї роботи зі stakeholder mapping у межах Innovation Bootcamp. Це навчально-експериментальна платформа в рамках програми відкритих інновацій для державного сектору GovTech Lab Ukraine, яку реалізує Global Government Technology Centre in Kyiv (GGTC Kyiv) — другий у світі GovTech-центр, співзаснований Всесвітнім економічним форумом і Міністерством цифрової трансформації України.

У межах GovTech Lab Innovation Bootcamp команди держслужбовців та стартапів спільно працюють над практичними цифровими рішеннями для державного сектору, вдосконалюють ідеї та готують їх до пілотного впровадження.

У межах Innovation Bootcamp я розробив воркшоп, де учасники працювали з ролями, будували карту впливу, визначали ключових гравців (державні органи, бізнес, громади, донори, медіа) та вчилися читати їхні реальні очікування — політичні, фінансові, соціальні чи емоційні.

Чому ця тема взагалі важлива?

Бо прямо на воркшопі я побачив: команди плутаються, хто тут стейкхолдер і яку роль він реально грає. До речі, це і в українських, і в іноземних команд. Навіть досвідчені учасники казали, що для них це нова методологія — раніше вони з цим системно не працювали. А значить, є ризик, що без цього інструмента ви будете втрачати місяці й «пілотувати» продукт замість того, щоб доводити його до впровадження.

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

І тут треба назвати ціну прямо якщо : якщо не робити stakeholder mapping, то з мого досвіду ціна = 6–12 місяців зависання.

За цей час ви:

• платите зарплати команді,
• інвестуєте в розробку,
• готуєте документи,
• «тримаєте» комунікацію,
• живете в очікуванні «ось-ось».

А потім реальність робить простий хід: людина, з якою ви 6 місяців синхронізувалися, йде в декрет або змінює позицію або підрозділ реорганізували або з’явився новий керівник і перезібрав пріоритети.

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

Ех, якби мені це сказали 15 років тому — було б легше.

Для кого стаття? — для тих, хто працює зі складними системами:

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

Що має статися після прочитання?

Розуміння як рухати проект через систему інтересів всіх учасників.

Часто ми не розуміємо, чому процес зупинився: листи не отримують відповіді, вас перекидають між підрозділами, просять «ще довідку», «ще погодження», «ще лист». І найгірше — причина не проговорюється.

Тут важливо зафіксувати: це не про «погану державу» а про те, що в системі є ролі, які не мають права сказати «так». Є ролі, які впливають, навіть не будучи в оргструктурі. І якщо команда цього не бачить — вона витрачає місяці не туди.

Рівні стейкхолдерів, що це?

Реально ти майже ніколи не знаєш, хто блокує і чому, поки не намалюєш собі картину впливу.

Бо блокування в GovTech часто виглядає не як «ні», а виглядає воно так:

• мовчання,
• нескінченні уточнення,
• «перекиньте в інший департамент»,
• «давайте після свят/після бюджету/після кадрових змін»,
• «нам треба ще один лист підтримки».

І саме тому stakeholder mapping — це про те, щоб перестати дивитися на реальність як на «чорне/біле» і побачити багатовимірну систему, де одночасно існують інтереси, страхи, обмеження і люди.

Чотири реальні типи стейкхолдерів у GovTech

У GovTech є чотири типи стейкхолдерів, які визначають долю будь-якого продукту:

1) Decision Makers — ті, хто формально приймає рішення

Міністерство, заступники, директори департаментів.

• Їхній біль: відповідальність, ризики, політичний тиск.
• Чого бояться: скандалів, збоїв, затримок, публічних провалів.

2) Gatekeepers — ті, хто блокує або відкриває двері

Юристи, ІТ-безпека, фінансові підрозділи, комітети, служби.

• Біль: навантаження, відсутність повноважень сказати «так».
• Бояться: порушити регуляцію або накосячити з бюджетом.

3) Hidden Influencers — ті, хто впливає неформально

Радники, партнери, експерти, донори, медіа.

• Біль: їх не враховують, а потім «горить».
• Бояться: втратити контроль над порядком денним.

Тут важливо: hidden influencers — це не «таємний персонаж у тіні». Частіше це контекст і мережа: хто з ким радиться, хто формує рамку, хто підсилює або знецінює рішення.

4) Beneficiaries — ті, хто буде користуватися продуктом

Громади, службовці, бізнес, громадські організації.

• Біль: складні сервіси, недоступність, низька якість.
• Бояться: що продукт буде «не для них» → і тоді включається саботаж.

Ключова думка проста: 95% команд бачать лише одну групу.

Що саме робити, щоб проєкт не застряг? Мій підхід дуже приземлений.

1. Виписати всіх стейкхолдерів (без самообману, що «нам достатньо одного контакта»).
2. Побудувати карту впливу: хто ухвалює, хто блокує, хто впливає, хто користується.
3. Поєднати це з дорожньою картою: на якому кроці який стейкхолдер стає критичним.
4. Зробити ціннісну пропозицію для кожної групи.
5. Йти в 1:1 розмови і синхронізувати очікування до того, як ви вклалися в розробку.

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

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

Ось простий адаптований фрейм:

• Ми пропонуємо: → [продукт / сервіс]
• Для кого: → [аудиторія / сегмент]
• Яку проблему вирішує: → [конкретна потреба / бар’єр]
• Завдяки чому це працює: → [механіка / ключові переваги]
• Який результат отримує стейкхолдер: → [вимірюваний ефект]
• Чому саме ми: → [унікальність / експертиза / модель]
• Додаткова вигода: → [сталість / економія ресурсів / довгий ефект]

Висновок

Перемагає той, хто бачить систему, а не тільки «свій шматок».

У великих системах все впирається в оптику: хто як дивиться на ризики, що для кого є успіхом, і хто реально впливає на рішення.

Stakeholder mapping — це спосіб налаштувати цю оптику.