I am sure a lot of consultants (me included) are in the race to declare the world's first v3 implementation.
Now that the dust has settled down and the v3 basics are known, what exactly is the difference between an ITIL v2 vs an ITIL v3 implementation?
ITIL implementations all over the world are based on ITIL v2 which primarily means that there have to be 10 processes, a CMDB and a service desk, a service catalog, and models for prioritization, categorisation and escalation. So, if someone is trying to do an ITIL v3 implementation, then the only difference is that there will be 23 to 28 processes and other bits and pieces like four functions instead of the solitary one in v2. The old service catalog is likely to be re-cast as a Service Portfolio with the active services listed under a Service Catalog and lo! we have a v3 implementation.
I think it would be apt to lable such efforts "extended v2 implementations" or to distort a popular phrase, v2 wine in a v3 bottle!
So, what does an ITIL v3 implementation look like?
Is it merely a matter of including the additional processes and generating evidence about the so called v3 trappings?
Can we convert an ITIL v2 setup to v3 by reconfiguring the existing processes to complete the v3 list?
Fundamentally, is the effort for v3 sufficiently capturable in "more process work" or is there something more to it?
Where should one look for evidence of an ITIL v3 Implementation?
As the world moves on to v3, this v2 hangover will persist for quite some time. Till consultants and client managers all over the world realize that the essential difference between v2 and v3 is not in the structure of the implementation, but in the practices (functioning) of the PEOPLE in the client organisation.
I think ITIL v3 is all about installing practices which ensure that the service lifecycle is managed properly in all its distinct phases with a decisive approach taken by the stakeholders. The decisiveness would come from a heightened understanding of the generic service lifecycle. Vitally, having a shared ability to communicate meaningfully about where each service is in its own lifecycle.
v3 differs from some significant aspects which I will take here one by one:
Integrated Service Design
SDP: The service design package template, when stabilized in an organisation will help them to design services in an integrated fashion. v3 propounds 5 major areas of service design - mostly different teams work on these areas.
Currently, any service is designed by people from one or more of these teams, therefore, there is a strong bias on that area - viz. Technology and architectural design. However, this doesn't obviate the need for designing other items. Therefore, the organisation 'discovers' the design problems in the other areas. e.g. for offering a wi-fi service, we need to design the billing processes along with the technology and architecture design. If we forget to design the billing process earlier, we will sooner or later discover that and end up designing or assembling the service somehow. This discover and resolve approach to service design takes more time and energies. It also suffers from lack of an integrated service design approach thereby leading to additional effort required to iron out inconsistencies amongst the various design elements.
The service design package (SDP) will ensure that all the five areas of design are adressed simultaneously giving us the benefits of an integrated design approach.
More in the second part. Please feel free to comment on this one, though
Cheers!
Atul Kherde
