ITIL v3: Service Catalog Should be Front and Center
Two years on and we're still not there, writes ITSMWatch columnist Rob England.
PRINT
COMMENTITIL is all about service management. This seemingly obvious fact gets lost at times when all the talk is about Service Desk and Incident Management and Change Management, and of course CMDB. In fact, ITIL discussion often gets deeply into the internals of process and technology, and forgets that ITSM is supposed to be an outward-facing discipline. ITSM is about concentrating on what comes out of the service pipe―the delivered services and the “service culture” that supports them―more than what machinery we build.
The very first step I took on the road to ITIL scepticism was when an architect at a major retailer (a real architect, reporting to the CIO) challenged ITIL on the basis that formal negotiated contracts destroy the teamwork mentality so important to that company’s relationship between IT and the business. SLAs encourage an “us and them”, “if it’s not in the contract …” mindset, which, in many organisations is counter-productive. In other places they fit the culture and work well.
The sum of it is that SLAs are only one way to approach ITSM. According to ITIL they are the only way. So, much of ITIL service delivery hinges on the SLA: service measurement, availability planning, capacity planning. This hasn’t changed in ITIL v3. Sservice levels are still formalised. What did change was the Service Catalogue gained a more prominent role.
If SLAs are not the common factor in all IT/business relationships, what is? The Service Catalogue, of course. Instead of a definition of commitments, the catalogue is a definition of business requirements (and IT capabilities). It defines what we do, not exactly how well we do it. Even organisations that want to maintain a loose, flexible, cooperative culture (read: no formal SLAs) when servicing the business still need a catalogue of what is to be serviced.
You can also argue that even where SLAs are treated as pivotal, the Service Catalogue is in fact more important. This is because true structured formalised SLAs can only be effected once a certain level of maturity in processes is achieved. You can’t agree on SLAs until you know what you can measure, to what level you can achieve those metrics, what the OLAs are and what they promise, and what matters to the business. Building the reporting infrastructure and gathering the data (and negotiating the SLAs) takes time. In theory, an SLA-centric organisation may never actually get to the SLAs themselves.
But a Service Catalogue must come very early in the process, to give people a framework for all those subsequent efforts, and just as importantly to provide a touchstone to drive service-centric thinking into the staff culture.
Some will ask “How can you have a Service Catalogue with no SLAs?” There are two forms of the Service Catalogue:
The business Service Catalogue (I like to call it the “Brochure”) is a high-level document written in business terms that defines what is provided (or could be provided) to the business. It is used by relationship managers to provide a basis for discussions. It is used by staff as a point of reference. The technical Service Catalogue (think of it as the technical specification) is the same document with extensive supplementary information. It is used as a point of reference in the ITIL processes. The SLAs form a part of it, and there is much else: critical components, related services, escalation paths, available training etc.
You build the first draft of the business Service Catalogue as early as possible in an ITIL implementation process. The technical specification starts at the same time and grows slowly over time, eventually including SLAs. No matter where you start with ITIL, producing a service catalogue should be one of the first steps.
Some organisations choose to “do”, say, Incident Management first and leave Service Level Management to later. Reading the ITIL v2 “blue book” (Best Practice for Service Support) one would be forgiven for thinking this means the Service Catalogue is not required for Incident Management. Seek in vain for a mention of it under Incident Management (it gets passing mention in only a couple of places in the whole “blue book” and one good solid reference where it is specified on page 56 as “fundamental” to the Service Desk function). But without a Service Catalogue you are not doing ITSM Incident Management. You are doing good old geeky technical-bits-are-broken Incident Management with zero understanding of the impact on the business (other than the number of phones ringing).
ITIL v3 has of course changed all that: the Service Design book has a whole process called Service Catalogue Management. Or has it? Look at Incident Management in the Service Operation book. How many mentions of Service Catalogue? None. In fact there is barely any mention of services at all outside the definition of an incident (“…an unplanned interruption to an IT service …”). Not even under incident classification or prioritization. SLAs get several mentions, but how one would know what SLA applies is unclear. And at no point does the ITIL v3 Incident Management process determine what service is impacted. Nor does Problem Management.
For another example, check out Service Transition. The Service Catalogue is mentioned in the definition (4.3.4.3) of the CMS (ITIL v3’s new improved CMDB) once, in a diagram, off to the side. Worse, it is relegated to the presentation layer of the Service Knowledge Management System. Hardly the hub.
Service Catalogue drives your people. It is a key mechanism in cultural change, the foundation of customer relationship, and a pivotal tool for organising effort.
Service Catalogue informs your processes. It is only once the services are defined (and yes, the service levels set, where possible) that all the other ITIL processes know what is required of them, and how to prioritise.
CMS is the technology hub of ITIL (if you have one … almost all of you don’t). CMS is arguably the hub of processes too, although I would go in to bat for the Service Catalogue instead. Service Catalogue is undoubtedly the hub around which the people revolve, not SLAs or CMS.
Not that you would know it to read either the v2 books or the v3 books. ITIL v3 pays more attention to the service lifecycle than v2 did. That focus draws out the importance of the Service Catalogue but ITIL v3 still fails to put it in its rightful place, up front and center with SLAs as an optional appendix and CMS as underpinning documentation.
Rob England is an IT industry commentator and consultant, best known for his blog the IT Skeptic.