Компания запускает новый процесс: приём заказа, комплектация, доставка. Через месяц выясняется, что при определённом сочетании условий заказ уходит не тому клиенту, а ошибку замечают лишь после жалобы. Разбор показывает, что о слабом месте кто-то догадывался, но в списке приоритетов его не было. FMEA (Failure Mode and Effects Analysis — анализ видов и последствий отказов) устроен ровно для этого: до запуска систематически перечислить, что и как может отказать, к чему это приведёт и как скоро это заметят, и заняться сначала самым опасным. Метод относится к базовым инструментам инженерии надёжности, безопасности и качества и применяется от аэрокосмической промышленности до бизнес-процессов и услуг. В этой статье — откуда пришёл метод и что о нём известно из справочных источников, как построена таблица FMEA, как считают число приоритета риска (RPN) и почему его критикуют, чем FMEA отличается от анализа дерева отказов, где метод ошибается и как использовать фрейм OrgDevTools.
Что такое FMEA и когда он нужен
По справочному определению, FMEA — метод индуктивного рассуждения (логики «вперёд») и анализа единичных точек отказа, и он является ключевой задачей в инженерии надёжности, безопасности и качества. Идея проста: на основании опыта с похожими продуктами и процессами и общей логики физики отказов выявить возможные виды отказов, а затем изучить последствия этих отказов на разных уровнях системы. Анализ последствий как раз и означает «effects analysis». Результат используют, чтобы структурировать меры снижения риска: либо уменьшить тяжесть отказа или его последствий, либо снизить вероятность отказа, либо и то и другое.
FMEA нужен, когда есть возможность действовать до отказа: при проектировании продукта, процесса или услуги, при запуске нового производства или сервиса, при значимых изменениях. Справочный обзор называет типовые поводы для проведения или пересмотра анализа: существующий продукт или процесс применяют новым образом; изменяются условия эксплуатации; вносится изменение в конструкцию; вводятся новые нормативные требования; обратная связь от клиентов указывает на проблему. Метод менее полезен, когда система уже сдана и любая доработка невозможна, когда объект анализа слишком мелок, чтобы оправдать трудозатраты, и когда нужно найти причину уже случившегося события — для этого лучше подходят пять «почему» и диаграмма Исикавы. Смежные методы: анализ дерева отказов (FTA), COSO ERM, анализ операционных рисков, ключевые индикаторы риска (KRI), DMADV (Design for Six Sigma), Lean Six Sigma, анализ Парето и матрица классификации решений по рискам.
Происхождение и исследовательская база
Метод возник в военной среде. По справочному обзору, процедуры проведения анализа видов, последствий и критичности отказов (FMECA) были описаны в 1949 году в документе вооружённых сил США MIL-P-1629 (9 ноября 1949 года), а в 1980 году пересмотрены как MIL-STD-1629A. К началу 1960-х годов подрядчики NASA использовали варианты FMECA и FMEA под разными названиями; среди программ NASA, где применялись такие варианты, названы «Аполлон», «Викинг», «Вояджер», «Магеллан», «Галилео» и «Скайлэб». Гражданская авиация стала одним из первых потребителей метода: SAE (Общество автомобильных инженеров, которое охватывает и авиацию) издало в 1967 году рекомендуемую практику ARP926; после двух редакций она заменена ARP4761, широко используемой в гражданской авиации.
В автомобильной промышленности FMEA начали применять к середине 1970-х годов. Справочный обзор связывает внедрение метода в отрасль компанией Ford с соображениями безопасности и регулирования после истории с автомобилем Pinto. Затем Ford применил тот же подход к процессам (PFMEA), чтобы оценивать возможные отказы, вызванные самим процессом, до начала производства. В 1993 году Automotive Industry Action Group (AIAG) впервые издала стандарт FMEA для автопрома (по данным обзора, сейчас он в четвёртой редакции), а SAE в 1994 году выпустило родственный стандарт J1739. В 2019 году оба описания метода заменило новое руководство AIAG/VDA, гармонизирующее прежние стандарты AIAG, VDA, SAE и другие описания; его принимают, среди прочих, GM, Ford, Stellantis, Honda NA, BMW, группа Volkswagen и Mercedes-Benz. Ниже — рерайт справочного обзора. Оговорка: тексты стандартов (MIL-STD-1629A, SAE J1739, руководство AIAG/VDA) в работе не читались; даты и перечни приведены по справочной статье.
Метод возник в 1949 году в военных процедурах США и за семь десятилетий прошёл путь от ракет и «Аполлона» до автомобильных заводов и бизнес-процессов.
Академическая теория: как устроен FMEA
Базовые термины
Отказ (failure) — потеря функции при заданных условиях. Вид отказа (failure mode) — конкретный способ, которым отказ проявляется, в терминах отказа детали, компонента, функции, оборудования, подсистемы или системы. Уровень детализации зависит от типа анализа: FMEA на уровне деталей рассматривает такие виды отказов, как сломанная или деформированная ось; функциональный FMEA — общие функциональные виды отказов (нет функции, избыточная функция, недостаточная функция, прерывистая функция, непреднамеренная функция); процессный FMEA (PFMEA) — виды отказов процесса, например ошибочная операция. Справочный обзор указывает, что FMEA можно проводить на уровне системы, подсистемы, узла, подузла или детали, а также применять к функциональным системам, процессам, программному обеспечению, бизнес-процессам, услугам и человеческому фактору.
Три уровня последствий
Последствия отказа рассматривают на нескольких уровнях. Локальное последствие — то, что происходит в самом элементе. Последствие на следующем уровне — эффект на вышестоящую подсистему. Конечное последствие — эффект на систему или пользователя. Для оценки тяжести берут наихудшее правдоподобное конечное последствие и формулируют его в терминах того, что увидит или почувствует пользователь: полная потеря функции, ухудшенные характеристики, функционирование в обратном режиме, слишком позднее срабатывание, нестабильная работа. Тяжесть ранжируют по шкале, например от I (нет эффекта) до V (катастрофа), исходя из стоимости, потери жизни или качества жизни.
Три оценки: тяжесть, вероятность, обнаружимость
В классической схеме каждому виду отказа присваивают три оценки. Тяжесть (Severity, S) — насколько серьёзно конечное последствие. Вероятность (Occurrence или Probability, O/P) — насколько вероятно возникновение отказа; её можно оценить лишь пониманием механизма отказа, поэтому анализ часто включает и причины отказов (дедуктивная часть), чтобы снизить вероятность устранением первопричин. Обнаружимость (Detection, D) — насколько вероятно, что отказ или его причина будут выявлены до того, как последствия дойдут до пользователя; в справочном обзоре с обнаружимостью связан и период «спячки» (dormancy) — время, в течение которого отказ остаётся необнаруженным. Период спячки влияет на вероятность конечного последствия, особенно в системах с резервированием.
Число приоритета риска (RPN)
Чтобы упорядочить виды отказов, три оценки перемножают: RPN = Severity × Occurrence × Detection. Чем выше число, тем выше приоритет мер. Расширение метода — FMECA (failure mode, effects, and criticality analysis) — добавляет анализ критичности с числами приоритета риска. Обычно применяют шкалы вроде 1–10 по каждому измерению (RPN тогда лежит в диапазоне от 1 до 1000), но конкретные шкалы задаются организацией или стандартом. Оговорка: диапазон 1–10 — распространённая практика, а не универсальное требование; справочный обзор приводит и другие классификации, например шкалу тяжести от I до V.
Критика RPN: перестановка рангов
Главная методологическая претензия к RPN — математическая. Оценки тяжести, вероятности и обнаружимости лежат на порядковой шкале: она говорит лишь о том, что одно значение лучше или хуже другого, но не насколько; оценка 8 не обязательно вдвое серьёзнее оценки 4. Умножение для порядковых чисел не определено. В результате возникают «перестановки рангов»: менее серьёзный вид отказа получает более высокое RPN, чем более серьёзный. Например, отказ с тяжестью 9, вероятностью 2 и обнаружимостью 2 даёт RPN 36, а отказ с тяжестью 3, вероятностью 4 и обнаружимостью 4 — 48: по RPN второй «важнее» первого, хотя первый может быть опасен для жизни. Предложены обходные решения, например нечёткая логика. В руководстве AIAG/VDA 2019 года, по справочному обзору, подход с RPN заменён на приоритет действий (Action Priority, AP), который заменяет прежнюю матрицу риска и RPN и указывает, требуются ли дополнительные меры. Практический вывод: RPN — удобная эвристика для сортировки, а не мера риска; отказы с наивысшей тяжестью стоит разбирать отдельно от значения произведения.
Рабочая таблица FMEA
Справочный обзор приводит пример рабочего листа, в котором для каждой строки указывают: ссылку на анализ, элемент, потенциальный вид отказа, возможные причины и механизмы, фазу миссии, локальные последствия, последствия на следующем уровне, конечное последствие, вероятность, тяжесть, обнаружимость (индикации оператору или обслуживающему персоналу), период спячки, уровень риска, действия по дальнейшему исследованию и меры снижения риска или требования. Для бизнес-процесса те же столбцы получают обычный смысл: этап процесса, что может пойти не так, причина, последствие для клиента и компании, существующие проверки, оценки, действие, ответственный и срок.
FMEA и FTA: снизу вверх и сверху вниз
FMEA — индуктивный анализ, идущий от отказа компонента к последствиям для системы («снизу вверх»). Анализ дерева отказов (FTA) идёт в обратном направлении: от нежелательного события к комбинациям причин. По справочному обзору, если применять FMEA как инструмент «сверху вниз», он выявит только основные виды отказов системы, и для такого анализа лучше подходит FTA; как инструмент «снизу вверх» FMEA дополняет FTA и находит гораздо больше причин и видов отказов, приводящих к симптомам верхнего уровня. Метод не способен обнаруживать сложные виды отказов, связанные с несколькими одновременными отказами внутри подсистемы. Когда несколько сценариев с множеством событий и важной ролью обнаружимости (например, в системах с резервированием), для точной вероятности и риска нужны деревья отказов или деревья событий. На практике FMEA часто используют для широкого обзора, а FTA — для глубокого разбора самых тяжёлых событий.
Своевременность: живой документ
Справочный обзор подчёркивает: анализ должен быть «живым документом», выполняемым одновременно с разработкой; наиболее важная его характеристика — своевременность. В крайнем случае анализ, выполненный после изготовления, почти бесполезен для решений по конструкции. Главная выгода — раннее выявление критических и катастрофических видов отказов, чтобы устранить их изменением конструкции в самый ранний момент. Кроме того, ранняя идентификация единичных точек отказа помогает при проверке того, что переключение на резервные элементы не нарушается единичными отказами, а также при разработке процедур диагностики и размещении устройств контроля.
Преимущества метода
Справочный обзор перечисляет преимущества метода: он становится катализатором командной работы и обмена идеями между функциями; делает упор на предотвращении проблем; улучшает имидж и конкурентоспособность компании; повышает выход годной продукции; повышает удовлетворённость пользователей; сокращает поздние изменения и связанные с ними затраты; снижает влияние на маржу и уменьшает время и стоимость разработки системы. Оговорка: перечень принадлежит справочному обзору и описывает потенциальные выгоды, а не измеренные эффекты в конкретных компаниях.
Учебный расчёт для бизнес-процесса
Условный процесс «выдача заказа клиенту». Вид отказа А: заказ оформлен на неверный адрес; тяжесть 6, вероятность 4, обнаружимость 7 (ошибку видят только по жалобе): RPN = 6 × 4 × 7 = 168. Вид отказа Б: товар повреждён при упаковке; тяжесть 5, вероятность 5, обнаружимость 3 (есть выборочная проверка): RPN = 75. Вид отказа В: в заказе перепутан товар с опасным свойством для здоровья; тяжесть 10, вероятность 2, обнаружимость 4: RPN = 80. По RPN первым идёт А, затем В и Б, но по логике критики вид отказа В с наивысшей тяжестью следует рассматривать отдельно и раньше. Мера для А — проверка адреса на этапе ввода (обнаружимость падает до 2, RPN = 48), для В — обязательная маркировка и вторая проверка. Числа и шкалы условные и иллюстрируют расчёт.
Ключевые идеи и принципы FMEA
Принцип: от вида отказа к последствиям
Анализ идёт не от «проблем вообще», а от конкретного вида отказа: что именно может не сработать и что произойдёт дальше — на уровне элемента, подсистемы и клиента. Такая привязка делает оценку проверяемой.
Принцип: три измерения, а не одно
Серьёзность, вероятность и обнаружимость нужно оценивать раздельно: редкий, но смертельно опасный отказ и частый, но безвредный и легко обнаруживаемый — разные задачи. Обнаружимость — самое недооценённое измерение: невидимый отказ опаснее видимого.
Принцип: системность вместо очевидных рисков
Метод проходит по каждому элементу процесса или продукта, а не только по тем, о которых уже думали. Именно перебор находит неочевидные места, о которых «кто-то догадывался», но их не записали.
Принцип: приоритет — эвристика, а не приговор
RPN и матрицы риска сортируют работу, но не заменяют суждения. Отказы с наивысшей тяжестью разбирают отдельно, а не только по значению произведения.
Принцип: анализ заканчивается действиями
Результат FMEA — не таблица, а меры: снижение тяжести, снижение вероятности, улучшение обнаружения — с ответственными и сроками, после чего оценки пересчитывают.
Принцип: живой документ и командная работа
FMEA выполняют вместе с проектированием и пересматривают при изменениях, а команду собирают из разных функций: разные люди видят разные отказы, а обсуждение спорных оценок — часть ценности метода.
Как провести FMEA: пошаговая инструкция
Практическая последовательность на основе справочных материалов; глубина и формат зависят от объекта. Определите объект и границы: какой процесс, продукт или услуга, на каком уровне детализации и в какой период жизненного цикла. Соберите команду из разных функций — тех, кто проектирует, выполняет, проверяет и получает результат. Опишите функции или шаги объекта: анализ отказов невозможен без ясного описания того, что должно происходить. Для каждой функции или шага перечислите возможные виды отказов: не выполнено, выполнено не полностью, выполнено слишком поздно, выполнено неверно, выполнено непреднамеренно.
Для каждого вида отказа опишите последствия: локальные, на следующем уровне и конечные, и оцените тяжесть по худшему правдоподобному сценарию. Определите причины и механизмы отказа и оцените вероятность. Опишите существующие способы обнаружения отказа или причины и оцените обнаружимость. Рассчитайте приоритет — по RPN или по принятой в организации матрице; отдельно выделите отказы с наивысшей тяжестью. Для самых приоритетных отказов определите меры: устранение причины, снижение тяжести, улучшение обнаружения; назначьте ответственных и сроки. После выполнения мер повторно оцените тяжесть, вероятность и обнаружимость и убедитесь, что приоритет снизился. Зафиксируйте, когда и после чего анализ пересматривают: изменение процесса, новые нормативные требования, реальные инциденты, жалобы клиентов.
Пример из практики: ранний выигрыш в NASA и автопроме
Справочный обзор фиксирует, что программы NASA («Аполлон», «Викинг», «Вояджер», «Магеллан», «Галилео», «Скайлэб») использовали варианты FMEA, а автомобильная промышленность пришла к методу к середине 1970-х годов — Ford ввёл его после истории с Pinto, а затем применил к производственным процессам. Урок для бизнеса: метод переносим — из ракет в автозаводы и далее в услуги. Оговорка: в использованных источниках нет количественной оценки эффекта FMEA в этих программах, поэтому это пример распространения метода, а не доказательство его результатов.
Ограничения, слепые зоны и критика FMEA
Первое ограничение — субъективность оценок. Тяжесть, вероятность и обнаружимость оценивают эксперты, и RPN отражает их мнение, а не измерение. Две команды, оценивающие один и тот же процесс, могут получить разные числа. Второе — математика RPN: порядковые оценки нельзя перемножать без потерь, из-за чего возникают перестановки рангов и разные комбинации оценок дают одинаковое число; поэтому в руководстве AIAG/VDA 2019 года RPN заменён на приоритет действий.
Третье — одиночные отказы. Метод рассматривает виды отказов по одному, и, по справочному обзору, не обнаруживает сложные виды отказов, где нужны несколько одновременных отказов внутри подсистемы; для них применяют FTA и деревья событий. Четвёртое — полнота: анализ содержит только те виды отказов, которые команда догадалась записать. Пятое — трудоёмкость: полный FMEA сложной системы — большая работа, и без соразмерного подхода команда тонет в таблицах. Шестое — своевременность: анализ, выполненный после запуска, часто превращается в формальность для аудита.
Седьмое — перенос в бизнес. Метод родился в инженерии, где отказы физических компонентов имеют статистику и стандарты. Для бизнес-процессов и услуг данных о вероятностях обычно нет, и оценки становятся мнением; человеческий фактор и организационные причины оцениваются хуже, чем отказы оборудования. Справочный обзор упоминает применение к бизнес-процессам, услугам и человеческому фактору, но не приводит для них проверенных шкал. Поэтому для бизнес-процессов шкалы лучше описывать словами и примерами, а результат считать ориентиром для обсуждения.
Типовые ошибки при проведении FMEA
Ошибка 1: FMEA делают только для очевидных рисков.
Команда записывает то, что и так известно, а неочевидные виды отказов остаются незамеченными до реального сбоя.
Как избежать
проходить по каждому шагу и функции процесса или продукта и для каждой перебирать типовые виды отказов.
Ошибка 2: доверяют RPN как мере риска.
Отказ с наивысшей тяжестью получает низкое RPN из-за малой вероятности и уступает более безобидным, но частым; из-за перестановок рангов опасный отказ теряется.
Как избежать
рассматривать отказы с наивысшей тяжестью отдельно от значения произведения и применять принятую в организации матрицу приоритетов.
Ошибка 3: оценки ставит один человек.
Субъективность одного эксперта искажает приоритет; спорные оценки не обсуждаются.
Как избежать
проводить оценку командой из разных функций и обсуждать расхождения.
Ошибка 4: анализ заканчивается таблицей.
Оценки есть, а мер, ответственных и сроков нет; риск остаётся прежним.
Как избежать
для высоких приоритетов записывать меры, назначать ответственных и сроки и пересчитывать оценки после исполнения.
Ошибка 5: анализ проводят после запуска.
Найденные проблемы уже нельзя исправить дёшево; анализ используется лишь для отчётности.
Как избежать
выполнять FMEA параллельно с проектированием и пересматривать при изменениях.
Ошибка 6: FMEA составляют один раз.
После изменений процесса, нормативов или реальных инцидентов документ устаревает.
Как избежать
зафиксировать поводы для пересмотра и срок регулярной проверки.
Ошибка 7: применяют полную процедуру ко всему подряд.
Команда тратит время на низкорисковые операции; на критичные не остаётся сил.
Как избежать
соразмерять глубину анализа с рискованностью объекта и начинать с самых критичных процессов.
Метрики: как оценивать FMEA
Универсальных нормативов нет; фиксируйте по своим данным:
Покрытие: доля шагов процесса или функций продукта, для которых перечислены виды отказов.
Приоритетные отказы: число видов отказов с высоким приоритетом и с наивысшей тяжестью.
Покрытие мерами: доля приоритетных отказов с назначенными мерами, ответственными и сроками.
Эффект мер: приоритет (RPN или AP) до и после выполнения мер.
Отказы вне анализа: доля реальных инцидентов, вида которых не было в FMEA, — показатель полноты.
Актуальность: дата последнего пересмотра и число изменений объекта после него.
FMEA ценен не столбцом с числом, а вопросом «что может пойти не так и заметим ли мы это вовремя».
План внедрения FMEA по неделям
Неделя 1: объект и команда
Выберите процесс или продукт, определите границы и соберите команду из разных функций.
Неделя 2: виды отказов и последствия
Опишите функции или шаги, перечислите виды отказов, последствия и причины.
Неделя 3: оценки и приоритеты
Оцените тяжесть, вероятность и обнаружимость, определите приоритеты и выделите отказы с наивысшей тяжестью.
Неделя 4: меры и пересчёт
Определите меры, ответственных и сроки; после исполнения пересчитайте оценки.
Далее: зафиксируйте поводы для пересмотра и обновляйте анализ при изменениях и инцидентах.
Как реализовать этот план с помощью фрейма «FMEA-анализ» в OrgDevTools
Фрейм работает как таблица FMEA. Вы описываете виды отказов и ставите оценки S, O, D, а фрейм сам считает RPN, отмечает отказы, которым нужны действия, сравнивает риск до и после мер и выводит итог. Это бесплатный тренажёр: он помогает пройти весь цикл методики, но командного обсуждения оценок не заменяет.
Вкладка «1. Виды отказов и RPN» — недели 2–3: виды отказов, последствия, оценки и приоритеты
По умолчанию таблица пуста. Строку добавляет кнопка «+ добавить вид отказа», удаляет «×». В строке есть поля «Шаг / функция», «Вид отказа», «Последствие» и «Причина» и три выпадающих списка S, O, D с баллами от 1 до 10. Подсказка над таблицей: S = 10 — угроза безопасности или закону, O = 10 — причина почти неизбежна, D = 10 — отказ не обнаружить до клиента.
RPN = S × O × D появляется, когда у строки есть название и все три балла. Число окрашено: от 100 — красное, от 50 — жёлтое, ниже — зелёное. При S от 9 строка получает метку «S≥9». Рамка краснеет, если RPN ≥ 100 или S ≥ 9. Такой отказ требует действий независимо от произведения: так фрейм выполняет совет статьи разбирать самые тяжёлые отказы отдельно. Пороги 100, 50 и 9 — рабочая настройка фрейма, а не норма методики. Внизу показано, сколько отказов оценено и сколько из них требуют действий. В учебном примере статьи в приоритетные попадут А (RPN 168) и В (S = 10 при RPN 80), а Б (75) не попадёт.
Вкладка «2. Действия и переоценка» — неделя 4: меры и пересчёт
Здесь собраны отказы, которым нужны действия, и те, где мера уже записана, по убыванию RPN. Для каждого есть поле меры, поле «Ответственный» и три списка «после: S, O, D». Из них фрейм считает новый RPN и показывает пару вида «RPN 168 → 48» с той же окраской. Строка без меры обведена красным. Если приоритетных отказов нет, вкладка пишет «Нет отказов с высоким приоритетом». Ниже — свободный список «Общие меры» для мер, которые закрывают сразу несколько отказов.
Вкладка «3. Обновление» — далее: поводы для пересмотра
На вкладке три свободных списка:
«Когда пересматриваем анализ»: изменения процесса, инциденты, график;
«Источники видов отказа»: жалобы, инциденты, мозговой штурм;
«Шкалы оценки»: как команда договорилась понимать баллы. Этот список стоит заполнить уже на неделе 3, чтобы оценки разных людей были сопоставимы.
В итоге участвует только первый список.
Вкладка «Визуализация» — недели 3–4: приоритеты и эффект мер
Диаграмма Парето показывает 12 отказов с наибольшим RPN. Серая полоса — риск до мер, цветная — после. Если переоценки нет, цветная полоса равна исходной. Красная вертикаль отмечает порог 100, правый столбец — накопленную долю суммарного RPN.
Вкладка «Итоги»
Итог проверяет условия по порядку и показывает первое сработавшее:
Нет ни одного полностью оценённого отказа — фрейм предлагает перечислить шаги и оценить S, O, D.
У части отказов нет одного из трёх баллов — предупреждение с их числом.
У приоритетного отказа нет меры — красное сообщение с названием отказа и его RPN или серьёзностью.
Мера есть, а ответственного нет.
Мера есть, а оценок «после» нет.
После мер RPN ≥ 100 или S ≥ 9 — нужна более сильная мера: изменение конструкции или процесса, а не только контроль.
Пуст список «Когда пересматриваем анализ».
Иначе — зелёный итог: суммарный RPN до и после и процент снижения.
Под итогом — сводка: число отказов, приоритетных и оставшихся без действий, суммарный RPN до и после, отказ с максимальным RPN. Кнопка «Создать задачу» есть у сохранённого документа. Название идёт в том же порядке, что и проверки итога: «Перечислить шаги процесса и виды отказов», «Оценить S, O, D по всем видам отказа», «Снизить риск отказа «…» (RPN …)», «Назначить ответственного за меру: …», «Пересчитать риск после действия: …», «Усилить меры по риску: …», «Назначить срок пересмотра FMEA»; если проблем нет — «Снизить риск сбоя с высоким RPN». В описание задачи попадает текст итога.
Чего фрейм не делает
Считает только RPN по шкале 1–10. Приоритет действий (AP) из руководства AIAG/VDA и шкалы вроде I–V не поддерживаются.
Не фиксирует объект, границы и команду (неделя 1), сроки мер, фазу и период спячки. Последствие хранится одним полем, без трёх уровней.
Пока нет ни одной полностью оценённой строки, недооценённые строки не замечает. Строки без названия игнорирует.
В суммарном RPN «после» непереоценённые отказы учитывает по исходному значению.
Не проверяет, что новый RPN ниже прежнего, если он остаётся под порогом.
Не видит перестановок рангов ниже порогов: отказ с S = 8 и RPN 64 приоритетным не станет.
Содержание текстов не проверяет. «Общие меры», источники и шкалы на итог не влияют.
Заполнили фрейм? Сохраните, чтобы не потерять
Книги и материалы по теме FMEA
MIL-P-1629 (1949) и MIL-STD-1629A (1980) — «Procedures for Performing a Failure Mode, Effects and Criticality Analysis». Первоисточники метода в военных стандартах США.
AIAG и VDA — «FMEA Handbook» (2019). Гармонизированное руководство для автомобильной промышленности; вводит приоритет действий (AP) вместо RPN.
SAE J1739 — «Potential Failure Mode and Effects Analysis in Design (Design FMEA) and Potential Failure Mode and Effects Analysis in Manufacturing and Assembly Processes (Process FMEA)». Прежний стандарт SAE.
Справочная статья «Failure mode and effects analysis» (Wikipedia). История, термины, рабочий лист, критика RPN, отличие от FTA.
%22%2F%3E%3Ccircle%20cx%3D%22504%22%20cy%3D%22272%22%20r%3D%2288%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.05%22%2F%3E%3Ccircle%20cx%3D%22603%22%20cy%3D%22260%22%20r%3D%22101%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.08%22%2F%3E%3Ccircle%20cx%3D%22540%22%20cy%3D%22147%22%20r%3D%22107%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.11%22%2F%3E%3Crect%20x%3D%2240%22%20y%3D%2248%22%20width%3D%22124%22%20height%3D%2230%22%20rx%3D%2215%22%20fill%3D%22%234f46e5%22%2F%3E%3Ctext%20x%3D%2258%22%20y%3D%2268%22%20font-size%3D%2215%22%20font-weight%3D%22700%22%20fill%3D%22%23fff%22%20letter-spacing%3D%220.8%22%3E%D0%9C%D0%95%D0%A2%D0%9E%D0%94%D0%98%D0%9A%D0%90%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22150%22%20font-size%3D%2238%22%20font-weight%3D%22800%22%20fill%3D%22%230f2b3d%22%3EFault%20Tree%20Analysis%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22198%22%20font-size%3D%2238%22%20font-weight%3D%22800%22%20fill%3D%22%230f2b3d%22%3E(FTA%2C%20%D0%94%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%20%D0%BE%D1%82%D0%BA%D0%B0%D0%B7%D0%BE%D0%B2)%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22372%22%20font-size%3D%2215%22%20font-weight%3D%22600%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%22.75%22%3Eorgdevtools.ru%3C%2Ftext%3E%3C%2Fsvg%3E)
%22%2F%3E%3Ccircle%20cx%3D%22409%22%20cy%3D%22284%22%20r%3D%22138%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.05%22%2F%3E%3Ccircle%20cx%3D%22516%22%20cy%3D%22329%22%20r%3D%22148%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.08%22%2F%3E%3Ccircle%20cx%3D%22454%22%20cy%3D%22331%22%20r%3D%22111%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.11%22%2F%3E%3Crect%20x%3D%2240%22%20y%3D%2248%22%20width%3D%22124%22%20height%3D%2230%22%20rx%3D%2215%22%20fill%3D%22%234f46e5%22%2F%3E%3Ctext%20x%3D%2258%22%20y%3D%2268%22%20font-size%3D%2215%22%20font-weight%3D%22700%22%20fill%3D%22%23fff%22%20letter-spacing%3D%220.8%22%3E%D0%9C%D0%95%D0%A2%D0%9E%D0%94%D0%98%D0%9A%D0%90%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22150%22%20font-size%3D%2238%22%20font-weight%3D%22800%22%20fill%3D%22%230f2b3d%22%3E%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0%20%D0%98%D1%81%D0%B8%D0%BA%D0%B0%D0%B2%D1%8B%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22198%22%20font-size%3D%2238%22%20font-weight%3D%22800%22%20fill%3D%22%230f2b3d%22%3E(Fishbone%20Diagram)%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22372%22%20font-size%3D%2215%22%20font-weight%3D%22600%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%22.75%22%3Eorgdevtools.ru%3C%2Ftext%3E%3C%2Fsvg%3E)
%22%2F%3E%3Ccircle%20cx%3D%22532%22%20cy%3D%2276%22%20r%3D%22115%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.05%22%2F%3E%3Ccircle%20cx%3D%22494%22%20cy%3D%22203%22%20r%3D%2277%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.08%22%2F%3E%3Ccircle%20cx%3D%22451%22%20cy%3D%2253%22%20r%3D%22103%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.11%22%2F%3E%3Crect%20x%3D%2240%22%20y%3D%2248%22%20width%3D%22124%22%20height%3D%2230%22%20rx%3D%2215%22%20fill%3D%22%234f46e5%22%2F%3E%3Ctext%20x%3D%2258%22%20y%3D%2268%22%20font-size%3D%2215%22%20font-weight%3D%22700%22%20fill%3D%22%23fff%22%20letter-spacing%3D%220.8%22%3E%D0%9C%D0%95%D0%A2%D0%9E%D0%94%D0%98%D0%9A%D0%90%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22150%22%20font-size%3D%2238%22%20font-weight%3D%22800%22%20fill%3D%22%230f2b3d%22%3ERoot%20Cause%20Analysis%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22198%22%20font-size%3D%2238%22%20font-weight%3D%22800%22%20fill%3D%22%230f2b3d%22%3E(RCA%2C%20%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%BD%D1%8B%D0%B9%20%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22246%22%20font-size%3D%2238%22%20font-weight%3D%22800%22%20fill%3D%22%230f2b3d%22%3E%D0%BF%D0%B5%D1%80%D0%B2%D0%BE%D0%BF%D1%80%D0%B8%D1%87%D0%B8%D0%BD)%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22372%22%20font-size%3D%2215%22%20font-weight%3D%22600%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%22.75%22%3Eorgdevtools.ru%3C%2Ftext%3E%3C%2Fsvg%3E)
%22%2F%3E%3Ccircle%20cx%3D%22194%22%20cy%3D%22-333%22%20r%3D%229%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.05%22%2F%3E%3Ccircle%20cx%3D%22301%22%20cy%3D%22-250%22%20r%3D%2270%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.08%22%2F%3E%3Ccircle%20cx%3D%22165%22%20cy%3D%22-20%22%20r%3D%2230%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.11%22%2F%3E%3Crect%20x%3D%2240%22%20y%3D%2248%22%20width%3D%22124%22%20height%3D%2230%22%20rx%3D%2215%22%20fill%3D%22%234f46e5%22%2F%3E%3Ctext%20x%3D%2258%22%20y%3D%2268%22%20font-size%3D%2215%22%20font-weight%3D%22700%22%20fill%3D%22%23fff%22%20letter-spacing%3D%220.8%22%3E%D0%9C%D0%95%D0%A2%D0%9E%D0%94%D0%98%D0%9A%D0%90%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22150%22%20font-size%3D%2238%22%20font-weight%3D%22800%22%20fill%3D%22%230f2b3d%22%3ECOSO%20ERM%20(Enterprise%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22198%22%20font-size%3D%2238%22%20font-weight%3D%22800%22%20fill%3D%22%230f2b3d%22%3ERisk%20Management)%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22372%22%20font-size%3D%2215%22%20font-weight%3D%22600%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%22.75%22%3Eorgdevtools.ru%3C%2Ftext%3E%3C%2Fsvg%3E)