Service Catalogue – Collaboration Is Key!

There are many different interpretations of service catalogue – in terms of what it is and how it delivers value. The concept has been kicking around for a few years now, initially coming from ITIL v3, although in reality it can be applied more widely and fundamentally to a number of different worlds, and approaches to IT service management (ITSM) and DevOps.

One of the reasons that there are multiple ways of understanding and applying service catalogue is that it has a number of different manifestations. It is, in essence, a multi-functional and multi-level instrument. There are also different stakeholders, with varying output requirements, so inputs and uses of the catalogue are varied.

There are two main areas that are generally referred to and presented in ITSM and standalone service catalogue toolsets:

1. User Portal, which provides automated self-service, provisioning, request management, and other capabilities direct to IT users. Usually this helps to improve the speed and efficiency of request delivery, as well as offering a professional and user-friendly interface for users/customers to interact with the IT department.

2. Business Service Map, which provides the structure of business services that are delivered by the IT organisation, and used for service introduction and other internal IT processes and functions. Often this also provides the model for business-level reporting, as well as a framework for IT to build its transition and support processes and documentation.

In some cases, these examples are referred to as ‘views’ (i.e. the business view, IT view, and user view) and there are other potential outputs that can be created from the core service catalogue database, i.e. a data store of information behind a structure of services.

To me, there are also some different ways of looking at how these views or perspectives are created and in what environments. For example, sometimes the User Portal is seen more as like the DevOps approach, with the Business Services Map as the ITIL strategic view. And the DevOps view is now often seen as the modern and enlightened approach that bypasses the need for an old ITIL structure.

Where Do You Start With Service Catalogue Creation?

There is also the added complication around how and where to start, in relation to services and configuration items – both the ‘top down’ (start with business services) and ‘bottom up’ (start with an understanding what we have in detail) methods are evangelised.

Top down is essential to identify critical business services and service bundles for operational focus and reporting. Bottom up is necessary to build the complete picture of the IT estate and the linkage between components of services. Both are needed for completeness and to meet both strategic and technical requirements.

Currently, improved discovery and dependency mapping tools are making this approach less of an ‘either or’ challenge, as the process of identifying not only components, but also the links between them, gets more automated and less manually dependant. For many IT organisations, this offers the chance to have improved visibility of their service supply chain.

This is also empowering for many IT organisations who may feel that they’ve lost control over the management of their services. The service catalogue is a useful tool that helps to define what IT does and then provides a structure for managing that. It seems obvious but no one would sensibly run a service business without some definition of what services are being offered and at what levels of quality and cost. Internal IT departments are not businesses of course but they do need to do more to clarify and quantify their services. This makes the business of managing, delivering, appraising, and improving these services much clearer and unequivocal.

I have worked in many organisations where this discussion has been met with rolling eyes and defensive responses like “we know what we deliver, we’ve been doing that for 30 years.” In those instances, I ask groups of people across the organisation to write down what they do and deliver – and of course they all write down something different. From the CIO and business perspective, this demonstrates a lack of unity and purpose – okay, maybe most people across the team share roughly similar views on what is important and how this should be delivered, but as an organisation, it is high risk and untenable.

So the simple task of defining a single view of ‘what we do’ in our IT organisation can immediately bring focus, clarity, and practical steps towards consensus. There is huge practical and also symbolic value in having a single declaration (and associated repository of information) of what the IT team is there to do, for whom, at what level, when, who owns it, how is it supported, etc.

After all, if you don’t have a definition of what you are doing, how can you say that you’ve achieved success, or how can you identify improvement?

Consensus is Key

I often work with IT organisations where they have been trying for some years to implement a service catalogue. A recent example was an IT department who had been trying to make this happen over the previous 4-5 years.

From an external viewpoint, this might seem odd. In fact, there had been several decent attempts to do this by different people. One version looked to me to be practical, with some good representation of services and good work done on populating each of these services with service data. Other attempts involved useful work although the focus was more on documentation and detail. Regardless, there was a lot of good work already done, yet somehow it hadn’t come together and been agreed as a way forward.

So what was missing?

Firstly, there had been little actual customer interaction – which of course is key. So that was going to be a vital element in improving the chances of success.

However, the bigger issue was that the fact that this had not been done collaboratively (read: together). A simple and key concept to bear in mind when building service catalogues and SLAs is simply this: Doing it together makes it work.

An initial summary document represents agreement. A definition of ‘service’ and ‘our services’ is far more likely to take hold and be used if this is defined collectively and collaboratively, and there are a number of reasons for this:

• Collaboration across teams is essential for all aspects of service management. Too often ITSM is thought to simply be the service desk, whereas of course all teams, internal and external, as well as customers, need to be involved in defining what a service consists of, how it is prioritised, and how it will be supported.
• Many people have widely differing views on what the services are and how they should be provided. A collaborative and inclusive approach will help to bring these views into a single focus.
• Similarly, there are often numerous interpretations and understandings of what service catalogue is. Part of the collaborative approach should involve some basic shared education, agreeing on definitions, taxonomy, and what it all means within your organisation. This saves considerable time and effort that can be wasted if groups and individuals aren’t working towards the same goals and criteria.
• Simply – collaboration is a practical and effective means to move forward. It may seem obvious, but engaging with and involving a variety of people and groups helps to build buy-in as well as consensus. Everyone could come up with their own definition of services and the catalogue, but the point is that organisations need to work together, and with their customers, to build their service catalogue.
• The service catalogue documents therefore represent a shared view and is the result of collaboration, discussion, and agreement. The process of creating it is where the value lies.

The organisation I mentioned above used some simple workshops for shared education and service definition, initial customer meetings, and forward planning on how to pull together the information gathered. The key change for success was around actually collaborating to do this and not working in isolation.

So, when we talk about building a service catalogue, make it our service catalogue (emphasis on the collective notion). Also when talking about SLAs, bear in mind that the third word in the acronym is ‘agreement’. Agreement is a result of collaboration, which is the current buzzword for how organisations need to work. The service level management process has been crying out for that for years.

Image credit