Ризик-менеджмент у проєктах ЦТ. Прийняття рішень в умовах невизначеності

Тема 2: Управління проєктами у військовому середовищі · Заняття 4

Теоретична довідка (питання 1–7)

1. Ідентифікація та класифікація ризиків: ризик-матриця та RAID-log

1.1. Поняття ризику

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

1.2. Методи ідентифікації

мозковий штурм команди й стейкхолдерів;
аналіз аналогів (які ризики реалізувалися в подібних проєктах);
чек-листи типових ризиків;
аналіз припущень (кожне припущення — потенційний ризик).

1.3. Класифікація ризиків

Категорія	Приклади
Технічні	Несумісність систем, недостатня продуктивність, дефекти.
Організаційні	Ротація ключових людей, зміна пріоритетів «згори».
Нормативні	Затримки погоджень, зміна вимог, незавершена реєстрація.
Ресурсні	Брак фахівців, бюджету, часу.
Безпекові	Вимоги ЗІ, ДСК, витік даних, компрометація доступів.

1.4. Ризик-матриця та RAID-log

Кожен ризик заноситься до RAID-log і позиціонується на ризик-матриці за двома вимірами: ймовірність настання та вплив (наслідки). Це основа для пріоритезації — увагу зосереджують на ризиках у «червоній» зоні.

1.5. Позитивні ризики (можливості)

Ризик може мати й позитивний характер — це можливість, яку варто використати. Наприклад, поява готового перевіреного рішення від іншого підрозділу може скоротити строки. Позитивні ризики теж фіксують у RAID-log і планують дії щодо їх реалізації (використати, підсилити, поділитися).

Типові помилки:

ідентифікація ризиків «одноразово» на старті й забуття про них;
формулювання ризику надто загально («щось піде не так»);
змішування ризику (ще не сталося) і проблеми (вже сталося).

Проміжний висновок: ідентифікація й класифікація — перший крок; ризик-матриця перетворює перелік на пріоритети.

2. Методи якісного та кількісного аналізу ризиків

2.1. Якісний аналіз

Якісний аналіз оцінює ймовірність та вплив кожного ризику за шкалами (низький/середній/високий) і пріоритезує ризики за матрицею. Це швидкий метод, достатній для більшості проєктів ЦТ.

2.2. Кількісний аналіз

Кількісний аналіз надає ризикам числові оцінки: очікувані втрати = ймовірність × вплив (у грошах, днях, ресурсі). За потреби застосовують сценарний аналіз (оптимістичний/базовий/песимістичний). Кількісний аналіз доречний для найкритичніших ризиків або великих проєктів.

Приклад. Ризик затримки погодження: ймовірність 50%, вплив — 3 тижні зсуву. Очікуваний вплив ≈ 1,5 тижня, що враховують у резерві часу.

2.3. Пріоритезація

Ризики ранжують за добутком «ймовірність × вплив». Найвищий пріоритет — високоймовірні ризики з високим впливом (червона зона матриці). Саме на них спрямовують ресурс реагування.

2.4. Приклад розрахунку очікуваних втрат (EMV)

Кількісний метод EMV (Expected Monetary Value) = ймовірність × вплив. Дозволяє порівняти ризики й обґрунтувати резерв:

Ризик	Ймовірність	Вплив (дні)	Очік. втрати
Затримка погодження ТЗ	50%	20	10 дн
Несумісність систем	30%	15	4,5 дн
Ротація PM	20%	10	2 дн

Висновок: найбільші очікувані втрати — від затримки погодження (10 дн), тому саме на цей ризик спрямовують основний ресурс реагування й закладають найбільший резерв.

Типові помилки:

оцінка «на око» без шкал ймовірності/впливу;
однакова увага до всіх ризиків без пріоритезації.

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

3. Issue vs risk: ключові відмінності та підходи до реагування

Розрізнення risk/issue — одна з найважливіших практичних навичок. Плутанина цих понять призводить або до паніки через ризики, або до запізнілої реакції на проблеми.

Ознака	Risk (ризик)	Issue (проблема)
Стан	Ще НЕ настав.	Уже настав.
Дія	Керуємо ймовірністю, готуємо реагування.	Реагуємо негайно, за потреби ескалюємо.
Горизонт	Майбутнє.	Теперішнє.

