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.

Customer Satisfaction Survey Grading

What grades do you use in customer satisfaction surveys? How are grades influenced by the culture of the country? What to do if you perform surveys in different countries with different background?

I have been discussing customer satisfaction here a few times. Related to that, let me share a brief anecdote with you:

We implemented a new Service Desk SW on a customer's site. They are a managed services company providing support all over the world, 24x7. After the resolution of every ticket, contact person on a ticket receives a mail notification with a link to a short web-based survey.

There were just a few questions regarding speed of resolution, communication, competence of support people and overall satisfaction with the ticket resolution.

Grades were 1-5, with the above explanation that 1=poor and 5=excellent.

We received quite a bunch of survey results at the beginning, which was the intention. Here and there, a low score was received, but we were not alarmed, you can't please everyone. Service Manager was in charge to treat all grades below 3 as a customer complaint and to follow up with customers to raise their satisfaction.

Then one day we received two very bad results, averaging below 2. Both from the same market. Alert! We are doing something wrong.

So Service Manager sent apologetic mail with a inquiry what went wrong and how can we improve, blah...
The answer came quickly, from both customers, saying they are sorry, but they thought 1 is better and 5 is poor.

Was something wrong with the survey code? Customers sent us their screenshots, everything is fine, the explanation at the form header clearly stated "1=poor and 5=excellent". Both customers were from Germany. On a request to explain how they misunderstood this clear instruction, they said: "German school grading system is 1 to 5, a one being the best grade (Sehr gut), and five the worst - insufficient (Nicht genügend)". So they didn't bother looking at explanations, they automatically presumed that this survey from another country complies to their long-term grading experience in German scholar system. Can't blame them.

Therefore we looked arround, what are grading standards in school systems around the world?

USA and influenced states use ABCDEF grades. Europe differs very much depending on history, somewhere 1 is bad, under the German skirt it is excellent (Chezh republic and Slovakia also).
Eastern European countries, Asia and Oceania use either Russian 1-5 system or percentage system 0-100%.

Interesting details:

• Venezuela uses rather exotic 0-20 grading system
• Ecuador and Serbia (opposite hemispheres) use similar 5-10 grading systems where 5=fail and 10=excellent.
• A lot of countries use different grading systems for primary, high school and university grades.

So what approach to take in grading customer satisfaction in order to make it intuitive regardless of their local education background?

 

We had only two solutions:

• Go to using 1, 2, 3, 4 grades, where customers won't be able to relate to their finer graded school system. 1-4 is also good because it eliminates the indifferent middle grade, and it forces a customer to decide for better or worse 2 or 3.
• Take the -2, -1, 0, 1, 2 grading approach. Good: it is self-explanatory, negative numbers can't be good. Bad: it leads the customer to a mediocre "0" grade, suggesting that it is OK.

For now, we are using the second proposed grading system, accepting the downside that some customers see nothing bad in selecting a "0", which is a neutral grade.

An additional tweak would be to change grades to -1, 0, 1, 2, which would "push" a customer towards positive grades some more.

What metod do you think is most apropriate for you?


Related articles:

Customer Satisfaction 
How bad do we need it in IT Service Management? Where is it mentioned and where is it dealt with in ITIL V3? How do we manage it in real life?

Customer Satisfaction Survey: What Methods To Use?
How to gather customer satisfaction data? What methods are there? What ITIL says? What methods will work for you?

What is Password Reset: Service Request, Incident or Change?

I browsed through a few social networks lately discussing basic Service Support activities like password reset. Interesting to see how even experienced IT professionals have different points of view on elementary procedures like this one.

One of discussions goes on and on about what is a Password Reset procedure: is it a Service Request, Incident or Change?
We can take for granted that these portals consider the simplest case of Password Reset event: the user forgot hers/his password. In a consolidated service desk of 2000s this was the most frequent event, making 50-80% of all calls.

Is it an Incident?
So, could it be an Incident? Obviously NOT. Incident definition requires a service downtime or probability of downtime. No service downtime here, only end user can't log in, by his own fault.

