Процес аналізу FMEA

Модулі

Інтеграція з ERP Abra Gen
Модуль керування завданнями та інформацією
Модуль Контакти та адресної книги (CRM)
Управління та автоматизація сайту
Модуль персоналізації
Модуль управління активами
Управління фінансами
Метрики та вимірювання

Технічні модулі

Модуль Сейбр
Модуль Enterprise Architect роз'єм (eacon)

Системні модулі

Framework – системна основа
Системний модуль фреймворку AyMINE

Дайте нам знати, що ви шукаєте

Ви хочете прямо запитати?

Телефонуйте за тел. +420 605 203 938

або використовуйте інші контакти

Процес аналізу FMEA

Процес аналізу FMEA складається з 7 кроків

Методологія FMEA в Аймине

AyMINE має підготовлену методологію для процесу FMEA (звичайно, ви можете редагувати її або створити власну методологію).

Методологія для FMEA

Досить згенерувати набір завдань за шаблонами в методології.

Огляд кроків FMEA

Розділи описують не весь процес, а його реалізацію в рамках AyMINE. Для більш повного розуміння FMEA ми рекомендуємо наше навчання, деталі також описані в деталях процесу безпосередньо в FMEA. Метою даного сайту є надання глобального погляду на процес, який може бути недостатньо очевидним з окремих завдань.

Крок 1 - Планування та підготовка

Підготовка FMEA здійснюється за зразком процесу FMEA. Процес може розпочатися керівником проекту або власником, відповідальним за продукт. Його слід підключити до аналізованого продукту або процесу. Його прив'язка можлива як до продукту, зареєстрованого вже в базі даних продукту, так і до елементів аналізу, тобто, наприклад, виробничого процесу.

Ключовою частиною 1-го кроку є визначення команди, яка здійснює FMEA аналіз. Ведучий призначає членів команди на завдання аналізу. Тобто не до завдання підготовки, яке є його відповідальністю.

Від часових можливостей і розмірів команди залежить план подальших дій:

  • Відповідальність за перегляд та доповнення аналізу оцінюваного предмета. Відповідальний працівник отримує завдання FMEA – крок 2.
    Відповідальність за підготовку функціонального аналізу – FMEA – крок 3.
  • Запрошення експертів на нараду для аналізу невдач і ризиків. Треба, щоб вони могли заздалегідь ознайомитися з аналізом, тому між виконанням кроків 2 і 3 і початком кроку 4 має бути достатньо місця (час залежить від того, чи будуть залучені незалежні експерти, які не знають цього предмета).

Другий важливий розділ – планування аналітичних зустрічей, коли будуть реалізовані кроки 4, 6.

Якісний план і підготовка можуть здаватися справою самоочевидною, роботою непотрібною. Але саме якісна підготовка вирішує, чи буде аналіз ефективним.

  • Необхідно чітко визначити обсяг аналізу. Точніше, де саме знаходяться межі об'єкта, що аналізується (процесу, продукту).
  • Оцінити, хто дійсно розуміє тему і сформувати компетентну команду
  • Планувати підготовку, зокрема підготовку матеріалів, а також всі подальші кроки

Крок 2 - Структурний аналіз

Виходом є структура предмета або у вигляді деталей (для виробу) або процесуальних кроків і використовуваного обладнання (для процесу).

Якщо для структурного аналізу використовується аналіз продукту, то результати структурного аналізу можна візуалізувати за допомогою Enterprise Architect. (Потрібне підключення за допомогою eacon роз'єму до моделі EA.)

Використовуючи документально оформлену компонентну базу, можна побудувати вже існуючий попередній FMEA-аналіз. Тому доцільно, по можливості, використовувати вже зазначені деталі і не створювати в рамках структурного аналізу їх дублікатів.

Крок 3 - Функціональний аналіз

У результаті виходять описи властивостей, режимів роботи і станів в деталях окремих цілих. На рівні деталей повинні бути описані характеристики деталей, які є актуальними з точки зору FMEA. Описи безпосередньо пов'язані з елементами, тому функціональний аналіз логічно можна проводити тільки після структурного аналізу.

Основним інструментом контролю функціонального аналізу є виконання функціональної специфікації продукту або процесу за допомогою властивостей (загальна назва, що включає):

  • Загальна властивість
  • Функціональність
  • Оперативний режим.

Якщо проводиться повторний FMEA-аналіз деталі з іншою метою, то можна скористатися документацією з попереднього аналізу або зробити новий аналіз для того ж елемента. Таким чином, для кожної характеристики можна уточнити, до якого аналізу вона включена. (Якщо це не уточнюється, він включений в усі.)

Крок 4 – Аналіз невдач

Можливі невдачі заповнюються за індивідуальними властивостями. До кожної властивості можна ввести збій масово, але краще розбити їх окремо на випадки відмови (вкладка в деталях.)

Випадки можливої відмови стають документацією властивостей, покриттям деталі (або процесуального кроку). Працює з ними далі на кроці 5.

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

Примітка про права: На аналізі можуть працювати ті, хто є активними співробітниками у сфері або проекті, де здійснюється аналіз. Але в той же час вони повинні мати право вступати в аналізи. Таким чином, можна добре контролювати, хто бере участь в аналізі.

Якість документації: Ми рекомендуємо всім, хто бере участь в аналізі, бути членами команди для цього завдання. Склад команди є частиною документації аналізу, саме на основі списку учасників. Для зустрічі організуйте наради, де FMEA буде єдиним пунктом для вирішення. При цьому немає жодних ризиків, що ФМЕА дійсно не братиме участі в переговорах.

Крок 5 - Аналіз ризиків

Аналіз ризику ґрунтується на аналізі відмови – він доповнює дані до випадків відмови, які були зафіксовані на етапі 5 FMEA процесу. В принципі, нові рядки не повинні додаватися до FMEA – вони відповідають можливим невдачам, але вже ідентифіковані будуть розглянуті.

Крок 6 - Оптимізація

Так само, як і крок 5, крок 6 будує на підготовці з кроків 2 і 3. Для кожної невдачі і аналізу ризиків система розраховує пріоритет дії по мінімізації ризиків. (Система підраховує і старіші RPN, оскільки багато команд все ще звикли використовувати цей індекс.)

Важливим компонентом оптимізації є проектування змін, які зменшать ймовірність виникнення. За кожною невдачею можна розрізняти і сучасні інструменти мінімізації, і новозапропоновані заходи.
В рамках аналізу задокументовані нові заходи, а також фіксується очікувана вартість – результатом аналізу є не тільки поточний стан, але і стан після реалізації всіх заходів.

Завдання та вимоги до розв'язання

Заходи аналізу додатково відображаються на вимогах до змін або завдань, які будуть вирішувати проблему. Обидва можуть бути засновані безпосередньо в деталях випадку невдачі або в деталях характеристик. Запит і завдання формуються з прив'язкою до можливої невдачі. Настільки очевидно, чому виникла вимога або завдання, я відстежую, чи вил вирішено.

Корисні посилання на сайт