Two sides of Service Catalogs – and why both are important?

What does “Service Catalog” mean to you? Is it part of your business service portfolio or just a list of “things” you can order from self-service portal? Maybe both or even more. Let us have a look at Service Catalogs as we know them at Justin.

What are we talking about?

Starting from the big picture, we are talking about Service Portfolios. The Service Portfolio tells us services we have in pipeline, up and running or already retired. It should include and manage the entire lifecycle of all services. Including 3rd party and “pass through” services provided as part of our offering. On the portfolio level, we should tie services into business strategy and value proposition towards our customers.

Live services in the portfolio can have elements in two different Service Catalogs: Business Service Catalog and Service Request Catalog. Following diagram illustrates the relationships between portfolio and catalogs.

Service Portfolio, Service Catalog(s) and Retired services

What is a Business Service Catalog?

Business Service Catalog provides detailed descriptions of all services that are currently available to customers. For every one of these services we should be able to answers questions like:

  • “what is included in the service?”
  • “who owns or manages this service”?
  • “how is it delivered and in what time?”
  • “what is the pricing model and how much is costs?”

On the other hand, we should know who is using the service and what is needed for delivery. For all this, we should find the answers from our Business Service Catalog or from several catalogs if split by business or functional area for example.

What is a Service Request Catalog then?

A Service Request Catalog is a collection of everything what a service consumer can request from a service provider. When you are using a service, you are a subscriber to a service and you might have access to different order forms and other catalog items. This is what we call Service Request Catalog.

On a high level, we have three kinds of requests:

  • Request for information: e.g. “Where can I find instructions for XXX?”
  • Request for goods: e.g. order a new laptop
  • Request for action: e.g. password reset or change of user’s contact information

All these requests are related to a service and therefore should be connected to Business Service Catalog. Below is an example what a record in Business Service Catalog vs. Service Request Catalog could look like.

Business Service Catalog vs. Service Request Catalog records

Why bother?

Many organizations struggle to define their business services and there is already a lot of work in developing the self-service portal and setting up the order catalog. But once you have all the pieces in place for one service, you will start to see the benefit and it is going to be easier for next ones.

Service Portfolio and Business Service Catalog gives structure and ownership to basically everything else. Proper business services work as an excellent categorization, reporting and escalation structure to several processes. Also by connecting “top tier configuration items” to “bottom level business services” your whole Configuration Management Data Base gets organized and becomes service aware.

Service Request Catalog is also much more than a collection of “order forms”. It is an important part of the customer experience and a valuable source of information for service development and planning. This “customer experience” must be planned as part of Service design and described as part of service descriptions. How service is delivered and experienced are also two different things 🙂

Service Description vs. Service Experience

What do you think?

What do you think about all this? All clear or maybe have some ideas or questions looking for a second opinion? We are having a webinar (in Finnish) shortly about this topic where we dig in a little bit deeper. Other than that, please do not hesitate to contact me or my colleagues around the topic via LinkedIn, email or phone and we are happy to help.

Julkaistu 16.12.2016

Mikko Juola

Service architect Read more

Related content