Obligation

User Modules

Task, project & quality management
Contacts and directories module (CRM)
Web management and automation
Human resources
Products, assets and sales

Technical Modules

Sabre plugin module
Enterprise Architect connector

System Modules

The AyMINE Framework Module
System Management

Give us contact

Do you prefer to ask us directly?

Call us +420 605 203 938 (the Czech Republic)

or use this contacts

Obligation

Obligation expresses in general any external instruction that determines what a company should do and comply with.

Typical examples of obligations are:

  • Laws – e.g. GDPR, Labour Code
  • Standards – e.g. ISO 26262, ISO 27000
  • Lawful regulations – e.g. Accounting Code
  • Industry standards
  • Social contract with trade unions
  • Company charters
  • General meeting decision
  • Owner's decision – typically corporate standards

Common features of obligations are that:

  • They are external
  • They are internally accepted by the company but not directly influenced by it
  • All internal directives, rules and procedures should follow their regulations.

Obligations as part of methodology

Obligations in the truest sense are not part of the internal quality system. The internal system should be made up of policies and directives that translate obligations into internal practice.

An obligation is not a part of the ISMJ – quality management system, but is closely related to it

AyMINE has obligations as part of methodology; with the quality system being the most common case and example of methodology. The main reason for including obligations in methodologies is that most of the time obligations are transferred within one methodology, and it is important to know which obligations are "covered" by the system.

AyMINE supports multiple methodologies

You can have multiple methodologies in AyMINE, and there may be a situation where the same obligation is reflected in multiple methodologies. Never re-enter an obligation into the system, AyMINE allows for a better solution. In principle, there are two solutions – either a separate methodology or an inclusion in an existing one.

Create a separate methodology only for obligations

If there are multiple obligations shared between methodologies, the most appropriate solution is to separate them from the methodology into a separate area – the methodology with obligations.

Obligations will not be displayed on the working area of the methodologies, but it is also possible to create links between directives and obligations. By not displaying any obligations in the methodology, it will be obvious at first glance that they are elsewhere.

Include an obligation in the methodology that is the solution most

If situations are dealt with where an obligation is in principle reflected by one methodology, but is taken into account somewhere, for example, by a directive from another methodology, the obligation can be further specified within the methodology that primarily deals with it.

Directives can be linked to obligations from any methodology, so it is not a problem to use obligations from other methodologies as well.