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

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

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

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

Что такое FMEA

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

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

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

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

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

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

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

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

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

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

Шаг 1.

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

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

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

Шаг 2.

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

Рисунок 1. Блок-схема процесса и взаимодействия.

Шаг 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 все еще высокий, вернитесь назад и измените свой план, чтобы устранить проблемы, которые по-прежнему представляют высокий риск сбоя.

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