ISO 20000 Resolution processes documentation

Incident and Problem management, being the most matured processes in service management should be easy to define in ISO20k. But where do we put documents and records? What do we have to pay attention to?

And here comes the infamous resolution process group. How to deal with these documents and records?

Incident and service request management
Procedure: As we know, in Incident management there are three separate procedures. If you are a small service support organization, all three of them can be in one document, as separate chapters.

Policy is not required, but, as I said, we like to keep the standard form for all processes. Policy, again, can be a separate document or a part of above mentioned procedure document, preferably in the beginning. Your documents will sit in a Resolution process group folder on your file share, document management system or a service management wiki.

Records: You probably have some kind of a ticketing app, or a full Service Desk application. Your Incident and Service request records will reside there.
Same as before, you have to agree with the customers about some details, AND don't forget to keep these agreements in electronic or paper form. Your auditor will probably want to see them.



Resolution process group in ISO/IEC 20000

Problem management
Procedure: As we know, the Problem management process can be fairly simple until you start to write it down. Please, try to have fun with this one as we did :)
Policy: same as above.

Records: Problem records, known errors, fixes and even reviews can be kept in your Service Desk application, or at least they can be linked to a document repository where they are saved in MS Word, PDF or other form.
Reports about process effectiveness will be kept in your document repository or maybe somewhere where you maintain your meeting minutes documents.

Problem Management Facts

Problem Management process can be roughly defined by a definition of Problem:

• Problem is the unknown cause of one or more incidents, often identified as a result of multiple similar incidents. It will become a Known Error when the Root Cause is known and a temporary Workaround or a Permanent Fix has been identified.
• Problem Control scope is transforming Problems into Known Errors.
• Error Control deals with resolving Known Errors via the Change Management process.
  

Goal
To minimize the adverse impact of Incidents and Problems on the business that are caused by errors within the IT Infrastructure, and to proactively prevent recurrence of related Incidents, Problems and errors.

Problem Management Mind Map

Inputs

• Incident details
• CMDB details
• Incident Management workarounds

Activities
a. Problem control

• Problem identification and recording
• Problem classification
• Problem investigation and diagnosis

b. Error control

• Error identification and recording
• Error Assessment
• Recording error resolution
• Error closure
• Monitoring resolution progress

c. Major Incident resolution assistance
d. Proactive PM

• Trend Analysis
• Targeting Support Action
• Providing info to organization

e. Obtaining management information
f. Completing major Problem reviews
Have in mind: Function of Problem control is to transform problems into Known Errors. Error Control resolves Known Errors thru Change Management.

Incident Matching

Outputs

• Known errors
• RFCs
• Updated and Closed problems
• Updates to Incidents
• Management Information
  

Benefits

• Improved IT services
• Reduced number of avoidable incidents
• Reduced impact on service availability
• Quicker recovery
• Permanent solutions
• Improved organizational learning
• Improved customer productivity
• Learn from past experiences
• Good reputation for IT department
• Greater control of IT services trough management information
• Improved first-call fix rate

Possible Problems

• Lack of management and staff commitment
• Ineffective Incident Management Process
• No reliable historical data for trend analysis
• Limited integration – incidents, problems, errors
• Limited integration with development
• Insufficient time for proactive work
• Bypassing the service desk
• Inability to build effective knowledge base
• Inaccurate assessment of business impact
• Cultural difficulties

Critical Success Factors

• Avoiding Repeated Incidents
• Minimizing Impact Of Problems

Key Performance Indicators
a. Avoiding Repeated Incidents

• Number of repeat incidents
• Number of existing Problems
• Number of existing Known Errors
  

b. Minimizing Impact Of Problems

• Average time for diagnosis of Problems
• Average time for resolution of Known Errors
• Number of open Problems
• Number of open Known Errors
• Number of repeat Problems
• Number of Major Incident/Problem reviews

Differences Between Incident and Problem Management
There is a potential conflict of interests between these two:
Incident Management wants to restore the service to operative state ASAP, while Problem Management focus is to discover unknown underlying cause of multiple incidents, and to resolve/prevent it, using top of the crop IT people. Obviously this can often lead to some disagreements between Incident and Problem Manager.

Implementation
Since Problem Management depends heavily on good Incident Management, generally accepted recommendation is to implement Problem Management in parallel or immediately after Incident Management. I strongly disagree here.

Problem Management is one of the most difficult Service Support processes to sell to the Management, it involves expensive resources with vague results, and Management is usually reluctant to buy it. If this is the case, Incident Management should be implemented and left alone for some time to gather critical mass of information which can later be used to justify the introduction of Problem Management.

Also, it is known that that some 20% of problems cause 80% of incidents, so develop Problem Management business processes with this fact in mind.

As for the IT tools for Problem Management support, have no worries: this is the easiest process to automate. Three to four forms and a very simple workflow, this process is more about the people and underlying technology, less about process automation. So probably any good ole tool will satisfy your needs, if it has Problem Management module. Focus on other processes automation.