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

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

Важливо, що всі ці помилки описані не заради критики. Більшість з них зустрічаються навіть у компаніях із розвиненими системами ризик-менеджменту. Знання про них — це спосіб уникнути повторення чужих хибних кроків і побудувати процес ідентифікації так, щоб він працював не “для регулятора”, а для реального контролю ризиків у бізнесі.

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

Помилка №1: починати з «оцінки», а не з ідентифікації

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

Проблема починається тоді, коли аналіз ведеться від кінця: “давайте визначимо, наскільки це ризиково”, — ще до того, як з’ясовано, що саме може піти не так насправді. Такий підхід суперечить логіці ISO 31000, де ідентифікація визначена як окремий, самостійний крок, який повинен передувати будь-якій оцінці. Якщо ідентифікація відбулася поверхнево — оцінювання автоматично стає недостовірним, яким би формально правильним воно не було.

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

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

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

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

Помилка №2: змішування джерел ризику з наслідками

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

Типовий приклад: компанія вказує ризик “недотримання законодавства”. Формально звучить серйозно, але з точки зору ISO 31000 це не ризик, а наслідок. Причини можуть бути зовсім різними: некоректна логіка в ІТ-системі, помилка оператора, відсутність оновлення нормативних файлів, неправильно розроблені бізнес-правила, помилка у методології розрахунку. Якщо не названо джерело або подію, система RM не може визначити, де саме виникає проблема — і що потрібно контролювати.

У публічних кейсах, які аналізували європейські регулятори (наприклад, FCA і PRA під час розслідувань системних інцидентів у компаніях фінансового сектору), прямо зазначалося: велика частина провалів у контролях була пов’язана з тим, що організація описувала ризики “через наслідки”. У результаті компанія створювала контроль там, де не було проблеми, і не створювала там, де вона була реальною. Це класичний ефект неправильної ідентифікації.

Ще один важливий аспект — змішування джерел і наслідків руйнує причинно-наслідкову логіку Bow-Tie, RCA та інших міжнародно визнаних технік. Якщо в “центрі” замість події записати наслідок, то ліве крило (джерела) та праве крило (наслідки) перестають мати сенс. Це робить аналіз неможливим, а результати — нефункціональними.

Наслідки такої помилки добре видно у реальних операційних інцидентах. Наприклад, у кількох звітах про події, які публікувалися страховими та банківськими регуляторами ЄС, фіксували випадки, коли компанії роками декларували ризик “помилки персоналу”, але реальна проблема полягала у структурі процесу: відсутність подвійної перевірки, складний інтерфейс, неправильні бізнес-правила. Формулювання “помилка персоналу” не дозволило знайти джерело слабкого місця — а отже, і контроль був неефективним.

Правильний підхід: ризик має бути сформульований як подія (“що може статися?”) або як джерело ризику (“що створює можливість події?”). Наслідки описуються окремо — у полі “potential impact”, як того вимагають і ISO, і НБУ. Така структура дозволяє побудувати коректні сценарії, визначити релевантні контролі, зробити реалістичні KRI та провести точну оцінку.

Помилка №3: дублювання загальних ризиків з Google

Це одна з найпоширеніших і водночас найшкідливіших практик. Замість реальної ідентифікації ризиків компанії часто використовують “готові списки”, які легко знайти в інтернеті або в презентаціях консультантів. Такі переліки виглядають солідно: «ризик шахрайства», «ризик недотримання законодавства», «ризик помилки персоналу», «ризик IT-збоїв». Але проблема в тому, що це не ризики компанії, а абстрактні загальні категорії, які однаково можна застосувати до будь-якого банку, страховика чи торгової мережі.

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

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

Ще один наслідок — неможливість прив’язати ризики до процесів, контролів і відповідальних осіб. Якщо формулювання абстрактне, воно не містить інформації про місце виникнення ризику, про операцію, про залежність або про технологічну точку. У результаті компанія формально “має ризики”, але не має жодного інструменту впливу на них.

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

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

Помилка №4: ідентифікація «з коробки», без аналізу процесів

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

Міжнародні регулятори неодноразово вказували на проблему “as-designed vs as-operating” — різницю між тим, як процес описаний у документах, і тим, як він працює насправді. У європейських страхових компаніях було зафіксовано чимало випадків, коли офіційні процесні схеми виглядали бездоганно, але реальні інциденти виникали саме в тих місцях, які не потрапили в аналіз: ручні виправлення даних, тимчасові таблиці Excel, інтеграції “на словах”, обхідні рішення, вплив сезонного навантаження. Це і є наслідки ідентифікації, проведеної “по документах”, а не по фактах.

Ще одна суттєва проблема виникає тоді, коли компанія підміняє аналіз процесів загальними обговореннями на рівні підрозділу. Наприклад, під час сесії менеджери говорять про ризики в широких категоріях: “затримки у роботі системи”, “ризик помилки”, “ризик неправильного внесення даних”. Але жоден з цих “ризиків” не вказує, де саме може виникнути проблема — на етапі отримання документів, розрахунку, передачі даних, погодження, імпорту, перевірки чи експорту. Без розбору процесу на етапи ризик-менеджмент перетворюється на припущення.

Слабкість такого підходу легко побачити у звітах про операційні інциденти. Багато міжнародних фінансових установ у публічних розслідуваннях визнавали, що причиною критичних інцидентів були “unknown process steps” — частини процесу, які не були задокументовані, але існували в реальній роботі. Ідентифікація “з коробки” ніколи не знаходить такі слабкі місця, тому що вона не працює з фактичними ланцюжками дій.

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

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

Помилка №5: відсутність прив’язки до контексту

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

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

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

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

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

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

Помилка №6: неправильна участь стейкхолдерів

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

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

Друга типова помилка — домінування однієї функції. Якщо ідентифікацію веде лише ІТ, ризики стають “технічними”. Якщо лише операції — ризики описуються через ручні кроки. Якщо тільки юридичний чи комплаєнс — весь перелік зводиться до регуляторних наслідків. Такий перекіс руйнує системність, бо реальні ризики завжди виникають на стиках: продукт → процес → дані → технологія → люди. Саме тому ISO 31000 вимагає “appropriate and timely involvement of stakeholders”.

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

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

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

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

Помилка №7: «ідеальні списки» без даних і без фактів

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

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

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

Ще одна характерна ознака «ідеальних списків» — повна відсутність конкретики. Наприклад: “ризик IT-збоїв”, “ризик неправильної обробки даних”, “ризик несвоєчасного врегулювання”, “ризик людської помилки”. Жоден з цих ризиків не містить інформації про те, де саме, на якому етапі, у якій системі, за яких умов і через що він може виникнути. Це робить неможливим прив’язку до контролів, до показників (KRI), до відповідальних осіб або до реальних сценаріїв.

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

Четвертий аспект — відсутність числової бази. Є процеси, де доступні статистика, SLA, частота затримок, час обробки, кількість помилок, навантаження на персонал, стабільність систем, частота інцидентів. Ігнорування цих даних робить ризики нечутливими до змін. Якщо компанія не використовує факти, вона не може побачити тренди, структуру причин або вразливі зони.

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

Фінал: як поєднати контекст і ідентифікацію ризиків у реальній системі управління

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

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

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

Дані — ще один ключовий елемент. Інциденти, затримки, відхилення, SLA, аудиторські зауваження, якість даних, статистика помилок — усе це не просто інформація, а докази існування ризиків. Без фактів будь-яка ідентифікація залишається інтуїтивною. З фактами — стає основою для правильних контролів, реалістичних KRI та коректної оцінки ризику.

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

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

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

Сергій БАБИЧ