makeOKR UA
Бібліотека OKR Чемпіона
OKR Чемпіон
  • Хто такий OKR Чемпіон
  • Ключові обов'язки OKR Чемпіона
  • Необхідні компетенції OKR Чемпіона
  • Типові причини провалу OKR Чемпіона
  • Рівні зрілості: від новачка до архітектора
Виконання
Інструменти
  • Робочий аркуш для написання OKR
  • Визначення рівнів впевненості
  • Формат CFR check-in
  • Щотижневий дашборд для керівника
  • Журнал ризиків OKR
  • Канва вирівнювання стейкхолдерів
  • Діагностичний чеклист здоров'я OKR
Управління
  • Карта ролей в OKR-системі
  • RACI для OKR управління
  • Модель ескалації проблем
  • Зв'язок зі стратегічним плануванням
  • Інтеграція з цифровими інструментами
Антипатерни
  • Фейкові OKR: діагностика та лікування
  • Надмірне каскадування
  • Звітний театр
  • Інфляція метрик
  • Втома від каденції
  • Збірка типових помилок впровадження
Кейси
  • Міністерство: впровадження OKR на рівні відомства
  • Підрозділ оборони: OKR в умовах обмежень
  • Громадська організація: адаптація OKR для НУО
  • Технологічний стартап: масштабування OKR з ростом
Довідник
Конфіденційність·Умови/
© 2026 OKR UA · v0.9.1
RУправління

RACI для OKR управління

Матриця відповідальності для ключових OKR-процесів — хто Responsible, Accountable, Consulted, Informed

Що таке RACI і навіщо вона для OKR

RACI — це матриця, яка для кожного процесу визначає чотири типи участі:

  • R (Responsible) — хто виконує роботу. Людина або група, яка безпосередньо робить задачу.
  • A (Accountable) — хто відповідає за результат. Одна людина, яка приймає фінальне рішення та несе відповідальність.
  • C (Consulted) — з ким консультуються. Люди, чию думку запитують до або під час виконання.
  • I (Informed) — кого інформують. Люди, яких повідомляють про результат після прийняття рішення.

Без RACI типова ситуація виглядає так: чемпіон думає, що тімліди самі проведуть scoring, тімліди думають, що це зробить чемпіон, а керівник департаменту дізнається про результати через місяць. RACI прибирає цю невизначеність.

Правила роботи з RACI:

  1. Для кожного процесу має бути рівно один A. Якщо нікого або двох — це сигнал проблеми.
  2. R може бути кілька, але один з них має бути primary.
  3. A і R можуть бути одна й та сама людина.
  4. Якщо комірка порожня — роль не задіяна в цьому процесі.

Ролі в матриці

Для матриці використовуються скорочення ролей:

СкороченняРоль
СПВиконавчий спонсор
ЧМOKR-чемпіон
КДКерівник департаменту
ТЛТімлід
ІКІндивідуальний контриб'ютор
HRHR-партнер
ITIT / Адміністратор інструментів

Основна RACI-матриця

Планування та постановка OKR

ПроцесСПЧМКДТЛІКHRIT
1. Стратегічні OKR організаціїA/RCCIII—
2. OKR департаментуICA/RC———
3. OKR команди—CARC——
4. Перевірка якості OKRIA/RCR———
5. Затвердження та публікація OKRARRIIIR

Виконання та tracking

ПроцесСПЧМКДТЛІКHRIT
6. Щотижневий check-in—IIA/RR——
7. Місячний review департаментуICA/RRI——
8. Рекалібрація OKR (mid-cycle)ACRRC——

Оцінка та рефлексія

ПроцесСПЧМКДТЛІКHRIT
9. Квартальний scoringICARR——
10. Ретроспектива команди—CIA/RRC—
11. Ретроспектива організаціїA/RRRIIC—

Підтримка та розвиток

ПроцесСПЧМКДТЛІКHRIT
12. Навчання та онбордингIA/RIC—R—
13. Адміністрування інструментів—A————R
14. Комунікація та звітністьARCIIC—
15. Збір зворотного зв'язкуIACCRR—

