The sad thing is most of what you read or hear about the SerCat has little relationship to the real world. Of course there are people who want you, or convince themselves, that it is the most important thing ever. Usually this is because:
- They can charge you a lot of money for their product
- They can charge you a lot of money for a year's work helping you create a service catalogue
- Having spent a lot of money on a product and consultancy they aren't going to admit it didn't achieve anything - so if nothing else they'll claim it moved them to ITIL v3
Myths
Before talking about the truth I guess we need to address the two big myths,
"The service catalogue was the big innovation that distinguished ITIL v3"
Funny that, because back in 1993 we were teaching about the service catalogue on ITIL courses and you'll also find it referred to in PD0005, the BSi guide to Service Management published in 1998.
To be fair back then the guidance was so vague that you were pretty much on your own. The examples we used to hand out on courses were orientated towards sales and projects - so a new external customer or a new project starting up could be made aware of the options available to them in choosing new services. In the service catalogue you might find the gold, silver and bronze contingency options, and whichever one the customer chose would end up in the SLA.
The other thing to point out here is that much of the utility that ITIL now attaches to the service catalogue and portfolio would still have been done under previous versions of ITIL but under different headings. For instance we preached that CMDB and the cost model needed to be tightly coupled .Services were a "virtual CI" and output cost units equated to services. We also recognised that portfolio management was going on within the wider context of the IT department.
OK, that's a history lesson. It doesn't have a material impact on whether or not you should be implementing a service catalogue.
Unlike:
"Introducing a customer facing Service Catalogue improves the customer perception of IT"
What gets me about this one is that no one seems to ever ask the customer. Whilst I don't subscribe to the view that all of ITIL is too theoretical this is one case where I do think ITIL has lost touch with reality and swallowed the kool-aid of wishful thinking. It amounts to
"We think the customer should like it, so they must do"
So what happens in reality? The IT department spends a year producing a two inch thick document, or an impenetrable Sharepoint site. How does the business react?
"Wow, that's fabulous, after giving you millions of pounds year after year you can finally tell us what it is you actually do?"
Right
If you are a CIO who needs a service catalogue project to identify what you do for your customers I think you should seriously consider another career. Especially when, in the majority of cases, when the business open the Service Catalogue they find it almost totally inaccessible and that it talks about services in a language that is resolutely unaware of just how "inside-out" it is.
What the business actually think is:
"Are you telling me you guys didn't know what it is that you do?"
"There is nothing in here that I recognise as a service"
"How is this supposed to help me?"
"Well I won't need sleeping tablets anymore"
Now some of you will be thinking that this only applies to a badly constructed service catalogue and that a good one would deal with all of these issues. The problem with that is I still haven't seen an example of a "good" service catalogue that stands up to scrutiny.
Hands up here, I include the ones that I've occasionally been forced to write.
At this point let me quote that brilliant Irish comedian Dara O Briain at one of his less successful early gigs
'This is awful, I am causing you more pain than you are causing me.’
So let me suggest...
What You Really Need to Do
First of all take away from ITIL the bits that are good and useful.
- You and your customers do need to know what services you offer.
- Different audiences at different points in the service lifecycle need different views of your service portfolio
- Services are customer facing
- Services are what you should cost and price
The Architectural Review Board need a different view of your services to the one the HR Director needs, and that is different again from the one a service designer needs. What they all need is different from what you need yourself to manage services internally.
Database tuning is NOT a customer facing service.
If you can't easily integrate IT costs and process with the business cost model then you probably aren't costing services.
That's pretty much it really, but here are some more tips.
Understanding your services doesn't mean being able to look them up in a catalogue. Watch how a good salesmen sells. What they understand is the customer need and how they make the customer feel that need has been fulfilled. That means being able to engage the customer in a conversation about what a service means for them.
Make sure you understand the fundamental difference between an aspirational service catalogue aimed at customers and a transactional request catalogue aimed at users. Integrate the request catalogue with the service desk self service portal.
Understand that business services aren't simple to identify - the business operates a complex value network.
Understand how good cost models work and apply that thinking to your service model.
And most important of all...
If you are going to build a service catalogue "for the business" at least have the decency to ask them what they want it to look like and how they think they might use it.
.
Posts
Nice post.
ReplyDeleteShould "database tuning" ever show up in a catalog - even a 'technical' one? Or is that really just a feature of the "database service" - which includes other features like: installing, configuring, maintaining the database.
I suppose that is a "it depends" kind of answer - what is just a feature and what is a 'stand alone' service...
Should an organization start with the technical /component catalog, the user request catalog or the aspirational catalog - assuming they have none of them already?
Personally, I think starting with the 'technical' one might be the easiest...it is all "inside" thinking right? Once that is in place you can start to 'bundle' them into the other more "outside" thinking catalogs - but even that might not really be the best benefit of the 'technical' catalog. I'd imagine you would find a lot of technical redundancy/waste/misuse and find ways to consolidate, and create standardization and efficiency as well as get a better handle on how new technologies will replace/disrupt/contribute/enhance existing technologies across the enterprise.
I just can't quite yet understand the rush to create a "menu" for a customer if you haven't yet got your own house in order.
Stephen, I've been in that very position about database tuning and the catalogue with a client. The simplistic question is does the customer care and/or can the customer influence the specific service? I don't think they can.
ReplyDeleteI don't want to set Rob on his "you can't draw parallels from the consumer world" theme but when I order groceries from Ocado they don't tell me about how often they service their lorries. They might tell me something about their distribution network as part of a marketing campaign, but thats different.
Obviously the IT department needs to know about tuning, and that is where an internal catalogue MIGHT be useful. The question is what granularity is useful, does the value justify the effort, and are there better ways of achieving the same end. Who needs to know what about the tuning? It might be the only thing anyone outside of the DBA team needs to know is not to do a release whilst tuning is in progress.
Easiest, of course, doesn't always equate to best.
So...um... we do need to write down what our services are, right? Everything you said seems to agree that we need to know what our services are, and yet you have a distaste for writing that down? If business services are complex, if services are the foundation for our cost models, if we need a portfolio to make investment decisions, if different audiences need different views of the same service information, then how can agreeing and recording a common definition of what those services are not be important? How can we build new services without agreeing what they are?
ReplyDeleteI'm VERY confused.
I admit the last catalogue I did ran to 64 pages but that was because I lost control of the content to an internal project manager who was also a BA, and so the data model blew out. I wont make that mistake again. But those 64 pages included lots of white space and pretty presentation, and covered a complex government body with many services.
We also produced a version on two sides of an A4 sheet, folded into a brochure.
the catalogue called out that IT didn't own the information or systems, just stewarded them. That was a revelation to a number of the customers.
the catalogue called out that IT provides a wide range of professional services to the organisation, from tech futures to BA to change to project management. That was even more of a revelation and hadn't featured in any cost conversations before.
That was the wrong thing to do and a waste of 8 person-weeks of work?
Back in 2006 I went after CMDB as a dumb idea but I didn't talk about catalogue. That's because CMDB is a dumb idea and catalogue isn't. I can't believe we're even having this discussion. If you have seen crap catalogues that - to me - is motivation to do better catalogues not abandon them
Rob, We need to know our services. What we need to write down, and where is determined by whether it adds value. Most SerCats don't add value because they aren't designed as part of an integrated capability.
DeleteThe key thing with your examples is why on earth wasn't the IT department making the business aware of those aspects of service anyway, by engaging with them. Is anyone going to refer to the catalogue again, or was its whole value in being a conversation piece? Did it really need 8 weeks works to start that conversation?
I could argue that if you've seen crap CMDBs thats motivation to do better CMDBs not abandon them - but I suspect that in reality the problems inherent in the SerCat are pretty much the same ones as you think are inherent in CMDB.
BTW, did I say "Don't write down our services" ? I think what I said is that from the earliest days of ITIL we've been storing information and analyzing it in a service centric way. That's why we can produce monthly dashboards on service performance. I think we also need to recognise the massive role that enterprise architects have to play in this area and how TOGAF and OBASHI can both help us.
DeleteSlowly fermenting in the back of my mind is that there is a sort of ACM element to this as well and that a lot of my dissatisfaction with the SerCats I'm seeing is the way they want to shoehorn all services into a single template.
yes I'm aware that I'm getting dangerously close to the arguments about CMDB. I do believe they are different : it's not that CMDBs are crap, its that they aren't there at all, or are massively expensive.
DeleteThe service catalogue is a definition of your services. if you have defined your services you have a service catalogue.
Will you quit with ignoring that point please. Sure catalogues get too big and complex. i admitted as much about the last one I did, though it wasn't that bad. But a simple list is a service catalogue, it does not have to be some mythical 2000 page strawman.
it works. i've seen it work. others have seen it work. But more than that, you MUST define your services to move past the crudest levels of maturity. And whether you like it for your arguments or not, any definition of services is a service catalogue.
Rob, indeed, remarkable the similarities between CMDB and SerCat but you've missed out "or left unloved and unmaintained because they didn't live up to the initial hype" out of the list of possibles states of a CMDB.
DeleteI'm really not sure what point you think I'm ignoring, so I suspect it might be something peripheral to the main thrust of my argument. And just to make that clear, it is that project to "create a service catalogue" are on a par with "lets implement ITIL" It isn't a discussion about what constitutes a catalogue, though it is worrying that within the ITSM world people seem to ahve such a range of things in mind when they talk about sercat. So yes a list of services and their definitions would be some sort of sercat, but so what?
Underlying my position is that the value of the sercat has to be judged in terms of its long term utility.That long term utility comes from how the secat is used in context of other aspects of ITSM, not as an end in itself A simple list is unlikely to have that long term utility, and to be any use those definitions have to be pretty good - which I suspect takes you away from the realm of a simple task.
Oh of course it won't work if you don't know what and how to do it.
ReplyDeleteI made it work. It took about 3 months to get the act together - with help of a ½ time resource (service catalogue manager) crawling through the service organization, documenting everything on correct level AND with business mindset.
Customer response to delivered result: "This is the first time I know what I can get from you". Customers were corporate IT managers from different business areas.
You can find the presentation at
http://dl.dropbox.com/u/17212759/fasttrack2011.pdf - check slide 11 for bad doc of what we did, it was actually really good.
End results of this service catalogue work:
- business service catalogue on high enough level, written in business language
- end user (offering) catalogue for "orderable items" incl. info of Service desk. This consisted of an easy-to-use portal and an advertizing brochure of IT end user services
- technical service catalogue for IT internal use - mostly application management to find contacts to server services, storage, net...
Oh wow, I wouldn't have even come across the idea of putting database tuning in any service catalogue. That sounds like defining incident management or any other process as a service or in a service description.
"..without the ownership of specific costs and risks.."
I like this one, it gives good ideas - http://www.vanharen.net/9789087535711/the-service-catalog
Timo
Timo, thanks for the link, though to be honest it doesn't contain any real detail of what you did on the sercat front. For instance what did you define as business facing services? How did you distinguish between commodity services and those adding direct business value? What about services delivered to multiple customers with different needs? How did the sercat relate to SLAs and other data repositories? What use is the business making of the catalogue today?
DeleteLike so much else in ITSM the success and value of a Sercat can't be assessed in the short term alone.
I have seen Timo's TietoTapiola case in and my view is that they made a beautiful catalog of technical services and a bland list of vague customer services.
DeleteBut I can believe that making the catalog was useful both in Timo's and Rob's cases. I think the main value of creating a service catalog comes from discussions with the customers.
I'm getting cynical because when ever someone tells me about a brilliant service catalogue the reality always turns out to be on a par with the ones I've tried to create myself.
DeleteAfter 20 years at the heart of the ITSM world and with a background in audit I think I pretty much know what I'm doing, so if I'm struggling to produce SerCats that deliver long term benefit it makes me think. Everything I see and hear in favour of the concept at the moment is pretty much what I would have written a decade ago.
I also worry when people tell me how quickly they've produced a sercat, knowing how hard it is for the business to clearly identify their own services when they have a complex value network.
My overall point is that knowing your own services is important and communicating that to the business and having dialogue with them about the match of IT services to business needs is vital. A traditional sercat project just strikes me as an inefficient way of starting the conversation and the catalogue itself isn't a substitute for either IT or the business UNDERSTANDING what IT can and should do.
Love this article--especially the end. However, you need a spell checker really bad!
ReplyDeleteMore to the point I need a spell checker that works
DeleteThe Van Haren book is ok, good if you like complexity and detail. i prefer the Pink one http://www.amazon.com/Defining-Success-Through-Service-Catalog/dp/098108110X, I'm more into principles and big picture. It's too tools oriented (two authors from a tools vendor) but I can live with that.
ReplyDeleteI'm glad i have both :)