Приклад. «Підрядник може не встигнути» — ризик (готуємо запасний план). «Підрядник не надав систему вчора» — issue (діємо зараз).

Проміжний висновок: risk — про майбутнє (готуємось), issue — про теперішнє (реагуємо); нереалізований ризик може стати issue.

4. Escalation criteria та risk owner

4.1. Власник ризику (risk owner)

Кожен ризик має власника — особу, відповідальну за моніторинг ризику й виконання плану реагування. Ризик без власника не контролюється. Власник не обов’язково керівник проєкту — це той, хто найкраще може впливати на ризик.

4.2. Критерії ескалації

Escalation criteria — заздалегідь визначені умови, за яких ризик або проблема виносяться на вищий рівень управління:

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

Ескалація — це керована управлінська дія, а не «скарга». Своєчасна ескалація часто рятує проєкт.

4.3. Комунікація ризиків командуванню

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

Приклад. «Ризик: погодження ТЗ може затриматися на 3 тижні (загроза віхи пілоту). Робимо: ранній старт узгодження. Потрібно: сприяння в пришвидшенні погодження органом ЗІ».

Типові помилки:

ризики без призначених власників;
ескалація «наприкінці», коли вже пізно;
сприйняття ескалації як визнання провалу.

Проміжний висновок: власник ризику й чіткі критерії ескалації перетворюють ризик-менеджмент на керований процес.

5. Contingency planning: запасні плани для критичних ризиків

5.1. Mitigation і contingency

Для критичних ризиків готують два типи заходів:

Mitigation (пом’якшення) — дії для зниження ймовірності або впливу ризику заздалегідь (наприклад, ранній старт погоджень).
Contingency (запасний план) — запасний план на випадок, якщо ризик усе ж реалізується (наприклад, альтернативний постачальник).

5.2. Резерви

Під найкритичніші ризики закладають резерв часу й ресурсу (contingency reserve). Це не «запас про всяк випадок», а обґрунтований резерв під конкретні ідентифіковані ризики.

5.3. Стратегії реагування

уникнути (змінити план, щоб ризик не виникав);
зменшити (mitigation);
передати (наприклад, договірні зобов’язання підрядника);
прийняти (з підготовленим contingency або свідомо).

5.4. Приклад плану реагування для критичного ризику

Ризик: «затримка погодження ТЗ органом ЗІ на 2–4 тижні» (ймовірність висока, вплив високий — критична зона).

Власник: власник — керівник проєкту (PM);
Mitigation: надіслати ТЗ на погодження на 3 тижні раніше планового старту розробки; попередньо узгодити вимоги ЗІ з органом на етапі чернетки ТЗ;
Contingency: якщо затримка настає — ескалація до командування з проханням сприяння; паралельно готувати роботи, що не залежать від погодженого ТЗ;
Критерії ескалації: перевищення 2 тижнів затримки → ескалація; загроза віхи пілоту → ескалація на рівень вище.

Типові помилки:

план реагування у вигляді «бути уважним» без конкретних дій;
відсутність запасного плану для критичних ризиків;
резерв «на око» без прив’язки до конкретних ризиків.

Проміжний висновок: для критичних ризиків потрібні і mitigation (заздалегідь), і contingency (на випадок реалізації).

6. Специфічні ризики ЦТ у ЗСУ

Проєкти ЦТ у ЗСУ мають характерний набір ризиків, який офіцер ЦТ має знати «напам’ять» і закладати в план від початку.

Ризик	Mitigation	Contingency
Безпека / ДСК, доступи	Раннє залучення органу ЗІ; вимоги ЗІ у ТЗ.	План обмеження доступів, реагування на інцидент.
Затримки погоджень	Ранній старт узгоджень; запас часу.	Перепланування віх, ескалація.
Зміна вимог «згори»	Фіксація припущень; гнучка архітектура.	Scope change control, перегляд плану.
Залежність від підрядника	Права на код; аудит; уникнення lock-in.	Альтернативний постачальник, ескроу коду.
Ротація ключових фахівців	Документація, розподіл знань.	Заміна, передача справ.

Типові помилки:

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

Проміжний висновок: специфічні ризики ЗСУ передбачувані — їх треба закладати в план від початку, а не «долати» постфактум.

7. Регулярний перегляд ризиків на синхронізаційних нарадах

