Вступ

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

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

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

ISO 31000 прямо наголошує, що аналіз ризику має виходити далеко за межі опису події. Він повинен включати розуміння причин виникнення ризику, факторів, які змінюють його ймовірність і масштаб, а також умов, за яких ризик переходить у фазу загострення. Та сама логіка закладена й у вимогах НБУ до системи управління ризиками: регулятор очікує не декларативних формулювань, а здатності компанії бачити динаміку ризиків і приймати рішення на основі реального аналітичного розуміння.

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

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

1. Аналіз причин (causal analysis): де насправді починається ризик

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

У практиці ризик-менеджменту причина — це не те, що «сталося», а те, що створювало умови для того, щоб це сталося. Вона завжди передує події і, як правило, існує значно довше за сам інцидент.

1.1. Подія не дорівнює причині: типова управлінська пастка

У реальних кейсах ця помилка виглядає дуже знайомо.

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

Причина тут була не в конкретній людині. Реальний causal analysis зазвичай виявляє інше:

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

Подія змінюється, співробітники змінюються, а причина залишається — і ризик продовжує реалізовуватися.

Те саме стосується й інших типових формулювань:

• «збій ІТ-системи»,
• «людський фактор»,
• «несвоєчасне виконання».

Усі вони описують симптом, але не пояснюють механіку ризику.

1.2. Типи причин: що насправді лежить під інцидентами

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

Структурні причини

Це те, що «вшито» у модель роботи компанії.

Практичний приклад (ІТ-ризик).
Компанія роками нарощує функціональність системи, інтегруючи нові модулі «швидкими рішеннями». Система працює, але:

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

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

Процесні причини

Це проблеми не в архітектурі, а в тому, як саме виконуються операції.

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

• частина з них застаріла;
• винятки вирішуються «вручну»;
• контроль відбувається вибірково.

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

Поведінкові причини

Найскладніші для виявлення — і водночас найпоширеніші.

Практичний приклад (HR-ризик).
Ключові функції тримаються на кількох досвідчених співробітниках. Формально це відомо, але не вважається критичним ризиком: люди працюють роками, скарг немає. З часом навантаження зростає, але KPI залишаються незмінними. Помилки починають з’являтися саме там, де їх найменше очікували.

Причина — не «втрата мотивації», а хронічна перевтома та відсутність реального заміщення, які довгий час не сприймалися як ризик.

1.3. Як causal analysis працює в реальному управлінні

Ефективний аналіз причин починається не з формального опису інциденту, а з питань до процесу.

Ключовий практичний прийом — послідовне «чому?»
У реальних кейсах достатньо 3–5 рівнів, щоб перейти від події до системної причини:

• чому сталася помилка?
• чому контроль не спрацював?
• чому процес допускає таку ситуацію?
• чому це вважається прийнятним станом?

На цьому етапі часто стає очевидно, що частина причин:

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

Саме тут аналіз ризику перестає бути формальністю і починає виконувати свою ключову функцію — пояснювати, що саме потрібно змінити, а не лише фіксувати факт помилки.

2. Драйвери ризику (risk drivers): чому ризик раптово «оживає»

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

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

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

2.1. Чому без драйверів аналіз ризику стає сліпим

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

Ситуація змінюється протягом кількох місяців: зростає обсяг роботи, з’являються нові продукти, посилюються регуляторні вимоги. Формально ризик не змінювався — жодних звільнень не було. Але драйвери вже працювали:

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

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

2.2. Типові драйвери, які змінюють поведінку ризиків

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

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

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

Зовнішнє середовище.
Регуляторні зміни, коливання ринку, макроекономічні фактори не створюють внутрішні ризики напряму, але різко змінюють їхню поведінку.

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

Технологічні фактори.
Збільшення обсягів даних, кількості інтеграцій або частоти змін у системах робить ризики менш передбачуваними.

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

Кадрові фактори та культура.
Толерантність до перевантажень, ставлення до помилок, реальна (а не задекларована) культура контролю безпосередньо впливають на ризики.

2.3. Драйвери як основа для KRI та управлінських рішень

У багатьох компаніях показники ризику (KRI) обираються інтуїтивно або як компроміс між доступністю даних і вимогами звітності. У результаті вони часто відображають наслідки, а не зміну поведінки ризику.

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

Коли KRI прив’язані до драйверів, компанія отримує можливість:

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

Без цього ризик-менеджмент знову зводиться до констатації факту.

2.4. Драйвери як місток між аналізом і діями

Драйвери — це той рівень аналізу, на якому ризик стає керованим. Причини пояснюють, чому ризик існує. Події показують, що він реалізувався. А драйвери відповідають на запитання, коли і за яких умов ризик починає виходити з-під контролю.

Саме тому без чітко визначених драйверів:

• профіль ризиків залишається статичним;
• моніторинг не дає управлінських сигналів;
• рішення ухвалюються із запізненням.

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

3. Тригери ризику (triggers): момент, коли ще можна встигнути

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

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

3.1. Чому відсутність тригерів робить ризик-менеджмент реактивним

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

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

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

3.2. Тригери ≠ показники ≠ наслідки

Одна з найпоширеніших помилок — плутанина між KRI, тригерами та наслідками.

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

У практиці це виглядає так:

• показник — середній час обробки заяв;
• тригер — перевищення встановленого порогу протягом визначеного періоду;
• подія — затримка виплат і скарги клієнтів.

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

3.3. Практичні приклади тригерів у реальних процесах

ІТ-ризики.
Система може працювати, але демонструвати нестабільність:

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

Тригером тут є не сам збій, а стійке відхилення показників від нормального рівня, яке вказує на втрату запасу міцності.

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

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

3.4. Тригери та управлінські дії: найслабша ланка

Навіть коли тригери формально визначені, вони часто не працюють через відсутність наступного кроку.

Практичний приклад.
У профілі ризиків зазначено: «перевищення порогового значення KRI». Але:

• не визначено, хто реагує;
• не встановлено строків;
• не описано можливі дії.

У результаті тригер спрацьовує «на папері», але не запускає управлінського механізму. Це створює ілюзію контролю без реального впливу.

Ефективний тригер завжди має:

• чіткий поріг;
• відповідального за реакцію;
• перелік можливих управлінських дій.

3.5. Тригери як інструмент випередження

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

Компанії, які системно працюють з тригерами, рідше стикаються з «раптовими» інцидентами. У більшості випадків проблеми не є несподіваними — вони просто не були визнані сигналом до дії вчасно.

4. Як поєднати причини, драйвери та тригери в єдиній моделі аналізу ризику

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

Практика показує: ризик стає керованим лише тоді, коли всі три елементи працюють як єдина система. Саме зв’язки між ними, а не окремі визначення, створюють основу для рішень.

4.1. Чому фрагментарний аналіз не працює

Практичний приклад (ІТ-ризик).
У профілі ризиків зазначено: «ризик збою інформаційних систем». Причини описані формально — «складність архітектури», «залежність від постачальників». Драйвери не деталізовані, тригери відсутні.

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

Проблема тут не в тому, що ризик був невідомий. Проблема в тому, що між причинами, драйверами та моментом дії не було логічного ланцюга.

4.2. Наскрізна модель: як це виглядає на практиці

Щоб аналіз ризику перестав бути описовим, він має відповідати на три управлінські запитання:

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

Практичний приклад (наскрізна логіка ІТ-ризику).

Причини ризику.

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

Ці причини існують постійно і самі по собі ще не означають неминучого інциденту.

Драйвери ризику.

• зростання кількості транзакцій;
• поява нових інтеграцій;
• збільшення частоти змін у системі.

Саме вони змінюють поведінку ризику і поступово зменшують запас стійкості системи.

Тригери ризику.

• перевищення часу відгуку понад встановлений поріг;
• повторювані помилки в логах у пікові години;
• зростання кількості інцидентів певного типу протягом короткого періоду.

Тригер фіксує момент, коли ризик перестає бути фоновим і потребує управлінського втручання.

4.3. Від аналізу до рішень: що змінюється для управління

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

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

• обмежити навантаження;
• перенести реліз;
• посилити контроль;
• залучити додаткові ресурси.

По-друге, моніторинг перестає бути формальністю. Показники більше не збираються «про всяк випадок», а чітко пов’язані з драйверами і тригерами.

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

4.4. Що відбувається, коли один з елементів відсутній

Практика добре показує наслідки перекосів:

• Без аналізу причин контролі спрямовані на симптоми, а не на джерело проблем.
• Без драйверів ризик виглядає стабільним, навіть коли його поведінка вже змінюється.
• Без тригерів компанія бачить ризик, але реагує запізно.

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

4.5. Інтегрована модель як основа всієї системи RM

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

• формується реалістична оцінка ризику;
• встановлюються ліміти;
• визначаються сценарії;
• будуються KRI;
• приймаються управлінські рішення.

Без цього будь-яка подальша оцінка ризику неминуче спиратиметься на спрощену, а іноді й хибну картину.

Висновки

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

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

Поєднання причин, драйверів і тригерів у єдиній моделі змінює саму логіку управління ризиками. Компанія перестає дивуватися інцидентам і починає бачити їхній розвиток заздалегідь. Моніторинг перестає бути звітністю заради звітності й стає інструментом ухвалення рішень. А відповідальність за ризики переходить з абстрактного рівня на цілком конкретний управлінський контур.

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

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

Сергій БАБИЧ