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.

Service Desk Quick Facts

I will continue with a series of quick facts of ITSM disciplines here.
A Service Desk is a primary IT capability called for in ITSM as defined by the ITIL. It is intended to provide a Single Point of Contact (SPOC) to meet the communications needs of both Users and IT and to satisfy both Customer and IT Provider objectives.

Objectives

• Providing a SPOC for customers
• Facilitating the restoration of normal operational service with minimal business impact on the customer within agreed SLA levels and business priorities

It is also a focal point for reporting Incidents (disruptions or potential disruptions in service availability or quality) and for users making Service Requests (routine requests for services). The Service Desk handles incidents and service requests, as well as providing an interface to users for other ITSM activities such as:

• Incident Management
• Problem Management
• Change Management
• Configuration Management
• Change Management
• Release Management
• Service Level Management
• Availability Management
• Capacity Management
• Financial Management
• IT Service Continuity Management
• Security Management

Activities

• Receiving calls, first-line customer liaison
• Recording and tracking incidents and complaints
• Keeping customers informed on request status and progress
• Making an initial assessment of requests, attempting to resolve them or refer them to someone who can
• Monitoring and escalation procedures relative to the appropriate SLA Identifying problems
• Closing incidents and confirmation with the customers
• Coordinating second and third line support
• Highlighting Customer education & training needs

Critical success factors
To introduce and maintain a successful Service Desk, it is essential that:

• Business needs are understood
• Customer requirements are understood
• Investment is made in training for Customers, support teams and Service Desk staff
• Service objectives, goals and deliverables are clearly defined
• Service levels are practical, agreed, and regularly reviewed
• The benefits are accepted by the business
  

Benefits

• Improves customer perception and satisfaction
• A prime deliverer of Customer satisfaction with IT
• A Single point of contact allowing improved accessability
• Requests solved faster and better
• Improved teamwork and communication
• Facilitation of proactive approach
• Reduced business impact of failures
• Improved control and management of infrastructure
• IT resources beter utilised
• Increased business productivity
• Provides meaningful management information

Microsoft System Center Service Manager

OK, I wanted to cover some more basic stuff before I move to tools description. And I will definitely, later. But here I have a chance to lay out fresh info on a new player on the market, significant new product that will probably change the odds at the market. Pompous announcement, all right, but that's how I see it at the moment.
Later this month, Microsoft will go public with beta1 of System Center Service Manager. You've heard about Microsoft System Center probably, a new set of system management tools revolving mainly around Operations Manager (now Ops Manager 2007) and SMS (now Configuration Manager in Beta). Well, last year MS started the development of the product with a coded name Service Desk. The decision was logical, maturity of MOM and SMS as main system management tools just craved for a service management main tool. The idea was to give as much ITIL/MOF compliant functionality in the first version as possible, with the help of mature MS technologies like SQL server and SharePoint. Codename of the product was changed from Service Desk to Service Manager, probably because it encompasses more functions then standard ITIL Service Desk. The product will have a System Center look & feel, meaning that the operator console will be similar to Operations Manager 2007. On the left is a standard "Wunderbar" navigation panel with main modules and user adapted views on them. On a right side is a detailed functionality.

Picture: Operator Console Prototype

Basics of the product are on Service Modeling Language (SML), an xml-based language developed in cooperation of MS, HP, Cisco, IBM, Sun, Dell and a few other big names. On my opinion, a great effort and a great advantage since it serves to define heterogeneous IT infrastructure and services based on it. A great effort from MS, and congratulations to them. I am otherwise not a great fan of MS products, but here I really got excited.
Final functionality will cover the following features and their respectful consequences:

• Incident Management: out-of-the-box implementation of core ITIL functionality, reduced call handle time with instant access to related asset and system health information, user defined queues, SLA metrics, escalation policies, built-in performance dashboards and trending reports, single unified search engine, automatic incident creation and escalation from services monitored by Ops Manager 2007
  
