Призначення

Журнал ризиків OKR — це реєстр загроз, які можуть завадити досягненню OKR або підірвати впровадження OKR-системи в організації. Кожен ризик фіксується, оцінюється за ймовірністю та впливом, має план реагування та відповідального.

Коли використовувати:

На етапі планування кварталу — для ідентифікації ризиків до старту.
На щотижневих check-in Чемпіона — для перегляду та оновлення статусу ризиків.
При зниженні впевненості KR нижче 0.4 — для формалізації ризику та плану дій.
При впровадженні OKR у нових командах — для фіксації ризиків адаптації.
На квартальній ретроспективі — для аналізу, які ризики спрацювали і наскільки ефективним був план.

Журнал ризиків відрізняється від списку блокерів. Блокер — це проблема, яка вже настала. Ризик — це проблема, яка може настати. Журнал ризиків працює на випередження: ви ідентифікуєте загрозу до того, як вона стала блокером, і готуєте план реагування заздалегідь.

Ведення журналу ризиків — відповідальність OKR Чемпіона. Переглядає журнал: Чемпіон щотижня, керівництво — щомісяця або при появі ризиків з рівнем "Високий".

Шаблон

Матриця оцінки ризиків (3x3)

	Вплив: Низький (L)	Вплив: Середній (M)	Вплив: Високий (H)
Ймовірність: Висока (H)	Середній пріоритет	Високий пріоритет	Критичний пріоритет
Ймовірність: Середня (M)	Низький пріоритет	Середній пріоритет	Високий пріоритет
Ймовірність: Низька (L)	Прийняти	Низький пріоритет	Середній пріоритет

Визначення рівнів ймовірності:

Рівень	Визначення
Висока (H)	Ризик з великою ймовірністю спрацює протягом кварталу (>60%). Є конкретні передумови.
Середня (M)	Ризик може спрацювати (20-60%). Є деякі ознаки, але ситуація невизначена.
Низька (L)	Ризик малоймовірний (<20%), але наслідки достатньо серйозні, щоб його відстежувати.

Визначення рівнів впливу:

Рівень	Визначення
Високий (H)	Провал 1+ OKR або зупинка впровадження OKR-системи в організації.
Середній (M)	Суттєве зниження впевненості (на 0.2+) для кількох KR. Потрібен перерозподіл ресурсів.
Низький (L)	Незначна затримка або необхідність коригування плану. Не впливає на загальний результат.

Журнал ризиків

ID	Опис ризику	Ймовірність	Вплив	Пріоритет	Які OKR під загрозою	План реагування	Відповідальний	Статус	Дата останнього перегляду
R-___	___________________	H/M/L	H/M/L	___________	___________________	___________________	___________	Відкритий / Моніторинг / Спрацював / Закритий	..__
R-___	___________________	H/M/L	H/M/L	___________	___________________	___________________	___________	Відкритий / Моніторинг / Спрацював / Закритий	..__
R-___	___________________	H/M/L	H/M/L	___________	___________________	___________________	___________	Відкритий / Моніторинг / Спрацював / Закритий	..__

Визначення статусів

Статус	Визначення
Відкритий	Ризик ідентифікований, план реагування визначений, активний моніторинг.
Моніторинг	Ризик знизився, але не зник. Перевіряємо раз на 2 тижні.
Спрацював	Ризик реалізувався. Перехід до виконання плану реагування. Зафіксувати фактичний вплив.
Закритий	Ризик більше не актуальний (зник, спрацював і оброблений, або квартал завершився).

Формат плану реагування

Для кожного ризику з пріоритетом "Високий" або "Критичний" має бути детальний план:

Елемент	Опис
Превентивні дії	Що робимо зараз, щоб знизити ймовірність? ___________________
Тригер	Яка подія/метрика сигналізує, що ризик спрацьовує? ___________________
Дії при спрацюванні	Що робимо негайно, якщо ризик реалізувався? ___________________
Ескалація	Кому повідомляємо і протягом якого часу? ___________________
Вплив на OKR	Як коригуємо OKR, якщо ризик спрацював? ___________________

Заповнений приклад

Контекст: IT-компанія (120 осіб), другий квартал впровадження OKR, Q2 2026.

Журнал ризиків

