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

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

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

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

Ризик, про який всі знають — але ніхто не ескалує

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

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

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

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

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

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

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

Коли ескалація відбувається занадто пізно: як виглядає запізніле рішення

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Висновок

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

Сергій БАБИЧ