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

 

Що трапляється, коли всі відповідають за все — і ніхто ні за що

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

      Знайомо? Це не лише про ризик-менеджмент. Це — про будь-яку ситуацію, де багато розумних людей з добрими намірами не можуть дійти згоди, хто що має робити, коли і за чиєї участі. У підсумку: запізнення, стрес, взаємні обвинувачення, недовіра. А далі — регуляторні штрафи, репутаційні втрати, проблеми з акціонерами.

     Управління ризиками, комплаєнс, ORSA, ESG — усі ці процеси, як і великі проєкти, живуть на стику між різними підрозділами, ролями й логіками мислення. Саме тут відсутність чітких ролей стає не просто незручністю, а ризиком сама по собі.

       Саме для таких випадків і були створені RACI, RAPID, DACI та інші подібні моделі.

 

RACI та її родичі — коли абревіатура рятує процес

RACI: класика жанру

     RACI — це, здавалося б, банальна матриця на чотири літери:

• Responsible — хто виконує роботу,
• Accountable — хто несе відповідальність за результат,
• Consulted — з ким треба порадитись,
• Informed — кого інформуємо про результат.

      Але ця структура — як система координат у хаосі міжфункціональної взаємодії. Особливо в складних організаціях.

Приклад з життя:

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

Замість «всі разом» — зʼявилось:

• Responsible: ризик-менеджер готує сценарії,
• Accountable: CRO затверджує та несе відповідальність за зміст,
• Consulted: CFO, Chief Actuary, Underwriting надають входи,
• Informed: CEO, наглядова рада, внутрішній аудит.

Результат — ORSA зібрано на тиждень раніше, без конфліктів і метушні.

 

RASCI: коли є ще й ті, хто підтримує

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

Приклад:
У процесі оцінки кіберризиків відповідальним був ІТ-директор, accountable — CRO, consulted — CISO і комплаєнс, але без підтримки внутрішнього ІТ-відділу (Support) система моніторингу загроз не запрацювала б вчасно.

 

DACI: де є драйвер, а не просто виконавець

      Цю модель часто використовують у продуктовому менеджменті, але вона чудово підходить і для ризиків, повʼязаних із стратегічними ініціативами, наприклад, запуск нової CRM або інтеграції після злиття.

• Driver — хто штовхає процес,
• Approver — хто остаточно ухвалює рішення,
• Contributor — хто дає експертизу й входи,
• Informed — кого ставлять до відома.

 

Приклад з практики:
Перед запуском нового цифрового каналу продажів, ризик-менеджер ініціював DACI для аналізу операційних і регуляторних ризиків.
Driver — він сам,
Approver — CEO,
Contributor — ІТ, юридичний відділ, актуарії,
Informed — наглядова рада, маркетинг.

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

RAPID: коли треба формалізувати прийняття рішення

       Особливо корисна ця модель у ситуаціях зі складними або конфліктними рішеннями.

• Recommend — хто формулює пропозицію,
• Agree — хто має погодити (часто блокери),
• Perform — хто впроваджує,
• Input — хто дає дані,
• Decide — хто вирішує.

Приклад:
Під час оновлення політики ризик-апетиту:

• Recommend — CRO формулює ліміти,
• Agree — CFO погоджує через вплив на бюджет,
• Input — фінансова аналітика, андеррайтинг, актуарії,
• Perform — відповідальні за інтеграцію в систему,
• Decide — CEO або Risk Committee.

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

 

CAIRO, RACIQ, RACI-VS: екзотика чи точне налаштування?

Є й менш відомі варіанти:

• CAIRO додає «Out of the loop» — корисно, коли треба вказати, хто не залучений (наприклад, підрядник, якого краще тримати осторонь).
• RACIQ вводить роль «Quality assurance» — валідація результату окремо.
• RACI-VS — підходить для ІТ і безпеки, коли важливо зазначити: хто перевіряє і хто підписує фінальну версію.

 

 

Не теорія, а практика — як RACI та його «родичі» працюють у страхових компаніях (і не тільки)

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

 

1. Процес оцінки ризиків у компанії (Risk Identification & Assessment)

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

Що зробили: CRO запровадив RACI-матрицю для кожного етапу:

Етап	Responsible	Accountable	Consulted	Informed
Оцінка ризиків по функціях	Підрозділи	Керівники підрозділів	CRO	CEO
Інтеграція в єдиний профіль	Risk team	CRO	CFO, Underwriting	Наглядова рада
Перевірка актуальності	Внутрішній аудит	CRO	—	—

Результат: Замість 20 листів у стилі «я думав, що це не моя справа» — чіткий план: хто що подає, хто збирає, хто несе відповідальність.

 

2. Підготовка ORSA-звіту — не війна, а спільна справа

Ситуація: До звіту включено невірні сценарії. CFO обурений: «Чому ризик-менеджмент вигадує сценарії без актуаріїв?». CRO відповідає: «Ми запитували, але нам не відповіли». Класика.

Рішення: Створено DACI-модель для процесу визначення сценаріїв:

• Driver: ризик-менеджер — він ініціює обговорення, формує драфт.
• Approver: CEO — затверджує перелік ORSA-сценаріїв.
• Contributors: актуарії (розраховують вплив), фінансовий директор (вплив на капітал), андеррайтери (операційна перспектива).
• Informed: Наглядова рада — отримує затверджений сценарний пакет.

Що змінилось: Зникла ситуація «ніхто не відповів на листа». Тепер ясно: драйвер ганяє, contributor дає, approver затверджує, всі задоволені. І звіт — вчасно.

 

3. Інцидент-менеджмент — хто першим гасить пожежу?

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

Рішення: Внутрішня політика реагування на інциденти переписана з урахуванням RAPID-моделі:

• Recommend: аналітик з інцидентів — пропонує варіанти розвʼязання;
• Agree: юристи та ІТ — мають погодити дії;
• Input: всі, хто має релевантні дані (аналітика, продажі, підрядник);
• Decide: керівник служби операційних ризиків;
• Perform: підрозділ, який виправляє проблему.

Нюанс: рішення приймається в межах 24 годин, а не 2 тижні «листування».
Результат: компанія мінімізувала втрати, встигла проінформувати регулятора до дедлайну, і ніхто не побіг у відпустку в розпал інциденту.

 

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

Ситуація: У компанії ухвалено рішення запустити пілот ESG-звітності. Але нікого «не стосується»: фінансисти кажуть «це не наша справа», ризик-менеджери — «ми не звітуємо», HR — «у нас немає ресурсів», PR — «ще не час».

Рішення: Впроваджено RACI для ESG-звітування:

Напрямок	Responsible	Accountable	Consulted	Informed
Екологічні показники	Адміністративна служба	COO	Risk, PR	CEO
Соціальна частина	HR	HRD	PR, Risk	Audit Committee
Управлінський блок (G)	Risk	CRO	Юридичний, комплаєнс	Правління

Плюс: Компанія також використала CAIRO — вказала, кого не залучати (наприклад, зовнішні підрядники на першому етапі). Це зменшило шум і заощадило ресурси.

 

5. Тестування нової системи аналітики — чий провал?

Ситуація: Компанія впроваджує нову BI-систему. Через неправильну інтеграцію автоматизовано завантажується неправильна інформація про андеррайтингові коефіцієнти. Хто винен? ІТ каже: «Це не наш блок даних», ризик-менеджер: «Ми лише користувачі», андеррайтинг: «Ми не замовляли цю систему».

Рішення: Після інциденту впроваджено RACI-VS:

• Responsible: ІТ та бізнес-аналітик.
• Accountable: керівник цифрових проєктів.
• Consulted: ризик-менеджер, андеррайтинг.
• Informed: CEO.
• Verify: актуарій — перевіряє логіку роботи інструменту.
• Sign-off: CRO — дає фінальне погодження перед запуском.

Післямова: нову систему більше не запускають без етапу перевірки та підпису. Ціна помилки була завелика.

 

Типові помилки — або як RACI перетворюється на RISK

Впровадити RACI або RAPID технічно нескладно. У найпростішому варіанті — це таблиця в Excel. Проблема в тому, що більшість організацій або формалізують ці моделі для «галочки», або починають використовувати їх у такий спосіб, що результат лише погіршується.

Ось кілька типових помилок і ситуацій, коли модель починає працювати не на вас, а проти вас:

1. Відсутній «Accountable» — і ніхто не відповідає за результат

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

Приклад з практики:
Компанія запустила проект впровадження оновленої політики управління ризиками. Кожен підрозділ відповідав за свій розділ, Risk team координував, але… відповідального за загальний документ не було. У результаті — 3 місяці затримки і три версії документа, жодна з яких не була повністю узгодженою.

Рішення: призначили одного Accountable (CRO), і процес зрушив з місця.

 

2. Забагато «C» і «I» — процес паралізований

Якщо на кожному етапі «консультуються» з пʼятьма департаментами, а ще десяток людей ставлять до відома — ви потрапили в бюрократичну пастку. Особливо, якщо всі «Consulted» починають нав’язувати свою думку, а не просто надають дані.

Приклад:
Оцінка ризику запуску нового продукту. У RACI було 7 осіб у колонці «Consulted», серед них — юридичний, комплаєнс, маркетинг, ІТ, PR… У результаті — нескінченні раунди коментарів, кожен вимагає змін, рішення затягується, дедлайн зірвано.

Рішення: обмежити «Consulted» до тих, хто дійсно має компетенцію, а не просто «має що сказати».

 

3. Змішування ролей — коли один і той самий працівник і «R», і «A», і «C» одночасно

У маленьких організаціях це іноді неминуче, але в ідеалі ролі мають бути розподілені, щоб була і перевірка, і зворотний зв’язок.

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

 

4. Ніхто не читає RACI-матрицю після створення

Ідеальна RACI-таблиця не допоможе, якщо вона існує лише у вигляді вкладення до політики, яку ніхто не відкривав з моменту затвердження. Це — формалізм, і він не працює.

Приклад:
Під час аудиту виявляється, що ролі в інцидент-менеджменті не виконуються згідно з RACI. На запитання: «А ви бачили, що в політиці ви маєте бути Responsible?» керівник відділу відповідає: «Я ж думав, це ІТ…»

Рішення: вбудовувати RACI в реальні процеси (внутрішні вказівки, шаблони дій, навіть Jira чи Trello), а не просто «зберігати в архіві».

 

5. Усе тримається на неформальних домовленостях

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

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

 

Як уникнути цих помилок?

• Перевірка на зрозумілість: чи може кожна людина в таблиці чітко пояснити свою роль?
• Живе обговорення: не просто надати матрицю, а пройтись по ній з командою.
• Вбудованість у процеси: використовувати ролі не лише в документах, а й у таск-трекерах, чек-листах, CRM.
• Регулярне оновлення: змінюється структура — оновіть матрицю.
• Одна людина ≠ вся таблиця: розділяйте відповідальність і повноваження.

 

 

 

В наступній частині спробуємо поговорити про те, як інтегрувати RACI, DACI, RAPID у внутрішні документи, політики, посадові інструкції та процеси управління ризиками (зокрема ORSA).

 

 

Сергій Бабич