Нашли виноватого, но не причину: почему сбой возвращается
На совещании быстро нашли объяснение: заявки задерживает отдел согласования. Команде добавили сотрудника, очередь разобрали. Через несколько недель просрочки накопились снова. Выяснилось, что часть заявок приходила без нужных сведений, возвращалась инициаторам, а затем повторно проходила согласование. Дополнительный сотрудник ускорил очередь, но не убрал механизм её появления.
Именно здесь начинается анализ первопричин (Root Cause Analysis, RCA). Его задача — пройти от заметного сбоя по цепочке условий и найти те, изменение которых снизит вероятность повторения проблемы. В Microsoft Azure Well-Architected Framework RCA определяется как систематическое исследование инцидента для выявления лежащих в его основе факторов и предотвращения повторения.
Симптом правдив — просто он объясняет не всё
Заявки действительно задерживались на согласовании. Ошибка была в выводе: этап с самой длинной очередью автоматически признали источником проблемы. Между тем очередь могла сформироваться раньше — из-за некорректного ввода, возвратов, разного понимания правил или сбоя интеграции.
Поэтому анализ начинают с точного описания результата. Какие заявки опоздали? Когда появилась задержка? Чем они отличаются от тех, что прошли вовремя? Формулировку «согласование работает плохо» нельзя проверить. А утверждение «заявки без заполненного поля возвращаются и повторно проходят два этапа» уже связывает отклонение с конкретным механизмом.
Гипотеза должна выдержать встречную проверку
Команда восстанавливает цепочку событий и сравнивает проблемные случаи с нормальными. Если возвраты связаны с незаполненным полем, важно проверить, встречается ли тот же дефект в заявках, прошедших вовремя, и не объясняется ли задержка другим признаком.
Данные помогают находить закономерности, но совпадение ещё не доказывает причинную связь. Гипотеза становится сильнее, когда объясняет механизм, подтверждается на разных группах случаев и не противоречит фактам. ASQ указывает, что RCA включает определение проблемы, поиск возможных причин, анализ причинно-следственных связей и разработку решения.
Можно задавать вопрос «почему?», строить причинно-следственную диаграмму или дерево причин. Но ни один метод не гарантирует верного ответа: результат зависит от качества данных, знания процесса и проверки версий.
Причина найдена, когда понятно, что менять
Если система позволяет отправить форму без обязательных сведений, решение может состоять в контроле при вводе. Если сотрудники по-разному трактуют требование, придётся уточнить правило. Если данные теряются между системами, исправлять нужно интеграцию. У одной проблемы может быть несколько причин.
По нашей практике, RCA полезно заканчивать проверяемым действием: какое условие меняется, какой показатель должен отреагировать и когда команда оценит результат. Сокращение возвратов станет аргументом в пользу найденной связи. Если ничего не изменилось, гипотезу придётся пересмотреть.
Анализ первопричин не позволяет спутать место, где проблема стала заметна, с местом, где она возникла.