Why then a plenty of Service organizations treat these events as Incidents? Because of the Service Desk TOOL they (miss)use. They have a nice little tool which is ITIL approved by some elephant. It can do all the process, you name it. But implementation of additional modules costs money and time. They already have Incident Management. Their implementer sucks, their ITSM consultant could do better, and they are often the same person. So they created a category "Password reset" in Incident Management module and they treat password reset as an incident. That's why it has to be an incident. If the only tool you have is a hammer, every problem is a nail. Let's move further.

Is it a Service Request?
Is password reset request a Service Request? Of course it is, there it is in the ITIL definition of a Service Request:

• A request from a User for information or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service requests are usually handled by a Service Desk, and do not require an RFC to be submitted.

So it's a small preapproved standard Change which is processed thru Request Fulfillment process.

Yes, it is a Change, but no need for Change Manager and CAB to get involved since it happens frequently and can be dealt with on the 1st level. And thank you God for technology you provided so that lately any end user password can be reset via a simple self-help portal. User just answers a secret question, puts in his employee ID and receives the new password via text message or such.

What other special flavors of password reset are there?

• Simple web application user passwords are a mild example of the above described case.
• Enterprise domain user password is closer to what first comes to our mind when we think about password reset. Now, we said it is a Service Request. In which cases it escalates to a Change Request? Well, if you have a strong security policy, implemented SOX or ISO/IEC 27001 and influential security officer, then it's possible that they require formalized approval cycle and implemented operational Standard Change procedure.
• VPN account passwords which enable user to connect from the outside of the company to internal network are a very sensitive security case, so all concerns regarding domain user accounts apply to them, and then some. A special case is a VPN account given to a 3rd party employee. Usually such a request has to have defined start and end of usage and approval from a high position (chief security, IT manager or CEO).
• Application Administrator account passwords enable the user to create a significant amount of damage to a company according to the importance of the application to the business. Examples: Intranet applications, CRM, ERP. Which one contains the most sensitive data for your company? Probably the ERP application.
• System Administrator Account presents the highest possible level of trust to an employee. Only security officer , Operations or IT Manager should approve these account creations and their password reset requests.
• Service Accounts under which different IT services are executed. These have to be taken care by the security officers, their catalogue has to point to services they enable (1:M relation) and access to their passwords has to be restricted only to most confidential people. Usually these accounts have broad authorization and they are set to rarely or never expire, so they should be maintained with utmost care, especially in organizations with frequent employee fluctuation. Best practice is to deposit them in a safe box by a single person.
   

Note: there are significant changes lately in best practices and recommendations with large vendors and consulting companies about the password lockout policy.
Until recently, the recommendation was to lock the user account after three to five unsuccessful attempts. What changed? Implementation of security standards and best practices introduced higher password complexity and more frequent user password changes. Majority of users have some kind of mobile device for connecting to an enterprise mail system. These devices cache user credentials and often lock-out user's accounts after password change. Virtualization also contributed to simplification of lockout policy since various user credentials can be cached on different physical and virtual machines.
Brute force attacks are measured in hundreds if not thousands of attempts in a short period of time, so it is now advised to lift the lockout attempt number to 60-100, or to turn the policy off completely and survey security logs with adequate tools.  

Let me just finish here in a nicer tone. ITIL is not too prescriptive in telling you how exactly to do things.
In the above example, if you process Service Requests as a special category Incidents, you are still in the green. Customers get their service, all needed reports can be generated as agreed, KPIs are there, you are good!

We are in business of keeping the customer business going. In the spirit of current holidays, I wish you the very best of luck with it. Because you are going to need it :)

For further reading I recommend 4.2 Incident Management, 4.3 Request Fulfilment and 4.5 Access Management chapters in ITIL Service Operation book.

Also, have a look at articles:

• Incident Management
• Change Management

ITIL Major Incident - All you want to know

