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

May 24, 2007

Incident Management Elements

I will go through main elements of ITSM processes and give my comments as they come. I am going through my ITIL Quick Reference card I made in Excel, preparing for ITIL Service Manager exam. Have been thinking lately to put it on this site for download, please comment if you would like that.
Incident Management is usually the first ITIL process implemented in Support organizations.

ITIL Incident Definition: "any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service"

So, Incident is not a Problem, nor a Change Request. And not every Service Call is an incident. Seems very logical, but a lot of business organizations in practice tend to forget this from time to time. Example: a mail server is down. Service Desk receives X phone calls. Is every call an incident, or there is only one incident and all the rest are connected service calls? According to the above definition, there is only one event that interrupted the service, and therefore only one incident. Still, a lot of Incident Managers and ITIL theoretics count them all as incidents.

Goal
To restore normal service operation as quickly as possible and minimize the adverse impact on business operations.
No comment on this one, obviously. Reactive business is this IM.

Roles

  • Incident Manager
    This guy is usually a Service Desk manager. No conflicts of interests here. He is a slave driver of the first and second line staff.
  • First, second & third line support staff
    Although mentioned in the same sentence, these people differ a lot. First are the least respected people in IT, and the last, 3rd line are usually holly cows.
Incident Management process diagram
Picture: Incident Management process



Inputs
  • Incident details sourced from Service Desk, networks or computer operations
  • Configuration details from CMDB
    What assets are involved, where are they, who is responsible for them and who uses them?
  • Response from Incident matching against Problems and Known Errors
    Are similar problems detected in Problem Management? If yes, then can we offer a Workaround or a Fix to the Customer?
  • Resolution details
    Response on RFC to effect resolution for Incidents If a Request for Change was initiated from an Incident, then the latter usually waits in "Pending RFC" status until a Change is implemented. Then you notify your Customer and resolve an incident.
Activities
  • Incident detection and recording
    One of the primary jobs of IM staff.
  • Classification and initial support
    First and most important task of 1st line support is to put a name on an Incident, i.e. categorize it properly. This will not only please the Management, but also will enable an escalation procedure to assign it to an adequate Queue or Assignment group, in case that it can't be solved in a first call.
  • Investigation and diagnosis
    This one is logical.
  • Resolution and recovery
    An incident can be resolved and "the service restored to it's standard operation mode".
  • Incident closure
    A VERY good ITIL recommendation is this two-step incident closure. After the resolution, Customer is notified, and only upon his confirmation, an incident is CLOSED. This is good for both, a customer and IM people. Think why.
  • Incident ownership, monitoring, tracking and communication
    Wherever the incident is escalated, there is a person in IM that owns it and takes care of it. Incidents do not go to a fade-out.
Outputs
  • RFC for Incident resolution
    We said that an incident can initiate a RFC
  • Updated Incident record (incl. resolution and/or Work-arounds)
    Obviously.
  • Resolved and closed Incidents
    The main motive.
  • Communication to Customers Management information (reports)
    "This is what we did for you". Very important way of improving IM visibility.
Benefits
For the business as a whole:
  • Reduced business impact of Incidents by timely resolution, thereby increasing effectiveness
  • The proactive identification of beneficial system enhancements and amendments
  • The availability of business-focused management information related to the SLA
For the IT organization:
  • Improved monitoring, allowing performance against SLAs to be accurately measured
  • Improved management information on aspects of service quality
  • Better staff utilization, leading to greater efficiency
  • Elimination of lost or incorrect Incidents and service requests
  • More accurate CMDB information (giving an ongoing audit while registering Incidents)
  • Improved User and Customer satisfaction
No need to comment the above bullets, since they are pretty logical. I will remind you again here that the focus is here on the customer satisfaction. It is ridiculously easy to forget this one during you day-to-day work. And the only really important measure of the quality of Service Support is what customer thinks about it. And his management, of course ;-)
Critical Success Factors
  • Up-to-date CMDB
    I have seen implementations of Incident Management without a real CMDB, even without a simple Inventory database. *sigh* Please, do not do that. Firefighting is probably your greatest pain during the implementation phase of IM and it's easy to fall to a temptation of Quick'n'Dirty methodology and implement CMDB-less IM. CMDB is a base function for all ITSM activities and if you neglect this fact, you will suffer. If you are in a great hurry, at least implement a simple Inventory tool with some automatic discovery options, so you have something to build on later. It is OK to have up-to date CMDB on at least 70% of your CIs in the beginning.
  • Knowledge Base
    This is an interesting one. Knowledge was a major hype in '90s. A number of methodologies and semi-religions were built around Knowledge Management, and some of them persisted due to lack of better methods for managing collective knowledge. In practice, most IM people access the needed knowledge on the net, on vendor-specific databases or in old incidents. So, when you decide for a IM tool, do not fall for an usual marketing Knowledge Management mumbo-jumbo. Put yourself in your SD Staff shoes and think how would you resolve various incidents. There are tools that handle knowledge better, with simple workflows and that integrate easily with vendor's knowledge bases. Implement these or none at all, doesn't matter much in the beginning.
  • Automated Incident Management system
    Tools? A lot of them out there. Hope that I will have time to review major ones here.
  • Close link to SLM for SLA targets
    Yess! Have in mind what you agreed with customers, and make all the people aware of the Service Level Agreements targets.
Key Performance Indicators
  • Numbers of Incidents
  • Mean time to resolution
  • Percentage within agreed response time
  • Average cost per Incident
  • Percentage closed by Service Desk
  • Incidents per SD workstation
  • Percentage resolved without a visit
These are the main Management reporting parameters. First reports you print will have these bullets on them.
A lot has been said on Incident Management, a lot of good stuff can be found on the net, and a lot of discussions on newsgroups. Keep Googling, and if I get the time, I will review a few sites and share my thoughts and links with you these days.

7 comments:

Anonymous said...

Dear Doctor,

You have done an astonishing job on this blog site.

It is better than any standards from the training I attended.

You have not just concentrated on what-is ahd how-to etc on processes...but this blog has made so easy to remember those what-is and how-to's.

As a value addition if you can post the excel sheet of your exam preparation chart it would be further helpful.

Thanks a ton for you.

Regards,

a Service Manager aspirant.

doctor said...

Dear friend,

Glad you liked it, and I will publish my PDF quick reference cards for you people as soon as I can.

Thanks for your kind comment.

Abdul Rehman said...

I agree that it indeed is a great help from the blog owner to the rest of the interested people learning ITIL.

I composed a corresponding Mindmap for Incident Management that can be downloaded from
http://www.esnips.com/doc/80f9859a-ef87-4a5e-81d2-dae6a6762a1e/Incident-Management-Mindmap

Senor Flippy Flop said...

This site has been a tremendous help to me with understanding ITIL.

thanks so much!

Anonymous said...

Great read! You may want to follow up to this topic!!!

Waldo

Anonymous said...

I needed to thanks for this great learn!! I definitely having fun with each little bit of it I've you bookmarked to take a look at new stuff you post

sam said...

your blogs help me more in understanding ITIL framework

thanks so much!