Документація – вступна сторінка
AyMINE – Technical doc. (in English)
abra
crm
- Модуль Контакти та адресної книги
- Системні права та налаштування CRM-модуля
- Огляд замовлень клієнтів
- Довідник
- Список і управління каталогами
- Політика конфіденційності та ділової інформації
- Надсилайте масові повідомлення відповідно до GDPR
- Патік масової електронної пошти
- Вихід і встановлення преференцій
для масової - Як коректно забути дані про людину
- Масові повідомлення електронної пошти
- Контракти, договори
- Партнер за контрактом
- Групи клієнтів
- Каталог або люди і компанії
- Контакти
- Швидко доступні контакти
sabre
hr
- Модуль персоналізації
- Цифровий кадровий архів
- Персоналізація – права користувача
- Облік кандидатів на роботу
- Посада
- Член команди – Працівник
- Огляд працівника
- Огляд власного персоналу
- Відповідальний персоналіст
- Синхронізація працівників та користувачів системи
- Трудовий договір
- modulesafety
- personalfolder
sys
- Системний модуль фреймворку AyMINE
- Клієнт
- Настроювання шлюзів для зовнішніх повідомлень
- Повідомлення із зовнішнім світом
- Правила для зовнішніх повідомлень
- Документи
- Додаткові функції з файлами
- Копіювання та переміщення файлів між об'єктами
- Презентація зображення
- Публічне посилання на документ
- Останні файли
- Дошка
- Розташування об'єкта на дошці оголошень
- Елементи клієнта
- Огляд і коментарі
- Безпека повідомлень і внутрішніх дискусій
- Переклади
- Зв'язки між об'єктами
- Типи сесій (відносин)
- Ролі та команди груп
- Користувач системи
- Адміністрація користувача
- GDPR та користувачі системи
- Безпечний вхід
- Адміністрація користувача
- Криптогаманець
- moduleclientoptions
frm
- introhelp
- introhelp_objectdetail
- AyMINE Framework
- Політика зберігання паролів
- Права користувача framework
- Модулі AyMINE
- Замки користувача
- Системні дозволи
- introhelp_deleting
- introhelp_settings
- introhelp_objectlist
- introhelp_dashboard
- introhelp_generalinfo
- introhelp_icons_dnadrhal9000_mar-22-220246-2023_caseconflict
- introhelp_icons
- Записи AyMINE
tsk
- 8D report
- Основним елементом FMEA
- FMEA
- FMEA - ймовірність виявлення
- Процес аналізу FMEA
- FMEA - ймовірність виникнення
- FMEA - оцінка тяжкості
- Модуль керування завданнями та інформаці
- Адміністрація модуля Управління завданнями
- Системні права модуля керування завданнями
- Події
- Акції, події та наради
- Персональний календар
- Журнал активності
- Згода керівника
- Чому не можна видалити деякі дані
- Область
- Область / проект / методологія
- Огляд областей
- Шаблони міток
- Управління тегами
- Мої області
- Подія
- Архівний пакет
- Кваліфікація, здібності / вміння
- Рівні компетентності та кваліфікації
- Необхідні здібності
- GDPR та облік кваліфікацій
- Право на управління кваліфікацією користувачів
- Кваліфікація користувача або контакту
- Команда проекту
- Рішення
- Об'єкти, які приймаються рішення
- Варіант прийняття рішень
- Шаблон плану / стратегії
- Визначення проекту
- Зразок запису
- Зразок ризику
- Визначення пакета
- шаблон завдання
- Активація події із завдання
- Управління відповідальністю – RACI matice
- Повідомлення про події
- Об'єкти, що відносяться до шаблонного завдання
- Події, що починаються
- Призначення нового завдання
- Обговорення
- Бізнес-подія
- Кнопки для активації події
- Події подій
- Покращення та запобіжні заходи
- Інформація
- Ключове слово
- Проведення наради
- Методики та правила
- Обов'язок
- Поняття
- Директиви та політики
- Управління змінами в проекті
- Проблеми, тікети та їх управління
- Центр обслуговування клієнтів
- Внутрішня довідка
- Об'єкти, яких стосується проблема
- Управління інцидентами, невідповідність якості
- Проект
- Графік проекту
- Команда проекту або команда до робочого процесу
- RACI-матриця для project
- Повернути план проекту за baseline
- Записи та журнали
- Записані дії
- Вимоги
- Вимоги до вступників
- Ризик
- Завдання
- Терміни викликів
- Огляд завдань
- Вплив завдання на право змінювати підключений obje
- Особисте завдання
- Член команди
- Об'єкти, які обробляються в задачі або вирішуються
- Завдання працівника
- Тест
- Типи тестів
- Попередження
- Попередження – приклад використання
- Попередження для себе
- tsktask_kanban
- moduleclientoptions
am
- amasset
- Модуль управління активами
- Процедура відбору та закупівлі
- Аналітична модель
- Постачальник продукту
- Категорія продуктів
- Властивість продукту або продукту
- Мета проекту
- Комерційна пропозиція
- Перерахувати пропозицію та замовлення
- Права доступу до пропозицій і цін
- Системний запит про стан замовлення
- Продукти та товари
- Стан продукту та його зміна
- Одиниці продуктів
- Критерії якості
- Про критерії якості продукції
- HARA продукту
Процес аналізу FMEA nothing
Процес аналізу FMEA складається з 7 кроків
- Методологія FMEA в Аймине
- Огляд кроків FMEA
- Крок 2 - Структурний аналіз
- Крок 3 - Функціональний аналіз
- Крок 5 - Аналіз ризиків
- Крок 6 - Оптимізація
- Корисні посилання на сайт
Методологія FMEA в Аймине
AyMINE має підготовлену методологію для процесу 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, оскільки багато команд все ще звикли використовувати цей індекс.)
Важливим компонентом оптимізації є проектування змін, які зменшать ймовірність виникнення. За кожною невдачею можна розрізняти і сучасні інструменти мінімізації, і новозапропоновані заходи.
В рамках аналізу задокументовані нові заходи, а також фіксується очікувана вартість – результатом аналізу є не тільки поточний стан, але і стан після реалізації всіх заходів.
Завдання та вимоги до розв'язання
Заходи аналізу додатково відображаються на вимогах до змін або завдань, які будуть вирішувати проблему. Обидва можуть бути засновані безпосередньо в деталях випадку невдачі або в деталях характеристик. Запит і завдання формуються з прив'язкою до можливої невдачі. Настільки очевидно, чому виникла вимога або завдання, я відстежую, чи вил вирішено.