Джерела ризиків: як знаходити те, що приховане у процесах, даних та залежностях
Чому джерела ризиків не завжди видно на поверхні
Управління ризиками починається з очевидного запитання: звідки беруться ризики? Зазвичай перша відповідь здається простою — «із процесів», «із людей», «із ІТ-систем», «із зовнішнього середовища». Але коли компанія починає реальну ідентифікацію, стає зрозумілим, що справжні джерела ризиків майже ніколи не лежать на поверхні. Вони приховані між процесами, у деталях взаємодій, у зв’язках між людьми, у поведінці систем та у залежностях, про які організація не замислюється щодня.
ISO 31000 підкреслює, що джерела ризику можуть бути внутрішніми, зовнішніми або пов’язаними з подіями та драйверами. Але стандарт не дає готового переліку — й це не недолік, а принципова позиція. Джерела ризиків завжди унікальні для конкретної компанії, і тому їх неможливо «побачити» за допомогою універсальної таблиці. Те, що є суттєвим у великій страховій групі, може бути несуттєвим у невеликому роздрібному страховикові, і навпаки. Логіка ISO базується на контексті: тільки розуміючи власну діяльність, компанія може побачити власні джерела ризику.
Складність також у тому, що джерела ризиків рідко проявляються напряму. У більшості випадків вони маскуються під звичайні операційні ознаки: затримки, залежності, ручні операції, технічні ланцюжки, людські домовленості або технічні обмеження. На рівні щоденної роботи всі ці речі виглядають «нормальними», і тому їх сприймають як частину процесу, а не як потенційне джерело серйозного ризику. Лише коли відбувається подія, стає очевидним, що корінь проблеми був у структурі — а не в окремому співробітнику чи «випадковому збої».
Ще одна причина, чому джерела ризиків непомітні, — це розподіленість знань у компанії. У кожного підрозділу є власне розуміння процесів, власні припущення, власні правила. Але ISO 31000 вимагає дивитися на ризики на рівні всієї організації. Там, де окремий підрозділ бачить лише «світлофор» у своїй частині операцій, на рівні компанії може існувати ланцюг залежностей, який у разі збою створює масштабну подію. Тому джерела ризиків часто непомітні не тому, що їх немає, а тому, що ніхто не зібрав усю картину разом.
Нарешті, джерела ризиків приховані ще й тому, що компанія не завжди усвідомлює власні слабкі місця. Частина процесів залишається недокументованою, частина — «живе» у знаннях окремих людей, частина — базується на історичних домовленостях чи компромісах. Ні ISO 31000, ні НБУ №64, ні НБУ №194 не вимагають ідеальної формалізації кожного процесу, але всі вони виходять з того, що джерела ризику слід шукати там, де є найменша прозорість. Саме у таких місцях зазвичай і зароджуються майбутні події.
Тому перший крок у роботі з джерелами ризиків — прийняти, що вони не очевидні. Не побачити їх з першого погляду — не ознака поганого RM, а нормальна властивість будь-якої складної організації. Задача risk management — не шукати ризики там, де їх легко знайти, а вміти побачити те, що сховане у структурі. І саме тому наступний розділ цієї статті буде присвячений тому, як ISO класифікує джерела ризиків і як ці категорії допомагають побачити приховане.
Три категорії джерел ризику за логікою ISO
У підході ISO є одна важлива риса: стандарт не дає готових переліків ризиків, але він дає чітку рамку мислення. Саме тому ISO 31000 виділяє три великі категорії джерел ризику, які допомагають системно подивитися на організацію. Це не списки і не «шаблони», а структурні орієнтири — щоб компанія не шукала ризики хаотично, а працювала з усією картиною. Ці три категорії — внутрішні джерела, зовнішні джерела та джерела, пов’язані з подіями і драйверами. Разом вони дозволяють побачити як очевидні, так і приховані аспекти ризикової структури компанії.
Внутрішні джерела ризику — це те, що закладено всередині самої організації. Йдеться про процеси, системи, людей, структуру управління, політики, ІТ-архітектуру, культуру та взаємодію між підрозділами. ISO не деталізує, які саме внутрішні фактори можуть породжувати ризики, бо вони різняться залежно від компанії. Але стандарт однозначно наголошує: внутрішні джерела ризиків є результатом того, як організація влаштована та як вона працює. Саме тому вони найчастіше непомітні на перший погляд і потребують особливо ретельної ідентифікації.
Зовнішні джерела ризику — це фактори середовища, на які компанія не може впливати, але повинна враховувати. Це регуляторні вимоги, економічна ситуація, ринки, технологічні зміни, дії контрагентів, соціальні та політичні події. У контексті НБУ №64 і №194 зовнішні джерела особливо важливі, оскільки регулятор прямо вимагає враховувати зміни середовища при визначенні істотних ризиків. ISO 31000 підкреслює, що зовнішні фактори не є ризиками самі по собі — вони стають джерелами ризику лише тоді, коли можуть спричинити подію, що порушує досягнення цілей.
Третя категорія — джерела, пов’язані з подіями та драйверами. Це проміжна зона між внутрішнім і зовнішнім середовищем, яку компанії часто недооцінюють. Події можуть бути як внутрішніми (збої, помилки, порушення процедур), так і зовнішніми (зміни у законодавстві, дії контрагентів, технічні інциденти). Драйвери — це фактори, що підвищують або знижують ймовірність настання цих подій. ISO підкреслює, що ризики не існують без подій, а події — без драйверів. Тому ця категорія допомагає побачити те, що знаходиться між структурою компанії та її середовищем: місця, де події формуються, підсилюються або повторюються.
Ці три категорії не працюють окремо — вони утворюють повну структуру можливих джерел ризиків. Внутрішні джерела визначають, як працює компанія. Зовнішні джерела — у якому середовищі вона працює. Події та драйвери — як змінюється ситуація між цими двома рівнями. Саме ця рамка дозволяє ідентифікувати ризики системно, а не через інтуїцію чи «знання окремих людей». У результаті компанія отримує можливість не тільки визначити ризики, а й зрозуміти, чому вони виникають і що впливає на їх частоту та масштаб.
У наступному розділі ми зосередимося на тому, як саме аналіз процесів допомагає побачити внутрішні джерела ризиків, які зазвичай не видно до того моменту, коли стається інцидент. Це один із ключових інструментів, який використовують у практиці ISO та в підходах НБУ до оцінки операційних і технічних ризиків.
Аналіз процесів як метод виявлення ризикових джерел
Аналіз процесів — це один із найнадійніших способів знайти внутрішні джерела ризиків, які у щоденній роботі залишаються непомітними. ISO 31000 не нав’язує конкретних інструментів, але логіка стандарту та практика управління ризиками однозначно показують: саме процеси є тим місцем, де взаємодіють технології, люди, дані, дії та залежності, — а отже, саме там найчастіше з’являються ризики. У страхових компаніях ця логіка набуває особливого значення, бо майже кожен ризик виникає або всередині процесу, або на стику кількох процесів.
Під час аналізу процесів важливо працювати не з формальними схемами, а з реальністю. Формальна модель процесу завжди виглядає ідеально: правильні переходи, чіткі ролі, логічна послідовність дій. Але ідентифікація ризиків починається там, де з’являється різниця між «як процес має працювати» і «як він працює насправді». Саме у цій різниці й виникає більшість джерел ризиків. Тому підхід ISO передбачає не лише документальні описи, а й фактичний аналіз: які дії виконуються вручну, де є залежність від окремої людини, яка інформація використовується, як працює технічна частина процесу.
Важливу роль відіграють точки переходу — моменти, коли результат однієї операції передається іншому підрозділу, іншій системі, іншій людині. На таких стиках зазвичай виникає найбільша кількість ризикових ситуацій. Це підтверджується і практикою оцінювання операційних ризиків, і вимогами НБУ №64 та №194, які прямо вказують на необхідність враховувати залежності між підрозділами та технологіями. Коли компанія аналізує процеси за такою логікою, стає видно те, що в повсякденному режимі здається буденним: ручні етапи, дублювання функцій, слабкі місця контролів, залежності від поодиноких експертів, складні технічні переходи.
Ще один важливий аспект — рівень деталізації. Ідентифікація ризиків не вимагає занурення у мікрорівень кожної дії, але потребує достатньої глибини для розуміння причин і драйверів подій. ISO 31000 наголошує: ризики виникають там, де є невизначеність. Якщо процес описаний надто поверхнево, джерела ризику залишаються невидимими. Якщо надто детально — компанія втрачає картину і фокусується на дрібницях. Оптимальна глибина — та, яка дозволяє сформувати повноцінний опис джерела, події, причин і наслідків.
Аналіз процесів — це не разовий захід, а постійна діяльність. Процеси змінюються, автоматизуються, інтегруються з новими ІТ-системами, підлаштовуються під нові вимоги НБУ, доповнюються новими ролями чи скорочуються. Кожна зміна автоматично створює нові потенційні джерела ризиків. Саме тому в ISO 31000 та в регуляторних вимогах наголошується на системності: ідентифікація має бути регулярною, а процеси — переглядатися у структурованому порядку.
У наступному розділі ми розглянемо інший важливий інструмент — роботу з інцидентами, аудиторськими спостереженнями та скаргами. Саме ці матеріали дозволяють побачити джерела ризиків, що вже проявили себе на практиці, та зрозуміти, які події повторюються або накопичуються у компанії.
Аналіз інцидентів, аудиторських зауважень та скарг
Аналіз інцидентів — один із найбільш недооцінених механізмів виявлення джерел ризиків. У багатьох компаніях інциденти розглядаються як «разові проблеми», а не як матеріал для системного аналізу. Але логіка ISO 31000 та підходи НБУ №64 і №194 прямо ведуть до іншого: інцидент — це не просто подія, а сигнал, що вказує на наявність певного джерела ризику або на слабкість у процесі. Тому будь-яка серйозна система управління ризиками використовує інциденти не лише для реагування, а передусім для ідентифікації.
Користь інцидентів полягає в тому, що вони показують реальну поведінку системи. Процеси можуть виглядати на папері ідеально, але фактичні збої, порушення строків, технічні помилки чи людські недогляди демонструють, де саме існує структурна вразливість. Це дозволяє побачити те, що рідко видно під час звичайного аналізу процесів: накопичувальні ефекти, повторювані проблеми, залежність від конкретних людей, складні або нестійкі переходи між системами, недоліки у контролях. Таким чином, інциденти допомагають виявити саме джерела ризиків, а не лише прояви подій.
Аудиторські спостереження відіграють не менш важливу роль. На відміну від інцидентів, вони часто не вказують на фактичний збій, але виявляють системні слабкі місця, які можуть стати джерелами майбутніх ризиків. Це можуть бути недосконалі процедури, надмірні ручні операції, недостатня деталізація регламентів, нечіткі зони відповідальності, відсутність належного контролю. У підходах НБУ аудиторські висновки — це важливий елемент оцінки системи управління ризиками. Якщо внутрішній чи зовнішній аудит вказує на слабкість, це означає, що компанія повинна ідентифікувати відповідні ризики та працювати з ними системно.
Скарги клієнтів — ще одне джерело інформації, яке допомагає побачити ті аспекти діяльності, що в операційному процесі можуть залишатися непомітними. Вони часто сигналізують про системні проблеми: помилки в комунікації, неточності у документах, технічні труднощі, недосконалість продуктів, надмірну складність процедур. Це не лише індикатори репутаційного ризику — вони є підказками щодо того, де в структурі компанії існують джерела операційних та процесних ризиків. ISO 31000 наголошує, що ідентифікація має враховувати всі релевантні дані, а скарги — це дані, які надходять безпосередньо від середовища, у якому компанія працює.
Особливо важливо, що інциденти, аудиторські спостереження та скарги дають компанії динамічну картину. На відміну від процесних описів, які відображають сталі структури, ці джерела показують реальний стан справ у режимі «тут і зараз». Вони дозволяють помітити тенденції: коли окремі випадки починають повторюватися, це означає, що джерело ризику може бути не поодиноким, а системним. Така інформація є критичною для відповідності НБУ №64, який вимагає враховувати істотні ризики, що проявляються у діяльності компанії.
Таким чином, робота з інцидентами, аудитом і скаргами — це не «підтримуюча» функція, а один із ключових елементів моделі ідентифікації. Вона дозволяє виявити джерела ризиків, які неможливо побачити лише через аналіз процесів або зовнішніх факторів. А головне — ця інформація доступна завжди, її не потрібно моделювати чи вигадувати: достатньо працювати з реальністю, яку компанія вже має.
У наступному розділі ми розглянемо третій великий механізм виявлення джерел ризиків — аналіз змін. Саме зміни, за логікою ISO, найчастіше створюють нові джерела ризиків або активують старі.
Аналіз змін: нові продукти, ІТ-рішення, регуляторні вимоги
Аналіз змін — один із найважливіших інструментів у сучасному ризик-менеджменті. ISO 31000 наголошує, що ризики виникають там, де є невизначеність, а зміни — це середовище з максимальною концентрацією невизначеності. Саме під час змін з’являються нові залежності, слабкі місця, технічні обмеження, людські помилки або незадокументовані рішення, які не можна побачити в поточних процесах. Тому кожного разу, коли компанія оновлює продукт, запускає нову ІТ-систему, змінює структуру або адаптується до регуляторних вимог, вона створює потенційні джерела ризиків, які необхідно вчасно ідентифікувати.
Нові продукти — окрема зона ризикової концентрації. У страхуванні будь-який продукт має багато вбудованих залежностей: андеррайтинг, врегулювання, документообіг, тарифи, систему мотивації, облік премій, взаємодію з брокерами, технічні параметри договорів. Новий продукт неминуче змінює щонайменше частину цих елементів. Якщо компанія не аналізує ці зміни, вона не побачить нових джерел ризиків: технічних, операційних, юридичних, продуктових або персональних. Постанова НБУ №194 прямо вимагає, щоб страховик проводив оцінку ризиків під час розробки продуктів — фактично говорячи про окрему зону ідентифікації, яку неможливо замінити загальними списками.
Зміни в ІТ-системах — це ще складніша сфера. ІТ — це не лише технологія, це основа всієї бізнес-логіки страховика: тарифи, ліміти, коридори премій, статуси договорів, виплати, резерви, онлайн-канали, інтеграції. Будь-яке оновлення, міграція, впровадження нового модуля або зміна архітектури створює нові джерела ризиків: залежність від постачальників, тимчасові ручні операції, можливі некоректні розрахунки, ризики безпеки, порушення даних. Постанова НБУ №64 прямо говорить про важливість управління інформаційними системами та ІТ-ризиками — а це неможливо без якісної ідентифікації, яка починається із аналізу кожної зміни.
Регуляторні зміни — ще один тип подій, який автоматично створює нові ризикові джерела. Коли НБУ оновлює вимоги до резервів, продуктів, звітності, процесів, систем управління або розкриття інформації, компанія змушена адаптувати внутрішні політики, бізнес-процеси, ІТ-інструменти, контрольні процедури. У момент таких змін часто виникають тимчасові вразливості: перехідні операції, недосконалі інструкції, подвоєні функції, неузгоджені ролі. Це не недолік компанії — це неминучий ефект будь-якої трансформації. ISO 31000 наголошує, що зміни повинні бути одним із регулярних тригерів для повторної ідентифікації ризиків.
Аналіз змін важливий ще й тому, що він дозволяє побачити те, що інші механізми не завжди виявляють. Процеси показують структуру. Інциденти показують те, що вже сталося. А зміни показують майбутні ризики — ті, які ще не встигли проявити себе, але можуть мати суттєвий вплив. Це дозволяє компанії діяти на випередження, а не тільки реагувати на минулі проблеми.
Таким чином, аналіз змін — це не формальність, а важливий елемент побудови надійної системи ідентифікації. Він допомагає побачити джерела ризиків там, де вони лише зароджуються, і забезпечує відповідність вимогам ISO 31000 та нормативам НБУ.
У наступному розділі ми перейдемо до ще однієї категорії джерел — операційних залежностей. Саме вони, за практикою галузі, є одними з найбільш прихованих і водночас найнебезпечніших.
Операційні залежності: люди, технології, контрагенти
Операційні залежності — одна з тих зон, де джерела ризиків найчастіше залишаються невидимими до моменту, коли вже стається подія. ISO 31000 підкреслює, що ризики виникають у точках взаємодії. А операційні залежності — це саме взаємодія: між людьми, між системами, між процесами, між компанією та зовнішніми учасниками. У сучасному страхуванні таких точок настільки багато, що без системного підходу практично неможливо побачити, які саме з них здатні стати джерелами ризику.
Залежності, пов’язані з людьми, є найочевиднішими, але водночас найменш формалізованими. У кожній компанії існують критичні знання, які зберігаються у головах окремих працівників; ручні операції, які виконуються «за звичкою»; неформальні домовленості між підрозділами; практики, що ніколи не були задокументовані. ISO 31000 наголошує, що людські фактори слід розглядати як частину внутрішнього середовища, а це означає — як потенційні джерела ризиків. НБУ №64 також вимагає оцінювати ризики персоналу, включаючи їхню компетентність, навантаження, доступи та відповідальність.
Залежності, пов’язані з технологіями, сьогодні є ще складнішими. ІТ-системи створюють враження надійності: автоматизація, інтеграції, цифрові сервіси, централізація даних. Але кожна інтеграція — це ланцюг залежностей. Кожний модуль — потенційне джерело ризику. Кожний інтерфейс — точка, де може виникнути збій. У багатьох компаніях ІТ-ризики залишаються недооціненими саме тому, що їх не видно до моменту технічного інциденту. НБУ №64 і №194 прямо зобов’язують страховиків враховувати ризики інформаційних систем та інформаційної безпеки — а це можливо лише через глибоку ідентифікацію залежностей між системами.
Залежності від контрагентів — ще одна складна зона, яка часто залишається поза увагою. Постачальники ПЗ, провайдери даних, партнери, брокери, асистанси, зовнішні експерти — усі вони формують частину операційного ланцюга. За логікою ISO ці зовнішні учасники є частиною зовнішнього контексту, але їхня взаємодія з компанією створює внутрішні залежності. Це означає, що вони можуть стати джерелами ризиків: через затримки, неякісні дані, невиконання умов, помилки у інтеграціях, недоступність сервісів. Постанова №194 вимагає, щоб страховик оцінював ризики, пов’язані з контрагентами, особливо в частині договорів, врегулювання та ІТ-рішень.
Операційні залежності небезпечні тим, що вони рідко існують ізольовано. Людська дія переходить у технологічну, технологічна — у взаємодію з контрагентом, а зовнішня подія може активувати внутрішній збій. Це створює «ланцюговий ефект», який складно передбачити без системної ідентифікації. Тому ISO 31000 та НБУ №64 наголошують на необхідності враховувати взаємозв’язки, а не тільки окремі процеси.
У наступному розділі ми поговоримо про типові помилки при визначенні джерел ризику. Це важливо, тому що навіть маючи якісні дані — процеси, інциденти, аудити, зміни — компанії часто роблять типові кроки, які спотворюють картину ризиків і призводять до неправильних висновків.
Помилки у визначенні джерел ризику
Попри те, що ISO 31000 дає зрозумілу рамку, а НБУ №64 і №194 підсилюють вимоги до системності, компанії часто припускаються однакових помилок під час визначення джерел ризику. На перший погляд вони здаються незначними, але на практиці саме ці помилки створюють спотворений ризик-профіль, ускладнюють аналіз і заважають побудувати ефективне управління ризиками. Розглянемо найтиповіші з них — ті, що зустрічаються в українській страховій практиці найчастіше.
Перша помилка — плутання джерел ризику з наслідками. Це трапляється тоді, коли компанія називає джерелом те, що є результатом події, а не її коренем. Наслідок завжди відображає вже здійснене відхилення від очікуваного, тоді як джерело — це фактор, що створює потенційну можливість для цього відхилення. Якщо компанія фіксує як «джерело ризику» фінансовий збиток, репутаційні втрати чи зниження премій, вона не визначає ризик, а лише описує його наслідки. ISO 31000 прямо розмежовує ці поняття, і порушення цього принципу веде до того, що причини подій залишаються невиявленими.
Друга помилка — надмірна узагальненість. Часто компанії замінюють реальні джерела ризику загальними фразами: «операційні ризики», «регуляторний ризик», «ризик персоналу», «ІТ-ризики». Такі формулювання не розкривають структуру ризику і не дають можливості провести ані аналіз причин, ані оцінювання. ISO 31000 наголошує, що ідентифікація повинна бути достатньо деталізованою — але без надмірної складності. Якщо джерело ризику не описане конкретно, компанія фактично не знає, що саме аналізувати.
Третя помилка — зосередження на «видимих» джерелах і ігнорування прихованих. У багатьох компаніях під час ідентифікації називають лише те, що вже відоме: затримки, помилки, навантаження, технічні збої. Але приховані джерела — ті, що містяться в переходах процесів, у людських залежностях, у старих рішеннях, у тимчасових обхідних схемах — залишаються поза увагою. Це створює ілюзію контролю: компанія бачить симптоми, але не бачить причин. Саме тому ISO й рекомендує аналізувати процеси, інциденти, аудити та зміни комплексно, а не окремо.
Четверта помилка — надмірна залежність від «загальних списків ризиків». Часто компанії використовують універсальні переліки ризиків, знайдені у методичках, у стандартах або в інтернеті. Але ці списки не відповідають конкретній діяльності, продуктам чи процесам страховика. ISO 31000 прямо підкреслює: ризики виникають із контексту, і без розуміння контексту жоден список не буде коректним. Такий підхід призводить до дублювання, формального виконання вимог і штучного ускладнення ризик-профілю.
П’ята помилка — визначення джерел ризику без урахування залежностей. У багатьох компаніях під час ідентифікації аналізують окремі процеси чи окремі системи, але не дивляться на взаємодію між ними. Саме у взаємодіях виникає більшість складних подій. Якщо компанія не враховує операційні, технологічні або зовнішні залежності, вона визначає джерела ризиків «по частинах», але не бачить загальної структури. Це суперечить логіці ISO, яка вимагає розглядати ризики як результат взаємодії елементів системи.
Шоста помилка — відсутність прив’язки до даних. Ідентифікація ризиків іноді проводиться як теоретична вправа: збір думок, дискусії, формальні зустрічі. Без урахування інцидентів, аудиту, скарг, технічних звітів, результатів контролів і змін такий підхід створює ризик-профіль, побудований на припущеннях. НБУ №64 і №194 прямо вимагають, щоб система управління ризиками була заснована на даних, а не на загальних судженнях.
Помилки у визначенні джерел ризиків — це не провина компанії, а природний виклик, з яким стикаються всі організації на шляху до зрілої системи RM. Важливо те, що їх можна уникнути, якщо працювати системно, використовувати дані, співвідносити внутрішні та зовнішні фактори і дотримуватися логіки ISO 31000. У наступному розділі ми підсумуємо всі елементи ідентифікації джерел ризику та зробимо місток до завершальної частини статті, присвяченої методам ідентифікації.
Місток → методи ідентифікації ризиків
Після того як компанія розглянула джерела ризиків на рівні процесів, інцидентів, змін і операційних залежностей, виникає логічне запитання: як забезпечити, щоб ці джерела були виявлені системно, а не випадково? Саме тут закінчується аналіз структури ризиків і починається тема методів ідентифікації — тих інструментів, без яких навіть найчіткіша логіка ISO 31000 залишиться лише концепцією.
Незалежно від того, наскільки якісно організація працює з процесами чи інцидентами, без структурованих методів результат завжди залежатиме від окремих людей, їхнього досвіду, обсягу інформації, розуміння контексту й навіть особистих пріоритетів. Ідентифікація ризиків може бути надійною лише тоді, коли вона спирається не на інтуїцію, а на формальні, повторювані та зрозумілі інструменти. Саме тому ISO 31000 та підтримуючі стандарти (особливо ISO 31010) наголошують на важливості методів — інтерв’ю, мозкових штурмів, структурованих списків, процесних оглядів, аналізу причин, аналізу сценаріїв та інших інструментів.
Важливо й те, що методи дозволяють подолати упередження, які неминуче виникають у будь-якій організації. Люди бачать лише те, що стосується їхніх процесів. Підрозділи фокусуються на власних зонах відповідальності. Менеджмент бачить стратегічні питання, але не завжди бачить операційні деталі. Якісні методи ідентифікації об’єднують ці різні рівні сприйняття і дозволяють побачити загальну картину. Вони забезпечують ту саму «структурованість», яку вимагають і ISO, і НБУ №64, і НБУ №194.
Ще один важливий аспект полягає в тому, що методи дозволяють масштабувати ідентифікацію. Коли компанія зростає, з’являються нові продукти, процеси, технології, команди, партнерства. Якщо ідентифікація базується лише на знаннях окремих людей або на формальних зустрічах, вона перестає встигати за темпом змін. Стандартизовані методи дозволяють зберегти єдиний підхід, забезпечити порівнюваність результатів та підтримувати системність незалежно від розміру й складності компанії.
Саме тому наступна стаття нашого циклу буде присвячена методам ідентифікації ризиків. Ми розглянемо лише ті інструменти, які мають формальне підґрунтя в міжнародних стандартах — ISO 31000, ISO 31010, COSO ERM. Жодних «вигаданих» або «популярних» методів, які не мають під собою офіційного обґрунтування. Лише ті, що можуть бути використані у реальній роботі страхової компанії і відповідають вимогам регулятора.
У цій статті ми завершили тему джерел ризику: звідки вони беруться, чому приховані, як їх знаходити через процеси, інциденти, зміни та залежності. Далі ми перейдемо до практичного інструментарію — того, що допомагає перетворити логіку на регулярний, керований, відтворюваний процес.
В наступній статті нашого циклу спробую відповісти на запитання:
«Як саме працюють методи ідентифікації ризиків і чим вони відрізняються один від одного?»
Сергій БАБИЧ