Why you need a Service Catalog

by | Sep 10, 2020

Before you consider to doing business with an organization, you first need to discover what they have to offer. You would like services and / or products to be organized and described in a way that makes sense to you, the (potential) customer. Law firms organize their offerings by fields of law like business law, family law or criminal law so you immediately know if they could help you registering a patent. A clinic will list the fields of medicine they practice and a car vendor will list the types (and brands) of cars they sell.

For the sake of this blog, let’s call ‘what the company has to offer’ a service and let’s call ‘the company’ a provider. So a provider offers one or multiple services. These services are described at a level of abstraction that makes sense to the customer (or user) and are combined into a collection that we call the service catalog.

In spite of this abstraction level, details matter. When you want to secure your home you start looking for a ‘home security’ solution. As soon as you find something that might be what you are looking for you will zoom into the details. How many camera’s are included, are these cameras wireless or do they need a cable, where are the recordings stored, how will you get notified of alerts etc. So you first start your search on a higher abstraction level and then zoom into the details. In a restaurant you will browse the menu for a dish (service) that sparkles your interest. Next, you look at the description of the ingredients and the way the dish is cooked. When you want to order something  specific, you first mention the dish and then the deviation from what is described in the menu. So you want the Greek salad, but without the olives. The service is the main subject of the conversation between provider and customer.

The service is the main subject of the conversation between provider and customer

As logical and straightforward as this all may sound, many IT organizations still struggle with this simple concept. They rather advertise and discuss the ingredients of their services (like hardware, applications and connectivity) rather than the service itself. If you work at a school and your responsibility is creating and maintaining the class schedules a service ‘Scheduling’ would probably make a lot of sense to you. When for some reason application ‘Classroom Scheduler 2.0’ is replaced by ‘Schedule Guru 2020’, the name and purpose of the service will not change. The planner does not need to know that the previous application required a dedicated server and a database while the new application is a cloud service.

So the first step in solving the disconnect between an IT organisation and it’s customers is defining services and hide complexity where it has no added value. Look for a useful segmentation of your users like business function or department and then describe what functionality you actually offer at an abstraction level that makes sense to these people. You might come up with services like finance, payroll, customer relationship management, quality management or scheduling. Combine these with commodity services like workplace, email, network access and document management and you are well on your way.

In a followup article we will further zoom in to the concept of child services and the role of the CMDB in this structure.

 

 

 

Related articles

More features, wrong reasons

More features, wrong reasons

When it comes to service management tools, more features means better. Simply because more features provide more options and the freedom to use the tools the way you want. Sounds simple, so what is the issue here? Let's further explore this idea with a simple example,...

Intelligent Swarming: prepare yourself for shift-left success

Intelligent Swarming: prepare yourself for shift-left success

This blog is a follow-up of a previous blog where we explained the challenges of most support organizations preparing for a shift-left initiative. As explained in that blog, the traditional tiered support model is no longer effective after a successful shift left and...

95% of all support organizations are not ready for shift-left

95% of all support organizations are not ready for shift-left

Most support organizations use a tiered support model for handling incoming requests. It all starts with level 1 (the service desk) and requests can be escalated to higher levels of support based on the complexity of the issue and the skills and knowledge of the...

NEXT STEP

TALK TO AN EXPERT