Деталізація кожного процесу

1. Стратегічні OKR організації

Спонсор формулює 2-3 Objectives на рік або квартал, що визначають напрямок організації. Чемпіон допомагає структурувати та перевірити формулювання. Керівники департаментів дають вхідні дані щодо можливостей та обмежень.

Вхід: Річна стратегія, ринкові дані, результати попереднього кварталу. Вихід: Затверджені стратегічні OKR, опубліковані для всієї організації. Термін: Перший тиждень кварталу.

2. OKR департаменту

Керівник департаменту декомпозує стратегічні OKR у 2-4 OKR свого департаменту. Чемпіон перевіряє якість та alignment. Тімліди дають зворотний зв'язок щодо реалістичності.

Вхід: Стратегічні OKR, контекст департаменту, ресурси. Вихід: OKR департаменту, узгоджені з суміжними департаментами. Термін: Другий тиждень кварталу.

3. OKR команди

Тімлід фасилітує сесію постановки OKR у команді. Команда колективно формулює 1-3 OKR. Керівник департаменту затверджує, чемпіон консультує по якості.

Вхід: OKR департаменту, командний контекст, вхідні дані від індивідуальних контриб'юторів. Вихід: Затверджені командні OKR. Термін: Другий-третій тиждень кварталу.

4. Перевірка якості OKR

Чемпіон перевіряє OKR всіх рівнів на відповідність стандартам: вимірюваність Key Results, формат "З X до Y", амбіційність, відсутність типових помилок. Тімліди вносять корективи за результатами перевірки.

Вхід: Чернетки OKR всіх рівнів. Вихід: Відгук з конкретними зауваженнями та рекомендаціями. Термін: Паралельно з процесами 2 та 3.

5. Затвердження та публікація OKR

Чемпіон збирає фінальні версії OKR і публікує їх у спільному інструменті. IT-адміністратор забезпечує технічну сторону. Спонсор дає фінальний go / no-go.

Вхід: Перевірені та узгоджені OKR всіх рівнів. Вихід: OKR доступні для перегляду всіма учасниками. Термін: Кінець третього тижня кварталу.

6. Щотижневий check-in

Тімлід проводить 15-30 хвилинний check-in з командою. Індивідуальні контриб'ютори оновлюють прогрес по Key Results. Чемпіон отримує агреговані дані для моніторингу.

Вхід: Дані прогресу по Key Results, нові блокери. Вихід: Оновлений статус OKR, список блокерів для ескалації. Термін: Щопонеділка або щоп'ятниці (фіксований день).

7. Місячний review департаменту

Керівник департаменту проводить review прогресу з тімлідами. Оцінюється загальний прогрес, виявляються ризики, перерозподіляються ресурси.

Вхід: Агреговані дані check-in за місяць, блокери. Вихід: Рішення щодо ресурсів, список ескалацій. Термін: Перший тиждень кожного місяця.

8. Рекалібрація OKR (mid-cycle)

Посередині кварталу (тиждень 6-7) оцінюється, чи потрібно змінити OKR. Це не планова зміна — це реакція на суттєві зміни контексту (зміна стратегії, втрата клієнта, зміна ринку). Спонсор приймає рішення про зміну стратегічних OKR, керівники департаментів — про OKR департаментів.

Вхід: Дані прогресу, зміни контексту, пропозиції від команд. Вихід: Рішення: залишити без змін / скоригувати / скасувати OKR. Термін: Тиждень 6-7 кварталу.

9. Квартальний scoring

Тімліди та контриб'ютори оцінюють кожен Key Result за шкалою 0.0-1.0. Керівник департаменту затверджує scoring по своєму департаменту. Чемпіон консультує щодо методології оцінки.

Вхід: Фактичні дані по Key Results. Вихід: Оцінки по кожному Key Result та Objective. Термін: Останній тиждень кварталу.

10. Ретроспектива команди