ID	Опис ризику	Ймовірність	Вплив	Пріоритет	Які OKR під загрозою	План реагування	Відповідальний	Статус	Дата останнього перегляду
R-001	Втрата ключового розробника в команді Platform, який веде міграцію на нову інфраструктуру	M	H	Високий	Engineering: "Забезпечити стабільну платформу" (KR1, KR2)	Документувати процес міграції щотижня. Підготувати другого розробника як backup. При звільненні — перерозподілити scope між командою + залучити підрядника на 1 місяць.	CTO	Відкритий	12.05.2026
R-002	Команда Sales відмовляється від OKR, вважаючи систему зайвим навантаженням	H	H	Критичний	Sales: "Збільшити дохід від B2B" (всі KR). Системний ризик: падіння довіри до OKR в організації.	Провести 1-на-1 з Head of Sales до 20.05. Показати зв'язок між OKR і бонусною системою. Адаптувати формат check-in для Sales (коротший, фокус на pipeline). При відмові — ескалювати до CEO.	OKR Чемпіон	Відкритий	12.05.2026
R-003	Дані для вимірювання KR недоступні або неточні — аналітична система не налаштована	M	M	Середній	Product (KR2: retention), Customer Success (KR1: NPS)	Провести аудит джерел даних до 19.05. Для KR без автоматичних даних — визначити ручний процес збору. Виділити 2 дні Data Engineer для налаштування дашбордів.	Data Lead	Відкритий	12.05.2026
R-004	CEO втрачає інтерес до OKR через відсутність швидких результатів	M	H	Високий	Системний ризик: зупинка впровадження.	Надсилати CEO щотижневий дашборд з конкретними прикладами прогресу. Підготувати case study внутрішнього успіху (Marketing KR досягнуто на тижні 6). Провести зустріч 1-на-1 з CEO щомісяця для обговорення OKR-процесу.	OKR Чемпіон	Моніторинг	12.05.2026
R-005	Зовнішній фактор: зміна регуляторних вимог вимагає переключення Engineering ресурсів на compliance	L	H	Середній	Engineering (всі KR), Product (KR залежні від Engineering)	Моніторити регуляторний ландшафт через юридичну команду. При спрацюванні: зменшити scope Engineering OKR, перерозподілити 2 KR на Q3. Повідомити керівництво протягом 48 годин.	COO	Моніторинг	05.05.2026

Детальний план реагування для R-002 (Критичний)

Елемент	Опис
Превентивні дії	1-на-1 з Head of Sales (до 20.05). Адаптувати check-in формат: 10 хв замість 25 хв, фокус на pipeline-метриках. Показати, як OKR допоможуть обґрунтувати запит на додатковий headcount.
Тригер	Head of Sales пропускає 2+ check-in поспіль або відкрито заявляє про відмову від OKR.
Дії при спрацюванні	Ескалація до CEO протягом 24 годин. Підготувати аргументацію: вплив на alignment, ризик для інших команд. Запропонувати компроміс: мінімальний OKR-формат для Sales (1 objective, 2 KR).
Ескалація	CEO — протягом 24 годин після тригера.
Вплив на OKR	Якщо Sales повністю виходять: їхні OKR видаляються з дашборду, залежні KR інших команд переглядаються. Якщо компроміс: зменшений scope, перегляд на початку Q3.

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

1. Журнал заповнюється один раз і забувається

Ризики ідентифікуються на початку кварталу, записуються в таблицю, і ніколи більше не переглядаються. Журнал ризиків — живий документ. Щотижневий перегляд Чемпіоном займає 10-15 хвилин. Без регулярного перегляду ризик R-002 спрацює непомітно, і ви дізнаєтесь про проблему, коли команда Sales вже місяць ігнорує OKR.

2. Ризики занадто абстрактні

"Може бути опір змінам" — це не ризик, це філософське спостереження. Ризик має бути конкретним: хто, що, коли, наслідки. Правильно: "Команда Sales відмовляється від OKR через сприйняття як зайвого навантаження". Конкретність дозволяє створити конкретний план реагування.

3. Відсутність плану реагування

Ризик записаний, ймовірність та вплив оцінені, але колонка "План реагування" порожня. Ідентифікація без плану — це усвідомлення проблеми без готовності до неї. Для кожного ризику з пріоритетом "Середній" і вище має бути хоча б одне речення в плані реагування. Для "Високий" та "Критичний" — повний формат (превентивні дії, тригер, дії, ескалація).

4. Завищення ймовірності для всіх ризиків

