Free Downloads

ISO 20000: 2011
ITIL 2011 MMap

Request for Change (RFC) Template

Major Incident Report Template

ISO 20000/ITIL Timeline poster


Sponsored Links



May 6, 2007

Service Support Evolution Model

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


Максим Ганнутин said...

I have been trying to find information about the way customer support works for the software company.
The questions I would like to ask are:
1) What is the prime cost of customer support(including product maintenance, customer support)?
2) What is the expenses structure?.

For example: How often support engineer have to visit client, how much time such a trip could take.
What is the percent of software caused client problems?

The motivation of manager for customer support team is interesting area also.
What is the key parameters for support team effectiveness estimation?
What is the common reward system for support?
There are a lot of information from ITIL , but it is very heavily-loaded for us, finding methods that are more agile would be very nice.
We have the box product with the several dozens of integrations per year. The product quality is rather high.
The most of the problems are caused by other software environment: bad DB version, security policy problems in LDAP and etc.

I know that these parameters are different for most companies, which have different projects, customers.
But we are interested in any experience you can share considering the subjects specified above.

Sample SLA would look like this:
We provide informational support by phone, email and using web site for the following areas:
- Product installation
- Product usage
The guaranteed answer time is:
- 2 days for email
- 4 hours for phone.
We also provide:
- The diagnostics which may be required if product problem persists.
- Bug fixing.
- Product update caused by federal law changes.
The customer have to provide us with the access to his systems where product is functioning, and we oblige not to break customer's security policy.

We would be happy to receive any information from you.

Definite ways of support department job quality estimation would be very nice to get.
For example:
- The percentage for answers in the period of time defined in SLA
- The percentage of answers that solved customer problem, without asking any more questions.

The separation of support problems and ones caused by developer faults would be nice

doctor said...

@maksim: nice to hear from you, maxim. you have some interesting questions, will be glad to give you answers I have, but it may have to wait until the weekend when I'm back home from a business trip. Best.

doctor said...

Maksim, I will try to answer quickly here:
- Read ITIL Service Support, with the focus the Service Desk and Incident Management disciplines.
- Read ITIL Service Delivery Financial Management chapter.
- Talk about this with your coleagues.

In my opinion, Customer Support for SW companies gives you the freedom of choice. Support can:
1. Be the cost center
2. Be the profit center
3. A bit of both

Meaning that some SW companies provide free support for some time after you purchase their product, and some of them give it away for free and charge only for support. Bug fixes are almost always free.

Since there is no free lunch, you organize your business in such a way that you don't cut the branch youre sitting on. Collect all financial info on included costs, and decide will you finance it from product profit or you will charge for it.

The nature of profitable business is that it satisfies both, the service provider and the customer.
It all depends on what does your agreement with the customer look like. E.g. a Customer should expect that the travel expenses will be charged to him. Or he will lose you to bankrupcy soon ;-)

ServiceDesk Supervisor/Incident Manager is motivated bu his team KPIs and their presentation to his manager.

Here are some examples for KPIs in Incident Management:
• 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

Also, there are ServiceDesk KPI examples:
• Percent Of Customers Given Satisfaction Surveys
• Customer Satisfaction Rating Of Service Desk
• Percent Of Caller Hold Times Within Service Targets
• Percent Of Calls Responded To Within Service Targets
• Number Of Incident Records Not Yet Closed
• Number Of Calls Abandoned
• Number Of Calls Referred To Sales Organization
• Dollar Value Of Referred Calls To Sales Organization
• Percent Of Calls Resolved At The Service Desk Without Escalation
• Staff Turnover Rate
• Overall Cost Per Call.

Have in mind their corresponding success factors.

Hope that these are answers some of your questions. If I was of mark, please inform me, I will be glad to help.

Splash said...

This all makes sense!!!!

As I was reading this I thought that you were reading my mind. Granted, it is the ITIL structure translated by you...thank you for the translation!

I am currently slogging through our current system and really want to attack the preventative stuff first. I have continuously been running into roadblocks trying to do so. The SD Evolution picture helped tremendously. Now I can actually map out the long term plan and remind myself that prevention is the final goal!

I do have a question; I read your entry on categories but I am still having a hard time wrapping my brain aroudn the options after being hip deep in our current system. Do you have some more examples that you can post?

Thank you for all your insight!

doctor said...

I see a lot of people bouncing of the All About Incident Classification page, so maybe I should modify it.

Sadly, when I look at it, it seems perfectly logical to me :-)
Talking about not seeing a tree from the forest...

Now, I strongly recommend reading the article Incident categorization in the V3 Service Operation book, since I find it pretty conformant to this article.

Here is an example from the book:
“Multi-level categorization is available in most tools – usually to three or four levels of granularity. For example, an incident may be categorized as:”
HW:Server:Memory Board:Card Failure
SW:Application:Finance Suite:Purchase Order System

And this is pretty much how tickets are categorized in my company. Also, use the six-step method from the article to create a category tree from scratch, or modify your existing tree.

Best wishes!