With which process do I start and what sequence should I follow? These are probably questions that are asked most often, especially in greenfield situations (mmm...does that still exist?) and by people that are relatively new to ITILv3. As a matter of fact I am regularly asked to provide input and feedback on project definitions and plans that are focused on "implementing ITILv3 processes".
Let me start by stating that implementing ITILv3 should never be the goal in and by itself, but is always a MEANS to control & manage the resources, capabilities and output (read: services) of an IT organization (read: service provider). In addition ITIL v3 is a best practice framework and not a cookbook. So it will tell you that you need an incident management process and describe some characteristics, however it will not provide you with all the details (such as e.g. training and tool settings) that are needed to have IT staff work with specific incident management applications (e.g. HP Service Manager) to resolve incidents on your specific IT services. In others words: ITILv3 is a piece of the puzzle for implementing a service management system and I have no clue how you can "implement ITILv3" without putting any details underneath (perhaps by putting the ITILv3 books on the shelf? ;-)).
Like with organizational design, the perfect sequence for implementing ITIL v3 processes and functions does not exist. Let me give you a sample: A couple of years ago I got involved in an ITIL based Service Management project with a relatively small IT organization of around 100 people all working in the same location. The IT organization had a very low attrition rate (people stayed until they retired and firing people was "not done") and their main issues were customer (dis-)satifaction and absolutely no control over their suppliers. When we wer discussing the order of processes, we basically concluded that there was no need to start with configuration management because each member of the IT staff was a walking CMDB. So we focused on incident- and problem management to begin with. So when planning the implementation of a service management system you need to take into account the problems that need to be resolved / goal that must be achieved as well as the resources and capabilities already in place.
In general I am seeing two strategies for implementing service management systems: 1) an inside-out approach (also referred to as bottom-up) and 2) an outside-in approach (let's call this top-down). The first approach is geared to first getting control over the individual resources through processes such as operations management, service asset and configuration management and change management. The service oriented processes follow later. The thinking behind this strategy is to make sure that any promises (read: agreed services) can actually be delivered. Downside here is that it might take a long time before the customers of the IT organization actually see any results / get any value from the internal restructuring.
In the second approach the focus is on first understanding the customer needs while definining the services that need to be provided and the value that they bring. Breaking down the services into resources and capabilities (read: service assets) follows later. This strategy is very customer-centric and helps to make sure that the value of IT is better visible. Downside here is that there is a significant risk that at will take a while before the results / value actually get delivered.
Which strategy do you use / prefer?
Regards,
Jeroen Bronkhorst
