На сервисной линии сломался один и тот же узел в третий раз за полгода. Каждый раз его чинили, заносили в чат «заменили, работает» и забывали. Никто не собрал три случая вместе, не спросил, почему это повторяется, и не проверил, помогла ли предыдущая замена. FRACAS (Failure Reporting, Analysis, and Corrective Action System — система отчётности об отказах, анализа и корректирующих действий) создана, чтобы такого не было: каждый отказ обязательно фиксируется в общей записи, для него ищется причина, назначается действие, а потом проверяется, что действие сработало и отказ не вернулся. Метод пришёл из военной инженерии надёжности, но его логика — «замкнутый цикл» от инцидента до подтверждённого устранения — применима к любым повторяющимся сбоям: в производстве, сервисе, ИТ и клиентской поддержке. В этой статье — откуда пришёл метод и что о нём известно из справочных источников, как устроен цикл, как связать FRACAS с анализом причин и CAPA, какие данные он даёт, где метод ограничен и как использовать фрейм OrgDevTools.
Что такое FRACAS и когда он нужен
По справочному определению, FRACAS — система (иногда реализованная программным обеспечением), которая задаёт процесс сообщения об отказах, их классификации, анализа и планирования корректирующих действий в ответ на них. Обычно её применяют в промышленной среде, чтобы собирать данные, записывать и анализировать отказы систем. Система может управлять множеством отчётов об отказах и формирует историю отказов и корректирующих действий. Она фиксирует проблемы, связанные с продуктом или процессом, и их первопричины и результаты анализа, чтобы помочь определить и внедрить корректирующие действия.
Иными словами, FRACAS — не разовое расследование, а постоянный «реестр отказов с судьбой»: у каждой записи есть автор, дата, описание, причина, действие и проверка. Ценность метода накапливается: чем дольше он работает, тем лучше видны повторяющиеся отказы, слабые компоненты и эффективность прошлых мер. Метод нужен там, где отказы повторяются и где цена повторного отказа выше, чем цена дисциплины: техническое обслуживание и эксплуатация оборудования, производство, разработка продуктов с гарантийными обязательствами, ИТ-сервисы, работа с рекламациями. Он менее нужен, когда отказы единичны и не повторяются, когда нет ресурса разбирать каждый случай (тогда начинают только с критичных отказов) и когда проблема не в отказах, а в проектировании — там сначала нужны FMEA и анализ дерева отказов. Смежные методы: пять «почему», диаграмма Исикавы, ITIL: управление инцидентами, блеймлесс-пост-мортем, анализ рекламаций, Total Productive Maintenance, цикл PDCA и культура ошибок.
Происхождение и исследовательская база
По справочному обзору, метод FRACAS был разработан правительством США и впервые введён для использования ВМС США и всеми ведомствами Министерства обороны в 1985 году; в качестве источника указан справочник MIL-HDBK-2155. Оговорка: текст самого справочника в работе не читался, и детали его требований здесь не приводятся.
В более широком контексте FRACAS вырос из инженерии надёжности — раздела системной инженерии, который изучает способность оборудования функционировать без отказов. Справочный обзор по инженерии надёжности называет систему сбора данных и информации (включая общий журнал опасностей надёжности и FRACAS) одной из задач программы надёжности и указывает, что её требования обычно задаются в контракте. Выбор задач надёжности зависит от критичности системы и стоимости: для критичной с точки зрения безопасности системы может потребоваться формальный процесс отчётности об отказах и их разбора на протяжении всей разработки, а для некритичной достаточно итоговых отчётов об испытаниях. Наиболее распространённые задачи программ надёжности документированы в стандартах MIL-STD-785 и IEEE 1332, а системы отчётности об отказах, анализа и корректирующих действий названы распространённым подходом к мониторингу надёжности продукта или процесса.
Тот же обзор описывает место FRACAS после запуска системы. Когда системы или детали производятся, инженерия надёжности пытается наблюдать, оценивать и исправлять недостатки. Поскольку невозможно предвидеть все виды отказов системы, особенно с человеческим элементом, отказы всё равно происходят; поэтому программа надёжности включает систематический анализ первопричин, выявляющий причинно-следственные связи отказа, чтобы можно было реализовать эффективные корректирующие действия. Сегодня, отмечает обзор, организации используют коммерческие системы (например, веб-приложения FRACAS), которые создают хранилище данных об отказах и инцидентах, из которого можно получить статистику для оценки надёжности, безопасности и качества. Ниже — рерайт справочных материалов. Оговорка: источники краткие; литературная база метода в работе тонкая, а исторические подробности (авторы, редакции стандарта) не проверялись.
Невозможно предвидеть все виды отказов — поэтому программа надёжности должна включать систематический анализ первопричин и корректирующих действий.
Академическая теория: как устроен замкнутый цикл FRACAS
Три шага замкнутого цикла
Справочный обзор описывает FRACAS как замкнутый цикл с тремя шагами. Первый — отчётность об отказе (Failure Reporting): отказы и неисправности системы, единицы оборудования, программного обеспечения или процесса формально фиксируются по стандартной форме — отчёт о дефекте или об отказе. Второй — анализ (Analysis): проводится анализ для выявления первопричины отказа. Третий — корректирующие действия (Corrective Actions): определяются, внедряются и проверяются корректирующие действия, чтобы предотвратить повторение отказа. Обратите внимание, что верификация входит в третий шаг: цикл не считается замкнутым, пока не подтверждено, что действие сработало. Во фрейме OrgDevTools верификация выделена в отдельный четвёртый блок — это методически осмысленная детализация того же шага.
Отчёт об отказе: что записывать
Стандартная форма нужна, чтобы записи можно было сравнивать и суммировать. Справочный обзор в перечне типичных выходных данных FRACAS называет поля, по которым потом строят статистику: номер и название детали, производителя, наработку на отказ в эксплуатации (MTBF), среднюю наработку между снятиями (MTBR), среднее время восстановления (MTTR), расход запасных частей, рост надёжности, распределение отказов и инцидентов по типу, местоположению, номеру детали, серийному номеру, симптому и другим признакам. Из этого перечня видно, что записывать нужно не пересказ события, а структурированные поля: что отказало, где, при каких условиях, каков симптом, что было сделано для восстановления и сколько времени это заняло. Для бизнес-процессов аналог — вид сбоя, участок, клиент или заказ, время выявления и время восстановления.
Анализ первопричины
Второй шаг — поиск первопричины, а не симптома. Справочный обзор по инженерии надёжности утверждает, что на практике большинство отказов можно проследить до какого-либо вида человеческой ошибки (например, в проектировании, производстве, обслуживании или инструкциях), и приводит книгу Уиттингема «The Blame Machine» (2007) как одну из опор такого взгляда. Оговорка: это точка зрения, приведённая в обзоре, и она не означает, что виноват человек: как и в блеймлесс-подходе, речь о том, чтобы найти условия, которые сделали ошибку возможной. Для структурированного поиска причин обзор упоминает анализ первопричин (в списке литературы — «Apollo Root Cause Analysis» Дина Гано, 2007). На практике используют пять «почему», диаграмму Исикавы, дерево отказов; выбор зависит от сложности случая.
Практически важно ещё одно замечание обзора: если для существующей системы исправляется первопричина обнаруженных отказов, первоначальная оценка MTBF может стать недействительной, потому что приходится делать новые допущения об эффекте исправления, а сами допущения подвержены высокой ошибке. Кроме того, детальные данные об отказах часто недоступны, а доступные фильтруются непоследовательно и не учитывают статистические ошибки, которые очень высоки для редких событий. Нужны очень ясные правила подсчёта и сравнения отказов с разными типами первопричин (производственные, эксплуатационные, транспортные, системные, конструктивные), иначе сравнение разных причин приведёт к неправильным оценкам и неправильным управленческим решениям о том, на чём сосредоточить улучшения.
Корректирующее действие и его проверка
Корректирующее действие — то, что устраняет причину, а не последствие. Родственная практика CAPA (corrective and preventive action — корректирующие и предупреждающие действия) в справочном описании включает, среди прочего, чётко определённые источники данных, которые выявляют проблемы для расследования, и анализ первопричин, определяющий причину расхождения или отклонения и предлагающий корректирующие действия. Корректирующее действие — действие по устранению причин несоответствий, чтобы предотвратить повторение; предупреждающее — действие по предотвращению возникновения несоответствий, как правило, по результатам анализа риска. Чтобы такие действия были эффективными, решающее значение имеет систематическое исследование первопричин. По справочному обзору, CAPA — часть системы менеджмента качества и понятие в надлежащей производственной практике (GMP), HACCP и многих стандартах ISO; в отдельных отраслях, например для медицинских изделий и фармацевтики в США, CAPA обязательна, и её нарушение считается нарушением федеральных правил (в источнике эта фраза помечена как требующая подтверждения). FRACAS можно считать реестром, на котором CAPA держится в течение времени.
Единая система и простота ввода
Один из практических выводов обзора по инженерии надёжности касается организационной стороны: для организации чрезвычайно важно принять единую систему FRACAS для всех конечных изделий; она должна позволять практично фиксировать результаты испытаний. Если не принять одну простую в использовании — с точки зрения ввода данных полевыми инженерами и специалистами ремонтных мастерских — и простую в сопровождении интегрированную систему, это, скорее всего, приведёт к провалу самой программы FRACAS. Вывод для бизнеса: если внесение отказа занимает десять минут и требует пяти согласований, отчёты перестанут поступать, а статистика станет искажённой.
Как FRACAS соотносится с FMEA и FTA
FMEA и FTA работают «до отказа»: они предсказывают возможные отказы и их причины при проектировании. FRACAS работает «после отказа»: он собирает реальные отказы и проверяет, что предсказания и меры соответствуют действительности. Связь двусторонняя: реальные отказы из FRACAS показывают, каких видов отказов не было в FMEA, и помогают уточнить оценки вероятности и обнаружимости; а FMEA и FTA помогают искать первопричину отказа из FRACAS. Справочный обзор по инженерии надёжности отмечает: поскольку невозможно предвидеть все виды отказов, система должна работать в связке с систематическим анализом первопричин.
Учебный расчёт
Условная сервисная линия записывает каждый отказ в единый журнал. За квартал зафиксировано 30 отказов, из них у 12 — один и тот же вид (перегрев узла X). Доля повторяющегося вида: 12 ÷ 30 = 40 %. Анализ первопричины показал, что радиатор установлен под неверным углом, и корректирующее действие — переработка монтажной схемы. Среднее время восстановления после такого отказа составляло 3 часа, значит потери за квартал — 12 × 3 = 36 часов простоя. Через квартал после внедрения верификация показала 2 отказа этого вида из 28: 2 ÷ 28 ≈ 7 %; простой сократился до 2 × 3 = 6 часов. Действие подтверждено данными, и запись можно закрыть. Если бы верификации не было, изменение долей могло бы остаться незамеченным, а при росте числа отказов причина осталась бы неопознанной. Числа условные и иллюстрируют расчёт.
Ключевые идеи и принципы FRACAS
Принцип: каждый отказ регистрируется
Цикл запускается только тогда, когда отказ записан. Простой и обязательный ввод — условие того, что статистика отражает реальность, а не только то, о чём принято сообщать.
Принцип: стандартная форма записи
Записи должны быть сопоставимы: одни и те же поля, единые классификаторы типов отказов и причин. Только так из отдельных случаев получается статистика повторяемости и распределения.
Принцип: причина, а не симптом
Расследование не заканчивается на «сотрудник ошибся» или «деталь сломалась». Важно, какие условия сделали ошибку или поломку возможными и как их изменить.
Принцип: действие устраняет причину и имеет владельца
«Усилить контроль» — не действие. Действие конкретно, направлено на найденную причину, имеет ответственного и срок.
Принцип: верификация закрывает цикл
Запись закрывают только после проверки, что действие реально устранило причину и отказ не повторяется в заданный период. Без этого FRACAS превращается в архив отчётов.
Принцип: единая система для всех изделий
Одна простая в использовании система вместо десятка таблиц: иначе данные нельзя объединить, а сама программа рискует провалиться из-за неудобства ввода.
Как внедрить FRACAS: пошаговая инструкция
Практическая последовательность на основе справочных материалов; объём и формальность зависят от критичности объекта. Определите, что считается отказом: потеря функции при заданных условиях, нарушение спецификации, инцидент у клиента; заранее решите, с каких отказов начинаете (например, критичных и повторяющихся). Создайте единую форму отчёта: что отказало, где, когда, при каких условиях, каков симптом, что сделано для восстановления, сколько времени заняло. Договоритесь, кто вправе вводить запись и кто отвечает за каждый этап: регистрация, анализ, действие, проверка. Сделайте ввод максимально простым, а сообщение об отказе — обязательным и безопасным для сообщающего.
Введите регулярный разбор новых и незакрытых записей: короткая встреча, на которой определяют, какие отказы требуют углублённого анализа, назначают исполнителей и сроки. Для выбранных отказов проводите анализ первопричины структурированными методами (пять «почему», диаграмма Исикавы, дерево отказов). Сформулируйте корректирующее действие с ответственным и сроком. После внедрения назначьте проверку через определённый период: повторился ли отказ, изменились ли метрики (частота, время восстановления). Закрывайте запись только после подтверждения. Периодически анализируйте базу: какие виды отказов повторяются, какие компоненты и участки слабее, работают ли принятые меры. Передавайте выводы в проектирование: если реальные отказы не были предсказаны FMEA, обновляйте анализ.
Пример из практики: единая система как условие успеха
Справочный обзор по инженерии надёжности содержит практическое предупреждение: если организация не принимает единую, простую в использовании систему для ввода данных полевыми инженерами и ремонтными мастерскими и простую в сопровождении, программа FRACAS с высокой вероятностью терпит неудачу. То есть главные риски метода — не аналитические, а организационные: неудобный ввод и разрозненные базы. Оговорка: это общее предупреждение из справочной статьи, а не описание конкретной компании.
Ограничения, слепые зоны и критика FRACAS
Первое ограничение — дисциплина. Цикл требует ресурсов на каждом шаге; при перегрузке процесс вырождается в формальное заполнение отчётов без реального анализа и проверки. Второе — качество данных. Справочный обзор указывает, что подробные данные об отказах часто недоступны, а доступные фильтруются непоследовательно и не учитывают статистические ошибки, очень высокие для редких событий; без единых правил подсчёта сравнение отказов с разными типами причин ведёт к неверным решениям.
Третье — иллюзия точности показателей. Оценки MTBF и другие показатели, посчитанные по базе отказов, зависят от полноты регистрации и от допущений об эффекте исправлений; после исправления первопричины прежняя оценка MTBF может стать неприменимой. Четвёртое — зависимость от культуры. Если сообщение об отказе ведёт к наказанию, сотрудники скрывают отказы, и база отражает не реальность, а страх; необходимо разделять регистрацию отказа и персональную ответственность. Пятое — реактивность. FRACAS начинает работать после отказа, поэтому он не заменяет проектный анализ (FMEA, FTA). Шестое — масштаб: для редких, но катастрофических событий накопить статистику невозможно, и здесь метод даёт мало.
Типовые ошибки при внедрении FRACAS
Ошибка 1: отчёт об отказе не обязателен или неудобен.
Часть сбоев не регистрируется, потому что ввод долгий или не ясно, нужен ли он; статистика оказывается неполной.
Как избежать
сделать сообщение об отказе простым и явно обязательным правилом для всех, кто наблюдает отказ.
Ошибка 2: анализ останавливается на поверхностной причине.
В записи причина «ошибка оператора» или «поломка детали», а системные условия не выявлены.
Как избежать
применять структурированные методы поиска первопричины и продолжать, пока причина не станет объектом действия.
Ошибка 3: корректирующее действие абстрактно.
«Усилить контроль» не объясняет, что именно изменится и как это проверить.
Как избежать
формулировать действие конкретно, с ответственным и сроком, направленное на найденную причину.
Ошибка 4: верификацию пропускают.
Действие выполнено, запись закрыта, но никто не проверил результат; отказ через время повторяется.
Как избежать
назначать проверку на определённый срок и закрывать запись только после подтверждения.
Ошибка 5: сообщение об отказе воспринимают как признание вины.
После наказаний за сообщённые инциденты люди скрывают отказы или занижают их серьёзность.
Как избежать
явно отделить регистрацию отказа от персональной ответственности и обсудить правило заранее.
Ошибка 6: у каждой команды своя таблица.
Данные нельзя объединить, повторяющиеся отказы в разных подразделениях не видны.
Как избежать
принять единую систему и единый классификатор для всех изделий и процессов.
Ошибка 7: базу не анализируют.
Записи копятся, но никто не смотрит на повторяемость и распределения; система становится архивом.
Как избежать
регулярно анализировать повторяющиеся виды отказов и передавать выводы в проектирование и обучение.
Метрики: как оценивать FRACAS
Универсальных нормативов нет; фиксируйте по своим данным:
Число зарегистрированных отказов: по периодам, типам, участкам и симптомам.
Доля повторяющихся отказов: сколько записей относятся к уже известным видам.
Время восстановления: среднее время от отказа до восстановления (MTTR).
Наработка между отказами: MTBF там, где данных достаточно и правила подсчёта едины.
Возраст открытых записей: сколько времени запись остаётся без анализа, действия или проверки.
Доля записей с верификацией: сколько закрытых записей подтверждено проверкой результата.
Эффективность действий: доля действий, после которых отказ этого вида не повторился за контрольный период.
Отказ, о котором никто не сообщил, повторится; действие, которое никто не проверил, — тоже.
План внедрения FRACAS по неделям
Неделя 1: определения и форма
Определите, что считается отказом, и создайте единую форму отчёта с обязательными полями.
Неделя 2: роли и ввод
Назначьте ответственных за регистрацию, анализ, действия и проверку и сделайте ввод простым.
Недели 3–4: первый цикл
Проведите разбор накопленных записей, выберите критичные и повторяющиеся отказы, найдите причины и определите действия.
Месяц 2–3: верификация и анализ базы
Проверьте результат действий, закройте подтверждённые записи и проанализируйте повторяемость.
Далее: проводите регулярные разборы и передавайте выводы в проектирование и обучение.
Как реализовать этот план с помощью фрейма «FRACAS» в OrgDevTools
Фрейм «FRACAS» — бесплатный тренажёр замкнутого цикла. В нём каждый отказ проходит путь от отчёта до верификации, видно, на какой стадии цикл рвётся и какие категории отказов дают основной риск. Фрейм открывается пустым: примеров отказов в нём нет, журнал вы заполняете сами.
Вкладка «1. Журнал отказов» — Недели 3–4: первый цикл
Каждый отказ — отдельная карточка, её добавляет кнопка «+ зарегистрировать отказ». В карточке шесть полей:
название;
категория (свободный текст);
тяжесть от 1 до 5;
число повторений «раз» (по умолчанию 1);
сколько дней отказ открыт (по умолчанию 0, вводится вручную).
Фрейм сам считает риск: тяжесть × повторения. Если тяжесть не указана, берётся 1. При тяжести от 4 цифра риска краснеет. Это рабочая настройка фрейма.
Под полями — пять кнопок стадий: «Отчёт», «Анализ причины», «Действие определено», «Внедрено», «Верифицировано». Выбранная стадия и все предыдущие закрашиваются.
Со стадии «Анализ причины» появляется поле коренной причины.
Со стадии «Действие определено» появляется поле действия.
На стадии «Верифицировано» появляется флажок «повторился после закрытия». Если он отмечен, рамка карточки становится красной.
Внизу вкладки — сводка: число отказов, доля замкнутых циклов, число повторов после закрытия и число отказов, открытых дольше 30 дней. Замкнутым считается только отказ на стадии «Верифицировано» без отметки о повторе. В расчёты попадают только карточки с названием.
Вкладка «2. Парето причин» — Месяц 2–3: анализ базы
Фрейм суммирует риск по категориям и выстраивает полосы по убыванию. Карточки без категории попадают в группу «без категории». Красным и жирным выделяются «немногие важные» категории: те, что набирают до 80 % накопленного риска, включая категорию, на которой порог перейдён. Порог 80 % — рабочая настройка фрейма. Под диаграммой — свободный список «Анализ коренных причин» для выводов и общих причин разных отказов.
Вкладка «3. Заметки» — Недели 1–2: определения, форма и роли
На вкладке три свободных списка:
«Правила отчёта» — кто и как регистрирует отказ, что обязательно указать;
«Корректирующие действия» — системные меры, затрагивающие несколько отказов, по шаблону «действие — срок — владелец»;
«Верификация» — срок наблюдения и критерий.
Записи из прежней версии фрейма сохраняются в этих списках и в списке анализа на вкладке «Парето».
Вкладка «Визуализация» — Месяц 2–3: верификация
Воронка из пяти стадий. Ширина полосы показывает, сколько отказов дошло до стадии или дальше. Справа подписано, сколько отказов стоит на этой стадии сейчас. Сужение воронки показывает, где цикл рвётся. Под воронкой — число повторов после закрытия.
Вкладка «Итоги» — Далее: регулярные разборы
Фрейм проверяет условия по порядку и показывает первое сработавшее:
Нет ни одного отказа с названием — предложение начать с отчёта.
Отказ на стадии «Действие определено» или дальше, а коренная причина не записана — красный сигнал «лечение симптома», нужно вернуться к анализу.
Отказ отмечен как повторившийся — красный сигнал: переоткрыть цикл с анализа.
Отказ с тяжестью от 4 ещё на стадии «Отчёт» или «Анализ причины» — предупреждение: критичные отказы анализируются первыми.
Стадия «Действие определено» или дальше, но текст действия пуст — предупреждение.
Незакрытые отказы открыты дольше 30 дней — предупреждение «цикл застрял»: назначить ответственного и срок.
Замкнуто меньше 60 % циклов — предупреждение с приоритетом по риску.
Иначе — «Цикл работает» и перечень категорий основного риска.
Пороги 30 дней и 60 % — рабочие настройки фрейма. Под итогом — распределение по стадиям, доля замкнутых и главный открытый риск, то есть незакрытый отказ с наибольшим риском.
Кнопка «Создать задачу» называет задачу в том же порядке, что и проверки итога: «Зарегистрировать отказы в FRACAS», «Найти корневую причину отказа: …», «Разобрать повтор отказа: …», «Закрыть критичный отказ: …», «Назначить корректирующее действие: …», «Закрыть долго открытый отказ: …»; если проблем нет — «Замкнуть цикл FRACAS: <главный открытый риск>». В описание задачи попадает текст итога.
Чего фрейм не делает
Не ведёт даты. «Дней открыт» — число, которое вы обновляете вручную, само оно не растёт.
В карточке нет ответственного и срока. Они есть только в шаблоне свободного списка заметок и с карточками не связаны.
Не считает MTBF и MTTR. Шкала тяжести 1–5 и формула риска — собственные правила фрейма, а не показатели методики.
Не задаёт контрольный период. Стадия «Верифицировано» — это ваша отметка, срок и критерий проверки фрейм не контролирует.
Отметка о повторе сохраняется, если вернуть отказ на раннюю стадию. Снять её можно только на стадии «Верифицировано», поэтому после переоткрытия итог продолжит сигналить о повторе.
В каждой проверке итог называет только первый проблемный отказ. Списки заметок в расчётах и итоге не участвуют.
Заполнили фрейм? Сохраните, чтобы не потерять
Книги и материалы по теме FRACAS
MIL-HDBK-2155 — справочник по системе отчётности об отказах, анализа и корректирующих действий (указан в справочном обзоре как источник метода); в работе не читался.
Справочная статья «FRACAS» (Wikipedia). Определение, три шага цикла, типичные выходные данные.
Справочная статья «Reliability engineering» (Wikipedia), раздел о системах FRACAS. Место метода в программе надёжности, практические предупреждения о данных и единой системе.
Справочная статья «Corrective and preventive action» (Wikipedia). Корректирующие и предупреждающие действия, связь с системой менеджмента качества.
%22%2F%3E%3Ccircle%20cx%3D%22512%22%20cy%3D%22156%22%20r%3D%2275%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.05%22%2F%3E%3Ccircle%20cx%3D%22454%22%20cy%3D%22118%22%20r%3D%2287%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.08%22%2F%3E%3Ccircle%20cx%3D%22409%22%20cy%3D%2271%22%20r%3D%22121%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%3EFMEA-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7%20(Failure%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%3EMode%20and%20Effects%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%3EAnalysis)%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%22618%22%20cy%3D%22299%22%20r%3D%22107%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.05%22%2F%3E%3Ccircle%20cx%3D%22429%22%20cy%3D%22262%22%20r%3D%22104%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.08%22%2F%3E%3Ccircle%20cx%3D%22481%22%20cy%3D%22260%22%20r%3D%22130%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%9B%D0%BE%D0%B3%D0%B8%D0%BA%D0%BE-%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%BD%D1%8B%D0%B9%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%D0%BF%D0%BE%D0%B4%D1%85%D0%BE%D0%B4%20(Logical%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%3EFramework%20Approach%2C%20LFA)%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%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%22528%22%20cy%3D%22374%22%20r%3D%22137%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.05%22%2F%3E%3Ccircle%20cx%3D%22568%22%20cy%3D%2242%22%20r%3D%22114%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.08%22%2F%3E%3Ccircle%20cx%3D%22611%22%20cy%3D%22201%22%20r%3D%2271%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%3ELine%20of%20Sight%3A%20%D1%81%D0%B2%D1%8F%D0%B7%D1%8C%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%D1%86%D0%B5%D0%BB%D0%B5%D0%B9%20%D1%81%D0%BE%D1%82%D1%80%D1%83%D0%B4%D0%BD%D0%B8%D0%BA%D0%B0%20%D1%81%D0%BE%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%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%B5%D0%B3%D0%B8%D0%B5%D0%B9%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)