What is a Major Incident in ITIL? What are the roles and responsibilities? How to avoid common mistakes? What to do After the Resolution?

Trust me, I know what I'm doing!
Sledge Hammer

What is a Major Incident?
Definition of a Major Incident has to be clear to every employee in Service Support. Therefore it has to be clearly described in a separate document, Major Incident Procedure.

What makes a Major Incident? It is usually defined by the impact outage has or could have on customer’s business process. Also, it may be determined by priority of the incident or by its urgency.

How come that the impact isn’t allways the only factor in defining the Major incident? For example, an incident of high impact can be resolved by Service Desk thru a simple resolution procedure, like switch resetting after network down event, or connecting a backup provider after internet down event.

Both examples are definitely high impact but we don’t have to recruit a bunch of higher level people on it just yet. We just have to have in mind that they are Priority 1 and they have to be resolved ASAP. In case they can’t be resolved by standard procedure, THEN they can be marked Major and handled with appropriate procedure and policy. That’s why most leading Incident Management tools on the market have a separate checkbox Major or Hot incident.

This was all theory. In practice, to simplify the procedure and make it easier to Service Desk staff, this is what I usually advise: all priority 1 incidents are Major Incidents, if they are not exceptions. Exceptions can be easily defined for particular customers, contracts and incident categories. For example: Major incidents are all Priority 1 incidents except cash register tickets, which are urgent but can be fixed by technicians, no need to involve for more important people. Or: all categories except end user incidents. Simple.

Major Incident Team

OK, now we have determined it’s a Major Incident. What next? We establish a Major Incident Team. Members are:

• Service Desk Manager – he will be responsible for communication with resolution team and timely reporting to the customer
• Incident Manager – in reasonable service organizations Incident Manager is usually also the Service Desk Manager. If not, then these two have to work closely together.
• Major Incident Manager: a frequent mistake is to promote Incident or Service Desk Manager into Major Incident Manager. This doesn’t have to, but can cause some serious conflicts of interests: he has to survive somewhere between Incident Management, Problem Management, Business Management and the customer.
  Major Incident Manager has to be a liaison between all internal parties involved, also acquainted well to technical aspects of the outage. So he will often be recruited between people formerly engaged in a project, or those involved in service catalogue definition.
• Problem Manager: remember him? He will be most helpful here in investigative phase, towards closure phase, and a life saver in post mortem reporting. Better keep him on our side. Mind you, Major Incident is still an incident, but usually has some underlying cause which will be recognized as a Problem. Hence Incident and Problem Manager have to work closely here, each with his own goal in mind (service restoration vs. underlying cause).
• Other members of Major Incident Team: representatives of all people involved, impacted users, competent technical staff, vendors... Good practice would be to choose people here the same way you would choose ECAB (Emergency Change Advisory Board) members. There is always a chance that you will be implementing an Emergency Change during a Major Incident resolution process.

Resolution Process

Major Incident resolution works on tight SLA parameters. Service Desk takes care of them. Also, ticket updates and frequent feedback to customers is performed by Service Desk. Remember, customer hates to be kept in the dark, even if news are bad (no progress) they must be updated frequently.

Major Incident Procedure has to define the escalation policy in case of SLA breech. Usually the incident is escalated vertically to higher level IT / Business management and to vendors of services/equipment underpinning the service.

After the battle

Upon the resolution, Incident Management Team stays “on call” and monitors the service for the period defined by Major Incident Manager. He also schedules a short team meeting for the next day.

Incident Review is performed on this meeting, points for improvement and lessons learned are defined and Post Mortem Major Incident Report is created.

Incident Manager sends the report to the customer.

I have prepared for you a template for Major Incident Report, free for download here.

Related posts:

Incident Management Elements
Key elements of Incident management.

Incident Management Mind Map
Download the incident management mind map.

All About Incident Classification

How to deal with incident categories.

What Everyone Should Know About Incident Priority

Incident prioritization in ITIL.

Hope this helps. Have a nice day!

