Документація – вступна сторінка
AyMINE – Technical doc. (in English)
Модулі
Модуль керування завданнями та інформацією
Кваліфікація, здібності / вміння
Кваліфікація користувача або контакту
Рівні компетентності та кваліфікації
Право на управління кваліфікацією користувачів
Вплив завдання на право змінювати підключений object
Об'єкти, які обробляються в задачі або вирішуються в проблемі
Працівник, відповідальний за завдання
Область / проект / методологія
8D report – системна підтримка
Об'єкти, яких стосується проблема
Повернути план проекту за baseline
Чому не можна видалити деякі дані
Об'єкти, які приймаються рішення
Модуль керування завданнями та інформацією
Адміністрація модуля Управління завданнями
Системні права модуля керування завданнями
Об'єкти, що відносяться до шаблонного завдання
Модуль Контакти та адресної книги (CRM)
Політика конфіденційності та ділової інформації
Список і управління каталогами
Надсилайте масові повідомлення відповідно до GDPR
Масові повідомлення електронної пошти
Вихід і встановлення преференцій
для масової пошти
Патік масової електронної пошти
Як коректно забути дані про людину
Модуль Контакти та адресної книги (CRM)
Системні права та налаштування CRM-модуля
Управління та автоматизація сайту
Користувацька документація AyMINE
Управління та автоматизація сайту
Модуль персоналізації
Персоналізація – права користувача
Синхронізація працівників та користувачів системи
Модуль управління активами
Перерахувати пропозицію та замовлення
Права доступу до пропозицій і цін
Властивість продукту або продукту
Процедура відбору та закупівлі
Управління фінансами
Метрики та вимірювання
Технічні модулі
Модуль Сейбр
Модуль Enterprise Architect роз'єм (eacon)
Модуль Enterprise Architect роз'єм (eacon)
Посилання до бази даних Enterprise Architect
Системні модулі
Framework – системна основа
Nastavte si, jak váš systém vypadá a funguje
Системний модуль фреймворку AyMINE
Розташування об'єкта на дошці оголошень
Копіювання та переміщення файлів між об'єктами
Публічне посилання на документ
Безпека повідомлень і внутрішніх дискусій
Властивість продукту або продукту
Властивості описують стани та поведінку продуктів для їх аналізу, включаючи FMEA
Які характеристики продукту?
Особливості продукту, важливі з точки зору аналізу, поділяються на основні групи за функціями, режимами роботи та іншими специфічними характеристиками. Специфічні характеристики варіюються залежно від типу продукту. Для активних одиниць це, наприклад, інтерфейс зв'язку, особливості внутрішньої пам'яті тощо.
Для чого використовується опис властивостей і як він виглядає
Властивості важливо описати як в рамках визначення продукту як компонент завдання, так і для аналізу його безпеки – FMEA.
Якісне введення виробу або деталі має містити опис його функціональності, робочих режимів та всіх інших атрибутів, що впливають на його функціонування.
Оцінка ризиків за FMEA
Властивості є ключовим входом для оцінки FMEA. Для оцінки ризиків ключовою є оцінка того, як кожна окрема властивість може сприяти загрозі або утискам користувачів, не працюючи взагалі або неправильно.
Тому для FMEA оцінки необхідно для кожної властивості.
- Що потенційно може статися з даною властивістю?
- Розглянемо, які зміни можуть викликати
- Оцінити:
- S: Severity – Як це вплине на користувачів?
О: Окурренс – Що проблемна ситуація виникає, - D: Detection – як легко виявити проблему?
- Запропонувати заходи, які потрібно зробити, щоб загальний ризик RPN (Risk Priority Number) зменшився
Як записувати оцінку
Якщо щодо характеристик існує більше можливих проблем та їх наслідків, завжди оцінюйте найгірший варіант у рейтингу.
Коли будуть запропоновані заходи, запишіть їх в однойменний пункт. Коли заходи будуть затверджені та включені до вимог, можливе подальше(!) зниження загального рейтингу. Залежно від того, що змінюють заходи безпеки, можуть знижуватися одне або кілька значень S, O, D.
NRP = добуток факторів ризику
Для оцінки ризику окремих факторів служить, перш за все, значення NRP, яке є добутком тяжкості, ймовірності виникнення та здатності до виявлення. NRP = S × O × D
. Система обчислює значення автоматично (діапазон 1 .. 1000) і не можуть бути введені.
Запобіжні заходи = вимога
Вжиті заходи слід записувати як вимогу до продукту або виробничого процесу. Важливо, щоб ці вимоги мали зв'язок від аналізу – тільки так можна перевірити, що захід дійсно потрапляє в реалізацію.
Щоб записати запит, скористайтеся функцією додавання запиту – ви можете прикріпити існуючий запит, як правило, але більше створюєте запит новий.
Як правильно перекинути S: Severity – O: Occurrence – D: Detection
Для оцінки впливу можливих пошкоджень існують стандартизовані таблиці, доступні за посиланнями нижче.
Ваш проект може вимагати іншої оцінки! Керуйтеся завжди тим, що має відношення до вашого проекту. Наведені приклади використовуються в секторі автомотиву, але і в ньому ваш клієнт може вимагати власну методологію.