Error Control overview

The Error Control objective is to effect permanent changes to Configuration Items (CIs) with known errors. Making permanent changes reduces the number of current and prospective incidents. Integrated Service Manager Error Control and Change Management processes enable you to track the entire workflow and update all affected records automatically.

Error Control activities

Service Manager has an appropriate action for each Error Control activity.

ITIL activity	ITIL workflow	Service Manager phases	Possible  Service Manager actions
Error Control	Error Assessment	Known Error Logging and Categorization	Click Problem Management > Error Control > Search Known Errors. For a known error record that is in the Known Error Logging and Categorization phase, you can elaborate the description of the underlying cause and possible workaround (if identified).
	Error Identification	Known Error Investigation	Click Problem Management > Error Control > Search Known Errors. For a known error record that is in the Known Error Investigation phase, you can define a temporary fix or permanent solution for the known error. Different solution alternatives can be evaluated until a definitive solution can be proposed to the Problem Manager.
	Error Resolution	Known Error Solution Acceptance	Click Problem Management > Error Control > Search Known Errors. For a known error record that is in the Known Error Solution Acceptance phase, you can create a Request for Change record. To do so, select the known error record, click More or the More Actions icon and choose Open Related Change.
	Close Error	Known Error Resolution	Click Problem Management > Error Control > Search Known Errors. You can select a known error record in the Known Error Resolution phase to record the resolution and close the known error.

Tracking and monitoring errors

The team that identified the root cause is not necessarily the team who will locate and apply the resolution. The first stage of Error Control is important for a smooth hand off of the error. The team that tracks the error keeps sources on the primary reporting matrix updated as necessary.

The steps in tracking and monitoring errors are:

• Obtain the error status.
• Reassess the error status.
• Update primary reporting matrix about the error status.
• Track any relevant data and ensure that the problem, known error, incident, and change records are all updated.

Service Manager posts updates to affected records automatically.

Phase 1: Logging

This phase is critical because it is where technical experts study the error to understand it and develop a solution.

Although a known error is the usual result of completing the last phase of Problem Control, an internal organization, such as Development or Customer Support can also identify known errors. For example, Development might notice a known error when performing current or new development activities such as upgrades, enhancements, or technology acquisitions. In this case, Development would Create a new problem record and verify the error during the Error assessment phase.

A permanent solution may require a change to the affected Configuration Item (CI). If this is the case, the error assessment team can open a Request for Change (RFC). Service Manager enables you to open an RFC from the known error record. It also updates all affected records automatically.

Known errors

Known errors are related records that link to the parent problem record, or to change records that also relate to the parent problem record. Problem records reside in the rootcause table; known error records reside in the knownerror and rootcause tables.

Creating a known error record has certain restrictions:

• To open a known error from a problem record, a Problem Management administrator must enable the option in both the phase record and the user profile record.
• You cannot open a task record from a known error record.
• The problem record must be in the Investigation phase if you follow the out-of-box ITIL workflow.
• If you open a known error record from a problem record, Problem Management copies the Description field from the problem record.

Error identification

The first phase of Error Control captures all information about the known error. A known error is the usual result of completing the last phase of problem Control.

An internal organization, such as Development or Customer Support may identify known errors, but the primary record must be the problem record, which becomes the parent of the known error record. For example, Development might notice a known error when performing current or new development activities such as upgrades, enhancements, or technology acquisitions. The first step is to open the problem record, then step through the problem Control phases before opening an associated known error record. The known error is verified during the Error identification phase.

When a known error evolves from problem Control phases, the known error has an identified root cause and a workaround, or an explanation of why root cause and workaround information does not apply.

Change requests

Error control often initiates a Request for Change (RFC) to implement a solution. The solution may require a technical change, revised process, training, or other organizational change. When you create an RFC, it becomes the responsibility of change Management. The priority of the RFC depends on the impact of the problem on business activities.

As long as Known error resolution is pending, the status of the RFC must be reported back to Problem Management and recorded in the known error record. The known error cannot close until the RFC closes.

Phase 2: Closure

Closing the record is the last Error Control activity and the last Problem Management activity. Do not close the record until you ensure that the error is resolved, and the Problem Management process functioned correctly.

You cannot close a known error record if there are any related Request for Change (RFC) records open.

Error resolution

The input to Error resolution is from the Error assessment phase, which produces a solution. This phase applies the solution to the known error through a Request for Change (RFC), submitted to change Management. The Change Management process applies the solution to the Configuration Item (CI) to eliminate the known error.

You must verify that the Request for Change (RFC) is complete, removes the error in the infrastructure, and does not introduce a new error before you can close the known error record.

When does a known error close?

Closing the known error record depends on these conditions:

• All related Request for Change (RFC) records must be closed.
• The Known Error Details section must have information about a Solution, Root Cause, and Workaround before you can close the known error record.
• The record must be in the Error Closure phase.