Many Calls One Incident

Every time user calls in, we log it as the new incident. Or we update an existing incident.
What happens when one major business service goes down? Do we log every call from a different user as a new incident?
Are these just related incidents or there is only one incident? What are calls?

I have seen a few interesting discussions on the Net about the technology of Service Desk Incident logging.

Since I have some 18 years of IT Service Management experience in practice and in theory, and this is a matter I have a strong opinion about, I might say a few words about it.

INCIDENT MANAGEMENT PROCESS
Incident Management is the oldest and most chewed up process in all IT Service Management. Everyone does Incident Management. Maybe not Capacity Management or IT Financial Management, but Incident Management is in phase 1 of most ITSM/ITIL implementations. So it is the best defined and best known process. Everyone interested in ITSM knows everything about it. Right?

DEFINITIONS
What was the definition of an incident? Here are some:

• ITIL V2: 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.
   
• ITIL V3: An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet impacted service is also an incident, for example failure of one disk from a mirror set.
   
• MOF: Failure of a service or component to provide a feature it was designed to deliver.

Very nice. All bases covered. Very defined. For decades.

SCENARIOS
So consider a few scenarios:

• User cannot log in, she forgot her password. Service Desk creates a incident ticket and resolves it in a first call. Splendid.
   
• User has a problem with his PC. Service Desk assigns a technician on that incident . Technician visits the customer, resolves the incident and SD closes it.
   
• Print server goes down. No one in the headquarters can print. Imagine the legal department people. Sales girls and their Tenders & Invoices... Hell must be a nicer place to be. Phones are off the hook, percentage of unanswered calls goes up fast.

Imagine a mail server crash in a large enterprise. That must be a show. This is a very common case, happens every day in IT all over the world.

So then, is every new call from a panicking user a new incident? Or it is just one incident, and many end user calls (inquiries?). Read ITIL books V2 and V3 all you want and you won't find the answer.

V2 books are in favor of rule that every new call is an incident. OK maybe if the same contact person calls a second time, then it can (maybe) be logged in the same Incident record. But, another person, another Incident.

V3 broke Incident management into new Incident Management and Request Fulfillment with an eye on Event Management. So everything is not an incident any more, it can be an user request. Which doesn't help us here much. Every call about the incident is still an incident by our good ITIL books. And that's best practice. Sort of.

ITIL Service Management sure has some place for improvement here. What I feel sorry for is that authors of V3 strived to cover as much new territory they could (Knowledge Management? Strategy Generation?), creating more ambiguity and material which will need improvement, and flaws of the basic processes remain uncovered. Best practice system should cover such basic scenarios as above mentioned.

What happens in example above, if every call is an incident? All incidents are logged and categorized. A lot of them.

If a mail server went down, is it a new incident every time user notices he can't send mail? No, of course not. It's ONE incident, i.e. one interruption of the mail service. In a good Service Desk environment this incident will often be recorded before any user notices it. The amount of users impacted will only influence Priority of the incident, (remember, Impact X Urgency), not the number of incidents.

This is a nice question I have asked every ITIL trainer/consultant I've met, and I've always had fun.

HOW SHOULD IT BE DONE? 

So, how do you do it at home?

In my company, Service Desk has an Incident Management tool which enables us to log an Incident. All later calls from the same contact person (department) are logged as updates of that incident.

All later calls from new persons regarding that incident (mail server down!) are creating new tickets which are connected to that first incident. These related tickets are not considered incidents, we call them simply "tickets".

When the original incident is resolved, an original contact person for that incident is asked to confirm. Incident is then closed, and all associated tickets too. All contact persons from these tickets get a notification about the closure and are asked to reopen the incident if they feel their service is not yet restored.

Some tools on the market even have special entities, "Calls", which are linked to an initial Incident in a similar manner. Some other tools are at least able to interlink incidents so that when the original one is resolved, SD people can at resolve related incidents one by one, "on foot".

