FMEA для начинающих: как разобрать возможные отказы процесса

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

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

1. Сначала задайте границы анализа

FMEA становится полезным, когда рассматривает не «всю компанию», а конкретный процесс с понятным началом и концом. Иначе в одну таблицу попадают склад, сайт, служба доставки и работа с претензиями, а причины начинают путаться. Для учебного разбора удобнее выбрать один поток: заказ получен, товары собраны, комплект проверен, коробка упакована, заказ передан на отправку.

После этого полезно перечислить операции по шагам и для каждой записать ее функцию простыми словами. Не «выполнить сборку», а «отобрать все позиции заказа в нужном количестве и без подмены». Такая формулировка сразу подсказывает, что отказом будет не абстрактная ошибка, а конкретное отклонение от функции: не все позиции отобраны, перепутан артикул, взято неверное количество.

Если процесс уже описан на схеме или карте потока, используйте ее как основу. Если схемы нет, достаточно чернового списка из 4–6 операций. Для первого PFMEA этого достаточно: вы не рисуете идеальную документацию, а создаете рабочую основу, на которой команда увидит слабые места процесса.

2. Опишите операцию через функцию и требование

Одна из частых ошибок новичка — начинать сразу с причин. Но причина имеет смысл только после ответа на вопрос: что операция должна обеспечить? Поэтому в строке PFMEA полезно сначала написать функцию или требование. Это дисциплинирует: отказ рассматривается не сам по себе, а как нарушение ожидаемого результата операции.

Учебный пример. Пусть в заказе три позиции: смартфон, наушники и чехол. Для операции «сборка» функция будет такой: собрать все позиции заказа по заданию, в правильном количестве и без пересортицы. Для операции «упаковка» функция: упаковать заказ так, чтобы комплект не повредился и не потерялся при передаче. Для операции «передача на отправку» функция: передать заказ в отгрузку без задержки и с корректной идентификацией.

После такой записи легче отделить виды отказов друг от друга. «Отсутствует чехол» и «вложен чужой товар» — это разные отказы одной операции. У них могут быть разные причины и разные действия. Если слить их в одну формулировку «ошибка сборки», вы потеряете практическую пользу анализа.

3. Разберите виды отказов, последствия и причины

Теперь можно заполнять основную логику PFMEA. Сначала записывают вид отказа: что именно пошло не так в операции. Затем последствие: что из этого увидит следующий этап процесса или клиент. После этого — причину: почему отказ возникает. Важно не путать уровни. «Клиент недоволен» — это последствие, а не причина. «Сборщик отвлекся» — слишком общее объяснение; полезнее искать процессный источник: похожие ячейки хранения, неочевидное задание, отсутствие подтверждения комплектности.

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

Такой фрагмент уже полезен в работе: он показывает не только «что бывает плохо», но и где процесс требует изменения. Для первого анализа этого достаточно. Не нужно искусственно добавлять десятки строк, если команда видит 3–5 повторяющихся и понятных отказов.

4. Как выбирать меры снижения риска

Хорошее действие меняет процесс, а не просто призывает людей быть внимательнее. Формулировка «провести беседу» может пригодиться как временная мера, но редко решает корневую причину. Намного полезнее действия, которые уточняют задание, делают проверку обязательной, меняют расположение товаров, упрощают различение похожих позиций или вводят понятный стандарт упаковки.

Выбор действия удобно проверять тремя вопросами. Во-первых, на что оно влияет: на причину отказа, на его раннее обнаружение или на снижение последствия? Во-вторых, можно ли увидеть результат на конкретной операции, а не только «в целом по компании»? В-третьих, кто именно должен выполнить изменение и как понять, что оно реально внедрено? Если на эти вопросы нет ответа, действие пока сырое.

Учебный пример. Для отказа «не вложен чехол» слабое действие звучит так: напомнить сборщикам о внимательности. Более рабочее действие: ввести обязательную отметку о проверке всех трех позиций по листу комплектации до упаковки. Второй вариант лучше, потому что меняет саму последовательность работы и оставляет наблюдаемый признак выполнения. Даже в учебном анализе видно, что такое действие легче проверить повторным наблюдением.

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

После заполнения PFMEA работа не заканчивается. Анализ нужен не ради таблицы, а ради изменения процесса. Поэтому после внедрения действий нужно повторно посмотреть на тот же участок: исчезла ли причина, стал ли контроль работать раньше, снизилось ли число повторяющихся ошибок в сравнимой выборке заказов.

Для учебной проверки не нужны сложные метрики. Достаточно взять одинаковый короткий интервал до и после изменения и сравнить однотипные случаи. Например, условно: до введения обязательной сверки в 20 собранных заказах нашли 4 ошибки комплектности на внутренней проверке, после изменения в следующих 20 заказах нашли 1 такую ошибку. Это не универсальный норматив и не обещание эффекта, а способ проверить, дало ли действие заметный сдвиг на выбранной операции.

Если ошибка перестала встречаться, полезно обновить рабочее описание процесса и оставить новый контроль как стандарт. Если ошибка сохранилась, PFMEA не считается провалом: это сигнал, что причина была определена слишком поверхностно или выбранное действие не затронуло источник проблемы. Практический результат хорошего первого PFMEA для новичка — не идеальная таблица, а понятный список из нескольких отказов, причин и проверяемых действий, который можно обсудить с командой и использовать в следующем цикле улучшений.

Если вы подбираете обучение по теме, смотрите не только на название курса, но и на три вещи: есть ли в программе именно PFMEA процесса, дадут ли самостоятельную практику на карте потока и форме регистрации, и как будет проверяться результат вашей работы. На странице курса «Анализ видов и последствий отказов продукта/конструкции/процессов (FMEA/PFMEA/DFMEA)» у ООО ОПК указаны разделы по планированию FMEA, категориям отказов и отдельное руководство по проведению PFMEA процесса с использованием карты потока и плана управления.