AyMINE – Technical documentation
Modules
Task, project & quality management
Manager approval with the task report
Why some data can't be deleted
Adminitration of areas, projects, calendars
Region / project / methodology
Change management process in a project
GDPR and record of qualifications
Qualification of user or contact
Right to Manage Qualifications
Analýza selhání pro jednotlivou vlastnost součástky či procesu
FMEA – Probability of Detection
FMEA – Probability of Occurrence
Task, project & quality management
Administration of the Task Management Module
System rights for the task management module
Methodology and Quality Management systems
What a methodology / QMS consists of
Collaborative Resolution of Multiple Problems
Customer Service Response Generation
Incident and Quality Issue Management
Objects affected by the problem
Problems, Incidents, Helpdesk Tickets
Return project plan by baseline
Sample tasks and methodologies of the area
Effect of the task on the right to modify the attached object
The person responsible for the task
Working procedure – task definition
Objects related to the task pattern
Contacts and directories module (CRM)
Order overview for customer groups
Contacts and directories module (CRM)
System Permissions and CRM Module Settings
Send bulk messages in compliance with GDPR
How to correctly forget a person's details
Unsubscribe and set preferences
for bulk mail
Web management and automation
Receiving a message from the web
Human resources
Personalistics – User Permissions
Human Resources module security
Manage department / division data
Overview of Personnel Information for pracov# Employment Contract
Synchronizing staff and system users
Products, assets and sales
Received order for goods or services
Finance management
Metrics and Measurements
Technical Modules
Sabre plugin module
Enterprise Architect connector
Database link to Enterprise Architect database
Enterprise Architect connector
System Modules
The AyMINE Framework Module
AyMINE — Tips for Mobile Usage
Configure how your system looks and works
Gestures and Keyboard Shortcuts
More about how the system works
Private notes and tags for objects
Overview of Modules and Record Types
Filtering in the list of records
System Management
Additional functions with files
Copying and moving files between objects
Files (documents) linked to the object
Formatted texts in the application
Gateway settings for external messages
IMP gateway settings for email communication
Internet Call Gateway Settings
Message with the outside world
FMEA Analysis - Process
The FMEA process is standardized, and AyMINE fully supports its latest version according to the AIAG & VDA FMEA Handbook.
A complete description of FMEA is available on a separate page here.
FMEA Process
The sections do not describe the entire process but its implementation within AyMINE. For a more comprehensive understanding of FMEA, we recommend our training courses, and details of the process are also described directly within the FMEA itself. The purpose of this page is to provide a global overview of the process, which may not be sufficiently clear from individual tasks.
Step 1 - Planning and Preparation
The preparation of FMEA is guided by the standard FMEA process. The process can be initiated by the project leader or the product owner. It should be linked to the analyzed product or process. This connection can be established either to a product already recorded in the product database or to elements of the analysis, such as a production process.
A key part of Step 1 is defining the team responsible for conducting the FMEA analysis. The leader nominates team members for the analysis task, not for the preparation task, which remains their responsibility.
The timeline and size of the team determine the planning of subsequent steps:
- Responsibility for reviewing and, if necessary, supplementing the analysis of the subject. The responsible team member is assigned the task FMEA - Step 2.
- Responsibility for preparing the functional analysis - FMEA - Step 3.
- Scheduling meetings with experts for failure and risk analysis. These experts should be given time to familiarize themselves with the analysis beforehand, so there should be sufficient time between completing Steps 2 and 3 and starting Step 4 (depending on whether independent experts unfamiliar with the subject are involved).
The second crucial part is planning analytical meetings, during which Steps 4 and 6 will be carried out.
Good planning and preparation may seem partly obvious, partly unnecessary. However, quality preparation determines whether the analysis will be effective.
- It is essential to clearly define the scope of the analysis, i.e., where exactly the boundaries of the analyzed subject (process, product) lie.
- Identify who truly understands the topic and assemble a competent team.
- Plan the preparation, especially the preparation of materials, as well as all subsequent steps.
Step 2 - Structural Analysis
The output is the structure of the subject, either in the form of parts (for a product) or process steps and the equipment used (for a process).
If structural analysis is applied to a product, the results can be visualized using Enterprise Architect. (This requires a connection to the EA model via the eacon connector).
When using a documented component database, it is possible to build on an existing previous FMEA analysis. Therefore, it is advisable to use already recorded parts whenever possible and avoid creating duplicates in the structural analysis.
Step 3 - Functional Analysis
The output includes descriptions of properties, operational modes, and states at the detail level of individual components. At the parts level, properties of parts relevant to the FMEA should be described. Descriptions are directly linked to elements, so functional analysis can logically only be conducted after structural analysis.
The primary tool for controlling functional analysis is meeting the functional specification of the product or process using properties (a general term encompassing):
- General properties
- Functionality
- Operational modes.
If a repeated FMEA analysis is conducted for a part for a different purpose, documentation from the previous analysis can be utilized, or a new analysis can be created for the same element. For this reason, it is possible to specify which analysis each property belongs to. (If not specified, it is included in all.)
Step 4 - Failure Analysis
Possible failures are recorded for each property. Failures can be entered collectively for each property, but it is better to detail them individually as failure cases (a tab in the detail view).
The possible failure cases become part of the documentation for the property and, by extension, for the part (or process step). These will be further used in Step 5.
Each part and each property are recorded separately, so it is not a problem to split the FMEA analysis into multiple groups if this makes sense given the differing properties.
Note on rights: Only those who are active collaborators in the area or project where the analysis is being conducted can work on the analysis. Additionally, they must have pright to access analyses. This ensures proper control over who contributes to the analysis.
Quality of documentation: We recommend that everyone involved in the analysis be members of the team for this task. The composition of the team is part of the analysis documentation, based on the list of participants. Organize meetings where FMEA is the sole agenda item. This prevents discussions from drifting away from the FMEA focus.
Step 5 - Risk Analysis
The risk analysis builds on the failure analysis - adding data to the failures that were recorded in step 5 of the FMEA process. In principle, no new lines should be added to the FMEA at this stage – these correspond to possible failures, but those have been identified.
Step 6 - Optimization
Like Step 5, Step 6 builds on the preparation from Steps 2 and 3. For each failure and risk analysis, the system calculates an action priority for risk minimization. (The system also calculates the older RPN index, as many teams are still accustomed to using it.)
A key part of optimization is proposing changes to reduce the likelihood of occurrence. For each failure, the system can distinguish between existing mitigation measures and newly proposed ones. The analysis documents new measures and records their anticipated effectiveness – the analysis output thus includes both the current state and the state after implementing all measures.
Tasks and Requirements for Resolution
Measures from the analysis are translated into change requests or tasks to address the problem. Both can be created directly in the detail of the failure case or the property detail. The request or task is linked to the possible failure, making it clear why it was created and allowing tracking of its resolution.