Ризик-менеджмент — це процес, а не разова дія на старті. Ризики переглядають регулярно (наприклад, щотижня на синхронізації): статус кожного ризику, зміна оцінки, нові ризики, закриті ризики, ефективність реагування.

Типовий порядок перегляду ризиків на нараді:

перевірити статус критичних ризиків і хід реагування;
оновити оцінки (ймовірність/вплив) за новими даними;
додати нові ризики, виявлені за тиждень;
закрити ризики, що втратили актуальність;
перевести реалізовані ризики в issues й призначити реагування.

Приклад. Щотижневий перегляд RAID-log: ризик «затримка погодження» підвищив ймовірність → підсилюємо mitigation (ескалація); ризик «брак доступів» реалізувався → став issue, реагуємо.

Типові помилки:

ризик-менеджмент лише на старті проєкту;
RAID-log ведеться, але не переглядається;
нові ризики не додаються протягом проєкту.

Проміжний висновок: цінність ризик-менеджменту — у регулярності; список ризиків має «жити» разом із проєктом.

Прийняття рішень в умовах невизначеності

Типи невизначеності

Ризик-менеджмент тісно пов’язаний із прийняттям рішень за неповних даних. Розрізняють: «відому невідомість» (ідентифіковані ризики, які можна оцінити й спланувати реагування) та «невідому невідомість» (непередбачені події, під які тримають загальний резерв).

Підходи до рішень в умовах невизначеності

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

Оборотні та необоротні рішення

Оборотні рішення (які легко відкотити) ухвалюють швидко, не витрачаючи час на надмірний аналіз. Необоротні рішення (важко або неможливо скасувати — наприклад, вибір базової архітектури чи підрядника з lock-in) потребують ретельнішого аналізу й, за можливості, пілоту. Розрізнення цих типів економить час і знижує ризик.

Приклад. Вибір формату звіту — оборотне рішення (ухвалюємо швидко). Вибір платформи для ІКС без прав на код — майже необоротне (аналізуємо ретельно, закладаємо вихід).

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

8. Практична вправа: оцінка та планування реагування на ризики

Мета вправи: для типового проєкту ЦТ слухачі формують risk register: ідентифікують ≥6 ризиків, оцінюють за матрицею, визначають власників і плани реагування.

Вихідні дані: опис проєкту впровадження ІКС; ризик-матриця (Додаток 1); шаблон risk register (Додаток 2).

Форма роботи: у парах/трійках, з подальшою презентацією 2–3 register.

Порядок виконання

Ідентифікувати ≥6 ризиків різних категорій (технічні, нормативні, ресурсні, безпекові) — 20 хв.
Оцінити кожен ризик за ймовірністю та впливом; розмістити на ризик-матриці — 20 хв.
Для 3 найкритичніших визначити власника, mitigation і contingency — 20 хв.
Взаємна перевірка та презентація 2–3 register із розбором — 10 хв.

Еталонне проходження (зразок для викладача)

Ідентифікація. Затримка погодження ТЗ (нормативний); несумісність з наявними системами (технічний); брак фахівців (ресурсний); витік ПД через надмірний доступ (безпековий); ротація PM (організаційний); залежність від підрядника (організаційний).

Оцінка. Затримка погодження — висока/високий (червона зона); витік ПД — середня/високий; ротація PM — середня/середній тощо.

Реагування (для критичних). Затримка погодження: власник — PM; mitigation — ранній старт узгоджень і запас часу; contingency — ескалація й перепланування. Витік ПД: власник — BA; mitigation — рольова модель у ТЗ; contingency — обмеження доступів, повідомлення.

Методичні вказівки викладачу

Під час роботи викладач контролює: (1) чи розрізняють risk та issue; (2) чи є власники ризиків; (3) чи план реагування конкретний (а не «бути уважним»); (4) чи охоплено безпекові й нормативні ризики. Для розбору обирає один сильний register і один із типовими помилками.

Контрольні питання

Як ідентифікувати та класифікувати ризики проєкту ЦТ?
Чим якісний аналіз ризиків відрізняється від кількісного?
У чому різниця між issue та risk і як це впливає на реагування?
Що таке risk owner та escalation criteria?
Чим mitigation відрізняється від contingency? Наведіть приклад.
Назвіть специфічні ризики ЦТ у ЗСУ та типові заходи реагування.
Чому ризик-менеджмент має бути регулярним процесом?

