Статья не о том, как правильно делать RCA (Root Cause Analysis), и не о том, какие шаблоны или методики лучше использовать, она о другом:

• о том, почему RCA в реальной жизни часто не приводит к изменениям,

• и почему отсутствие RCA это не нейтральное состояние, а решение менеджмента, даже если его так не называют.

Иллюзия работающего RCA

В большинстве компаний RCA формально существует (документ, встреча, выводы и рекомендации), но при этом:

• похожие инциденты повторяются,

• одни и те же формулировки кочуют из отчёта в отчёт,

• решения так и не доходят до изменений в системе.

В какой-то момент появляется ощущение, что RCA всего лишь очередной бесполезный ритуал. На практике, сложившаяся ситуация, почти всегда, не проблема плохого анализа, а скорее отражение того, как в компании принимаются решения.

В своей работе я применяю ITIL 4, в связи с этим, я буду использовать терминологию применяемую в этом фреймворке.

Коротко о терминах

Чтобы дальше говорить на одном языке, зафиксируем ключевые определения (incident, problem, RCA). Тем, кто знаком с терминологией ITIL 4 можно пропустить.

Ранее я раскрывал принципы заложенные в фреймворку ITIL 4 в статье: ITIL 4 Guiding Principles: теория и практика на основе реального опыта

В терминологии ITIL 4 Incident Management фокусируется на быстром восстановлении сервиса, тогда как Problem Management направлен на снижение вероятности и влияния повторяющихся инцидентов (ITIL® 4 Foundation, Axelos).

В ITIL 4 RCA не самодостаточен, а является инструментом внутри практики Problem Management. Важно, что целью Problem Management является не поиск «идеальной причины», а снижение влияния проблем на бизнес, в том числе через осознанное решение ничего не менять.

Это ключевой момент, который часто теряется при формальном применении RCA.

Почему RCA не «взлетает» в реальности

Плохой RCA это симптом. Он почти всегда указывает на более ранние проблемы:

1. RCA как отчёт, а не как решение

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

К сожалению, я очень часто наблюдал как компании нанимают «орду» менеджеров, которые знают множество терминов, но не имеют навыков/компетенций/понимания практик которые внедряют и/или участвуют.

2. У решений нет владельца

Рекомендации существуют, но:

• они не входят в чей-либо backlog,

• у них нет ответственного,

• их некому защищать при конфликте приоритетов.

RCA без ownership это не инструмент, а документ.

Когда я начинаю говорить о ролях и зонах ответственности, некоторые воспринимают это как очередной этап бюрократии. На деле это ключевой момент для эффективности любого процесса в работе. Проблема, из-за которой у людей складывается «неприятный рефлекс» на определение ролей, то что зачастую они требуют проработки и конкретики. А по итогу, определения ролей, может оказаться что принцип Парето (80/20), применяемый к разделению работы, обратно пропорционален (20/80) распределению окладов.

3. Решения конфликтуют с бизнес-реальностью

Очень типичная картина:

• причина понятна,

• решение известно,

• риски описаны.

Но выясняется, что решение:

• дорого,

• замедляет delivery,

• требует изменений в структуре или процессах.

И именно здесь RCA перестаёт быть инженерной задачей и становится чисто выбором менеджмента. Если RCA не приводит к изменениям, это не потому, что «плохо разобрали», а потому что компания уже сделала выбор в пользу других компромиссов. И это хорошо, если самоосознанность менеджмента это принимает и не боится говорить об этом.

Когда отсутствие RCA — это нормально

Это важный момент, который часто игнорируют. Отсутствие RCA может быть зрелым и осознанным решением, если:

• инцидент одноразовый и не повторяется,

• стоимость анализа выше потенциальной пользы,

• причина очевидна и устранена сразу,

• компания осознанно выбирает скорость вместо оптимальности.

В ITIL 4 одним из ключевых принципов является Focus on Value. Принцип обосновывает такое решение если RCA не создаёт ценности, а его отсутствие не является проблемой.

Когда отсутствие RCA — это проблема

Отсутствие RCA становится опасным, когда:

• инциденты повторяются,

• команда постоянно «тушит пожары»,

• знания не фиксируются,

• решения принимаются реактивно.

В этот момент компания теряет способность учиться на собственных ошибках, backlog начинает демонстрировать признаки неуправляемости (фокус на инцидентах, а не на фичах). И это уже не операционная проблема, а управленческая.

Быстрые RCA важнее идеальных

Один из самых важных сдвигов в зрелых организациях отказ от идеи «идеального RCA». Кто-то с этого начинает, кто-то к этому приходит выходя из кризиса. Не каждый инцидент требует:

• глубокого анализа,

• сложных диаграмм,

• многочасовых обсуждений.

Гораздо большую ценность дают:

• быстрые RCA (роли, процессы, time-aging),

• единый формат (хорошо проработанная структура шаблона),

• регулярный пересмотр тенденций.

Ценность не в глубине одного документа, а в системных тенденциях. ITIL 4 отражает этот выбор в принципах Progress Iteratively with Feedback и Start Where You Are. Инженеры находят причины. Часто, довольно быстро. Но только менеджмент решает, что с этими причинами делать:

• принять риск,

• отложить решение,

• компенсировать последствия,

• или не менять ничего.

И все эти варианты являются решениями, даже если они не оформлены как таковые.

Вывод

RCA не внедряется как инструмент контроля и не как способ «назначить крайнего». Это зеркало того, насколько компания готова:

• признавать ограничения,

• принимать неприятные компромиссы,

• осознанно выбирать, за что она платит сегодня, а за что завтра.

Иногда отсутствие RCA признак зрелости, а иногда симптом того, что управляемость начинает ускользать. Ключевая разница в осознанности этого выбора.

НЕЛЬЗЯ:

• превращать RCA в формальность,

• требовать одинаковой глубины анализа для всех инцидентов,

• использовать как инструмент давления на команды.

Расскажите о том, как RCA или его отсутствие повлияло на вас или работу вашей команды?