Problem Management is used to minimise the adverse impact of Incidents and Problems and to prevent recurrence by ticket handling and root cause determination.
Click the links below to learn more information:
- Incident – Problem Integration
- Operation – From the Incident
- Operation – From the Dashboard
- Linking Incidents and Problems
- Closing Incidents from Problem
- Status Codes for Problem Management
- Problem Management Maintenance
Incident – Problem Integration
It is easy to raise linked Problems from the Incident, raise new Linked Incidents from the Problem and search the Known Error Data Base. The graphic below shows the various options:
Operation – From the Incident
The Incident call logging screen includes two new options that simplify the Incident – Problem relationship:
a) Raise New Linked Problem
If the incident being logged is indicative of an underlying Problem, it is very easy to create a new Problem directly from the Incident.
Types and Sub-Type categories should be shared between the Incident and Problem Folders to allow more meaningful relationships between the two and more effective searching of the Known Error Database.
The Problem Screen is shown below with data carried over from the Incident:
As well as the categorisation from the Incident, users have the option to specify a generic Problem Type that can be used for high level reporting. The Problem can also be given an Impact and Urgency which will drive a Priority value. By raising the Problem from the Incident, the relationship between the two is automatically established and evident on both the Incident and Problem screens.
b) Search the Known Error Database
This is an option from the Incident screen that allows Users to interrogate the Known Error Database (KEDB).
The KEDB consists of Tickets in the Problem folder that have been flagged as “Known Problems”. The flag may be set on any problem irrespective of status, the main criteria being that the problem has a recorded workaround/Solution and is still valid.
When the button “Search the Known Error DB” is clicked on the Incident the user is presented with a set of search criteria. Some of which may have already been completed based on the current Incident.
There is some intelligence built into this as the system will carry out a pre-check of the KEDB for the Service and the Asset and if none are found then these search parameters are left blank.
Clicking OK executes the Search and shows all applicable entries in the KEDB.
If the KEDB entry is appropriate for the underlying Incident, the user can select the button “Copy KEDB Solution to Incident” which returns the user back to the Incident with the Solution in place and also links the Tickets.
Operation – From the Dashboard
There is a new Button that can be dropped onto the Dashboard and allows a search to be carried out on the Known Error Database.
The first screen that is presented is the generic search selection that allows multiple search criteria to be selected. In the example below the user has simply selected to search for entries in the KEDB which have the “Accounts” service.
Activating the search shows those problems that match the criteria.
And upon opening the selected Problem the user now has a new option “Raise New Linked Incident”
This allows a new Linked Incident to be raised with the data from the Problem carried over and the Problem and Incident automatically linked.
Manual linking of Incidents and Problems
Along the top menu there is an option called “Link”.
Closing Linked Incidents from the Problem
The integration between Incidents and Problems allows the automatic closure of Incidents that are linked to a Problem, when that problem is Resolved or Closed.
The first part of the setup for this is to mark the Closed/Resolved Status codes used within the Problem Folder such that they automatically close child (linked) records.
Navigate to the Settings Cog > Service Level Management:
Click on the status you would like to setup and tick the Close Child Records checkbox in Actions:
When this is in place the action of selecting that status on the problem .
In this theoretical case a Workaround has been found for the Problem which can be moved to a status of “Problem Closed – No RFC” and the Workaround changed to a Solution.
Once this has been updated the linked Incidents are automatically closed and the solution set to that from the problem.
The actual “Closed” status that is set against the Incidents is defined on the Incident Folder settings.
Status Codes for Problem Management
There are a number of Status codes used to track the lifecycle of Problems.
The Status code workflow is shown below:
The three options for closing the Problem allows for detailed closure analysis with regards to the relationship between call closure and Changes.
Problem Management Maintenance
An explanation of the defaults fields available on the Problem Management Form.
- Service – May be selected from available Services or may be inherited from linked Incidents
- Asset – May be selected or inherited from linked Incidents. It may be more appropriate to set this specifically for the Problem Folder – in Folder Settings
- Type – May be selected from available Services or may be inherited from linked Incidents
To enforce a close relationship between Incidents and Problems the Type and Sub-Type list should be shared between the two folders (Service Level Management) - Sub-Type – May be selected from available Services or may be inherited from linked Incidents.
To enforce a close relationship between Incidents and Problems the Type and Sub-Type list should be shared between the two folders (Service Level Management) - Problem Type – An independent list that can be used for high level reporting over and above the Type – Sub-Type
- Impact/Urgency/Priority – Created in Service Level Management – a matrix of Impact and Urgency which drives a default Priority. The Priority in turn sets the target fix time
- Raised By – Set automatically as the logged user
- Group/Assignee – Can be defaulted at creation. A specific Problem Group can be created and assignees added to that Group using Resource Allocation
- Status – See Status Codes defined above
- Known Error – If the Problem has been investigated and a workaround or solution has been developed then the Problem can be flagged as a “Known Error”, in which case the Problem will be shown when searching the “Known Error Database”. If the workaround/solution becomes redundant or the Problem in general is no longer applicable then the Known error tick box should be unset
- #Linked Incidents – The number of linked Incidents to this Problem
- Cost – Field allowing a monetary cost to be set against the Problem
- Analysis – Offers 3 options – Awaiting Review, Review Complete, and No Review Required. This can be used to manage the Problem review process. This has multiple uses in that it may track Problems that are awaiting entry to the KEDB but require peer review first, or it may track a review process just for Major Problems
- Problem – A description of a Problem
- Workaround/Solution – Information as to how the Problem can be overcome
- Root Cause – Information about the Root Cause of the Problem if it can be determined
- Add to KnowledgeBase – A tick option that will add the details of the Problem to the Knowledgebase. There is a preset field mapping between Problem and Knowledgebase item
Still haven’t found what you’re looking for? Contact documentation@houseonthehill.com
