Матриця проти хаосу: як RACI допомагає знижувати операційні ризики компанії

 

  1. Навіщо потрібна RACI-матриця?

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

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

Саме тому матриця RACI — це про прозорість ролей, про відповідальність, що має ім’я, і про те, щоб у ключовий момент не з’ясовувати, “а хто мав це зробити?”, коли вже запущений продукт, подано звіт, або (що гірше) отримано штраф.

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

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

І саме ризик-менеджер може стати тим, хто поставить логічне запитання:
“Чи впевнені ми, що в цьому процесі визначено не лише власника ризику, але й тих, хто його контролює, консультує і про нього інформується?”

  1. Що таке RACI-матриця: простими словами для ризик-менеджера

RACI — це абревіатура з чотирьох ключових ролей у процесі:

  • R – Responsible (відповідальний за виконання): той, хто виконує завдання або забезпечує реалізацію дії. Може бути кілька осіб, але бажано — одна ключова.
  • A – Accountable (підзвітний, власник результату): особа, яка несе остаточну відповідальність. Саме вона «тримає удар», якщо щось пішло не так. Має бути лише одна на кожне завдання.
  • C – Consulted (консультанти): експерти або підрозділи, з якими потрібно порадитися до прийняття рішення. Це може бути юридичний департамент, ризик-менеджер, ІТ-фахівець тощо.
  • I – Informed (інформовані): ті, кого потрібно тримати в курсі. Вони не впливають на рішення, але мають знати про його результати (наприклад, комплаєнс або керівництво).

Чим RACI важлива саме для ризик-менеджменту?

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

Наприклад:
– Хто відповідальний за контроль збитковості по ОСЦПВ?
– А хто має оновлювати методику її розрахунку?
– А хто погоджує межі втручання?
– А хто має бути поінформований у разі порушення нормативів?

Без RACI всі ці ролі можуть або перетинатися (всі все роблять — отже, ніхто не відповідає), або навпаки — залишатися невизначеними («це не мій напрям»).

Ще одна особливість RACI — вона проста і наочна. Один рядок таблиці — це один процес або завдання, один стовпчик — це конкретна посадова особа або підрозділ. І навпроти кожного — літера, яка визначає його роль. Мінімум формалізму — максимум прозорості.

У практиці ризик-менеджменту RACI також допомагає:

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

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

 

  1. Як RACI-матриці працюють у страхових компаніях: від продукту до збитків

У страхових компаніях, особливо в тих, що працюють з масовими видами страхування, такими як ОСЦПВ, RACI-матриці можуть бути застосовані до будь-якого процесу, де є ризики, складна взаємодія між підрозділами і потреба в прозорості.

Розглянемо кілька типових напрямків, де RACI дійсно працює:

 

3.1 Розробка нового страхового продукту

  • Responsible: андеррайтер, який розробляє умови, страхові тарифи, винятки.
  • Accountable: керівник продуктового напрямку або директор із розвитку — саме він затверджує продукт.
  • Consulted: юридичний департамент (щодо відповідності до законодавства), ризик-менеджер (щодо оцінки ризик-профілю продукту), актуарій.
  • Informed: ІТ (про специфікацію продукту для інтеграції в CRM), маркетинг (про особливості продажу), контакт-центр.

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

 

3.2 Контроль збитковості по ОСЦПВ

  • Responsible: підрозділ актуаріїв/фінансової аналітики, який обробляє дані та готує розрахунки.
  • Accountable: фінансовий директор або член правління з фінансів.
  • Consulted: ризик-менеджер (оцінює, чи перевищена допустима межа), операційний блок (вплив частоти/структури збитків), підрозділ врегулювання.
  • Informed: керівництво, Наглядова рада (якщо йдеться про порушення стратегічних KPI).

Типовий ризик: збитковість вийшла за межі планової. Хто реагує? RACI допомагає не лише встановити, хто винен, а й хто має діяти.

 

3.3 Інцидент інформаційної безпеки (наприклад, витік даних клієнтів)

  • Responsible: ІТ-служба, яка виявила інцидент і проводить технічне розслідування.
  • Accountable: директор з безпеки або СЕО — залежно від серйозності інциденту.
  • Consulted: юридичний департамент (щодо обов’язку повідомлення Кіберполіції, НБУ, клієнтів), ризик-менеджер (щодо оцінки збитку і повторного ризику), PR-служба.
  • Informed: Наглядова рада, клієнти (якщо потрібно), підрозділ продажів.

Типовий виклик: багато учасників процесу, різні цілі. RACI знижує ризик хаосу в перші 24 години після виявлення інциденту.

 

3.4 Закупівля зовнішньої IT-платформи (наприклад, CRM)

  • Responsible: ІТ-підрозділ + закупівлі.
  • Accountable: СЕО або директор з розвитку.
  • Consulted: ризик-менеджер (оцінка постачальника, кіберризики, SLA), фінансовий директор (вартість і повернення інвестицій).
  • Informed: користувачі, відділ навчання, техпідтримка.

Цінність для ризик-менеджера: можливість вчасно вбудувати KRI і вимоги з безпеки в технічне завдання.

 

Таким чином, RACI — це не просто «таблиця з буквами», а структурований підхід до запобігання ризикам, особливо там, де процеси міжфункціональні й розпорошені. У наступному розділі ми покажемо, як виглядає RACI-матриця саме для процесу контролю збитковості по ОСЦПВ — з практичною схемою.

  1. RACI-матриця для контролю збитковості по ОСЦПВ: як це виглядає на практиці

Контроль збитковості — один із ключових елементів ризик-менеджменту в ОСЦПВ. Його мета — не лише фіксувати рівень витрат, а й вчасно реагувати на відхилення, ухвалювати коригуючі рішення, мінімізувати збитки та уникнути санкцій з боку МТСБУ або НБУ.

Але щоб це працювало, треба чітко розуміти: хто саме відповідає за моніторинг, хто — за аналіз, хто — за рішення, а хто має бути в курсі. І тут у пригоді стає RACI.

 

Типова RACI-матриця для процесу контролю збитковості ОСЦПВ

Етап процесу

Актуарій

Фіндиректор

Ризик-менеджер

Врегулювання

Продажі

Правління

Наглядова рада

Збір та обробка статистики за звітний період

R

  

C

   

Підготовка розрахунку фактичної збитковості

R

A

C

C

   

Аналіз відхилень від плану / попереднього періоду

C

R

R

C

 

A

 

Виявлення причин зростання збитковості

C

R

R

R

C

A

 

Погодження управлінських рішень щодо реагування

 

C

R

C

 

A

C

Впровадження змін (тарифи, андеррайтинг тощо)

C

 

C

R

R

A

I

Звітність до НБУ або МТСБУ

R

A

C

C

  

I

 

Пояснення до матриці: що кому належить

  • Актуарій (R): забезпечує технічну точність розрахунків, готує дані, формули, сценарії. Це його зона відповідальності.
  • Фінансовий директор (A): як правило, власник процесу звітності та збитковості. Саме він підзвітний перед правлінням та наглядовою радою.
  • Ризик-менеджер (R/C): ключовий партнер у діагностиці причин і наслідків. Його завдання — перевірити, чи є відхилення значущим, чи порушено апетит до ризику, які KRI вийшли за межі.
  • Підрозділ врегулювання (R/C): бере участь у пошуку причин (наприклад, сплеск шахрайства), ініціює зміну процесів (строки, перевірки).
  • Правління (A): ухвалює рішення щодо змін — бо це стратегічно важливе питання.
  • Наглядова рада (I/C): має бути в курсі або залучена до обговорення — особливо якщо збитковість системно висока.

 

 На що звертає увагу ризик-менеджер, коли бачить таку матрицю?

  • Чи не розмита відповідальність? Якщо в кожному рядку по три «R» — це привід для тривоги.
  • Чи є чітка точка фінальної відповідальності (A) — тобто хто «тримає удар»?
  • Чи залучено ризик-менеджера як консультанта, а не лише як спостерігача?
  • Чи отримує Наглядова рада інформацію, яку має? Це критично для good governance.
  • Чи не ігнорується підрозділ продажів? Він часто впливає на збитковість — через структуру клієнтів, бонусну політику тощо.

 

  1. Типові помилки у використанні RACI-матриць

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

 

