что такое root cause analysis
InLean
Методики бережливого производства и оптимизации бизнес процессов
Анализ коренных причин
Анализ коренных причин – это систематический подход, для выяснения коренной причины проблемы или инцидента, позволяющий найти и внедрить наиболее эффективное решение. Охватывает совокупность методов решения проблем, используемых для выявления реальной причины проблемы.
Что такое Анализ коренных причин?
Анализ коренных причин (Root Cause Analysis, RCA) – это пошаговый процесс для определения коренной причины проблемы или события и плана действий по реагированию на них. Большинсвто организаций имеют тенденцию фокусироваться на одном факторе или выделяют конкретно его при попытке определить первопричину, что приводит к неполному решению. Анализ первопричин помогает избежать этой тенденции и рассмотривает всю проблему целиком. Другой момент – организации занимаются лечением симптомов, а не фактических проблем, что приводит к повторным проблемам.
Зачем проводить Анализ коренных причин?
Повторяющиеся проблемы являются источником потерь производства. Потери в виде простоев оборудования, переработки продукта, образования брака и т.д. Мы можем верить, что проблема решена, но в действительности мы только устранили симптом, а не истинную причину. Правильно сделынный анализ коренных причин может выявить слабости в ваших процессах или системах, которые привевели к несоответствию, и определить, как избежать повторения. RCA выполняется, чтобы определить Что произошло, Почему это произошло, а затем определить, какие улучшения или изменения требуются. Благодаря праильному применению RCA, можно устранить поторяющиеся проблемы.
Как проводить Анализ Коренных причин?
В зависимости от условий и отрасли процесс анализа коренных причин может отличаться. Однако большинство из них использует один и тот же подход состоящий из пяти шагов.
1. Проверка условий
Прежде чем углубиться в решение проблемы, необходимо удостовериться, что внедрено временное корректирующее действие. Оно будет действительным, до тех пор, пока не будут разработаны действия, влияющие на коренные причины. Эти действия позволяют сдерживать распространение проблемы, но не решает ее полностью.
Следующий момент, который необходимо проверить – это наличие стандартов. Необходимо удостовериться, что стандарт на выполнение операции, с которой случилась проблема, существует, он присутствует на рабочем месте и понятен всем работникам.
2. Сбор данных, определение проблемы
Как детективы тщательно собирают улики с места преступления, так и вы должны должным образом собрать всю необходимую информацию, прежде чем начать сам анализ. Сбор данных, вероятно, является наиболее важным шагом в процессе анализа первопричин. И к этому шагу рекомендуется приступать сразу после возникновения проблемы. В этом случае используется инструмент 5W1H, который отвечает на вопросы Что случилось, Где случилось, Когда случилось, Кто вовлечен в проблему, Какие тренды наблюдаются, Как текущее состояние отличется от нормального.
3. Анализ проблемы
Существует несколько инструментов, которые могут быть использованы при Анализе проблемы в рамках Анализа коренных причин. В этом разделе будут рассмотрены некоторые инструменты.
Диаграмма причинно-следственных связей
Эта диаграмма также называется диаграмма Исикавы, или «рыбий скелет». Диаграмма получила такое название, так как похожа на скелет рыбы. Как правило, такая диаграмма используется в процессе мозгового штурма для структурирования идей и визуального отображения причинно-следственных связей.
В основе метода лежит связь возможных причин, влияющих на проблемы. Причины разделены на шесть основных аспектов, относящихся к проблеме. Как правило, используются следующие категории (6 М): Man (человек), Machine (машина), Method (метод), Material (материал), Measurement (измерение), Environment (окружающая среда), Information (информация) (особенно это важно в случае проблем с организацией поставок).
После определения всех возможных причин проблемы и распределения их по категориям, необходимо выявить наиболее вероятную, и проанализировать, действительно ли данное обстоятельство является причиной возникшей проблемы.
Анализ 5 Почему (5Why)
После того как были определены факторы, относящиеся к проблеме, необходимо проанализировать, почему это событие произошло, или, другими словами, первопричины проблемы с использованием методики 5 Почему. (Помните о том, что 5 является ориентировочным числом и количество «почему» может меняться в зависимости от проблемы.) Методика работает следующим образом: Вначале обозначается проблема или наблюдаемые обстоятельства, затем задается вопрос «почему», чтобы определить причину возникновения этих обстоятельств, до тех пор, пока не доберетесь до первопричины.
4. План действий
Как только команда определила первопричину, она должна разработать соответсвующие контрмеры. В плане действий должно быть четко определена задача, ответственный за выполнение и сроки. Без этого ваш план действий далеко не продвинется, и действия не выполнятся. План действий должен быть общедоступен и статус выполнения должен отслеживаться на оперативных совещаниях
5. Стандартизация
Если решение оказалось эффективным, он должно быть принято в качестве стандарта и применяться постоянно. Если этого не сделать, уровень производительности вскоре упадет до исходных значений.
Часто бывает так, что операторы получают неправильные инструкции или имеют недостаточную подготовку для работы на соответствующем оборудовании, выполнения настройки или контроля качества продукта. Это может привести к поломкам, низкому качеству продукции и большому количеству брака.
Лучший метод работы должен быть описан, и операторы должны пройти необходимое обучение:
Пример Анализа коренных причин
Ниже вы можете познакомиться с примером Анализа коренных причин. Данный пример, отражает классический подход к выявлению первопричины и формированию плана действий для предотвращения возникновения проблемы в будущем.
Потренироваться в выполнении Анализа коренных причин можно на общеизвестных событиях, где детали и причины происшествия уже известны. В своих обучающих сессиях я использую такие видео. С одним из них вы можете познакомиться по ссылке.
Анализ коренных причин позволяет ответить на следующие вопросы: Что произошло?, Как проишло? и Почему произошло? Также формирует план действий для устранения проблем.
В конце концов, анализ первопричин сводится к трем задачам. Первая, как следует из названия: выяснить первопричину проблемы или события. Вторая — состоит в том, чтобы понять, как исправить, компенсировать или извлечь уроки из причин, вызванных коренной причиной. Третья и самая важная цель — применить то, что вы узнали из анализа, для предотвращения проблем в будущем.
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
5 инструментов для анализа первопричин (RCA), которые помогут вам улучшить тестирование и QA
Привет, Хабр! В рамках набора учащихся на курс «QA Lead» подготовили перевод статьи.
Приглашаем также всех желающих зарегистрироваться на открытый вебинар «Организация процесса тестирования в agile и не agile-командах». На вебинаре участники вместе с экспертом рассмотрят вопросы:
1. Организация процесса работы в waterfall проекте.
2. Организация процесса тестирования в scrum команде.
3. Организация процесса работы в масштабируемых agile-подходах.
4. Организация процесса тестирования в команде, работающей по kanban методу.
Необходим отчет о результатах RCA, чтобы найти фактическую причину проблемы, это поможет восстановить основные системы и процессы и решить проблему с помощью постоянного, а не временного решения.
Что такое RCA?
Это мера контроля качества, которая позволяет выяснить, что произошло, понять, почему это произошло, а затем начать настройку процесса так, чтобы уменьшить вероятность повторения одной и той же проблемы.
RCA работает на основе того, что все системы и события взаимосвязаны. Что-то одно в определенной области триггерит что-то другое в другой области. Способность отслеживать эти взаимосвязанные триггеры позволяет человеку видеть, с чего начиналась проблема и как она становилась системой, которая сейчас является основной проблемой. RCA ищет паттерны, находит ошибки, которые скрыты внутри самой системы. Он эффективно показывает первопричину или несколько причин существующих проблем.
RCA определяет, был ли дефект вызван ошибкой при тестировании, ошибкой при разработке или, возможно, требованием или ошибкой при проектировании.
Более того, крайне важно выяснить, чтобы релизы, выпущенные позже, были бы без дефекта. Ошибка при проектировании позволяет любому человеку просмотреть проектную документацию и внести коррективы, как если бы дефект был вызван ошибкой при тестировании. Это пример факторного анализа причинно-следственных связей.
Инструменты RCA
Наличие соответствующих инструментов RCA поможет вам следить за процессом, систематически исследуя факторы, способствующие возникновению глубинных проблем.
Поиск истинной первопричины проблем с помощью хорошего инструмента для анализа означает, что вы не просто пытаетесь «потушить пожар от первоначальных симптомов».
Вот пять методов RCA, которые можно использовать в качестве инструментов для выявления первопричины проблемы.
8D RCA
Этот процесс нацелен на поиск потенциальных первопричин. Он сужает круг причин до фактической, затем создает процессы сдерживания и использует корректирующую меру, чтобы предотвратить повторение проблем. Он способствует систематическому изменению и решает непосредственную проблему вместе с другими, которые могут возникнуть в результате систематического сбоя. Этот процесс последователен, прост для команды в изучении и очень подробен при применении.
Сосредоточение внимания на команде, а не на индивидууме также приносит пользу. Эта методология улучшает качество и надежность и работает над потенциальными проблемами будущего, прежде чем они погубят продукт. Ее следует использовать для оценки:
Безопасности и регулярных обнаруженных проблем
Поступающих жалоб клиентов
Ситуаций, когда гарантийные проблемы показывают более высокую частоту отказов, чем ожидалось.
Неприемлемых уровней внутреннего брака и низкой производительности или полных отказов при тестировании.
Инструмент Исикавы для RCA
Инструмент Исикавы — Диаграмма Исикавы или диаграмма «рыбьей кости».
Как бы странно ни звучало название, оно описывает внешний вид анализа на бумаге. В самом простом варианте, это просто причинно-следственная диаграмма. Она также называется «Диаграмма Исикавы».
Этот инструмент помогает при «брейнсшторминге» как части процесса анализа в попытке выявить элементы, которые вызвали проблему. По сути, это дерево первопричин в обратном направлении. Схема дерева используется для того, чтобы сузить список причин, а «рыбья кость» расширяет его. Диаграмма рыбной кости используется для изучения причин и следствий. Проблема помещается на «голову рыбы», а затем на маленьких костях различных категорий записываются потенциальные причины.
Она позволяет взглянуть на потенциальные причины, которые в противном случае могли бы быть упущены. После четкого определения проблемы командой создаются такие категории, как поставки, оборудование, персонал и т.п. Затем вы брейнштормите о том, почему произошло определенное событие. Диаграмма «рыбная кость» держит в центре внимания причину, а не «симптомы». Ценность диаграммы в том, что она позволяет членам команды глубоко копнуть и понять проблему, чтобы ее можно было адекватно решить в настоящем и будущем.
Техника RCA 5-Почему
Этот процесс осуществляется путем формирования межфункциональной команды для наличия различных уникальных точек зрения. Вам нужно четко определить проблему, чтобы не было сомнений в том, что исследуется. Пусть кто-нибудь возглавит команду и будет фокусировать ее на проблеме. Начните спрашивать «почему?» и анализировать ответы до тех пор, пока не найдете первопричину проблемы.
Будьте открыты к тому, что, возможно, причина будет не одна. Что возможно вам нужно будет принять определенные меры по устранению проблемы, как только будет найдена ее причина. Проверяйте, была ли устранена проблема и если нет, начните процесс заново.
5m, 6m, и E Анализ RCA
Эти инструменты для анализа первопричины очень схожи. Все эти анализы: 5М, 6М и E имеют похожие категории для анализа: Люди, Инструменты, Измерения, Материалы, Методы и Окружение. Эти элементы содержат ответы в случае возникновения проблемы или изменений в процессе.
Существуют вопросы, которые необходимо задать, на которые необходимо ответить и оценить для того, чтобы сузить область, в которой может находиться первопричина. Это может применяться к тестированию программного обеспечения, поскольку проблемы могут исходить не только от внутренней программы. Является ли это проблемой пользователя? Программирования? Аналитики? Человеческой ошибкой? Метода или это просто глюк, который каким-то образом стал частью программного обеспечения из внешнего источника?
Эти 5-6 пунктов структурированы таким образом, чтобы назвать и связать отношения между событиями, пользователями и проблемами, которые привели к сбою или инциденту.
Как и в других протоколах RCA, этот протокол используется для выяснения и устранения неисправности, которая вызвала конкретную проблему. Это протокол помогает снизить трудозатраты и экономические потери, выявляя первопричину, и таким образом, облегчая «симптомы», которые сигнализировали о проблеме. Это, в свою очередь, помогает предотвратить повторные сбои.
RCA Software
Для анализа и решения проблем имеются различные программы RCA. Эти программы собирают данные и используют их в помощь командам при проведении различных анализов, что способствует эффективному управлению качеством. Данные анализы:
Исикава ( диаграмма рыбной кости)
Gap-анализ (анализ разрывов)
Анализ случаев (accident)
Анализ причин и последствий отказов (FMEA)
Преимущества софта RCA заключаются в том, что оно может значительно упростить анализ причин, записывая любые и все инциденты и данные анализа причин в одном месте в веб-пространстве, чтобы их можно было совместно использовать в доступном виде.
После того, как софт определяет первопричину, можно приступать к корректирующим действиям, чтобы устранить основную проблему и снизить риск.
Сотрудники могут быть назначены для работы над определенными задачами, чтобы удостовериться, что все исправлено и переделано. Программное обеспечение может помочь уменьшить количество подобных инцидентов, а также снизить затраты и частоту возникновения инцидентов, устранив первопричину.
Выводы
Использование любого из вышеперечисленных инструментов RCA может обеспечить более качественное тестирование и надежную поддержку QA (обеспечения качества), когда команда сталкивается с «симптомами проблемы» и нуждается в определении первопричин для устранения проблемы.
Все эти инструменты просты в понимании и логичны в том, как они решают различные проблемные ситуации.
Очень важно знать то, как использовать один или все вышеперечисленные инструменты RCA, когда дело доходит до создания команды, которая может не только создать, но и устранить, а также минимизировать последствия. Использование этих инструментов вместе с поддержкой коллег, как часть процесса RCA, открывает дверь к получению точных ответов, улучшению процесса и общему улучшению качества продукта.
Root Cause Analysis как метод предотвращения багов
Привет! Мое имя Юра Гомон, я BA Tech Lead в NIX и вот уже 8 лет занимаюсь бизнес-анализом, помогая реализовывать веб- и мобильные решения для бизнеса, а также автоматизировать бизнес-процессы. Мое имя кажется Вам знакомым, т.к. недавно я опубликовал на Хабре свой BA Digest.
Цель статьи – напомнить бизнес-аналитикам о методе Root Cause Analysis (далее – RCA) и поделиться опытом его применения для предотвращения багов.
В сети очень много информации по RCA, потому не хочу повторяться в отношении теории. Если Вы еще не использовали Problem-solving техники и, в частности, RCA, рекомендую ознакомиться с материалами по ссылками ниже, а уже затем переходить к статье:
A Brief History of Root Cause Analysis. Истоки появления техники, описание шагов, смежные подходы.
В своей статье, планирую поделиться кейсами из практики, где RCA очень помогло не делать ошибок в будущем либо предотвратить потенциальные последствия.
Кейс первый – о политиках
В ливной enterprise-системе на 200+ пользователей все было хорошо: жили – не тужили, работали три года после релиза. Но в один прекрасный день при попытке перейти по ссылке в систему вместо желаемого результата пользователей ждало угрожающее сообщение…
Аналог сообщения, которое увидели пользователи. Оригинал не сохранился 🙂 Источник: Bytebitebit
Разумеется, это вызвало, мягко говоря, недоумение. В глазах пользователей работа оказалась заблокированной. Мало того, что угроза кражи паролей, так еще и предложение продолжить, но уже unsafe. Страшно.
Как только о проблеме стало известно, ответственные как могли успокоили пользователей и пообещали быстро все выяснить и поправить. Первым делом, они помчались разбираться в местную поддержку, где состоялся примерно такой диалог:
– Почему пользователи видят эту страницу?
– Посмотрим… А-а, так это заэкспайрился SSL-сертификат, продлим, и все будет в порядке.
– А почему это не сделали заранее?
– Никто не поставил напоминание, а три года быстро пролетели.
– Резонно. Как думаете, почему не поставили?
– Хм, по-моему, это первый проект, где была потребность в использовании SSL. Это уже после вас стали сертификаты покупать и другим.
– Так это и в других системах может случиться?
– Пожалуй, пойдем везде проверим, поставим напоминалки и в гайдлайны внутренних систем добавим, что надо не забывать это делать.
В итоге ошибку быстро исправили – и работа возобновилась. Пользователей обняли, пообещали новых вкусных фич и, отдышавшись, пошли делать обещанное.
Что из этого стоит вынести? Ответственные, те, кто знаком с методами RCA и Five Whys, не только исправили ошибку, но начали задавать вопросы, чтобы найти истинную причину. Как только это случилось, проблему превентивно закрыли везде, где она могла произойти, то есть предотвратили баг безопасности в других системах. Косвенно это привело к тому, что в компании стали уделять еще больше внимания безопасности.
Кейс второй – о людях
Мой приятель, ресурсный менеджер из одной украинской компании, поделился со мной одним любопытным случаем. Подбивая статистику в очередном проекте, он обратил внимание, что количество багов стало увеличиваться. Менеджер обратился к техлиду за деталями и обнаружил следующее: большинство ошибок сделал один и тот же Junior-разработчик. Это оказалось не случайностью, а тенденцией в последние несколько итераций. Специалист стал пропускать требования, в коде появились «детские» ошибки. При этом ранее не было никаких нареканий.
Менеджер вызвал человека на разговор, но в силу замкнутости последнего это не помогло докопаться до сути. Максимум, что узнал – «нет настроения работать», «сильно устаю». Чтобы все-таки разобраться с этом ситуацией, менеджер использовал технику RCA, и вот что получилось:
Менеджер задокументировал ключевые поинты разговора с человеком – названные им причины.
Предположил варианты со своего опыта.
Собрал доказательства существованию причин, проанализировал.
Попытался связать разные причины в одну систему, поскольку редко бывает так, чтобы причина была только в чем-то одном.
Граф причин проблемы, воссозданный со слов рассказчика
Большинство причин нижнего уровня можно было решить быстро, а некоторые догадки (овертаймы, нежелание ментора менторить) и вовсе не подтвердились. Однако глаз менеджера зацепился за гипотезы, выделенные красным, так как их не получилось проработать из-за скрытности человека и недостатка информации «на поверхности». Менеджер продолжил изучать причины, после чего выстроил следующий таймлайн событий:
Сначала человек стал засиживаться в офисе после работы почти каждый день.
Затем примерно в одно и то же время стал слишком часто залипать в инстаграм и фейсбук, что было хорошо видно на его мониторе, а также много выходить поговорить по телефону.
Следом вместо домашней еды он стал питаться подножным кормом.
Менеджер проанализировал «улики» расследования и вызвал человека на прямой разговор после работы, где уже благодаря паре бокалов виски узнал, что у специалиста дома проблемы, все идет к расставанию с девушкой, а работать в таких условиях он эффективно не может. Узнав это, менеджер предложил сотруднику отгул на несколько дней, чтобы тот имел возможность осмыслить проблему в спокойном рижиме и придумать, что делать дальше. После этого разработчик вернулся уже чуть более спокойным и положение немного наладилось.
В течение следующих пары месяцев разработчик брал отгулы еще несколько раз, а менеджер оказывал моральную поддержку. Не советом, но помогал переключаться на что-то позитивное – настолки, совместные обеды и так далее. В итоге человек получил время и внутренний ресурс для решения проблем дома, а затем вернулся в свой нормальный рабочий ритм, и более к нему вопросов не возникало.
Кейс третий – о работе с требованиями
Когда БА входит в проект, который идет уже некоторое время, первая задача – разобраться с требованиями, то есть провести аудит. Об этом кейсе я делал доклад на NIX Multiconf в 2019 году. Сегодня раскрою некоторые детали того случая с точки зрения применения RCA: как искали причины того, почему в проекте начало появляться много багов.
В первый же день я запросил доступ к каналам коммуникации, описанию стейкхолдеров, команд и процессов, по которым жил проект, так как по опыту это места, где стоит искать корни проблемы в первую очередь. В течение недели я получил нужную информацию, категоризировал ее и проработал проблемы на пару уровней вниз, используя Five Whys. Ниже представлен отрывок из перечня проблем, которые удалось выявить:
Коммуникация
Невозможно было найти ответ или решение через время. Обсуждение требований велось в Asana, Slack, JIRA, через почту, в онлайн- и офлайн-документах. Среди всех источников не было единого:
клиент писал там, где ему было удобно в текущий момент;
остальные команды не поддержали нашу критику, поскольку им «и так норм»;
бюджет на ведение SRS, митинг-минуток и структурирование информации не выделялся.
Наша команда не получала ответов вовремя. Другие команды не понимали наших вопросов:
если не пинговать, то могли забы(и)вать нам ответить;
пинговать из-за большой разницы с двумя другими таймзонами было затруднительно.
Стейкхолдеры
Наша команда получала разную информацию из разных источников.
Не было обмена решениями с другими командами:
не было четких зон ответственности в плане шаринга информации;
структурированные минутки и синки команд требовали времени, которое не хотели выделять.
Клиент часто менял требования / принимал решения. Настолько часто, что одна команда успевала получить одно, а вторая – уже другое:
у клиента не было четкой бизнес-идеи, он старался быстро адаптироваться под нужды целевой аудитории;
клиент хотел реализовать как можно больше фич, невзирая на общий концепт приложения, а также удовлетворить всех пользователей;
на заказчика давили инвесторы, которые требовали постоянного увеличения аудитории и финансовых результатов.
Уже этих причин вполне достаточно, чтобы понять масштаб трагедии, источник потенциальных дефектов. Безусловно, с нашей стороны также были проблемы. Например, техлид выполнял роль БА и пытался кое-как зафиксировать требования в рамках своей загрузки, а значит, недостаточно ревьювил более молодых разработчиков. Однако больше всего проблем было из-за хаоса в коммуникации, отсутствия продуктовой стратегии, не фиксирования требований в достаточном объеме. Все это привело к невозможности планировать архитектуру и писать код требуемого качества.
Не дожидаясь правок по нескольким десяткам других пунктов, ЛПРы со стороны команды реорганизовали перечень каналов связи и оставили всего три: обсуждение идей велось в Asana, дизайна и требований – в соответствующих каналах Slack, там же создали канал для общих вопросов. Кроме того, все решения по каждой функции стали фиксировать в JIRA, куда перевели только те таски, которые должны были идти в разработку. В дополнение ввели жесткие правила по неизменности скоупа в рамках спринта (либо полной приостановке и планированию спринта с нуля) и длительности спринта.
В итоге чудесным образом количество дефектов стало резко уменьшаться. ЛПРы воодушевились успехом и продолжили вносить изменения, которые также несли положительный результат. Но, как оказалось, положительным он оказался только для нас, т. к. вскоре клиент попрощался с нами под предлогом того, что не был готов к «такому уровню бюрократии» 🙂 Если заинтриговал, то в докладе по ссылке выше больше подробностей.
И что?
Есть вещи, которые вот уже 8 лет, с момента как я вошел в IT, я не перестаю «евангелизировать», поскольку нахожу им применение либо вижу отражение в окружающем мире. Среди них философия «пиши-сокращай», модель Кано, принцип Парето, think out of the box и так далее. Как вы уже догадались, RCA входит в этот перечень. А все потому, что важнейшая, если не первичная задача БА заключается в том, чтобы понять «почему». Будь то проблемная функция в системе, ошибки в бизнес-процессах, нюансы человеческого поведения, негативные события вокруг – все имеет глубокие корни.
Нередко вопросы «почему» спасают продукт от фичи, которая абсолютно ему не нужна, от принятия решения, которое приведет к негативным последствиям либо вызовет баг в системе. А если не спасет, то хотя бы поможет подготовиться к возможным трудностям и сделать так, чтобы больше не наступать на те же грабли.
RCA, конечно же, не «серебряная пуля», но инструмент, который однажды сможет предотвратить очередную проблему. Многие из нас пользуются RCA интуитивно, поскольку любознательность присуща людям, работающим в IT. Однако, использование техники на полную выведет вас на новый уровень при поиске причин ошибок.