• Self Service: a centralized interface for end users to get information (health of their services, relevant announcements from IT, status of their requests), reduced number of calls to the helpdesk by enabling end users to solve their own problems (search knowledge base, list of common issues, create service requests), reduce service requests by enabling end users to request software and OS deployments to their own assets (built on 'Change Management' and supports review, license count check, approval and scheduling workflows, users only see software they are allowed to request...)


• Asset Management: SML models of assets and their relationships, built in Connectors (SMS 2003, SCCM 2007, OpsMgr 2007, Active Directory), extendable by partners and customers, customizable level of CI tracking , manage the lifecycle of assets, actual up-to-dataset configuration
• Change Management: Out-of-the-box implementation of core ITIL functionality, standard RFC fields (links to affected CIs, reason, priority, impact, etc.), support all roles (initiators, reviewers, approvers, implementers), workflows for Minor, Standard, and Urgent RFCs, creation of RFCs by initiating directly from incidents or assets, filling of RFC information quickly using a template system for pre-defining common RFC data, automatically update the CMDB when RFCs are completed, measure performance and effectiveness through dashboards and reports

Service Manager's functionalities are based on Solution Packs, similar to Management Packs in OpsManager. OOB installation doesn't have operational modules in it - all you get is an empty console. You have to import Incident Management solution pack to get IM functionality, Change Management solution pack to get CM functionality, and so on. Meaning that everything is in a solution pack: forms, workflows, reports, portal features, views...You (and 3rd party vendors) can create your own solution packs that will contain all system customizations and special features. This is way too cool for me, as I've implemented and redeployed some ServiceDesk products that didn't have these options. Took a lot of time and nerves.

Connectors to Configuration Manager and Operations Manager will enable a user to know what he has, where it is (CMDB) and how it works (incidents, problems).

Picture: Basic Architecture

MS System Center Service Manager "sits" on mature MS technologies: SQL Server and Reporting Services, SharePoint 2007, .Net, Office and SML. These products by them self are among the better bunch in MS portfolio (I am not a fan, remember?). And from what I've seen in new Operations Manager, we have every right to expect a robust, well thought and sexy ServiceDesk product. And that will surely give other big players something to think of. Which is always good for us, the people.

Timeline?

• Beta 1 will be available later in May 2007, and it will have Incident and Change Management solution packs. Also the IT portal for self-service provisioning. Connectors for AD and SMS2005 will be available.
• Beta 2 is planned for 3Q 2007. It will add Asset Management solution pack and connectors for OpsManager 2007 and SCCM. Reporting is also be included.
• Release Candidate version is expected by the end of 2007.
• RTM version is planned for the beginning of 2008.

Key Points:

• Companies with majority of Microsoft IT infrastructure. If you already have SMS or OpsManager, this is a product to consider. Will have a competitive price and good integration with existing management tools.
• SM has OOB implementation of best practice knowledge and workflows.
• Extendable, customizable platform, different topologies to adapt to company growth.
• SML: Microsoft is putting a lot of resources and effort into this.
• Built on reliable, mature MS technologies. No reinventing the wheel.
• INTEGRATION: many of existing products have problems here, and you get aware of them when you get to the point that you need integration: with your CMDB, inventory discovery, ERP...
• Functionality of Solution Packs is so cool

So, let's wait and see what happens. From my experience with MS OpsManager, RTM will probably be the first usable version. Since I am so curious, I will start with the Beta 1 and keep you informed.

Service Desk

Here is where the Service Support business starts and ends. At least from end users perspective. Customer problems and needs should be streamlined here and all feedback should come from here.

Other Service Support disciplines (Problem, Change, Release, Configuration Management) are PROCESSES, and Service Desk is a FUNCTION. Since Service Desk acts as a Single Point Of Contact (SPOC) for customers, and most of the time other disciplines are initiated from SD, it is rightfully the first SS discipline defined in the Blue book.

Support organizations have a Service Desk. Sometimes they call it differently, but it performs basic ITIL SD processes, so it is a SD. Sometimes people call it SD, and in reality it is a simple HelpDesk or even just a Call Centre. The difference?

• Call Centre's primary function is to handle large volume of calls, and hence the name. These calls can be outgoing (we sell something - telesales of commodities or simple products) or incoming, with prospect or customers inquiries and feedback. Main tools used here are some CRM or a good contact management with CTI and case tracking, e-mail, fax integration and an electronic catalogue.
• Help Desk mainly resolves a large number of Incidents from a known, probably large customer pool. Incidents and enquiries are usually simple, since they are constricted to a technology niche of a supported product (cell phones, telecommunications...), so the typical employee of a HD is briefly educated, given an issue tracking tool and a simple knowledge base, and maybe a couple of taps on his shoulder. Help Desk operation is a stressful business, and life expectancy of the operator is 6 months to 2 years. After that all his savings go to his therapist.
• Service Desk shares some features with the former two, since all three entities are interfaces of service business to the customer, and they are most responsible for the customer satisfaction. They use the same or similar technology.But SD's perspective is much broader, and encompasses all disciplines of Service Support and Service Delivery.

SD Primary function is to handle incidents and problems, but it also receives RFCs, deals with service and maintenance contracts, SW licenses, Configuration Management, and contributes to all five disciplines of Service Delivery.

What is the typical situation of support without SD?
Nicely put, customers perceive you as a disorganized untrustworthy bunch of nerds

• Changes to your IT infrastructure are uncoordinated and disorganized, and most of them cause bursts of incidents
• Your main job is to put out these fires that come out of nowhere
• Most of the problems occur in a repetitive manner You over-depend on your best engineers, who are most competent to resolve incidents initiated by their irresponsible unauthorized changes
• Support resources are undermanaged, while some people can behave like on vacation, others work their head off, and no one can be sure who is who
• Poor feedback to customers (this should be about their satisfaction, remember?)
• Poor feedback to management - without reports, their function is meaningless, and your job is at stake
• Evidently, implementation of SD will change these drawbacks into advantages, dramatically rising customer satisfaction, i.e. retention.

OK, What basically does Service Desk do?

I will briefly mention key activities here:

• receiving calls, first-line Customer liaison.
• recording and tracking Incidents and complaints - first line operators key task is proper classification of an incident.
• keeping Customers informed on request status and progress - every communication, even an automatic one, strongly influences customer satisfaction level. Structured, uniform automatic notifications reassures the customer that an organized business entity is taking care of his problem.
• making an initial assessment of requests, attempting to resolve them or refer them to someone who can, based on agreed service levels.
• monitoring and escalation procedures relative to the appropriate SLA .
• managing the request life-cycle, including closure and verification - a request should not be closed before a customer verifies it.
• communicating planned and short-term changes of service levels to Customers.
• coordinating second-line and third-party support groups.
• providing management information and recommendations for service improvement - crucial task that takes a lot of SD manager's time is keeping the management happy and improving the vertical visibility of SD efforts.
• identifying Problems highlighting Customer training and education needs
• closing Incidents and confirmation with the Customer - an incident should not be closed before a customer verifies it.
• contributing to Problem identification.

Key point of modern SD is common with all quality control standards: puts things into perspective, and customer satisfaction into focus. Highly skilled IT people tend to behave like spoiled children, self centered and often distracted by technology features, computer games, inadequate sexual performances... Implementing standards, policies and procedures sets them back on track and reminds them where the food comes from. Also, ServiceDesk methodology relieves 2nd and 3rd level engineers (expensive ones) from the stress by removing frequent interrupts of customers requests. Work comes to them adequately prioritized and categorized and they can perform it in an organized way.

If you plan to implement a SD, a lot of useful advice can be found in ITIL Service Support book. Buy it. Read it. Certify your people. Do not overdo it, but ensure that all the key people are acquainted with the stuff and speak the same language, this will raise the collective state of mind in your organization.

ITIL is a framework, not a methodology. It is fairly descriptive (good for learning), and it doesn't prescript every little detail of work. When you plan SD implementation, there will be a lot of vague and undefined issues, and ITIL should be referred to during plan phase brainstorming to silence that loud category of people that like to speak about things they don't know much of.

"Those that have something to say, say nothing because those who have nothing to say, have to say something."

One of the key points in SD implementation is technology. What IT product will you choose for SD automation? Your current needs, if you are in pre-firefighting phase, may blur your real future needs. That's why ITIL education is good. Warns you of the problems that will arise when you get rid of your pathetic little initial pains.

Choose the tool that will ensure you GROWTH. Select a well known vendor and implement his functionality modules as you move forward. Do not choose a cheap solution that will choke you in the future. At some point, either you will have to choose a new, expensive solution and get fired for that, or you will get fired in the first place and someone new taking your place will select a high-end solution. In both cases you lost a lot of the money for your company and people will spit on every mention of your name.

Even if you follow this safe recommended path, there is a chance that you will make a bad decision. For example, ask all the former Peregrine customers ;-)

If your company core business is not development, DO NOT build a solution yourself. Period.

I have to say some more about existing solutions later, and this should suffice for this post.

If this all looks like too much, you can always consider outsourcing the SD. There are criteria mentioned in ITIL about an outsourcing decision, consider them. Sometimes renting of an apartment is better then buying it. Rarely, though.

Service Support Evolution Model

Pic: SD evolution vs MS DSI model

There are some philosophical arguments in the trade, as to what Service Support process should be implemented first, and many knowledgeable people hide behind phrases like "each must decide for himself" or "business organizations differ", or "ITIL is prescriptive, not descriptive" and stuff like that. Blah. If you are new in the trade and just began browsing ITIL literature, you WILL implement Service Desk. Why? This is the only mentioned discipline which is not a process, it's a function.
And if you are a beginner in Service Support, you are most likely here for firefighting reasons: you want to be reactive and solve incidents that emerge daily on your IT infrastructure. You want to make your customers happy instantly, resolve their incidents and you hope that they will stay happy until the next incident.

FIREFIGHTING: So you implement the Incident Management process with the Service Desk. Good. You define who are your users (hopefully you know their names, either from LDAP, AD or contracts you created with them - let's put aside helpdesks supporting unknown customers for now), you create basic categorization of incidents, define escalation policies and select/implement a ServiceDesk technology.
If you are really smart, you implement some inventory database/wannabe CMDB under it, but this is not necessary at this point. Most likely, you will have several service/helpdesks at the beginning, each one formed and evolved around separate technology or business need, i.e. ERP, desktop, networking... You are in a FIREFIGHTING phase.
Your main target in this phase shifts from the beginning need to resolve as many incidents as you can, to consolidate things a bit and create only one ServiceDesk as a single point of contact (SPOC) for all business customers. This is a difficult task since you have to overcome many cultural, political and organizational barriers here.
Most of the IT departments here are SO SPECIAL, NW people don't talk to system admins, developers don't know how to talk to anyone, and ERP people WILL NOT talk to anyone. And you are just a small fry, helpdesk organization is usually the lowest form of life in any corporate IT.
So you need to work and learn for some time, include the stakeholders in your processes, get some mentors, and increase visibility of your work in the company. By constant reporting, customer portals, knowledge bases, sleeve pulling etc. Some do it for years before they get enough attention to be able to move to next phase.

REACTIVE: Big deal, you consolidate your helpdesks in one single organization, SPOC. Everyone calls you and hate you ;-). You are a ServiceDesk with some political and cultural background, and you gain less dissatisfied customers then before. No more rerouting between different helpdesks, more and more incidents resolved in a first call, your resources become cost-efficient, trend analysis and reporting go smooth and you look better and better. You are in REACTIVE phase.
Still, from the sheer quantity of aggregated incident information, you notice that your people often resolve repetitive problems, there are still champions in your team which are the only possible resolvers of specific incident types.
Also, aside from simple service requests and forgotten password resetting, most incidents are initiated from unconsolidated/unauthorized changes to you IT infrastructure.
Periodically you try to bulk-update your inventory base by hand, and think of system/network monitoring tools that would keep your inventory info (CMDB?) up to date and inform you about changes that make your life miserable.
You implement some of these tools in this phase, and your people become more knowledgeable about the infrastructure they support, and they notice more and more incidents before they are reported by the customer.
Still, you still do a lot of firefighting here.