Якщо всі 10 ризиків мають ймовірність "Висока" — шкала не працює. Це означає або параноїю, або нерозуміння критеріїв. Перечитайте визначення: "Висока" = >60% ймовірність з конкретними передумовами. Більшість ризиків мають бути "Середні" або "Низькі". Якщо більше 30% ризиків — "Високі", перекалібруйте оцінки.

5. Ризик без відповідального

Колонка "Відповідальний" порожня або містить "команда". Ризик без конкретного відповідального — це нічийний ризик. Ніхто не моніторить, ніхто не реагує. Кожен ризик має одну конкретну людину (не команду, не "всі"). Ця людина не обов'язково вирішує проблему — вона відповідає за моніторинг та ескалацію.

6. Плутання ризиків з блокерами

В журнал потрапляють проблеми, які вже настали: "Розробник звільнився", "Дані недоступні". Це не ризики — це факти. Факти мають йти в блокери check-in або в action items дашборду. Журнал ризиків — для того, що ще не сталося, але може статися. Якщо ризик спрацював — змініть статус на "Спрацював" і перемістіть action items у відповідний інструмент.

7. Ігнорування каскадних ризиків

Ризик в одній команді впливає на OKR іншої команди, але це не зафіксовано. Наприклад, проблеми Engineering впливають на Customer Success (NPS залежить від стабільності платформи), але в журналі це не відображено. Колонка "Які OKR під загрозою" має включати всі залежні OKR, не тільки прямо пов'язані.

8. Немає аналізу ризиків на ретроспективі

Квартал завершується, ризики закриваються, але ніхто не аналізує: які ризики спрацювали, чи допоміг план реагування, які ризики були пропущені. Без цього аналізу кожен квартал ви ідентифікуєте ризики з нуля. На ретроспективі приділіть 15 хвилин аналізу журналу: що спрацювало, що ні, що додати на наступний квартал.

Призначення

Коли використовувати:

На етапі планування кварталу — для ідентифікації ризиків до старту.
На щотижневих check-in Чемпіона — для перегляду та оновлення статусу ризиків.
При зниженні впевненості KR нижче 0.4 — для формалізації ризику та плану дій.
При впровадженні OKR у нових командах — для фіксації ризиків адаптації.
На квартальній ретроспективі — для аналізу, які ризики спрацювали і наскільки ефективним був план.

Шаблон

Матриця оцінки ризиків (3x3)

	Вплив: Низький (L)	Вплив: Середній (M)	Вплив: Високий (H)
Ймовірність: Висока (H)	Середній пріоритет	Високий пріоритет	Критичний пріоритет
Ймовірність: Середня (M)	Низький пріоритет	Середній пріоритет	Високий пріоритет
Ймовірність: Низька (L)	Прийняти	Низький пріоритет	Середній пріоритет

Визначення рівнів ймовірності:

Рівень	Визначення
Висока (H)	Ризик з великою ймовірністю спрацює протягом кварталу (>60%). Є конкретні передумови.
Середня (M)	Ризик може спрацювати (20-60%). Є деякі ознаки, але ситуація невизначена.
Низька (L)	Ризик малоймовірний (<20%), але наслідки достатньо серйозні, щоб його відстежувати.

Визначення рівнів впливу:

Рівень	Визначення
Високий (H)	Провал 1+ OKR або зупинка впровадження OKR-системи в організації.
Середній (M)	Суттєве зниження впевненості (на 0.2+) для кількох KR. Потрібен перерозподіл ресурсів.
Низький (L)	Незначна затримка або необхідність коригування плану. Не впливає на загальний результат.

Журнал ризиків

ID	Опис ризику	Ймовірність	Вплив	Пріоритет	Які OKR під загрозою	План реагування	Відповідальний	Статус	Дата останнього перегляду
R-___	___________________	H/M/L	H/M/L	___________	___________________	___________________	___________	Відкритий / Моніторинг / Спрацював / Закритий	..__
R-___	___________________	H/M/L	H/M/L	___________	___________________	___________________	___________	Відкритий / Моніторинг / Спрацював / Закритий	..__
R-___	___________________	H/M/L	H/M/L	___________	___________________	___________________	___________	Відкритий / Моніторинг / Спрацював / Закритий	..__

Визначення статусів

