tskproblem_quality-management

Documentation – main page

AyMINE – Technical documentation

AyMINE® home page

sys
tsk
crm
web
am
eacon
frm
hr
sabre
sabreAbout
fi
bsc

Let us know what you're looking for

Do you prefer to ask us directly?

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

or use this contacts

Incident and Quality Issue Management

The purpose of problem management is to ensure that every issue is evaluated and fully resolved. Problem-solving includes the agendas of the quality department as well as the helpdesk for customers and users.

No one wants problems, but they are an inseparable part of any significant project. Quality management systems pay close attention to them because solving problems is a key step not only in their elimination but also in overall improvement.

Monitoring and resolving problems are integral to both project management and routine process management within a company. Naturally, it is also part of overall quality system management.

The term "problem" encompasses a broader range of events, which often have specific terminology within a company. Different types can be distinguished using a classification system defined in accordance with corporate methodology:

  • Non-conformance – A deviation from the standard, typically identified during an internal audit. Non-conformance does not necessarily lead to a defect.
  • Problem – Ambiguity about a solution, such as during development, or issues in production (e.g., recurring defects).
  • Defect – An output that fails to meet one or more input requirements.
  • Suggestion – A proposal, comment, or alert from any member of the resolution team. Further analysis often clarifies its classification—such as a problem or an improvement suggestion.

Problem Lifecycle

Every problem should be recorded as soon as it arises—assuming it isn't immediately resolved (in which case, it's probably not a problem).

Once recorded, a problem remains "active" until resolved. The lifecycle of a problem is essentially the same as a task or request. It is assumed that someone will take ownership of the issue; until then, it may remain open without an assigned resolver.

Recording a Problem

Most process methodologies require that all or most of the following information is documented. Verify your organization's specific methodology requirements.

Problem Occurrence

The initial documentation of a problem record should include:

  • Description of how the problem manifests.
  • Identification of who reported it and when (not necessarily the person who recorded it).
  • When the problem began, occurred, or was first detected.
  • Who is responsible for the problem.

Problem Resolution

Further analysis should document:

  • Root Cause – Determining the cause may require in-depth analysis, such as Root Cause Analysis, Fishbone diagrams, or 8D reports. These analyses should be included in the problem documentation, as they are critical records of the process. The cause is documented in a separate tab within the details.
  • Resolution Process – What actions and findings were undertaken to resolve the problem:
    • Events: Documented as events (activity tab).
    • Findings: Recorded under the resolution process section. If they are assumptions, discussion points, or suggestions, we recommend documenting them in the problem's discussion. Note: The discussion is archived just like the main object and serves as part of the solution documentation for later review or auditing.

Problem Resolution Statuses

  • New – Just created; no one is addressing the problem yet.
  • Open for Resolution – The problem is marked as awaiting someone to take responsibility.
  • In Progress – Someone has taken ownership of the problem.
  • Resolved – The problem has been resolved and awaits confirmation from the administrator. If the administrator resolves it directly, it won't reach this status.
  • Completed – The problem is fully resolved. This status is reached either by the administrator resolving it directly or by confirming its resolution (if solved by someone else).
  • Rejected – The problem is deemed unnecessary to address. This status can be manually set by the resolver. A problem might be rejected if, for example, it pertains to a canceled order.

Problem Documentation

Problems can remain open indefinitely. The system cannot evaluate problem urgency and therefore does not enforce resolution deadlines. However, each problem should have a resolution deadline, and overdue problems are highlighted on the workspace.

Problem documentation also offers additional benefits:

  • Increases team member interchangeability by facilitating the handover of unresolved tasks.
  • Enables experience sharing across different and future projects, helping to anticipate and address similar issues.
  • Thorough problem documentation can provide insight into effective resolution strategies for future scenarios.
  • Satisfies requirements of methodologies such as PMBOK, ISO 9001, ASPICE, ISO 26262, and others, which view problem documentation as essential for ensuring problems are addressed and resolved.

Proper Problem Description

To ensure resolution, problems must be documented from the beginning. This is especially crucial if the resolver is different from the reporter or if the solution will be delayed. Quality methodologies and internal standards often define the contents of problem descriptions. They generally agree that the description should include at least:

  • Precise identification of the environment where the problem arose (e.g., whether it occurred on internal equipment or at a customer's site, and which one).
  • The circumstances under which the problem occurred.
  • The impact or potential impact of the problem.
  • The severity of the consequences.
  • The steps taken to replicate the issue (if applicable).
  • The expected correct behavior.

Additionally, if known and relevant:

  • Reference to documentation describing the correct state (e.g., a manual for the malfunctioning device).
  • Logs or other records of incorrect behavior.

Not all of these elements apply to every problem. For example, technical issues with equipment can often be fully documented, while knowledge gaps in a team member might not require detailed documentation. Both scenarios, however, are problems that should be recorded when they occur.

Resolution Documentation

The resolution process should be documented alongside the problem details since circumstances often evolve during resolution. In complex cases, problems may be subdivided into smaller issues or linked to others through logical connections.

You May Also Be Interested In