PROACTIVE: You finally gain enough visibility and management attention to propose the implementation of Change Management to your business, and sell the benefits of it to stakeholders. Maybe in the meantime they were educated or heard from their peers in other companies about ITIL and stuff, maybe they even fired the previous service desk managers for lingering too long in reactive phase (is this good or bad for you?), so you pick the tool and methodology to implement CM. A lot of problems and risks here, we will discuss them later.
Presume here that everything went up the happy path, and you manage changes. Cool, you now know where is what and how it works, you implemented customer portal with self-help features and aside from customer's problems you are ready to accept other kinds of requests, like upgrades, new equipment and education.
More sophisticated NSM tools are implemented, and they are tighter integrated to your ServiceDesk tool. This integration can be a major pain here, so a lot of support orgs replace the complete toolset in this phase. Have that in mind if you just started firefighting and are picking your tools.
I am not trying to do some stealth marketing here, just telling you what I experienced. Pick up a robust, established tool in the beginning and use just modules that you need. Licensing policy with ServiceDesk tools usually enables you to do that. In this phase you have probably implemented some tools for remote desktop control and you customers like that.
Some sexy OLAP reporting tools are also implemented, to keep the management happy. You finally understand that you have to be the owner of CM process and all CMDB information. Because without that, you will be proactive only in your dreams, and most of the time you will just react to uncoordinated changes in IT infrastructure.

PREVENTIVE/AGILE/Business Policy SS: This phase is the least explored and defined one, since it represents an ideal stage to which every support organization should strive. This one is the most creatively perceived and can depend on corporate goals, mission, vision.
However, there are some basic key points which are a common classic. Since you "proactivated", now and only now you are enabled to manage Service Level Agreements (SLA).
Until now your contracts with customers have been strictly reactive, with defined response times and escalation policy. You were unable to guarantee availability of IT functions to the business, since you were not the owner of the key processes.
Now you hopefully manage and control all the changes, release them and have an up-to-date ideal picture of IT infrastructure in your CMDB (yeah, sure:). You and your business customer can now negotiate the amount of availability he is ready to invest in. SLA is often perceived as a penalty mechanism to the service provider in case of SLA breeches.
At the end of the day, as the relationship between Service provider and the customer evolves, negotiating SLAs becomes a process of communication improvement and better understanding of the two parties. Will have to say more on that later.
Your Request Management by now is thoroughly defined, you have services/asset catalogs and developed standard procedures and workflows for frequent service requests like add/move new employee etc.
You implement Asset Lifecycle Management and integrate with your ERP to avoid overlapping of the two.
As you evolve, it becomes clear to you that the key focus on Configuration Management and CMDB has to be broadened to encompass contracts, financial parameters of your assets.
You are not satisfied with the knowledge of what you have, where it is and how it works, you want to know is it yours or leased, when the contract expires, at what stage the depreciation of the asset is in, does it have a warranty, when will it retire. It is a huge cultural shock if you try to take ownership to that data from ERP, so it is usually a matter of long negotiations where the referent data will reside and in what amount. Natural place for that data is in ERP, but some access and update rights should be given to Service Support. Here the vision of this phase becomes crucially dependant on technology development.

Some twenty years ago it was much easier: you had a mainframe and terminals, so the standard ITIL procedures were much easier to perform. After all, IBM and peers had similar standards defined a decade before ITIL emerged. Ten years ago it was a two or three-tier infrastructure with smarter and smarter clients all over the place, and the maintenance became very difficult. Now it is n-tiered architecture, applications and services distributed everywhere - on clients, intranet, extranet, internet and management of these becomes next to impossible.

So the two main trends evolve:

1. With reduced prices of bandwidth, applications and functionality will migrate from clients to hosted environment, where they will be easier to maintain. Web2.0 and the consequent Enterprise2.0 will probably influence this evolution in the next few years.
2. Infrastructure will tend to virtualize and lot of the maintenance, problem/change/configuration management will be automated as much as possible. Have a look at MS DSI initiative and their vision of IT infrastructure evolution, it pretty much complies with above four stages of SD.

Well, this has been a long one, and that I will try to avoid in the future. In the meantime, I wish you all a happy firefighting ;-)

Service Support

As we mentioned earlier, IT Service Management consists of Service Support and Service Delivery modules. Service Support is known as an ITIL Red Book, and if you are starting in ITIL, this is the first book you will reach for.
Starting support organizations in an unconsolidated, firefighting phase are usually first interested in Service Desk and Incident Management. We will discuss this later, but let's mention all ITIL Service Support disciplines here:

• Service Desk - point of contact function for all IT customers for service requests. SD reports customers on statuses of their requests and informs them on any outages of relevant IT services planned in the change process
• Incident Management - a reactive process of restoration of IT services into a state before the incident. Closely connected to Problem and Change Management
• Problem Management - a very simple process: finds the underlying common cause of a few similar incidents, creates a workaround or temporary fix, and defines a permanent fix, usually as a result of previously initiated change. Implementation of PM is often omitted due to lack of resources, since it requires expensive educated staff, and by default these people much more like to play Warcraft or visit dirty web sites than to analyze Problem Root Causes.
• Change Management - this one is the toughest: plan and manage all changes in IT infrastructure. Basically, it deals with the problem of convincing IT people (mostly geek prototypes) that corporate IT infrastructure serves to more important stuff than their childish need to play with it. Involves risks analysis and impacts of changes to business IT services.
• Release Management - here is another long shot: after you plan changes, someone has to actually go on the field and perform them. Usually there are more changes implemented at the same time, mostly due off-work hours and weekends. RM task is to coordinate IT people with no life for it's dark non-human low purposes.
• Configuration Management - here I will stop with my feeble intentions to be funny: here is the cornerstone of all ITSM talk, it begins at incidents and here is where it ends. I am STRONGLY convinced that knowing A. what you have, B. where it is and C. how it works is the cause and a mean to all ITSM gibberish. Keeping your CMDB up-to-date is something you should do as if your life depends on that. And if you are a ITSM professional, it does.

What should be the implementation order of these functionalities in our business? Do we implement one by one, all at once, or in few phases? Let us discuss that in the next post.

What is ITIL®?

Here we will shortly discuss a framework that became a de facto standard in ITSM.
Everyone in the industry is getting certificates in ITIL, from people to SW. Why is that? Probably because ITIL is founded on best practices in IT since early 1980s

ITIL (Information Technology Infrastructure Library) is a best practices framework to manage IT services in an effective and efficient way.

ITIL was initiated in the second half of 1980’s by the British government in order to design a set of operational IT guidance. The main goal was to increase efficiency in Government IT and the task was given to Central Computer and Telecommunications Agency (CCTA).

Authors consolidated best practices and guidelines from existing industry standards in a so called Government Infrastructure Management Method (GITMM). In 1989 it was renamed to Information Technology Infrastructure Library (ITIL®).

During the 90’s it gained worldwide popularity as the most complete set of best practices in IT Governance.

The updated version 2 in the year 2000 gained even more followers in the IT industry, as it focused more on bringing IT and business to understand each other. It defined a standard for a common language in IT, especially around IT Service Management (ITSM ), which was covered by two central books: Service Support and Service Delivery.

ITIL® ITSM with its ten basic processes and Service Desk function covered basic needs of various IT service departments for best practice guidance in daily operations.

ITIL V2 Service Management model

1. Service Support - Blue Book is focused on the user of the IT services. Function and processes:

• Service Desk
• Incident Management
• Problem Management
• Change Management
• Release Management
• Configuration Management

2. Service Delivery - Red Book is focused on the Business IT needs:

• Service Level Management
• Financial Management for IT Services
• Capacity Management
• IT Service Continuity Management
• Availability Management

ITIL® V1 and V2 were obviously process oriented, since relatively young IT organizations in the 90’s and 2000’s mostly needed basic organizational knowledge and skills.
In the 2000’s two very important ITIL® offspring were created:

• MOF: Microsoft® Operations Framework is a complete and mature framework based on ITIL® V2, completely free of charge and public
• ISO/IEC 20000: ISO standard evolved from British standard BS15000 and provides ITIL® V2 related auditable set of requirements for IT service management business organizations willing to ensure full alignment with basic processes.

ISO/IEC 20000 Model

In 2001 CCTA became a part of the British Office of Government Commerce (OGC).
In May 2007 the third version of ITIL® was published. It introduced roughly 16 new processes and three functions. The main update was that processes were spread over five new lifecycle stages:

1. Service Strategy
2. Service Design
3. Service Transition
4. Service Operation
5. Continual Service Improvement

ITIL V3 Lifecycle stages

This lifecycle approach was justified as IT organizations gained maturity towards 2010s, when IT ceased to be a mere support for business functions, but it became an integral part of the business - a crucial and strategic asset. Hence it is important to follow the service through its lifecycle in order to support the business in an optimized way.



ITIL V3 Processes

About IT Service Management

IT Service Management, as a primary enabler of IT Governance objectives, deals with IT systems from a customer's view: "What and how can my IT contribute to my business?"

ITSM is a discipline for managing enterprise IT. It's task is to defocus IT practitioners from technology and put customer deliverables on a first place.

Definition: “Service Management is a set of specialized organizational capabilities for providing value to customers in the form of services.”

IT Service Management is a discipline which deals with transforming resources into value for a customer, according to definition of a service. Main capabilities in Service Management are functions and processes for managing services through the service lifecycle.

By purchasing or using a service customers get the outcomes they want to achieve. Perceived quality of these outcomes determines the value of the service to the customer.

A process “is a set of coordinated activities combining and implementing resources and capabilities in order to produce an outcome, which, directly or indirectly, creates value for an external customer or stakeholder.”

Business wants  IT to support its existing business processes effectively and dynamically. Business managers often lack the insight on complexity and problems of supporting the business process within the realm of IT resources. IT people, on the other hand, do not exactly understand goals of business managers. Service Management principles are used to reduce this gap. Among others these principles are specialization and coordination, agency principle, encapsulation etc.

As said earlier, main Service Management capabilities are functions and processes:

Functions
Functions are “units of organizations specialized to perform certain types of work and be responsible for specific outcomes.” Functions are self-contained  units with their work methods, processes and body of knowledge. They can be viewed like, and often they are, organizational business units.

Service Desk is the oldest known ITIL function. It provides a single point of contact for Customers while dealing with restoration of normal operational service with minimal business impact on the Customer. Other functions are Application, Technical and Operations management.

To improve cross-functional coordination and evade pitfall of silo-mentality, service management needs well defined Processes.

Processes
Process has actions, dependencies, sequence, inputs and outputs. Process is measurable, it has specific results and its own customers (owners). Also, process is usually event driven.
For Example, Incident Management is a process:

• It starts by incoming call or operations control tool notification (Event)
• We can count incidents, resolved in a first call or specific types (Measurable)
• We know the results of all closed incidents (Output result)
• Every incident has a contact person, (Customer) and Service Desk is the Owner

Operations Management is not a process, it’s a day-to-day activity which interacts with processes. On the other hand, some organizations can define some functions as processes if it suits their business and organizational requirements.

ITIL Processes in Lifecycle stages

Service Management

Have been thinking about service management a lot lately. Since the core bussines of my company is SM, we are educated in most of the known methodologies and implementing most of the best practices from ITIL, MOF, COBIT, ISO...
Blogging about it could be a good way of setting some basic knowledge points for the new people in the business. I will take the liberty of reshaping and adding to previous posts according to comments and sugestions of the People.