Статус	Визначення
Відкритий	Ризик ідентифікований, план реагування визначений, активний моніторинг.
Моніторинг	Ризик знизився, але не зник. Перевіряємо раз на 2 тижні.
Спрацював	Ризик реалізувався. Перехід до виконання плану реагування. Зафіксувати фактичний вплив.
Закритий	Ризик більше не актуальний (зник, спрацював і оброблений, або квартал завершився).

Формат плану реагування

Для кожного ризику з пріоритетом "Високий" або "Критичний" має бути детальний план:

Елемент	Опис
Превентивні дії	Що робимо зараз, щоб знизити ймовірність? ___________________
Тригер	Яка подія/метрика сигналізує, що ризик спрацьовує? ___________________
Дії при спрацюванні	Що робимо негайно, якщо ризик реалізувався? ___________________
Ескалація	Кому повідомляємо і протягом якого часу? ___________________
Вплив на OKR	Як коригуємо OKR, якщо ризик спрацював? ___________________

Заповнений приклад

Контекст: IT-компанія (120 осіб), другий квартал впровадження OKR, Q2 2026.

Журнал ризиків

ID	Опис ризику	Ймовірність	Вплив	Пріоритет	Які OKR під загрозою	План реагування	Відповідальний	Статус	Дата останнього перегляду
R-001	Втрата ключового розробника в команді Platform, який веде міграцію на нову інфраструктуру	M	H	Високий	Engineering: "Забезпечити стабільну платформу" (KR1, KR2)	Документувати процес міграції щотижня. Підготувати другого розробника як backup. При звільненні — перерозподілити scope між командою + залучити підрядника на 1 місяць.	CTO	Відкритий	12.05.2026
R-002	Команда Sales відмовляється від OKR, вважаючи систему зайвим навантаженням	H	H	Критичний	Sales: "Збільшити дохід від B2B" (всі KR). Системний ризик: падіння довіри до OKR в організації.	Провести 1-на-1 з Head of Sales до 20.05. Показати зв'язок між OKR і бонусною системою. Адаптувати формат check-in для Sales (коротший, фокус на pipeline). При відмові — ескалювати до CEO.	OKR Чемпіон	Відкритий	12.05.2026
R-003	Дані для вимірювання KR недоступні або неточні — аналітична система не налаштована	M	M	Середній	Product (KR2: retention), Customer Success (KR1: NPS)	Провести аудит джерел даних до 19.05. Для KR без автоматичних даних — визначити ручний процес збору. Виділити 2 дні Data Engineer для налаштування дашбордів.	Data Lead	Відкритий	12.05.2026
R-004	CEO втрачає інтерес до OKR через відсутність швидких результатів	M	H	Високий	Системний ризик: зупинка впровадження.	Надсилати CEO щотижневий дашборд з конкретними прикладами прогресу. Підготувати case study внутрішнього успіху (Marketing KR досягнуто на тижні 6). Провести зустріч 1-на-1 з CEO щомісяця для обговорення OKR-процесу.	OKR Чемпіон	Моніторинг	12.05.2026
R-005	Зовнішній фактор: зміна регуляторних вимог вимагає переключення Engineering ресурсів на compliance	L	H	Середній	Engineering (всі KR), Product (KR залежні від Engineering)	Моніторити регуляторний ландшафт через юридичну команду. При спрацюванні: зменшити scope Engineering OKR, перерозподілити 2 KR на Q3. Повідомити керівництво протягом 48 годин.	COO	Моніторинг	05.05.2026

Детальний план реагування для R-002 (Критичний)

Елемент	Опис
Превентивні дії	1-на-1 з Head of Sales (до 20.05). Адаптувати check-in формат: 10 хв замість 25 хв, фокус на pipeline-метриках. Показати, як OKR допоможуть обґрунтувати запит на додатковий headcount.
Тригер	Head of Sales пропускає 2+ check-in поспіль або відкрито заявляє про відмову від OKR.
Дії при спрацюванні	Ескалація до CEO протягом 24 годин. Підготувати аргументацію: вплив на alignment, ризик для інших команд. Запропонувати компроміс: мінімальний OKR-формат для Sales (1 objective, 2 KR).
Ескалація	CEO — протягом 24 годин після тригера.
Вплив на OKR	Якщо Sales повністю виходять: їхні OKR видаляються з дашборду, залежні KR інших команд переглядаються. Якщо компроміс: зменшений scope, перегляд на початку Q3.