This scenario can repeat quite often in enterprise Incident Management, even in mid-sized managed service companies. So it would be nice if someone explained it to good ITIL best practices author.

NOTE

There is one potential catch with "One incident/Many tickets" method: if you treat various departments or business units of your company as different customers, i.e. you have a different SLA with Finance, Legal or Marketing, then you would want incidents and outages to show on their respective SLA reports. If your IM and reporting tools are not perfectly linked to the service Configuration Items in your CMDB or your Service Catalog item, you will probably want to create one incident for every contracted SLA.

This will also be the case if your contact defines a business unit associated with the incident, and the reporting tool regards incidents as service disruptions on associated business units. Here the value of a good Service Catalog/Portfolio comes to the fore.

Sometimes this vagueness is justified by “descriptive, non prescriptive” nature of ITIL. Well in my humble opinion, if something is called best practice, then it should describe the best practice of common events.

It would be very nice if this issue gets to be addressed in the next ITIL release, don't you agree?

Related posts:

Incident Management Elements
Key elements of Incident management.
http://itservicemngmt.blogspot.com/2007/05/i-will-go-through-main-elements-of-itsm.html

Incident Management Mind Map
Download the incident management mind map.
http://itservicemngmt.blogspot.com/2007/05/incident-management-mind-map.html

All About Incident Classification

How to deal with incident categories.

http://itservicemngmt.blogspot.com/2007/05/all-about-incident-classification.html

 

What Everyone Should Know About Incident Priority

Incident prioritization in ITIL.

http://itservicemngmt.blogspot.com/2007/06/incident-priority-what-everyone-should.html

  

Configuration Management Basics

Mission
To identify, record and report on configuration items and their relationships that underpin IT services.

Goals

• To account for all IT assets, configurations and services within organization
• To provide accurate information and documentation on configurations and assets to other SM processes
• To provide a sound basis for Incident, Problem, Change and Release management
• To verify configuration record and correct exceptions

Configuration Management Mind Map

Definitions
Configuration Management: The process of identifying and defining Configuration Items in a system, recording and reporting the status of Configuration Items and Requests for Change, and verifying the completeness and correctness of Configuration Items.
CMDB - Configuration Management Database: database which contains details about the attributes and the history of each CI and details of the important relationships between CIs.
CI - Configuration Item: basic CMDB element. Component of an infrastructure that is under the control of Configuration Management. CIs may vary widely in complexity, size and type, from an entire system (including all hardware, software and documentation) to a single module or a minor hardware component.
DSL - Definitive Software Library: a physical library or storage repository which contains authorized master copies of software versions. May consist of one or more physical software libraries or filestores, and can include physical store to hold master copies of purchased software, disaster safe.
DHS - Definitive Hardware Store: secure storage of definitive hardware spare components and assemblies. Details of these components and their builds and contents should reside in CMDB. DHS items can be used on demand for additional systems or in the recovery from major Incidents.

Objectives

• To provide accurate configuration information
• To define and document processes and procedures
• To identify, label and record CI
• To control and store authorized specifications documentation and software
• To report on status and history of CIs
• To record changes to CI in a timely way
• To audit physical items and reconcile any differences between them and the CMDB
• To educate and train in control processes
• To produce metrics on CI, changes and releases
• To audit and report and exceptions to standards and procedures

Process

• Planning
• Identification
• Control
• Status accounting
• Verification and auditing

Benefits

• Accurate information on CIs and their documentation
• Controlling valuable CIs
• Adherence to legal obligations
• Financial and expenditure planning
• Making software Changes visible
• Contributing to contingency planning
• Supporting and improving Release Management
• Improving security by controlling the versions of CIs in use
• Enabling the organisation to reduce the use of unauthorised software
• Allowing the organisation to perform impact analysis and schedule Changes safely, efficiently and effectively
• Providing Problem Management with data on trends
  

Possible Problems

• Wrong CI detail level
• Adequate initial analysis and design
• Configuration Management implemented in isolation
• Lack of commitment to maintaining accuracy

