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

Аналіз першопричин (root cause analysis, RCA) — це, мабуть, один із найбільш “зрозумілих” інструментів у ризик-менеджменті. Його проводять після інцидентів, використовують у внутрішньому контролі, вимагають регулятори, і майже в кожній компанії є формалізований підхід до його проведення. З формальної точки зору все виглядає правильно: подія сталася, причина визначена, заходи зафіксовані.

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

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

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

Кейс 1. Операційна помилка: коли “людський фактор” — це не відповідь

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

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

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

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

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

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

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

Кейс 2. Прострочена звітність: коли причина відома, але нічого не змінюється

Компанія неодноразово порушувала строки подання фінансової звітності регулятору. Порушення не були критичними з точки зору тривалості, але мали системний характер і в підсумку призвели до штрафних санкцій. Ситуація була добре відома менеджменту, інциденти фіксувалися, аналіз першопричин (root cause analysis, RCA) проводився після кожного випадку.

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

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

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

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

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

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

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

Кейс 3. ІТ-збій: коли технічна причина не пояснює бізнес-ризик

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

Аналіз першопричин (root cause analysis, RCA) був проведений оперативно. Технічна причина була визначена достатньо швидко: збій у роботі одного з компонентів системи, який призвів до каскадного відключення сервісів. Це пояснення виглядало переконливо і дозволяло формально закрити інцидент на рівні ІТ.

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

Подальший аналіз показав, що критичним фактором був не сам збій, а відсутність готовності до нього. Не було повноцінно протестованого плану відновлення (disaster recovery), резервні сценарії існували формально, але не відпрацьовувалися на практиці, а залежність бізнес-процесів від однієї системи була значно вищою, ніж це усвідомлювалося.

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

У розглянутому кейсі рішення включало не лише технічне усунення причини. Було переглянуто підхід до забезпечення безперервності бізнесу (business continuity), проведено повноцінне тестування сценаріїв відновлення, а також зменшено критичну залежність окремих процесів від однієї системи. Крім того, відповідальність за стійкість була чітко розподілена не лише в межах ІТ, а й на рівні бізнес-підрозділів.

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

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

Висновки: де закінчується аналіз і починається управління

Розглянуті кейси показують спільну закономірність: аналіз першопричин (root cause analysis, RCA) часто зупиняється значно раніше, ніж мав би. У більшості випадків знаходиться пояснення події, але не приймається рішення, яке змінює систему. У результаті компанія отримує опис проблеми, але не отримує інструменту для її запобігання.

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

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

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

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

Сергій БАБИЧ