Цикл: Практика ризик-менеджменту

Сценарний аналіз (scenario analysis) давно став обов’язковим елементом системи управління ризиками. Він використовується в ORSA, входить до вимог регулятора, регулярно згадується у внутрішніх документах і майже завжди присутній у звітності. Якщо подивитися формально, у більшості компаній із цим інструментом проблем немає — сценарії будуються, розрахунки проводяться, результати фіксуються.

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

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

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

Як зазвичай “роблять” сценарний аналіз — і чому це не працює

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

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

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

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

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

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

Кейс 1. ОСЦПВ: коли сценарій показує не проблему, а момент для рішення

У ситуації з портфелем ОСЦПВ компанія зіткнулася з класичною дилемою: зростання бізнесу виглядало позитивно, але внутрішній аналіз почав показувати накопичення ризику. Саме на цьому етапі було прийнято рішення провести сценарний аналіз, але не в класичному форматі “базовий–песимістичний”, а з чітким фокусом на конкретному питанні: як зміниться ситуація при зростанні середнього збитку.

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

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

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

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

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

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

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

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

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

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

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

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

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

Кейс 3. Перестрахування: коли сценарій руйнує ілюзію захисту

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

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

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

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

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

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

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

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

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

Кейс 4. Операційний процес: коли сценарій показує не помилку, а закономірність

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

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

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

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

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

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

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

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

Висновки: як виглядає сценарний аналіз, коли він працює

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

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

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

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

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

Сергій БАБИЧ