Critical Success Factors

• Managing Configuration Item information
• Providing capability to perform risk analysis of changes and releases

Key Performance Indicators
Managing CI Information

• Number of CIs logged and tracked
• Number of CIs with attribute failures
• Number of changes to CI attributes
• Number of additional CIs
• Number of deletions of CIs
• Number and frequency of exceptions in configuration audits

Providing Capability To Perform Risk Analysis Of Changes and Releases

• Number of incidents caused by inaccurate configuration data
• Percentage of Services tracked with CIs versus known products and services

Incident Priority - What Everyone Should Know

As ITIL defines it, Incident priority is primarily formed out of it's Impact and Urgency. There are also additional elements, like size, scope, complexity and resources required for resolution.

So, most consultants recommend the simple matrix which will automatically calculate incident priority out of the simple value of Impact x Urgency.

Recommended granulation of Priority is 4 to 5 different values.
Usually the lower the value - the higher the Priority, thus Priority=1 is the highest one, and Priority=5 the lowest.
There are also some sophisticated methods for defining Priority, but eventually it all boils down to something like:


Picture: Standard Priority Matrix

Impact of the incident is the measure of how business critical it is. Since this is difficult to determine in shoes of overworked and underpaid 1st level operator, some simplifications are necessary here. So impact is usually directly proportional to a number of users influenced by the incident. If an up-to date CMDB is available, then it's easy to determine affected users from the Business Service which suffers from specific Configuration Item malfunction.

Urgency is a necessary speed of resolving an incident. Some incident management tools perform automatic calculations for Urgency based on Impact, SLA and OLA involved etc. Nice feature if you have it. If not, a simple workaround would be to educate Service Desk operators on a regular basis and to inform them on parameters of signed contracts. Incident Urgency for certain Services may vary in time (example: HR application during payroll calculation) and this additional complexity is easier to resolve by raising staff awareness level then to implement it in software tools.

Major Incident is an incident with extreme impact to business, or an excessive disruption of service. It will have Priority=1, and additionally, depending on your SLA and support process definition, it usually has additional attribute (checkbox is fine) that says this is a Major or Hot incident. All key Support Staff members attend to resolution of major incidents, and the project is strongly supported by Problem Management.

Also, should be said here that Incidents do not age gracefully. Data on that reside in the escalation schemes, based on Service Level Agreement (SLA) targets. If an incident owner can't deal with that, his manager has to be notified in time.



Update: Incident Escalation

Just a few words on Incident escalations. Escalations are mechanisms that help us to resolve incidents on time. There are two major types:

Functional Escalation - reassigning incidents to a higher tier support group due to lack of expertise. Also, this can happen after a predefined time interval passes, in accordance with SLA.


Picture: Functional Escalation


Hierarchical Escalation - when a support employee can't deal with an incident, either due to lack of knowledge or insufficient time, his manager has to be informed in order to preserve SLA targets and customer satisfaction. In practice, this escalation type usually boils down to a simple notification to the manager.


Picture: Hierarchical Escalation

All About Incident Classification

Incident classification is among the main tasks of Service Desk 1st tier people. It adds structured data to a basically hectic unstructured series of info we get from a nervous Customer.

Aside from prioritisation, which is another important issue, there are three main reasons for classification of incidents:

• Assignment and escalation
• Problem analysis
• Reporting

First reason gives us a hint why a Customer shouldn't categorize an incident. He is not trained for that, he reports his problem (over the phone, web, mail...) and it is an Operators task to assign the incident to a proper category.

Reporting is important because it provides inputs to other ITSM processes (Problem, Change...) and helps us stay in good relations with the Customer and the Management.

