Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
The Problem Management is the process responsible for managing lifecycle of all problems. The general purpose is to prevent incidents and to minimize the influence of those that cannot be prevented.
Within SimpleOne, the Problem Management solution allows users to perfom the following types of process activities:
- Identificate and log problems;
- Prioritize and categorize them by impact and urgency, CIs and services;
- Assign problems to appropriate persons and groups;
- Investigate and perform functional or hierarchical escalation if necessary;
- Produce workarounds to reduce problem affection and to keep system functionality running while searching for a resolution;
- Resolve and Close problems with the objects related to them.
Problem Identification and Categorization
When detecting an issue, it is neccessary to log and describe all the aspects of a problem. Create a Problem record to properly identificate the issue, and to log all activities and works on a problem.
Categorize and prioritize a problem for a proper assessment of the impact on your system functionality, in order to produce an effective resolution.
Problem Investigation
Use the Problem Management features to investigate problems and objects related to them. Establish hierarchical and functional relationships with Incidents and Change Requests to identify the issue cause.
Produce a workaround
You can reduce or eliminate the impact of a problem that cannot be resolved for some reason. Create a Known Error record to produce a workaround useful for the relevant problems and issues.
Problem Resolution
Initiate and produce the most appropriate problem solution by the SimpleOne features. Create Change Requests and Problem Tasks that are neccessary for problem resolution.
Problem Closure
Close completed Problems after verifying whether the issue has actually been eliminated.
Problem Management State Model
The problem states
State | Description | ||
|---|---|---|---|
| Registered | The incident problem is recorded (via phone/email/Self-Service Portal) detected and recorded but not yet categorized. | ||
| Assigned | The incident problem is categorized and assigned to a relevant person or group. | ||
| In Progress | The person started working on the issue. | ||
| Postponed | The incident problem can be marked Postponed if the incident problem resolving should be postponed for a known period. If the incident moves to this status, then planned resolving date must be specified in the Resubmission field. But if the incident If the problem affects business functions, then it must have at least a temporary workaround. | ||
| Known Error | A problem that has been analysed but has not been resolved. Keep produced workarounds in the Known Error Database (Knowledge Base → KEDB) and apply them when related incidents occur. | ||
| Completed | An incident problem is considered resolved when an agent has come up with a temporary workaround or with a permanent solution for this issue. In this case, he/she must change the status state to Completed so that the caller could perform the tests. If the tests are successful, then the incident problem should be marked as Closed; otherwise, it should be marked as Rejected by User. | ||
| Closed | After the problem caller is satisfied with the problem solution, he/she could close the incident (mark it as Closed ) . If the problem was not closed after it was marked as Completed, then it can be closed automatically over an adjustable timeframe.
|
Only the problem caller has the right to close the problem according to the best ITSM practice.
| Table of Contents | ||
|---|---|---|
|