Building a Service Catalogue

This blog is part of the coordinated service management blogging flashmob, with the idea to have a number of bloggers posting an article on the same agreed theme (at the same date/time). The theme for this first edition is ‘My Best Tip for building the Service Catalog’ (yes, American spelling).

I myself have had a bit of a love-hate relationship with the Service Catalogue.

In the beginning, during the dark ages of service management, or rather the 90s, I was spruiking the Service Catalogue as the best thing since sliced bread and an absolute starting point for anyone inspiring to do service management. After all in those days the concepts of service management, or even of a service, were relatively unknown and it seemed a logical starting point to define what your services actually are.

As, in essence, that is what the Service Catalogue is: a list of services. In its purest, simplest form it doesn't even need a lot of text, just a short description, so the customer knows what they can expect from the service provider. This is why a restaurant menu is so often used as an example/analogy for a Service Catalogue (which is wrong, but more about that later).

But then came ITIL v3 and the Service Catalogue obtained its own process, within the Service Design publication. The definition became: Service Catalogue (Service Design) - A database or structured Document with information about all Live IT Services, including those available for Deployment. The Service Catalogue is the only part of the Service Portfolio published to Customers, and is used to support the sale and delivery of IT Services. The Service Catalogue includes information about deliverables, prices, contact points, ordering and request Processes.

Not enough to really obtain an indication of the importance, or irrelevance, of the catalogue. More interesting is how the book describes the two different aspects (or better perhaps: ‘views’) of the Service Catalogue: the Business Service Catalogue and the Technical Service Catalogue. This is a great clarification of the vague reference in version 2 of a ‘hierarchical’ structure of services with some being ‘invisible’ to the Customer. The two newly defined aspects/views show the difference between the visible, outward facing catalogue (for the Customer) and an internal one which can be used for the development & management of systems and teams.

However, at the same time ITIL started confusing what the objective of the Service Catalogue is, and where/when it should be used. Not helped by (the usual ITIL) ambiguity of definitions and inconsistencies across the publications. The main one that bugs me is the distinct different uses of the Service Catalogue in Design (as part of Service Catalogue and Service Level Management), Operation (in Request Fulfilment) and in Service Strategy.

In 2010 I wrote an article (published in the itSMF-A Winter bulletin) on ‘Is the Service Catalogue really necessary?’ (leave comment if you'd like a copy). It concluded that the Service Catalogue has become a strategic document, in the ITIL Lifecycle, defining the Market and the Offerings as well as a structure for the delivery of those. It straddles the bridge between the Portfolio\Pipeline for the future and the ‘next’ Customer, leading to Service Level negotiations.

PS: This is also the main reason why the menu card is not the Service Catalogue of a restaurant: After all, the meals on the menu are merely the products delivered (comparable to an application). And it is not the product the customer wants, but the value he or she derives from this. For instance a bowl of chips is the same product whether it is obtained in the drive-through of a fast food restaurant -with screaming kids in the backseat-, in a pub during the Sunday-session -with mates and a beer-, or as part of a romantic dinner-for-two in a seaside a-la-carte restaurant; same product but the value is completely different (convenience, atmosphere, privacy, view, ...).

Thus the ‘real’ Service Catalogue of a restaurant is the style, location, opening hours, interior, ambience etc.etc. ... All those things that make someone decide to go to that particular restaurant in the first place, rather than pick a specific dish of the menu

So, now leading to my best Tip for building the Service Catalogue. I think the secret is in the diagram showing the Business & Technical Service Catalogue.

Based on Cabinet Office ITIL® material. Reproduced under licence from the Cabinet Office

The business side is showing a link between (business, customer-facing) services and business processes. These links form the bases for Service Level negotiations & Agreements (SLAs) and thus we need to define the utility that these services provide. And I think that is ‘easiest’ done by defining Patterns of Business Activity (PBAs as they are called in Demand Management). PBAs are often related to core business and revenue and thus define (too a large degree) the success of the business and by extension the value of the service.

If you could quantify these PBAs, they are going to be mighty helpful not only in defining the service for the Service Catalogue, but also negotiating the service levels, determining change impact, incident prioritisation etc.etc.

TIP 1: Define Patters of Business Activity, which will lead to utility and service definition

So, that is one half of the solution, on the other, technical side we see how those same services are linked to bits of technology. I think the picture is skipping a level here, as the technology is managed by ‘someone’ (a team, a provider, ...). These links represent the OLAs and Underpinning Contracts that need to be in place with these people (in order to deliver the SLA, customer-facing services above). 

So instead of technology, identify your functions, your teams and suppliers; and then define the (technical) services that each of those deliver. You'll find that these are probably more warranty-focused.

TIP 2: Identify teams that deliver technical, underpinning, supporting services

That's my tip(s): PBAs, utility & SLAs for the customer-facing services; and functions, technology & OLAs/UCs for the technical ones.

But if all else fails, one more tip: start with your applications!

Not all of them, and not in their technical appearance, name or version (no funny acronyms). But applications are the most visible part of a service for the customer, and they provide the utility to the customer and are thus closely related to the customer-facing service definition. 

This is not a perfect solution or (ITIL) theoretically correct, but you could do worse that to start here.

Good luck!

the ITIL Zealot
October 2013