Therefore, the Incident Management tool should allow assigned people to re-classify the incident (change it's category) along the escalation path. Because sometimes the problem shows to be somewhere else. I.e. it's not the printer but the network. Some of the top Incident Management tools I know are very rigid regarding this and I know some Service Desks which used to close existing incident and open another one with a proper classification in this case. Sad.

Activities

Now, what are the best practices telling us, how do we assign categories to incidents? ITIL does not prescribe a hard coded form of classification. Usually the chosen IM tool will guide us, no matter how much is it advertised as fully customizable to adapt to your business process. So one should have this on the list of important factors during a tool selection process.

Here are a few things we should do:

• First, everyone has a legacy incident database. Being new to ITIL IM doesn't mean that you didn't resolve tickets, incidents or issues before. Take a look at the structure of legacy data, and discuss what is useful for your business process, what hierarchy should you prefer, and what's missing.
• Consider the management and customer reporting needs, this should give you some ideas.
• Business should understand your categories, although they are usually technical.
• Key Performance Indicator list - should define what is important.
• Review your process definitions and your main competency matrix. Are you technology or business oriented? Try to define your category tree based on that. See your legacy incidents, try to assign defined categories to them and analyse. Is it any good?
• Your Services Catalog and your SLAs should tell you a lot. Even if you don't have them, you probably know what are the major business critical services: mail, printing, document management, accounting. The longer the list, the more probable that you'll want to put these in the root of the category tree.
• Talk to your Problem Management people, they should know a lot.
• Brainstorm a lot.
• Start an Incident Management Pilot project for a month, and use your classification system. Analyze. See what's right and what can be better. Redefine if necessary. It's better to try and err then not to try at all until major production.

Possible Problems

• 1st line Operator education
• Customer portals sometimes offer a classification tool to a customer during Incident reporting. If this is done, this should be on a very basic level, and always checked and redefined by a 1st level operator.
• Depending on business process definition and classification scheme, it will be difficult for a 1st level operator to differ between Incidents, RFCs and Service Requests.

Examples

Now, how does this look in practice? As I mentioned, a tool can influence your decision a lot. Peregrine Service Center gives you a structure:
Category:Subcategory:ProductType:ProblemType
It's a nice four-tiered schema.

Remedy gives you
Category:Type:Item
A three-tiered schema, very good technical schema.

HP OpenView Service Desk provides two categories in combination with type and service.
It's fair to mention that the above tools and most of the others allow some amount of customization, adding or removing categories, and dynamically requesting different depth of classification based on type or main category. So whatever tool you choose, there is a chance that you will be able to adapt it fairly to your process. It's just that some of them will require more time/money and customized solutions can create problems on upgrades to following versions.

Now, examples? Some standard three tiered schema examples:

• Software:Server:Exchange (Technical classification according to your org. chart - Department:Team:Assignment)
• Server:Software:Exchange (Technical classification By CI categorization)
• Printing:Printer:Cannot Print (Service oriented - Service:Component:Problem)
• E-mail:Outlook:Access (Service oriented)

Depending on business requests and technology, some creativity is allowed here. For one of my customers we created the following: they had in-house developed IM tool, and some specific needs, so we created a category tree of unrestricted depth, with technology-oriented categories. Every node (category) has its own assigned Queue and escalation schema. Their expertise level varied with technology so some tickets had category field like:

Network:Switch

and some were:

Software:Server:OperatingSystem:Microsoft:Windows2k3

This system works for two years now, and they are a happy customer. They have a bit more complex reporting then usual, but also the classification that fits their business process.

Remember that along with categorization, Incidents carry a lot more of structured data (Priority, CI Info, SLA...), so in most cases a nice three-tiered categorization combined with these data will cover all your needs.

Of course, if there is a need for more, then a four-tiered possible classification would look like:

Software:Server:IBM:Domino
or:
Email:Server:Domino:JunkMail Filter (Service:Component:ProductType:ProblemType)

After all mentioned, one does understand that there is no easy formula. Sometimes the best way to understand things is to try and make mistakes. I hope that the above concerns will at least help you make less of them.

Incident Management Mind Map

I have process mind maps, and I am looking for a free tool to display them on the web. Until then, here is a JPG of Incident Management mind map.

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.

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.