AyMINE – Technical documentation
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
Sample tasks and methodologies of the area
Effect of the task on the right to modify the attached object
Objects related to the task pattern
Contacts and directories module (CRM)
Address book or people and companies
Web management and automation
Receiving a message from the web
Asset management module
Sabre plugin module
Enterprise Architect connector
Database link to Enterprise Architect database
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
Additional functions with files
Copying and moving files between objects
Files (documents) linked to the object
Problem Resolution Management
The purpose of the process resolution is to manage the problem until the complete resolving – both correction and prevention actions.
- Life cycle of a problem
- Problem vs. task and time report
- Correct description of the problem
- Documentation of the solution
Problem resolution process area is necessary part of all quality management systems. The problem management shall be managed both in the project and in general business. Sure, it is also part the quality control.
Problem logging refers to a wider group of events that often have a separate name in the business terminology. In AyMINE, it is possible to distinguish individual types by using a client-defined counter in accordance with the company methodology:
- Disagreement – Deviation from the standard, typically identified by an internal audit. Disagreement may not result in a fault
- Problem – Uncertainty about the solution e.g. during development, but also e.g. a problem in production (occurring faults)
- Faulty – A bad output that does not meet any of the input requirements.
- Initiative – A suggestion, comment or warning from anyone on the research team. Further analysis usually finds out how to classify it in more detail – e.g. as a problem, but also e.g. a suggestion for improvement.
Life cycle of a problem
Every problem should be recorded as soon as possible when it occurs. Of course, only if it is not solved immediately (then it is probably not a problem)
When a problem is recorded, it remains "active", i.e. solved until termination. In AyMINE, a problem has essentially the same life cycle as a task or a request. It is assumed that someone will take charge of the problem elimination, until then it can remain open without a solver.
Recording the problem
Most process methodologies require that all or most of the data below be recorded. Check your organisation's own methodology, what exactly is requires.
Creation of the problem
The documentation when setting up a problem record should include:
- Description of how the problem manifests
- Identification of who and when reported the problem (not necessarily the person who recorded it)
- When the problem began to manifest, arose or was first discovered
- Who is in charge of the problem
Solving the problem
Records should be created as part of the next analysis:
- Problem cause – Its findings may require more detailed analysis, e.g. Root-cause, Fishbone, 8D report, etc. These analyses should be attached as they are an important documentation of the process. The cause is documented on a custom tab in detail.
- Problem resolution procedure – What events and findings were performed in solving the problem:
- Events: Documented in the form of an event (activity tab)
- Discovery: Recorded in the solution procedure (below the actual description of the problem). When it comes to assumptions, things to discuss or suggestions, we recommend documenting in the discussion of the problem. Note: the discussion is archived in the same way as the object itself and is therefore a solution documentation that can be revised and audited afterwards.
Problem resolution states
- New – after creation, the problem is still not being addressed
- Free to resolve – The problem was marked by the "administrator" as waiting for someone to take charge of it
- In resolution – The problem is being handled by someone
- Solved – The problem has been resolved and is waiting for confirmation by the administrator. If the problem is directly resolved by the administrator, the problem does not get into this state at all
- Finished – The problem has been completely resolved. The problem gets into the state either by resolving it by the administrator or by confirming that the problem is resolved (by the administrator when someone else has solved it)
- Excluded – The problem has ceased to make sense to solve. The solver can manually convert it into this state with a command. The problem is discarded, for example, if it related to a job that was cancelled.
Problems can remain open in general for however long. The system does not have a tool to evaluate the urgency of a problem and therefore does not generally provide a solution. However, the issue should indicate by when it is to be resolved, and issues that exceed that date are highlighted on the workspace.
But documenting the problem has other benefits as well:
- Increased interchangeability of team members, who can more easily communicate the agenda to be addressed.
- Passing the experience on to other and later projects that can gain experience of what to watch out for and what to expect that may occur
- With good documentation of the solution to the problem, experience of how to deal with the problem can also be fed into other projects or activities in general.
- Meeting the requirements of methodologies such as PMBOK, ISO9000, ASPICE, ISO26262 and many others that see problem documentation as a vital tool for ensuring that problems do not go unresolved.
Problem vs. task and time report
Problems are not tasks and even in a system they stand alone. They can be tracked and resolved without creating a task to resolve them, but if a task proves to be important, a task can be created for the problem. In particular, this can be useful if a group needs to be formed to collaborate on a solution to a problem. (For example, the task can be put on people's calendars and capacity can be planned for it.)
The need to create a task depends on the way how your team works. For example, if a colleague synchronises tasks to the mobile phone, creating a task will synchronise it and a colleague gets notice about the problem even if he/she doesn't look into the AyMINE.
Right next to the problem, it is possible to report the work done to solve it. There is no reason to create a special task to solve just because of the work report.
Correct description of the problem
In order for a problem to be solved, it must be documented from the beginning. Especially if the problem is to be solved by someone other than the person who identified and wrote down the problem, or if it is known that the solution is delayed and will not be immediate. The content of the problem description is usually also defined by the quality methodologies of the work and the internal quality system. The methodologies agree that the description should include, at a minimum:
- Accurate identification of the environment in which the problem occurred (e.g., whether the problem is at an internal facility or at the customer's facility and at which facility)
- Under what circumstances the problem occurred
- What caused or may cause the problem
- How severe the impact is
- What steps were taken to bring it about (especially if it can be brought about again by the same steps)
- What the correct behaviour should be
The following should also be included (if known and relevant):
- Reference to documentation describing the correct condition (e.g. manual of the malfunctioning device)
- Logs or other records of the malfunctioning behaviour
For many problems, of course, some of the above values are not relevant, or are only relevant in a figurative sense (a prime example for problem documentation is the occasional misbehaving device. In this case, the documentation is fully meaningful. In another example – lack of knowledge in a project team member, most of the description points will of course be unusable. Both examples are problems that should be noted at the time of creation.)
Documentation of the solution
The problem should state how it was solved. The description is included in the same description as the details of the problem, because in the course of solving, circumstances are often refined, and both are worked together.
Especially when solving more complex problems, it is common for the problem to be split into sub-problems, or for other sub-problems to become apparent. It is therefore possible to introduce sub-problems to a problem, or to link a problem to another problem by logical linkage.