1. Всі «відповідальні» — отже, відповідального нема

Ситуація: у рядку по три літери «R» — наприклад, «Актуарій», «Фіндиректор», «Ризик-менеджер».
Ризик: колективна безвідповідальність. У момент проблеми ніхто не вважає себе зобов’язаним діяти.
Коментар: RACI не про рівноправність, а про чіткість: одна людина — одна роль. Р — лише одна.

 

2. Немає фінального «A» — ніхто не приймає рішення

Ситуація: у ключових точках немає особи з роллю «Accountable».
Ризик: процес зависає між рівнями, чекає погодження, буксує.
Коментар: «A» — це не контрольна галочка. Це людина, яка тримає відповідальність перед керівництвом і регулятором.

 

3. Не залучено підрозділи, які реально впливають

Ситуація: матриця будується лише навколо “фінансово-актуарних” функцій. Врегулювання, продажі, ІТ — поза процесом.
Ризик: рішення не враховують практику, втрачається зв’язок з операційною реальністю.
Коментар: Страхування — командна гра. Особливо ОСЦПВ, де багато складових: шахрайство, поведінка клієнтів, збитки, виплати.

 

4. Забагато «C» — всі радять, але ніхто не діє

Ситуація: в усіх рядках присутні “consulted” ролі — але не видно виконавців.
Ризик: рішення затягуються, всі хочуть “обговорити”, але не реалізовують.
Коментар: Іноді краще “повідомити” (I), ніж “радитися” (C) — особливо в антикризових діях.

 

5. Немає інтеграції з ризик-апетитом та KRI

Ситуація: RACI існує сам по собі, не прив’язаний до інших елементів RM-системи.
Ризик: навіть найкраща матриця не активізує процес, якщо немає порогів спрацювання, тригерів і обов’язкових дій.
Коментар: RACI має бути частиною зв’язаної системи: апетит → контроль → дія → відповідальний → звітність.

 

  1. Роль ризик-менеджера: від фасилітатора до архітектора RACI

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

Фасилітатор процесу: допомагає ставити питання

Ризик-менеджер не мусить «наказувати», хто за що відповідає. Але саме він ініціює розмову:
– Хто реально приймає рішення?
– Хто повинен реагувати на тригери?
– Хто несе відповідальність перед наглядовою радою?
Це особливо важливо в багатофункціональних процесах, як-от управління збитковістю ОСЦПВ, де потрібно залучити не лише фінансовий блок, а й ІТ, продажі, врегулювання.

Технічний архітектор: інтегрує RACI в ризик-структуру

Саме ризик-менеджер може пов’язати RACI з іншими елементами системи:

  • з апетитом до ризику — наприклад, якщо збитковість ОСЦПВ перевищує 85%, спрацьовує певна дія;
  • з KRI — автоматичне формування звіту для особи з «R» або «A»;
  • з планами заходів у випадку перевищення ліміту ризику.

Так формується зв’язок між оцінкою ризику, контролем і реакцією, що часто втрачається в реальних компаніях.

Провідник культури відповідальності

Формально RACI — про ролі. Але неформально — про культуру. Ризик-менеджер може і має формувати культуру запитань:

  • Чи знаєш ти, за що ти відповідаєш?
  • Чи є у тебе ресурси, щоб це виконати?
  • Чи маєш право приймати рішення?
  • Кого ти мусиш попередити в разі ризику?

Саме ці питання — основа управління ризиками. Бо ризик не живе в Excel — він живе в людях, діях і бездіяльності.

Зв’язок із стратегічним рівнем

І, нарешті, ризик-менеджер — той, хто виводить RACI за межі операційної рутини. Наприклад, у процесі ORSA, антикризового планування, управління резервами. Там, де йдеться не лише про «хто натискає кнопку», а про «хто відповідає за майбутнє компанії».

 

Замість післямови

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