Анализ видов и последствий сбоев (FMEA)

Когда что-то уже пошло не так, легко оглянуться назад и сказать: ”мы должны были предвидеть, что это произойдет”. И, возможно, действительно проблем можно было бы избежать, проявив немного предусмотрительности. Если бы только кто-нибудь вовремя спросил: “Что может пойти не так?” ..

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

Вам не нужно уметь путешествовать во времени, чтобы выявить проблемы до принятия решения: просто подумайте на этапе планирования, что может пойти не так. Так вы сможете предотвратить проблемы, затратив немного ресурсов, по сравнению с ситуацией, когда исправление последствий ошибок в уже реализованном решении потребовало бы огромных усилий и затрат. Анализ видов и последствий сбоев (FMEA) поможет вам сделать это.

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

Что такое FMEA

Метод FMEA первоначально был известен как анализ видов сбоев, эффектов и критичности (FMECA) и был впервые опубликован в 1949 году Министерством обороны США. FMEA вырос из системной инженерии и широко используется как инструмент контроля качества. В нём используются такие инструменты, как анализ рисков и причинно-следственный анализ, что позволяет предсказать сбои до того, как они произойдут. Первоначально применявшийся при разработке продукта, он также эффективен при улучшении проектирования бизнес-процессов и систем.

При использовании FMEA вы начинаете с детального рассмотрения предлагаемого решения (см. подсказку ниже), а затем систематически определяете все точки, в которых оно может дать сбой. Как только эти потенциальные сбои будут выявлены, определите потенциальные последствия каждого из них в соответствии с:

• серьезностью – насколько критичен сбой?
• риском возникновения – какова вероятность сбоя?
• вероятностью обнаружения – насколько легко будет обнаружить сбой?

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

После того как вы изменили свое решение, стоит повторить анализ FMEA, чтобы убедиться, что в проект не были внесены новые потенциальные сбои.

При использовании FMEA лучше привлечь экспертных членов команды широкого спектра специализаций и ролей, чтобы вы могли взглянуть на предлагаемое решение с разных точек зрения. Цель FMEA — выявить и определить как можно больше потенциальных сбоев, поэтому, чем тщательнее расследование, тем полезнее результат анализа. О том, как собрать эффективную команду для обсуждения, читайте в наших материалах раздела “Формирование группы”

Существует целый ряд инструментов, которые вы можете использовать для разработки решения:

• блок-схема (Flow Charts);
• диаграмма “плавательные дорожки”;
• системные диаграммы;
• анализ цепочки создания стоимости.

То, какой инструмент подойдет вам лучше всего, будет зависеть от типа рассматриваемого решения.

Как использовать инструмент

Лучший способ понять FMEA — воспользоваться примером. Давайте рассмотрим предложение по простому процессу расчета заработной платы.

Шаг 1 - Определение объекта анализа.

Определите решение, систему или процесс, которые вы рассматриваете, и, при необходимости, основную проблему, которую вы хотите исследовать. Перечислите критические элементы в логическом (например, хронологическом) порядке.

Предлагаемый процесс начисления заработной платы – ключевые элементы системы:

• почасовая ведомость учета рабочего времени;
• расчет отпускных;
• расчет сверхурочной работы.

Шаг 2 - Схематизация.

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

Шаг 3 - Определение возможных проблем.

Для каждого элемента процесса используйте мозговой штурм или проведите анализ рисков, чтобы определить потенциальные сбои, которые могут произойти. Укажите способы, из-за которых решение или процесс могут завершиться сбоем, в столбце режим сбоя матрицы FMEA. Например:

• Отправить табель учета рабочего времени – сотрудники не представляют табели учета рабочего времени.
• Отправить табель учета рабочего времени – сотрудники вводят данные плохого качества в табели учета рабочего времени.
• Отправить табель учета рабочего времени – сотрудник использует неправильные коды анализа.
• Ввод часов – человеческая ошибка при вводе данных.
• Расчет отпускных – человеческая ошибка при составлении формул.
• Расчет отпускных – справочные таблицы не ведутся.
• И так далее...

Шаг 4 - Оценка возможных последствий.

Для каждого потенциального сбоя определите последствия. Например:

• Отправить табель учета рабочего времени – сотрудники не представляют табели учета рабочего времени – занижение счетов клиентов, невыплата заработной платы сотрудникам.
• Отправить табель учета рабочего времени – сотрудники вводят данные плохого качества в табели учета рабочего времени – неправильно выставленные счета клиентам, недостоверная управленческая информация.
• Отправить табель учета рабочего времени – сотрудник использует неправильные коды анализа – недостоверная управленческая информация.
• Ввод часов – человеческая ошибка при вводе данных – недоплата или переплата заработной платы.
• Расчет отпускных – человеческая ошибка при составлении формул – значительная и систематическая переплата или недоплата заработной платы.
• И так далее....

Шаг 5 - Оценка рисков.

Для каждого потенциального сбоя в системе определите степень серьезности, риск возникновения и легкость обнаружения, используя следующие шкалы:

• Серьезность – насколько критичен сбой?

5 – очень высокий (огромные убытки, которые угрожают жизнедеятельности компании);

4 – высокий (большие убытки, компания все еще работоспособна);

3 – умеренный (потери существуют, могут быть исправлены);

2 – незначительный (потеря минимальна, совершенно незначительна);

1 – низкий (без эффекта).

• Риск возникновения – какова вероятность сбоя?

5 – очень высокий (должен быть устранен немедленно, проблемы будут постоянно);

4 – высокий (проблемы будут происходить часто);

3 – умеренный (вызовет единичные проблемы, будет случаться время от времени);

2 – незначительный (проблем будет немного, и они будут происходить довольно редко);

1 – низкий (проблемы маловероятны, вряд ли когда-либо произойдут).

• Обнаружение – насколько легко будет обнаружить сбой?

5 – очень сложно;

4 – трудно;

3 – довольно легко;

2 – легко;

1 – очень просто.

В нашем примере потенциальный сбой при расчете отпускных может быть определен как:

• серьезность 4 – переплата заработной платы, если ее не обнаружить, может привести к значительным финансовым потерям;
• возникновение 5 – если это уже происходит, то может повторяться очень часто;
• обнаружение 3 – руководители скорее всего обнаружат значительную переплату заработной платы

Шаг 6 - Ранжирование рисков.

Рассчитайте номер приоритета риска (RPN) для каждого из режимов и эффектов путем умножения 3 оценок (серьезность × возникновение × обнаружение). В приведенном выше примере RPN=60. Он, вероятно, будет одним из наиболее значительных моментов риска в этом процессе, и поэтому его необходимо исправить.

Шаг 7 - План управления рисками.

Теперь вы готовы провести мозговой штурм вариантов действий и выработать рекомендации по устранению выявленных вами потенциальных угроз. Этот шаг лучше всего выполнять поэтапно, начиная с моделей и последствий, которые имеют самый высокий RPN – другими словами, с тех, которые представляют наибольшую угрозу.

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

Шаг 8 - Проверка плана.

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

Если это проекты, за которые вы несете ответственность, то успех ваших проектов — это ваш собственный успех.