Problem Management Facts

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

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

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

Problem Management Mind Map

Inputs

• Incident details
• CMDB details
• Incident Management workarounds

Activities
a. Problem control

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

b. Error control

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

c. Major Incident resolution assistance
d. Proactive PM

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

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

Incident Matching

Outputs

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

Benefits

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

Possible Problems

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

Critical Success Factors

• Avoiding Repeated Incidents
• Minimizing Impact Of Problems

Key Performance Indicators
a. Avoiding Repeated Incidents

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

b. Minimizing Impact Of Problems

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

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

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

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

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

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

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.

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 ;-)