Если в вашей компании RCA формально существует, но инциденты повторяются, а выводы так и не доходят до backlog, то эта статья для вас.
Статья не о том, как правильно делать RCA (Root Cause Analysis), и не о том, какие шаблоны или методики лучше использовать, она о другом:
о том, почему RCA в реальной жизни часто не приводит к изменениям,
и почему отсутствие RCA это не нейтральное состояние, а решение менеджмента, даже если его так не называют.
Иллюзия работающего RCA
В большинстве компаний RCA формально существует (документ, встреча, выводы и рекомендации), но при этом:
похожие инциденты повторяются,
одни и те же формулировки кочуют из отчёта в отчёт,
решения так и не доходят до изменений в системе.
В какой-то момент появляется ощущение, что RCA всего лишь очередной бесполезный ритуал. На практике, сложившаяся ситуация, почти всегда, не проблема плохого анализа, а скорее отражение того, как в компании принимаются решения.
В своей работе я применяю ITIL 4, в связи с этим, я буду использовать терминологию применяемую этого фреймворка.
Коротко о терминах
Чтобы дальше говорить на одном языке, зафиксируем ключевые определения (incident, problem, RCA).
Ранее я раскрывал принципы заложенные в фреймворк ITIL 4 в статье: ITIL 4 Guiding Principles: теория и практика на основе реального опыта
Скрытый текст
Incident - незапланированное нарушение работы сервиса или снижение его качества, которое требует быстрой реакции для восстановления нормальной работы.
Problem - причина одного или нескольких инцидентов, которую имеет смысл анализировать и устранять, если её влияние на бизнес значительно.
Root Cause Analysis (RCA) - анализ причин возникновения проблемы, цель которого - определить, какие изменения предотвратят повторение инцидентов
или снизят их влияние.
В терминологии 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. У решений нет владельца и это ломает RCA
Рекомендации существуют, но:
они не входят в чей-либо 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 в вашей компании перестал работать или наоборот стал полезным инструментом?
