ITIL 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 lately, of course, CMDB.

In fact, ITIL discussions often get 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 outcomes more than what machinery we build to deliver it.

You’d be forgiven for wondering when reading some of the ITIL books, in particular the “red book,” Best Practice for Service Delivery. The book shows all the signs of its origins: old-school, monolithic, bureaucratic, mainframe, government shops where the customer was someone you nailed with a written service contract and the relationship was managed by a second tier manager.

The key function of ITSM, Relationship Management, and the key mechanism, the Service Catalogue, are embedded deep in a process called Service Level Management (SLM).

There is no over-arching process to manage the customer relationship among the 10 core processes of ITIL. There is no CRM. Managing the levels is only one aspect of managing service delivery to the customer, and yet all the other aspects are only mentioned in passing within SLM.

The name is misleading, the process is just an equal among the other processes, and it rates 32 pages in a 300 page book (Financial gets 60 and Availability gets 82). It is hard to see how ITIL Version 2 is customer focused.

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.

Contract Mentality

SLAs encourage an “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 is SLAs are only one way to approach ITSM. But, according to ITIL, they are the only way.

This is because so much of ITIL service delivery hinges on the SLA: service measurement, availability planning, capacity planning … the common components that show up across the ITIL books are SLAs and the CMDB.

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 when servicing the business still need a definition 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 deliver those measures, 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 them.

First Steps

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 say, “How can you have a Service Catalogue with no SLAs?” There are two forms of the Service Catalogue: SLAs are not the centre of the ITSM universe, the Service Catalogue is. We'll have to want and see if this changes in Version 3.

ITIL 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 lately, of course, CMDB.

In fact, ITIL discussions often get 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 outcomes more than what machinery we build to deliver it.

You’d be forgiven for wondering when reading some of the ITIL books, in particular the “red book,” Best Practice for Service Delivery. The book shows all the signs of its origins: old-school, monolithic, bureaucratic, mainframe, government shops where the customer was someone you nailed with a written service contract and the relationship was managed by a second tier manager.

The key function of ITSM, Relationship Management, and the key mechanism, the Service Catalogue, are embedded deep in a process called Service Level Management (SLM).

There is no over-arching process to manage the customer relationship among the 10 core processes of ITIL. There is no CRM. Managing the levels is only one aspect of managing service delivery to the customer, and yet all the other aspects are only mentioned in passing within SLM.

The name is misleading, the process is just an equal among the other processes, and it rates 32 pages in a 300 page book (Financial gets 60 and Availability gets 82). It is hard to see how ITIL Version 2 is customer focused.

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.

Contract Mentality

SLAs encourage an “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 is SLAs are only one way to approach ITSM. But, according to ITIL, they are the only way.

This is because so much of ITIL service delivery hinges on the SLA: service measurement, availability planning, capacity planning … the common components that show up across the ITIL books are SLAs and the CMDB.

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 when servicing the business still need a definition 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 deliver those measures, 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 them.

First Steps

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 say, “How can you have a Service Catalogue with no SLAs?” There are two forms of the Service Catalogue:
SLAs are not the centre of the ITSM universe, the Service Catalogue is. We'll have to want and see if this changes in Version 3.

ITIL 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 lately, of course, CMDB.

In fact, ITIL discussions often get 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 outcomes more than what machinery we build to deliver it.

You’d be forgiven for wondering when reading some of the ITIL books, in particular the “red book,” Best Practice for Service Delivery. The book shows all the signs of its origins: old-school, monolithic, bureaucratic, mainframe, government shops where the customer was someone you nailed with a written service contract and the relationship was managed by a second tier manager.

The key function of ITSM, Relationship Management, and the key mechanism, the Service Catalogue, are embedded deep in a process called Service Level Management (SLM).

There is no over-arching process to manage the customer relationship among the 10 core processes of ITIL. There is no CRM. Managing the levels is only one aspect of managing service delivery to the customer, and yet all the other aspects are only mentioned in passing within SLM.

The name is misleading, the process is just an equal among the other processes, and it rates 32 pages in a 300 page book (Financial gets 60 and Availability gets 82). It is hard to see how ITIL Version 2 is customer focused.

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.

Contract Mentality

SLAs encourage an “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 is SLAs are only one way to approach ITSM. But, according to ITIL, they are the only way.

This is because so much of ITIL service delivery hinges on the SLA: service measurement, availability planning, capacity planning … the common components that show up across the ITIL books are SLAs and the CMDB.

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 when servicing the business still need a definition 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 deliver those measures, 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 them.

First Steps

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 say, “How can you have a Service Catalogue with no SLAs?” There are two forms of the Service Catalogue:

You build the brochure as early as possible in an ITIL implementation process. The technical specification grows slowly over time.

ITIL agrees. Page 33 of the “red book” lists producing a Service Catalogue as the very first activity of implementing SLM. Unfortunately, this advice is buried one level too low. Producing a service catalogue is one of the first activities of implementing any ITIL process.

Some organisations choose to “do”, say, incident management first and leave SLM to later. Reading the ITIL “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).

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 that all the other ITIL processes know what is required of them, and how to prioritise.

Service Catalogue lives in the CMDB and the CMDB is the technology hub of ITIL. CMDB is arguably the hub of all ITIL processes too, although I would go in to bat for the Service Catalogue. But Service Catalogue is undoubtedly the hub around which the people revolve, not SLAs or CMDB.

Not that you would know it to read the Version 2 books. Version 3 pays more attention to the “service lifecycle”: the process of implementing the processes, as it were.

So we can hope that such a focus will draw out the importance of the Service Catalogue and put it in its rightful place, up front and in the middle, with SLAs as an appendix and CMDB as underpinning documentation.