AyMINE – Technical documentation
User Modules
Task, project & quality management
Manager approval with the task report
Why some data can't be deleted
Region / project / methodology
Change management process in a project
Qualification of user or contact
Right to Manage Qualifications
Methodology and Quality Management systems
What a methodology / QMS consists of
Customer Service Response Generation
Objects affected by the problem
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)
Web management and automation
Receiving a message from the web
Human resources
Human Resources module security
Manage department / division data
Synchronizing staff and system users
Products, assets and sales
Received order for goods or services
Technical Modules
Sabre plugin module
Enterprise Architect connector
Database link to Enterprise Architect database
System Modules
The AyMINE Framework Module
Configure how your system looks and works
Gestures and keyboard shortcuts
More about how the system works
Private notes and tags for objects
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
FMEA – pravděpodobnost odhalení
Pravděpodobnost odhalení poruchy, pokud porucha nastala.
Níže uvedený přehled vychází z normy pro automobilový průmysl. Před použitím zkontrolujte, zda je to relevantní pro váš případ!
Pravděpodobnosti odhalení podle druhu kontroly
No detection
opportunity
Rank 10: Almost Impossible. No current design control; Cannot detect or is not analyzed
Not likely to detect at any stage
Rank 9: Very Remote. Design analysis/detection controls have a weak detection capability; Virtual Analysis (e.g., CAE, FEA) is not correlated to expected actual operating conditions.
Post Design Freeze and prior to launch
Rank 8: Remote. Product verification/validation after design freeze and prior to launch with pass/fail testing (Subsystem or system testing with acceptance criteria, such as ride and handling, shipping evaluation).
Rank 7: Very Low. Product verification/validation after design freeze and prior to launch with test to failure testing (Subsystem or system testing until failure occurs, testing of system interactions, etc.).
Rank 6: Low. Product verification/validation after design freeze and prior to launch with degradation testing (Subsystem or
system testing after durability test, e.g., function check).
Prior to Design Freeze
Rank 5: Moderate. Product validation (reliability testing, development or validation tests) prior to design freeze using pass/fail testing (e.g., acceptance criteria for performance, function checks).
Rank 4: Moderately High. Product validation (reliability testing, development or validation tests) prior to design freeze using test to failure (e.g., until leaks, yields, cracks).
Rank 3: High. Product validation (reliability testing, development or validation tests) prior to design freeze using degradation
testing (e.g., data trends, before/after values).
Virtual Analysis – Correlated
Rank 2: Design analysis/detection controls have a strong detection capability. Virtual analysis (e.g., CAE, FEA) is highly correlated with actual or expected operating conditions prior to design freeze.
Detection not applicable; Failure Prevention
Rank 1: Almost Certain. Failure cause or failure mode can not occur because it is fully prevented through design solutions (e.g., proven design standard, best practice or common material).