Branimir Valentic What I have witnessed many times is that SLAs (Service Level Agreements) define incident handling, including incident resolution time. That is OK until you face two opposing views – customers and service delivery, i.e., maintenance people (usually represented by the Service Level Manager). What happens is that once the incident occurs, IT resolves it and considers the SLA to be fulfilled. The customer has the same view until the same incident happens again. Then they start asking: “Why do you consider it resolved, but it happened again?” And, they have a point.
By resolving incidents – you (usually) haven’t resolved the root cause. That’s the job of Problem Management. The trouble is that the definition of problems is (usually) not defined in the scope of the SLA. If they were defined, then both the customer and the IT organization would benefit. The customer would be assured that the root cause of the (one or more) incidents will be found and eliminated, and the IT service provider would know that they had enough time to find the root cause. One important step in problem resolution is the Problem Record.
Problem and Problem Record – What are they?
A problem, according to ITIL as well as ISO 20000, is defined as a root cause of one or more incidents. It is the job of the Problem Management process to handle problems throughout their lifecycles. By “lifecycle,” I mean – from the time they are created until they are resolved (let’s stop with resolved, because if we consider continual improvement, then problem-related information would be used longer and much more widely).
In order to have all relevant information (about a particular problem, as well as history of resolved problems) needed to resolve the problem – a respective record must exist. That’s the Problem Record. Quite contrary to incidents (which must be resolved as quickly as possible), problems require significantly more time to be resolved. This also implies that many activities (e.g., analysis, trials and errors, various diagnostic activities, measurements, etc.) will be performed until you get to the point that you can say: “That’s the root cause of the incident.” All of those activities will be documented in the Problem Record. And that’s your knowledge. You can apply it later on while resolving some similar kinds of problems and/or incidents.
Read the articles ITIL and ISO 20000 Problem Management – Organizing for problem resolution and ITIL Problem Management: getting rid of problems to learn more about Problem Management.
Problem Record – The content
Most of you are familiar with incidents and incident records (or, as many people name it – an incident ticket). They are part of the daily activities in most IT organizations. The relationship – or, I should say, dependency – between an incident and the Problem Record is that the Problem Record contains a great deal of useful information (i.e., indices) that Problem Management needs to resolve the problem.
Problem Records are opened, as you can see in the previous paragraph, based on an incident. So are the Problem records. What tools usually offer is that, once you open an incident ticket, you get the possibility to create a problem ticket. And, all relevant information is copied from the incident ticket (e.g., requestor, configuration item affected, description, etc.). That makes life easier, and makes the information in the Problem Record more precise.
So, let’s see what usual the content of a Problem Record is. ISO 20000 is not very specific about the content, as opposed to ITIL (recommendations). So, the content of a Problem Record is:
- Requestor, i.e., affected user – most probably during analysis (and Problem Management does that very often), you’ll need more information from the affected user.
- Category – the recommendation is (and experience has proven) that problem categories are the same as incident categories (because problems are usually opened on the basis of an incident, so you don’t need to re-categorize).
- Description – in addition to copying all information from the incident ticket, include what was done to resolve related incidents (i.e., workaround), tests performed, technical solutions, related supplier activities (if present), etc. Meaning – include all data (could be technical in nature) which led to efficient problem resolution.
- Reference to related incident(s) – once you resolve a problem, incident(s) will be resolved as well. Tools can usually provide such automation.
- Log of activities performed – in this way, you have an overview of what was done related to the problem.
Read the article How to resolve the problem ticket/record according to ITIL/ISO 20000 to learn more.
How to apply it
First of all, as with many other items in the scope of your ITSM, application of the Problem Record depends on two items:
- If you are implementing ISO 20000 – then you have the requirement to implement the record and update the record (throughout the problem lifecycle). In the case of ITIL implementation, you’ll need to decide for yourself which details to record, and when to trigger Problem Management, i.e., create the Problem Record.
- Tool – if you are using an ITSM tool, and have the Problem Management process in the scope of the tool, then you already have default content (which is pre-defined in the tool). And, that’s usually based on ITIL recommendations, so most of your headaches are “cured.”
Incident Management (and the existence of incident records) is one of the prerequisites. Another one is Service Asset and Configuration Management (or Configuration Management in the case of ISO 20000), which will take care of the CMDB (a database with all your Configuration Items, or CIs). Information about affected CIs is the typical content of the Problem Record, and is necessary for analysis that leads to problem resolution.
Generally, no matter the Problem Record’s form (a tool, or a simpler form like a spreadsheet), it’s important to record as many details as possible. That’s your chance to learn and improve. IT Service Management (ITSM) inside the company does not only resolve IT service-related issues. It also ensures that ITSM gets better and better. Problem Records are an important element to achieve such improvement.
Click here to see a free preview of a Problem Record template to see what such a record looks like.