Тімлід фасилітує ретроспективу: що працювало, що не працювало, що змінити. Контриб'ютори — активні учасники. Чемпіон може бути присутнім як спостерігач або фасилітатор (на перших циклах). HR-партнер збирає зворотний зв'язок.

Вхід: Результати scoring, досвід кварталу. Вихід: Список action items для покращення процесу. Термін: Останній тиждень кварталу, після scoring.

11. Ретроспектива організації

Спонсор проводить ретроспективу з керівниками департаментів та чемпіоном. Оцінюються результати кварталу, системні проблеми, зміни в процесі.

Вхід: Scoring всіх департаментів, зворотний зв'язок від ретроспектив команд. Вихід: Рішення щодо змін у процесі на наступний квартал. Термін: Перший тиждень наступного кварталу.

12. Навчання та онбординг

Чемпіон розробляє та проводить навчальні матеріали. HR-партнер координує логістику та залучення. Тімліди дають зворотний зв'язок щодо потреб своїх команд.

Вхід: Потреби в навчанні, нові учасники процесу. Вихід: Проведені воркшопи, оновлена база знань. Термін: Безперервно, з акцентом на початок кварталу.

13. Адміністрування інструментів

IT-адміністратор підтримує інструменти, налаштовує доступи, вирішує технічні проблеми. Чемпіон визначає вимоги до інструментів та пріоритети.

Вхід: Запити від користувачів, зміни в процесі. Вихід: Працюючі інструменти, актуальні шаблони. Термін: Безперервно.

14. Комунікація та звітність

Чемпіон готує квартальні звіти та комунікації. Спонсор затверджує ключові повідомлення. Керівники департаментів надають дані.

Вхід: Дані scoring, результати ретроспектив. Вихід: Звіт для організації, ключові метрики OKR-процесу. Термін: Перший тиждень кожного кварталу (за минулий квартал).

15. Збір зворотного зв'язку

Чемпіон ініціює та координує збір зворотного зв'язку. HR-партнер проводить опитування та 1-на-1 бесіди. Контриб'ютори — основне джерело інформації.

Вхід: Запитання про задоволеність, корисність, навантаження. Вихід: Агрегований звіт з рекомендаціями. Термін: Кінець кожного кварталу.

Як адаптувати RACI під свою організацію

Крок 1. Визначте реальні ролі

Не всі 7 ролей існують у кожній організації. Якщо HR-партнер не задіяний в OKR — приберіть цю колонку. Якщо IT-адміністратор — це той самий чемпіон, об'єднайте.

Крок 2. Перевірте правило "один A"

Пройдіться по кожному рядку. Якщо в рядку немає A — процес не має власника. Якщо A двоє — вирішіть, хто приймає фінальне рішення.

Крок 3. Перевірте навантаження

Підрахуйте кількість R та A для кожної ролі. Якщо одна людина має 10+ R/A — вона перевантажена. Розгляньте делегування.

Крок 4. Узгодьте з учасниками

Покажіть матрицю кожному учаснику та запитайте: "Чи згодні ви з тим, що для вас зазначено?" Неузгоджена RACI гірша за відсутню.

Крок 5. Опублікуйте та переглядайте

Матриця має бути доступна всім учасникам OKR-процесу. Переглядайте її на квартальній ретроспективі організації. Якщо щось не працює — змінюйте.

Типові помилки при створенні RACI

Всі — Responsible. Якщо всі відповідають за процес — ніхто не відповідає. R має бути конкретна людина або невелика група.

Accountable розмитий. "Ми всі відповідальні" — це не RACI. Один процес — один A.

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

RACI створена і забута. Матриця написана, покладена в папку, ніхто до неї не повертається. Якщо RACI не використовується при прийнятті рішень — вона не працює.

Матриця не відповідає реальності. В RACI написано, що тімлід Accountable за check-in, але фактично це робить чемпіон. Матриця має відображати бажаний стан, але розрив з реальністю потрібно закривати поступово.

ПопередняКарта ролей в OKR-системіНаступнаМодель ескалації проблем