The Real Value of Service Catalogue
I recently worked with a service management organisation (in the manufacturing sector) that wanted to improve their service delivery. They asked me to help them with some areas where they had a clear view of what they wanted to do but were stuck about how to do it.
They had identified the need to build a ‘service catalogue’ – a practical list of their services delivered, organized in such a way that their customers could understand and also as something that their (IT) staff could use to work towards as a key set of operational goals.
This was a commendable approach. They had identified that the service catalogue would provide a single source of information on how their IT components rolled up into customer-experienced services. They would be able to use this to set targets and measure their performance. This would also be the basis for a support model and a service structure that would help their service desk to escalate issues more speedily and effectively, as well as providing the model for knowledge management. Most of all, this would help the IT management to create a more business focussed engagement with the customer base.
The catalogue would be the central model of services and how IT delivers this – all in all, a great idea. One other thing – ideally, they also wanted to use the catalogue as the model for request management, since they were also implementing a new IT service management (ITSM) toolset.
So What’s the Problem?
So far so good, you might think. In many cases, it can take several months or even years to get an organisation to the point that it (1) understands, (2) sees the potential benefits of, and (3) is actively seeking to do ‘service catalogue’. So you might think that this particular organisation that I was working with was well down the track of achieving this. The truth was, however, that they had been at this point for some time – some years in fact. They had made several attempts to implement a service catalogue and failed to do so, over a period of several years.
When I started to look at the work that had been done, it was clear that on a couple of occasions the organisation had come very close to defining highly workable and effective models for service catalogue; they just hadn’t managed to agree on a common approach, and then changed direction too many times. As a result, no decision had risen to the surface and been approved.
So all the planned benefits were waiting for the catalogue to appear and were duly all on hold in a work-based traffic jam of epic proportions. At the head of the jam was the service desk folk who were pulling out lumps of hair daily, trying to work with old tools, poor service data, minimal ‘joined up’ processes, and a lack of any service-based ownership.
Sound terrible or just sound familiar?!
It’s Not Unusual
The fact is that I come across this type of situation many times a year, and it’s been that way for many years past. It’s not unusual to find. Consultants are often brought in as the last resort, the final stab at making it work. I do sometimes feel like some kind of sorcerer or witch doctor, engaged with some skepticism but also great expectation as a final act of desperation… ”we don’t care how you do it (and maybe don’t need to know) but just make it work – please.”
This requires no sorcery or witchcraft, rather a pragmatic and collaborative approach.
For me the challenge in doing this kind of work is not so much what is done but how it’s done. So the format of the catalogue and service definitions is far less important than the process and project used to achieve agreement on it.
The value to many organisations of a service catalogue varies considerably – and this is reflected in many current debates around whether there is a benefit or use in having such a function at all. For some, there is no need to try and define ‘services’ as internal-facing entities, since the actual ‘service’ is often simply a technical capability or an external customer-facing service. Many organisations will get some benefits (as set out above as expectations), although this is not consistent in terms of outcomes and perceived value.
However, all organisations will benefit from going through the process of trying to work this out – and in particular doing this as a collective and inclusive project. Getting people together from different teams and perspectives will help to build a comprehensive set of service definitions and service views.
Engaging with support and development teams, IT and business management, and end users is a great way for all parties to get involved and understand different perspectives.
Working together to build the service catalogue will mean that more people will feel involved and therefore be more engaged in its use and development. These people, in turn, will also act as promoters and help to spread the word about how to use it and why it’s a good thing.
Learning and building knowledge as a group helps to break down barriers and build trust and mutual respect across teams.
It’s All in the Doing
So ultimately the output from this work may or may not deliver a catalogue as planned, but organisations and their people gain a lot through doing it. The solution for my client and for many other recent engagements, was simply to get people together and to ensure that the work done around service definition was shared and really collaborative. One of the reasons that the company hadn’t reached agreement was that in the various attempts to build the catalogue, there had been either too much or too little ownership. So either nobody had been ready to make a decision about what was a suitable structure, or on other occasions this had simply been done unilaterally by one or two people without any consensus.
Discord and disarray had given way to consensus and momentum, certainty and engagement – all this was done by ensuring that the ‘project’ was inclusive and decisive. It can help if there is an external facilitator to guide and nudge people along in this process – particularly to give them the confidence to know when they have built something useable and practical; however it’s not essential, many organisations can do this by themselves.
Additionally, to make service catalog work, I offer the following supplementary tips:
- Spend some time getting those involved informed or educated on key service level management/service catalogue concepts and principles. This saves a lot of time wasted going back over definitions and taxonomy.
- It’s also useful to do this learning as part of a workshop so that everyone is at the same level of understanding and the learning process is always good for bonding.
- Taxonomy should be what works for your organisation. It can be helpful to use ITIL, for example, and other best-practice terminology, however the key point is that everyone in your organisation and supply chain knows and understands your definitions, whatever they are.
- Services can be defined in a simple structure initially. A useful approach is to get everyone to write down all the things they think are services and then sort through these to focus only on business outcomes and key services. This helps to clarify the difference between IT system components and user/customer-based services.
- Regardless of approach for IT and internal-facing staff, customers must be involved in this process. Don’t bring customers in too early – before your IT people have worked through definitions and basic understanding. However, it’s vital to involve customers as early as possible to sense check your service structure.
Service catalogue can mean many things, in terms of delivery and value, to different people – it’s the work involved in creating it that delivers real value through collaboration.
