Free Downloads

MindMaps:
ISO 20000: 2011
and
ITIL 2011 MMap
 

Templates:
Request for Change (RFC) Template

Major Incident Report Template

Posters:
ISO 20000/ITIL Timeline poster

    

Sponsored Links

 

Google

Jun 4, 2007

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 MindMap Picture
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.
ITIL Problem Management Process
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.

No comments: