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