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
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
How the system works and how it protects data
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
Project Goal
Goal allows to include the definition of the project objective in the project analysis, in particular to link requirements to objectives.
Objectives are part of the project documentation. Describing them as a separate element in the analysis gives the possibility to define for each requirement which project objective is fulfilled by it.
The logic of the goal in the documentation corresponds to its concept in the motivation layer ArchiMate.
Common program goals for multiple projects
A goal is always included in some part of the analytical model. The motivation model should be part of the project documentation, so the objective will logically belong to the project. However, the same goal can be followed by multiple projects and can refer to a common goal.
If you are implementing projects pursuing common goals, it's a common to define the program under which the goals are pursued and the projects are coordinated. The programme defines programme objectives, which can then be subdivided into sub-objectives that are met by individual projects.
Projects may fulfil their own objectives, derived programme objectives or a direct programme objective. The structure of the objectives should be adapted to the programme complexity. Be careful not to hunt to many rabbits at once :)
How the programme and its objectives are defined
The programme is registered in the system as a "global" project and the individual projects are its sub-projects. Thus, the projects will take their target from the programme to which they belong.
We recommend keeping the programme objectives and sub-objectives within one analytical model, i.e. the programme. The objectives can be better managed and reviewed when they are together. The programme manager has simple overview that all goals relate each other correctly.
If you want to model the incentive level in detail and create an incentive scheme, it is possible to use connector to Enterprise Architect and manage the model there.
The business goal in the analytical model
Goal is a part of the project's analytical modal, it is not a part of the enterprise architecture. Enterprise architecture model describes As-Is state , whilst the goal describes direction to the To-Be state.