Завдання на самостійну підготовку

Тема: Управління ресурсами та командою проєкту.

Опрацювати принципи формування проєктної команди та розподілу ролей.
Описати підходи до мотивації та управління ефективністю команди в умовах воєнного часу.
Сформувати risk register для реального проєкту свого підрозділу (≥6 ризиків із планами реагування).

Додаток 1. Ризик-матриця (ймовірність × вплив)

Ймовірність \ Вплив	Низький	Середній	Високий
Висока	Середній	Високий	Критичний
Середня	Низький	Середній	Високий
Низька	Низький	Низький	Середній

Зона реагування: критична/висока (червона) — обов’язкове реагування з власником і планом; середня (жовта) — моніторинг; низька (зелена) — прийняти.

Додаток 2. Шаблон risk register

№	Ризик	Ймовір.	Вплив	Власник	Реагування (mitigation / contingency)
1
2
3
4
5
6

Додаток 3. Критерії оцінювання risk register

Критерій	Бали	Орієнтир
Ідентифікація: ≥6 ризиків різних категорій	0–3	Охоплено безпекові й нормативні ризики.
Оцінка за матрицею (ймовірність × вплив)	0–2	Пріоритезація коректна.
Власники ризиків призначені	0–2	Кожен критичний ризик має власника.
Реагування конкретне (mitigation + contingency)	0–3	Не «бути уважним», а конкретні дії.
Разом	0–10	9–10 «відмінно»; 7–8 «добре»; 5–6 «задовільно».

Додаток 4. Приклад заповненого risk register (для розбору)

№	Ризик	Ймов.	Вплив	Власник	Реагування
1	Затримка погодження ТЗ.	Вис.	Вис.	PM	M: ранній старт, запас часу. C: ескалація.
2	Витік ПД через надмірний доступ.	Сер.	Вис.	BA	M: рольова модель у ТЗ. C: обмеження доступів.
3	Залежність від підрядника.	Сер.	Вис.	DT Lead	M: права на код, аудит. C: альт. постачальник.
4	Ротація PM.	Сер.	Сер.	DT Lead	M: документація. C: передача справ.

Додаток 5. Глосарій ключових термінів

Ризик (risk) — можлива майбутня подія, що вплине на проєкт.
Проблема (issue) — подія, що вже настала й потребує реагування.
Ризик-матриця — інструмент оцінки ризику за ймовірністю та впливом.
Risk register — реєстр ризиків із оцінкою, власниками та планами реагування.
Risk owner — власник ризику, відповідальний за моніторинг і реагування.
Mitigation — заходи зниження ймовірності/впливу ризику заздалегідь.
Contingency — запасний план на випадок реалізації ризику.
Escalation criteria — умови винесення ризику/проблеми на вищий рівень.
Contingency reserve — резерв часу/ресурсу під ідентифіковані ризики.

Додаток 6. Структура категорій ризиків (чек-лист для ідентифікації)

Використовується під час мозкового штурму, щоб не пропустити категорію ризиків:

Категорія	Питання для перевірки
Технічні	Чи сумісне рішення з наявними системами? Чи вистачить продуктивності?
Нормативні	Чи встигнемо з погодженнями? Чи є ризик зміни вимог? Чи завершена реєстрація?
Безпекові	Чи закладено ЗІ/ПД? Чи контролюються доступи? Чи є ризик витоку?
Ресурсні	Чи вистачить людей, часу, бюджету?
Організаційні	Чи є ризик ротації, зміни пріоритетів, залежності від підрядника?

Додаток 7. Шаблон і приклад ескалаційного повідомлення

Структура ескалації (для доповіді командуванню):

Елемент	Зміст
Ризик / проблема	Що саме загрожує (коротко).
Наслідок	Що станеться, якщо не втрутитися (строк, віха, безпека).
Що вже зроблено	Вжиті заходи реагування.
Потрібне рішення	Що конкретно потрібно від командування й до якого строку.

Приклад:

«Погодження ТЗ органом ЗІ затримується (2 тижні). Наслідок — зсув віхи пілоту, cost of delay ≈ 100 год/тиждень особового складу. Зроблено: направлено ТЗ достроково, узгоджено вимоги на етапі чернетки. Потрібно: сприяння командування у пришвидшенні погодження до 15 числа».