Як компанія визначає scope ідентифікації

У реальній компанії ідентифікація ризиків починається не з таблиць і навіть не з методів. Вона починається з відповіді на запитання: “що саме ми аналізуємо і з якою метою?” ISO 31000 наголошує, що визначення сфери (scope) — це фундамент для всього подальшого процесу. Якщо компанія не окреслює межі ідентифікації, вона або пропустить важливі зони, або навпаки розпорошить ресурси на несуттєве. Правильний scope — це баланс між системністю і практичністю.

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

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

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

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

Остаточним кроком є документування scope. Це вимога №185 і №194: компанія повинна мати доказову базу того, які процеси та продукти були охоплені, які межі встановлені, які припущення застосовувалися. Документований scope — це захист від довільності, від помилок інтерпретації та від “зміщення фокуса” під час аналізу. Він є опорою для аудиту, керівних органів і повторюваності процедури.

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

Ідентифікація на рівні процесів

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

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

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

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

Четвертий принцип — використання комбінованих методів. Walk-through, структуровані інтерв’ю, аналіз інцидентів, огляд контролів — усе це разом дає можливість розкласти процес на операційні елементи і знайти джерела ризиків, які не видно при використанні одного методу. ISO 31010 наголошує, що для процесів із великою кількістю ручних дій або технічних залежностей комбіновані підходи є рекомендованими.

П’ятий принцип — чітке документування виявлених ризиків у контексті етапу процесу. Це вимога НБУ №185 і №194: ризики повинні бути прив’язані до конкретних операцій, а не описані загальними фразами. Така прив’язка дозволяє не лише правильно оцінити ризик, а й визначити відповідального, контроль, частоту моніторингу та потенційні наслідки.

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

Ідентифікація на рівні продуктів

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

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

Другий принцип — увага до передумов, на яких базується продукт. Тарифи ґрунтуються на актуарних припущеннях, які залежать від ринку, збитковості, портфелю, сезонності, регіонів, динаміки продажів. Умови покриття побудовані на правових та операційних можливостях компанії. Андеррайтинг спирається на експертизу персоналу, якість даних, доступність інформації. Якщо ці передумови змінюються, продукт автоматично створює нові ризики. Саме тому ISO 31000 наголошує на зв’язку між ризиками та припущеннями.

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

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

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

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

Ідентифікація під час змін (IT, регулювання, персонал)

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

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

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

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

Четвертий принцип — зміни у персоналі також є змінами, які потрібно аналізувати. Перехід ключових співробітників, нові ролі, зміна команди, перепризначення відповідальності, нові підрозділи — усе це створює джерела ризиків. ISO 31000 вважає людський фактор критичним елементом контексту, а Постанова №194 визначає ризик персоналу як окремий вид ризику, що потребує системної ідентифікації.

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

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

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

Роль власників ризиків

У міжнародних стандартах немає жодної моделі управління ризиками, де ризик-менеджер самостійно “ідентифікує” ризики для всієї компанії. ISO 31000 та COSO ERM однозначно визначають: власники ризиків  є ключовими учасниками процесу, і якість ідентифікації прямо залежить від їхньої активної участі (стандарти не використовують термін “власник ризику” – СБ). У реальній організації саме вони мають знання, які дозволяють побачити реальні джерела ризиків — не формальні, а ті, що існують у щоденній роботі.

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

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

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

Четвертий принцип — власник ризику забезпечує практичність результатів. Якщо ризик визначений “іззовні”, він зазвичай стає або занадто теоретичним, або надто загальним. Якщо ризик визначений разом із власником — він завжди конкретний, прив’язаний до операції, містить інформацію, яку можна використати для контролю, моніторингу або зміни процесу. Саме це відповідає вимогам НБУ №64 та №194 щодо системності управління ризиками.

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

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

Артефакти: робочі записи, логічні схеми, протоколи

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

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

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

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

Четвертий артефакт — протокол ідентифікації ризиків. Це документ, у якому фіксується не лише перелік ризиків, але й:

• scope аналізу,
• методи, які застосовувалися,
• учасники процесу,
• джерела інформації,
• ключові припущення,
• критерії суттєвості,
• попередні висновки щодо причин і наслідків.

Постанова №194 прямо вимагає системності та документованості процесів управління ризиками, тому протокол є критично важливим елементом. Він показує «як» компанія дійшла до визначених ризиків — і це те, що перевіряє аудит і регулятор.

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

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

Чому RM не може «ідентифікувати ризики сам»

У жодній сучасній моделі управління ризиками ризик-менеджер не є «генератором ризиків». ISO 31000, COSO ERM, EIOPA Guidelines і Постанова НБУ №195 — усі документи однозначно визначають: ризики мають ідентифікувати ті, хто працює у процесах, ухвалює рішення, володіє даними, управляє продуктами або системами. Роль ризик-менеджера — методологія, фасилітація, якість, системність. Але не зміст і не операційні деталі. Причина проста: жоден RM-функціонал не бачить усього того, що знають власники процесів.

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

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

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

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

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

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

Саме тому у зрілих RM-системах ризик-менеджери не “збирають ризики”, а керують процесом, в якому бере участь бізнес.

Заключні положення

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

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

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

Саме тому наступна стаття нашого циклу буде присвячена найпоширенішим помилкам в ідентифікації ризиків — тим, які зустрічаються і у початкових, і у вже досвідчених компаніях. Ми розберемо, чому вони виникають, чим загрожують і як їх уникати, користуючись лише стандартом ISO 31000 та вимогами НБУ. Це буде логічне завершення практичного блоку перед переходом до оцінки ризиків як третього кроку RM.

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

Сергій БАБИЧ