A menu is not a service catalogue

A menu is not a service catalogue. Please can we desist with this awful analogy. It makes people think automated service requests is an "actionable service catalogue". It's not. It's an actionable request catalogue.

I dislike the analogy because a restaurant is not a good analogy for most business situations. Service catalogue describes services provides to customers. Request catalogue is what the user can request. These are not even similar unless user = customer, which is often not the case. Remember: customer pays, user consumes. That's true mostly in retail contexts, not business or public sector.

First and foremost, a service catalogue describes what a service provider does. How often and what flavour are only options to a service or package of services. Choices are (generally) not distinct services. They are requests to be fulfilled. There is a many-to-many relationship between service and request: one service has many requests and one request can involve many services, e.g. provision a new staff member. I recall from my data modelling days that this is a clear indicator of distinct logical entities.

A restaurant's services are some or all of:

• food a la carte
• buffet
• drinks
• BYO
• takeaways
• deliveries
• toilet
• private functions
• catering
• cooking lessons
• ...

THAT is their service catalogue

Railway timetables

I wrote about service catalogues at The ITSM Review, using railways as an example. Check out that article. As part of the comments on that article we got into this debate, but not over menus, rather we debated timetables for train services, which are just another kind of menu. I said a timetable on a station wall is a request catalogue. A request catalogue is a consumer's view of their available choices for one or more services. If a timetable is a service catalogue rather than a request catalogue then the service of transporting me from A to B is a different service depending on what time of day it is. That is absurd. The IT analogy would be that email at 10am is a different service to email at 11am.

Actionable catalogue

In the long tradition of IT solving everything with technology, there is a fad right now for "actionable service catalogue" "like Amazon". The vendors are beating this drum. It is automation of request entry or all of request fulfillment. Following on from the argument above, we can see that this is not service catalogue that is being made interactive; it is request catalogue.

If a full service catalogue were automated, a new customer could request a new service, with agreement of contractuals, costs and SLAs. This does happen with cloud providers, and in some cases even deals with service fulfillment where the customer is distinct from the user(s), e.g Google Apps.

But this is bleeding edge, and I'm tired of all the excitement over bleeding edge when most of the world is still trying to come to terms with the new millennium. In the vast majority of cases right now where the vendors have got a client excited about "actionable service catalogue", they are talking about automating service requests for in-house users.

That's nice (if there really is a business case for automating it and we're not succumbing to the usual IT infatuation with automation), but it isn't service catalogue. It is one subset, one use-case, one limited view of service catalogue: a request catalogue.

Let's get that clear. Several times I've raised service catalogue only to be told "Oh we're getting a tool to automate that". No you're not.

Starting with requests and working bottom-up to service catalogue is a fine approach (personally I prefer top-down from services to requests but that's a different debate), but let's be clear that service catalogue is a different thing and developing and maintaining and using it are different tasks. By all means build a request catalogue: you'll still have your service catalogue to do.

More on this from me in this article for The ITSM Review