Service Catalogue in a nutshell
A reader asked for advice on Service Catalogue. Here's my "Service Catalogue in a nutshell":
A catalogue is a list of services. Any further detail is bells and whistles.
Top down: look for taxonomies already existing within the business to describe services. Go ask Governance Reporting, Marketing, Product, Sales, Finance, Continuity Planning...
Bottom up: list and then group all the requests that you are asked to fulfill.
The big challenge of catalogue is that the list of services must be meaningful in different contexts: negotiating new services, negotiating SLAs, reporting service levels, support, planning availability and continuity, monitoring live systems... Ultimately the customers are the most important stakeholder in catalogue composition and content.
There are some crude samples of my own here http://www.itskeptic.org/sample-itil-service-catalogue-documents and better ones here http://www.servicecatalogs.com/
Any pithy advice you would add to this?
Made in New Zealand 
Comments
Don't go overboard
Most of the example service catalogs I've seen are way too granular. "Send mail"? Really?
In the real world the Service Catalog idea is key because it is a menu of "what we do". And now we can pin all of our internal processes to those service catalog items.
When you link the service catalog (what we do) to CI's in your CMDB (what we use to do it), and then layer your event/incident/problem/requisition system on top of that you get something pretty powerful.
Gettinng the catalogUE right.
Having done (or tried to do) catalogues for a few companies both as an employee and as a consultant, it becomes difficult when the services are offered to internal customers who do not pay for the service. It becomes a list of what IT provides and the level of service aimed for, without actually providing meaningful costs and on occassion without providing SLAs. More often than not, the internal customer (sounds dirty) is not bothered by SLAs, but just wants a good and reliable level of service. Therefore they struggle to understand why they need the catalogue and it can look as if IT are forcing more documentation on a company, which will never get looked at.
Using the catalogue as the basis for an online service request tool is a good course, as customers start to see the benefit and then open up to discussing it further.
However without the catalogue, it becomes hard to agree what will be aimed for. It also then becomes a tool for IT to use to justify additional spend.
Have I gone off topic here?
Service Catalog or Service Request Catalog ?
It could be interesting to distinguish Service Catalog (list of available services) and service request catalog (list of possible requests possible for users to gain access to Service catalog).
Service Catalog entry : Send Mail.
Service Request Catalog Entry : Create new email address, Add email address to whitelist, Redirect email from address 1 to address 2.
Confusion between Service Catalog and service request catalog usually makes service request management process and specifically self service portal implementations very complex.
pithy and proper
Plilippe, James: all good advice but not exactly pithy nutshell stuff :)
P.s. catalogUE please. We lost every other ITIL spelling battle to the US power base. Leave us this one vestige of proper English please.
Pithy and proper
Sorry Skep - beer keeps my pithyness away
pithy
Really? Beer makes me pithy... sometimes thoroughly pithed
Prices
A Service Catalog is like a menu.
A menu without prices is rather like an all-you-can-eat buffet.
Stamp out restaurant analogies
I disagree. The restaurant analogy is a facile one that we ought to stamp out. In ITSM, it is not unusual for customers to pay different prices. The menu is open to negotiation and the terms for each table of diners may be commercial in confidence. Therefore any "menu" (which is often a menu of requests not a menu of services) may well be a distinct document separate from the catalogue, i.e. the SLA contract
The only meaningful way to a catalog is thr the request
Just like you cant deliver excellent service without managing the experience and deciding what you will fail at, you cant create a meaningful service catalog without first building a service request catalog. Requests are the building blocks of a service.... customers understand these. They are also the fundamental elements of a service agreement. And they make it so much easier to promise things around.
Skep - the restaurant analogy is just fine - leave it alone. As is the brewery and hospital one. By the way, here in the US, the term service request is i common use - Google Service Request 311.... our local Indian has a 'request menu' for take-aways.... and a catalog should be a menu or brochure of services - actionable because you can order directly from it - why else have one... oh yeh - so you can show you have done something related to ITSM or ITIL... ho hum.
balance
OK I'll bite. let's consider the case where IT department hosts a core application used by multiple business units. What are the requests?:
- access to app (add change delete)
- app is broken
- run report XYZ
That list seems to me a pretty facile definition of a service which incorporates infrastructure management, account management, batch processing, data integrity, threat management, continuity, capacity planning... Sure the request list is informative when defining services, but I think it is a two-dimensional profile of a three-dimensional service. Just as one can be so inside-out that one disappears up one's own fundamental, one can also be so insistently outside-in that one explodes out of it. Balance is required between the two perspectives.
outsidein insideout continuum
Skep
Whatever made you think it was inside-out or outside-in. The OI-IO continuum (in new OI for service book due out shortly) makes it crystal clear we need both, its a case of where you start. You run the risk of wasting time, effort and focus by starting IO. As for facile definitions - if yoiu start OI you are sitting with those requesting stuff and documenting it in their language.... the obstacle for many is translating those into a 'service' because it seems we 'MUST' define services. We don't. In fact thats where many go off the cliff. I've said for years now - you do not NEED a service catalog (spelling!) to succeed at service management. Its a tactical, marketing decision.
Remember - "sell it the way they want to buy it"...