...
Problems represent the Problem records track the investigation and diagnosis of a root cause of one or more Incidents or possible Incidents. Resolving a problem means resolving/preventing related Incidents.incidents. Problems identify the underlying issue such that resolving the problem not only resolves the incident, it prevents further incidents. Incident Management is concerned with restoring service as quickly as possible, whereas Problem Management is concerned with determining and eliminating root causes (, and hence eliminating repeat problems).
The primary objectives of Problem Management are to prevent Incidents from happening incidents caused by a similar root situation from recurring and to minimize the impact of Incidents incidents that cannot be prevented. 
...
Problem Creation and Overview
When an incident is determined to be based on an underlying Problemproblem, first-response support technicians create a Problem problem record from the Incidentincident, automatically creating a link between the Incident incident record and the Problemproblem. The new problem record imports relevant information from the Incidentincident, such as the linked Configuration Itemconfiguration item. Problems are also creatable independent of existing Incidentscan also be created without being linked to existing incidents, such as in cases where a problem is discovered internally but no Incidents have been reported.
The Submittersubmitter, along with their Department department and contact information, are automatically populated based on the person who creates the problem, and the reporting source of the Problem is also captured in the record. Resolution of problems may require Changes changes to the system. Staff addressing the problem may determine that a shared CI needs to be replaced or modified, and may therefore file a Change Requestchange request. All updates throughout the lifecycle life cycle of the Problem Record problem record are logged in the record's History history along with the date and time, and updates can also be logged in the Additional Notes field, which logs the updater and time stamp of the update.
When the problem is resolved, a technician updates the record with relevant information and closes the record, in turn prompting automation to begin closing procedures for related Incidents. If the problem cannot be resolved it may be classified as a Known Error and a permanent work-around supplied. This will also update the related Incidents.
...
...
Processing of Records
Once created, Problem problem records can be linked to Incidents incidents from either the Problem problem record or from an Incident incident record.
Priority
Priority, a measure of the Problemproblem's urgency and relative importance, is set by default to based on the Priority combination of Impact and Urgency and how the Problem Priority Group is configured. The default priority matrix for problems is shown below.
These values may be changed to match a company's preferences. See the Impact, Urgency, and Priority Management section for more details. Problem priority the spawning Incident, but can be changed at the time of creation. Problem Priority, a measure of impact and risk, particularly with regards to IT service operations, may be determined separately as part of Problem Classification procedures. Together Priority priority and Problem Priority problem priority help IT managers make factual decisions for scheduling and planning and help determine the category of related Change Requests. By default new Problems have a Problem Priority of Standard (0), indicating no special review or authorization is needed.
...
change requests.
Diagnosis
The Problem problem record follows its own workflow separate from the Incidentincident. Ops team members open the problem record in the default state status of " Pending Diagnosis " to indicate that a diagnosis has yet to be determined, or " Diagnosed " if no further steps are required. A record may sit in a state of Pending Diagnosis for some time before staff actually begin to perform the diagnosis, so Start Clock and Stop Clock buttons let users indicate how much time was spent diagnosing a particular problem.The default Problem SLA has specified targets for completing diagnosis, based on the priority, and a diagnosis clock is started upon creation of the problem record. As part of the diagnosis, technicians select the service involved based on existing Incident incident reports or based on the most likely service to be affected by related to the Problemproblem. If a particular Configuration Item configuration item is identified as the source of the problem's root cause, staff can quickly link the Problem problem to the CI record.
Once a diagnosis is supplied, staff will move the record into a state status of " Diagnosed" and , fill out the Root Cause description and any further analysis, and save the record. They may also suggest a temporary fix, or "workaround", for the problem and push that to related incidents (, e.g. "use Printer B3 for now instead") , if a permanent solution is not readily available. While determining a workaround and/or permanent resolution, technicians can use Start and Stop Clock buttons to track the time spent determining workarounds and solutions for this Problem.
Diagnosis and Resolution Clocks
When the status changes from Pending Diagnosis to Diagnosed, Pending Change, Resolved, or Deferred, the diagnosis clock stops, the Diagnosis End Time field automatically populates with the current time, and the resolution clock starts. The diagnosis clock measures the working support hours between creation of the problem and diagnosis of the problem against the SLA diagnosis target.
The resolution clock measures time between when diagnosis is completed and the problem is resolved or deferred, excluding the time when the status is Pending Change, against the SLA resolution target for problems. While the status is in Pending Change, both clocks are stopped, since the people handling problems may not have control over when a change request can be scheduled and implemented.
Workarounds
If a workaround exists while the problem investigation is in progress, you can send the workaround to any related Incidents and the incident submitters. To do this...
- Enter the details of the workaround into the Workaround field.
- On the Related Records tab, change the Workaround Provided field to Yes.
- Click 'Update Incident with Workaround.' This posts the workaround to all related Incidents and changes the status to Workaround Provided. When the Incident status changes to Workaround Provided, the system sends an email to both the end user (submitter) and the assigned staff person of the Incidents, along with any CC's.
Deferring and Seeking More Information
During If at any time during the root cause diagnosis or determination of the proper solution, staff may need more information from a separate process, such as Incident details from first level support, the Problem record may be placed in a state of "Pending More Information".If a Problem for example incident details. In this case, technicians change the problem's Status to Pending More Information and send an email to staff members with requests for information. If a problem is deemed too risky or of lower priority than more imminent issues, it may be put in a status of "Deferred" change the status to Deferred to reflect no ongoing diagnosis or pending changes.
| Anchor |
|---|
...
|
...
|
...
Resolution
In most cases where a Problemproblem's root cause deals with a Configuration Itemconfiguration item, a Change Request change request will be submitted to make the appropriate fixes to the Configuration Itemconfiguration item. When Change Requests are creatable created directly from the Problem problem record, they are instantly linking themlinked. While a problem is waiting for a Change Request change request to be implemented, it can be put in the status of " Pending Change". If the Change Request change request linked to a Problem problem is closed, the system will send an email notification to notify the problem assignee so that the individual can to take additional steps to close the Problem problem record if it was pending change for resolutionin a status of Pending Change.
A problem whose root cause is known but for which there is no permanent resolution is considered a Known Error. Known Errors should have Workarounds workarounds to allow Incident Management to restore service as quickly as possible. The "Update Incident with Workaround" button allows staff working the Problem to quickly disseminate workaround information to linked Incidents with the click of a button. Clicking the button will post the workaround in all related incidents and change their status to Workaround Provided, which will also trigger an email to both the end user and the assigned staff person of the Incident(s).
A similar button is used to transfer the problem Solution to related Incidents. Clicking the "Update Incidents with Solution" button in the problem will populate the Solution field of the Problem into the Incident Solution field and set the status of the Incident to Closed, emailing the customer.
When the problem is resolved either directly, or through a change request, all related incidents can be closed at once. On the Related Records tab, the button Update Incidents with Solution can be used to push the Resolution field of the problem into the Resolution field of the linked incidents, closing the incident and triggering an email to the customer with the resolution.
Once the Once a permanent resolution is determined and implemented, staff users enter the description in the Resolution field and set the status to Resolved. If A Closure Category for the resolution contains information that is useful outside of this problem's particular scope, the "Add to Knowledgebase?" field can be set to Yes to make the Resolution field available via FAQs.
...
of the problem can be selected. In addition, a required Review for Knowledgebase field is displayed when closing, and if set to Yes, a knowledge article can be created from the problem for review to be added to the Knowledge Articles table.
| Anchor | ||||
|---|---|---|---|---|
|
It is important to learn from problems to reduce the likelihood of repeat issues. There are two fields intended to facilitate analysis after a major problem.
- Include in Major Problem Review: this is a required field.
- Major Problem Review notes: this is used to write up notes about what was done well in the crisis, what didn't work so well, and what could be done to prevent such a crisis in the future. This field is only visible if the Include in Major Problem Review field has a Yes value.
| Anchor | ||||
|---|---|---|---|---|
|
Problems can be marked as known errors by setting the Known Error field to a Yes value. All known errors can be easily viewed by support technicians using the Known Errors saved search. Additional saved searches for Known Errors Unresolved and Resolved Known Errors show problem records that are still unaddressed, and those that have been resolved, respectively.
For known errors that should be visible to end users, we recommend that they are pushed into a knowledgebase article, which can be done directly from the problem record.
Ownership
Problems are owned Problems are "owned" by the staff member who creates the Problem problem record. Since only internal technical staff will generally see Problem problem records, groups may share responsibilities between Incident Management and Problem Management and multiple individuals may share ownership over timebe given responsibility for a problem without actually owning it.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
This section contains an overview and screenshot examples of the information stored in a Problem record in the out-of-the-box system. The common area is shown in all tabs, and shows the progress of the problem, such as its Status, its Team Assignment, as well as the Assigned Person or owner of the problem record.
Details tab
...
The Details tab contains most of the information and updates pertaining to the problem, including the Submitter, Submitter Department and Contact Information, Source of the problem (how it was reported), the Location of the problem, the Business Service and Service impacted by the problem, as well as the Impact, Urgency, and resulting Priority of the Problem. If a CI has been identified, it can also be selected here.
Work Status Tab
All Diagnosis details can be logged here along with the Risk and Root Cause analysis, and any additional working diagnosis notes with time stamps. The Resolution Details section in this tab allows for the detailing of a Workaround for the problem, which can later be updated in the related incidents, or to pull an existing Resolution from the Known Error subset of problems. If the status is Resolved, a Closure Category can also be specified for the problem, and a determination must be made as to whether the problem should be included in a future Major Problem Review. The date the problem was resolved is then automatically logged in the History tab of the record to provide an audit trail.
| Anchor | ||||
|---|---|---|---|---|
|
The Time tab displays the SLA thresholds for the problem, including thresholds for the SLA Diagnosis Time, SLA Resolution Time, and the progress against those thresholds. Amount of time spent working on the problem can also be logged here.
| Anchor | ||||
|---|---|---|---|---|
|
The Related Records tab shows the list of incidents related to the problem. If a workaround or resolution has been provided, it can also be pushed from the problem record to all of its related incidents. The problem can also be linked to an existing change request, or can be used to create a new one, copying over all of the relevant information directly from the problem record to the change request. In addition, the Knowledge Management section of this tab also allows the problem to be directly integrated and converted into a record in the Knowledge Articles table with a status of Pending Review.
Anchor reporting_and_statistics reporting_and_statistics
Reporting and Statistics
| reporting_and_statistics | |
| reporting_and_statistics |
There are numerous default reports measuring different metrics for problems, and a few of the most relevant and frequently used are listed here as examples.
Known Error Trend Analysis
This is a Trend graph that shows the number of problems marked as Known Errors over the course of a pre-defined period of time (by default, this is since the beginning of the current year).
| Anchor | ||||
|---|---|---|---|---|
|
This is a Segmented Bar Chart that shows the number of problems that were reported for each CI type, segmented by the name of the Configuration Item.
| Anchor | ||||
|---|---|---|---|---|
|
This report shows the major problems by month over the past year. Additional details are in the HTML portion of the report.
...
...
Please see Problem Fields in the Appendix