Цикл «Коли управління ризиками не спрацьовує»

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

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

Ця стаття — про механізм такого зникнення. Про те, як працює не-ескалація в реальних організаціях. І про те, чому формальна наявність процедури не гарантує, що в критичний момент хтось скаже: «Ми повинні зупинитися».

Коли сигнал був у системі, але не став рішенням: уроки Boeing 737 MAX

Історія з літаками Boeing 737 MAX стала одним із найгучніших прикладів того, як сигнал може існувати всередині складної організації, але не трансформуватися в управлінське рішення вчасно. Після двох катастроф у 2018–2019 роках розслідування виявили: інформація про проблеми із системою керування польотом (MCAS) була відома на різних рівнях компанії задовго до другого інциденту.

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

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

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

Третій елемент — мова звітності. Розслідування показали, що окремі ризики були описані як такі, що «ймовірність низька» або «в межах прийнятного». Формально це коректні формулювання. Але саме така мова здатна знизити гостроту сигналу, коли він піднімається нагору.

У результаті правління не бачить системної загрози. Воно бачить набір технічних питань, які «перебувають під контролем». А це принципово різні управлінські ситуації.

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

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

Коли ризик «вирішують локально» і не виносять нагору: приклад Volkswagen

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

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

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

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

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

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

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

У випадку Volkswagen проблема не полягала в нестачі регламентів. Вона полягала в управлінському рішенні не піднімати питання до моменту, коли воно стало публічним.

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

Коли сигнал доходить нагору, але втрачає гостроту: сила формулювань і агрегування

Існує ще один тип не-ескалації, який формально не виглядає як збій. Сигнал передається. Звіт підготовлений. Питання винесене на комітет. Але в процесі підготовки матеріалів ризик поступово втрачає свою критичність. Він стає частиною узагальненої статистики, «поточної динаміки» або «контрольованої ситуації».

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

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

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

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

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

Для функції управління ризиками це означає необхідність чіткої межі між «інформуванням» і «попередженням». Інформування передає дані. Попередження формує управлінський контекст і прямо вказує на потенційні наслідки.

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

Коли ескалація відбулася, але відповідальність розчинилася

Існують ситуації, коли ризик справді піднімається нагору. Питання включене до порядку денного. Матеріали підготовлені. Обговорення відбулося. Протокол зафіксував позиції сторін. З формальної точки зору — ескалація спрацювала. Але рішення не змінилося. А відповідальність стала колективною настільки, що фактично перестала бути персональною.

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

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

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

У таких ситуаціях ескалація не блокується і не пом’якшується. Вона просто завершується компромісом. А компроміс у сфері ризику іноді означає продовження руху за відсутності повної впевненості.

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

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

Що робить ескалацію реальною, а не формальною

Якщо узагальнити розглянуті кейси — від Boeing 737 MAX до Volkswagen та рішення в межах NASA — стає очевидно: сигнал не зникає випадково. Він або фрагментується, або «заземлюється» на операційному рівні, або пом’якшується мовою звітності, або розчиняється в колегіальності. У кожному випадку механізм різний, але результат однаковий — рішення не змінюється.

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

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

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

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

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

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

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

Про це — у наступній статті циклу.

Сергій БАБИЧ