If you look at the agenda of recent IT Service Management events, you might notice that the service catalogue has become a very popular discussion topic and it’s obvious that more and more IT organizations are seeking to implement the often so-called ‘missing link between IT and business’. However, having participated in some of these discussions, I was surprised how often they were limited to a nicely looking service brochure or in best case a shopping cart in place. One reason for this might be the misleading word Catalogue, which makes people automatically think of a shopping cart as the only purpose (this is why I actually prefer the term Service Map). In my opinion another reason is ironically the ITIL Best Practice framework itself, which was so far not able to link the IT Service Management processes consequently into the service catalogue, – which is in fact the ‘core’ of what you provide to your customers. Service Catalogue Management and the resulting catalogue is not just another ITSM process and process result which needs to be ‘Under Control’, it is in fact the backbone of the whole Service Lifecycle – together with the Service Portfolio Management. Please allow me to make it clear with some examples:
- The Service Catalogue with it’s elements is the base to determine what are the actual full costs of your services and therefore part of any service ROI calculation
- It is a prerequisite for negotiating and agreeing service levels (warranty) with your customer
- Without a service catalogue you will never understand what happens to your business if certain service components fail
- Going down to IT Operations the service catalogue will help you to categorize your Incidents and Service Requests in a meaningful way and handle them properly
I would like to highlight the role of the Service Catalogue along the IT Service Lifecycle as follows.
Service Catalogue Management – A Wrap Up
Let’s first do a short wrap-up of some core definitions around Service Catalogue Management (Please skip this section if you are familiar with it). According to Best Practice, the purpose of Service Catalogue Management is to provide and maintain a single source of consistent information on all operational services and those being prepared to be run operationally, and to ensure that it is widely available to those who are authorized to access it. Logically, it is embedded into the more strategic process Service Portfolio Management, which has a wider focus by deciding which services you actually want to offer as an IT service provider and which not. The result out of the Service Catalogue Management process is the Service Catalogue, which is basically divided into two connected layers:
- Customer-facing services: IT services that are seen by the customer. These are typically services that support the customer’s business processes, directly facilitating some outcome desired by the customer. An example for this is an SAP HR application service, which supports the HR process of a company.
Always keep in mind: A service is a means of delivering value to customers by facilitating the outcome customers want to achieve, without the ownership of costs and risks.
- Supporting services: (sometimes also called ‘service components’ or ‘enabling services’): IT services that support or ‘underpin’ the customer-facing services. These are typically invisible to the customer, but essential for the delivery of customer-facing IT services. An example for this could be the network, which is needed in order for the customer to access the email-service (customer facing). This layer usually can be linked further down to other CI, in our example routers, switches etc.
The Graph below nicely illustrates the link between the business processes, customer-facing and supporting services:
What to use it for?
In order to answer the question what use is the service catalogue, it is important to put it into context of other ITSM processes along the service lifecycle. You can get some interesting ideas on this out of my first blogs (‘Don’t forget the Service Lifecycle’). Basically the ITSM processes give you some guidance on how to manage the IT Services, but you should link them into the actual services (which in turn is something coming out of the service catalogue). This is also why it is the backbone of the Service Lifecycle. I will to go through the most prominent examples as follows:
Service Level Management (SLM): By agreeing, securing, monitoring and controlling service level agreements (SLAs), the SLM process is a key player around ensuring service quality. What is often not understood is that SLM is just covering the warranty-aspects of a service, meaning on how good they are provided (typically this will be the service availability, e.g. 99.9991%). The definition what is delivered is always defined through the services that have found their way to the service catalogue through service portfolio management.
Incident Management: If it comes to the point that an IT Service is interrupted, the Incident Management process steps in to restore normal service operation as fast as possible. The essential steps of this process include having an understanding of the incident category and priority of each incident. “Which service is affected by the incident?” is here the leading question, and of course you can only answer this if you understand the services which come out of the catalogue. In addition, the critical aspect of a service, which also should be included in the service catalogue, is the main source for the proper prioritization of the incident.
Financial Management: Identifying and quantifying IT cost drivers such as infrastructure elements and humans resources is fairly easy, but has only limited informative value. What is much more interesting from a service-perspective is to determine what are the actual costs and value of your services. This is where the service catalogue comes into place. It shows the link from the actual customer-facing service to IT service-components down to each infrastructure CI. This is how you are able to recomposition your costs into true service costs.
Request Fulfillment: The service catalogue plays a central role in the Request Fulfillment process. Each request to the Service Desk should have a clear link to a service that is offered to the end user (->Service Catalogue). This becomes especially important if you automate your Request Fulfillment process through a self-service portal. The end user can order the service directly out of the service catalogue, each one with clear service levels attached and automatically linked to the underlying service components (which)
Event Management: The most critical success factor in Event Management is to have the right rules in place to separate the events that have a meaning for the management of the IT infrastructure from the events that have just informational character. By having an understanding of the services and how they are made up from an infrastructure perspective (something you get out of the service catalogue), you are definitely able to measure the right events and set the right thresholds.
Availability Management: Similar as in Event Management, you can look at the service catalogue from an availability influence perspective. E.g. which are the service components that make up the e-mail service and what happens if they fail? Modern availability dashboards are based on a service catalogue, because they show the availability of the IT Service by linking them end-to-end from business view (customer facing) down to IT Infrastructure.
IT Service Continuity Management (ITSCM): In order to manage the risks that can seriously impact IT services (which is the main goal of ITSCM), you first need to have an understanding which IT Services are critical to the business (Business Impact Analysis). The Service Catalogue is the main source for this, because it shows the link from IT Services to Business Processes.