Close this search box.
Close this search box.
Service Catalog

Service Catalog: because it is more than just a list of services

Often a limited perception regarding the Service Catalog leads to consider it as a static list of services, whose usefulness does not go beyond the mere listing. In reality, it is a fundamental tool for managing digital services: let's delve together into how it helps us ensure that the offer always meets the needs of the organization and end users.

A superficial understanding of the Service Catalog and its essential function leads to an underestimation of its usefulness in the management of digital services, where the Service Catalog instead plays a fundamental role.

This limited perception often results in viewing it as a static list of services, whose usefulness does not go beyond the mere listing of the features offered. It is actually much more than that: it is a structured and detailed register that provides a clear and understandable view of the full range of services and their relationship to business processes and the needs of the business and its users.

Finding in a single source of truth constantly updated the essential information about the services offered, including details such as descriptions, conditions of delivery, requirements, costs, delivery times, and other relevant information has a twofold value:

  • EXTERNAL because it facilitates communication between service providers (including their business channels) and users, improving transparency, mutual understanding, and expectation management
  • INTERNAL because it enables better alignment with business objectives through continuous optimization of service management that results in efficient use of resources against a user experience that is always in line with expectations

From the perspective of ITIL (Information Technology Infrastructure Library) practices, the Service Catalog mainly refers to the practices of "Service Catalogue Management" and "Service Portfolio Management." In the latter, which covers the management of the entire IT service portfolio (so all of them, from those being defined, developed, and delivered to those in retirement), Service Catalog focuses on defining, managing, and publishing the catalog of services that are in transition or that are already available in the live environment, with accompanying information.

Let us now look in detail at what information we need to ensure that digital services meet the needs of the organization and end users.

Service Catalog: what information it must contain

Given that, according to ITIL, the main role of the Service Catalogue Management practice is to help the service provider focus on "customer outcomes" (the results expected by the end stakeholder) from a correlation between internal service activities, supporting assets (the CIs) and business processes, the first important distinction to make is about the type of service.

Within a Service Catalog, services can be divided into two main categories:

  • Customer-Facing Services : these are those that are directly visible and perceived by end users and directly meet their needs or requirements (e.g., customer support, access to online platforms, delivery of digital services, etc.).
  • Supporting Services: are those that support and enable the delivery of Customer-Facing Services but are not directly visible to end users. In short, they are internal services that work behind the scenes to ensure that core services are delivered effectively and reliably (e.g., infrastructure management, systems maintenance, network monitoring and security, etc.).

For example, users want to send and receive e-mail quickly and reliably. This is an example of Customer-Facing Service in that the user is directly involved in using the service and expects it to be efficient and fast. The Service Provider (in this case the IT team) manages Supporting Services to ensure that the mail service works properly without the user having to worry about the underlying technical details.

So if we talk about the management of routers, switches, firewalls, and other network devices that enable data communication, they are all invisible to the user: whether one mail provider or server is used over another, the user is indifferent as long as his needs are met. In this regard we can quote Philip Kotler, the modern marketing guru: "People don't want a drill, they want a hole in the wall."

In the image below, we see an example of how the two service types can tie in with each other and specifically with the business processes and users they support. A service can be listed individually, but also as a "package": in that case to compose it there can be a main service (core service) and one or more additional services (enhancing service). In the case of a "package" there may be a single SLA (service level agreement) to cover it, with the remaining services being covered by their own SLAs.

Service Catalog

The Service Catalog must provide a complete description of each service offered by the organization and include links to all relevant service components in order to provide a clear view of the assets, processes and systems involved in the delivery of each service.

To define, document and maintain these links accurately and up-to-date, the Service Catalogue Management practice must work closely with the Asset Management and Configuration Management practices. The Configuration Management Database (CMDB) is the central repository where information about assets, configurations and the relationships between them are stored. The Service Catalog must therefore be integrated with the CMDB to ensure that service information is aligned and up-to-date with respect to the assets and configurations that support them.

What is the benefit of this integration? By defining each service as a CI (Configuration Item) and, where possible, linking them together to form the service delivery chain, the organization is able to trace back upstream the domino effect that occurs with incidents or changes and consequently is also able to lay the groundwork for service monitoring and reporting (e.g., it can analyze whether the frequency of incidents affecting a particular service is related to a specific cause and take action accordingly).

In addition to the detail on service configurations and dependencies, it is also important to qualify how they are performing and how they will perform: this is where information such as Service Reports come in, which provide an overview of service performance (in close relation to defined SLAs and OLAs), but also discussions of any requests for improvement(Service Reviews) and their security rating (which can give an indicative estimate of the percentage of risk for which future service disruptions might occur).

From Service Catalog to BIA (Business Impact Analysis)

Since the Service Catalog provides a consolidated view of the IT services offered and their links to business processes, it becomes a key tool for BIA (Business Impact Analysis) activity: the assessment of IT service dependencies helps, in fact, to determine the risk (defined as probability per impact) and the financial, operational and reputational consequences that an IT service disruption could have on business operations.

The quality and completeness of the information in the Service Catalog will affect the effectiveness of the BIA: this is why a "top-down" approach should be favored when constructing the catalog (we also discussed this in this article on service management). Only starting from the analysis of strategic objectives will you be able to identify which are the key business processes and consequently which are the critical services that have a significant impact on the business and require special attention in terms of business continuity and risk management.

Otherwise, with a "bottom-up" approach where the catalog is built from what is detected by asset and configuration discovery and management systems, we risk failing to link the information provided into a strategic view of service relevance and criticality Let us remember that an asset is recognized as critical when it supports a critical service.

In addition to impact assessment, this approach has positive spin-offs in two respects:

  • OPTIMIZATION OF IT SERVICES MANAGEMENT: Starting from the top down, the services that have the greatest impact on the business and require prioritization in resources and investments are identified. This enables more effective allocation of limited resources, focusing attention on the areas that generate the most value for the organization.
  • ORGANIZATIONAL CHANGE MANAGEMENT: Digital services are designed to directly support business processes and user needs. Understanding their relevance helps define them with a more outcomes-centric focus and consequently facilitates the adoption and effectiveness of services within the organization.

Service Catalog: how to structure it

We recommend structuring the Service Catalog data in a single repository : even an Excel sheet with links to resources is sufficient to start with. In its presentation (since it must be easily accessible to all stakeholders), also keep in mind the target audience to which it is addressed.

For example, if the Service Catalog is for IT use, refer to CMS (or at any rate the tools that contain data on assets, configurations and their dependencies) for detailed information on technical/support services. If the Service Catalog is for use by end users (or otherwise by entities that support their promotion and sales), details on Customer-Facing Services could be made available through browser-based applications.

Service Catalog

Here then a world opens up: with a well-structured catalog it is easier to enable self-service management of services.

In constructing the Excel file (below an example template taken from the ITIL Service Design book), the service provider should consider which services (data rows) and which data elements or fields (data columns) should be included in each view. For example, which details about support services are important to include in a view for a technical staff and which are of no interest to end users (and therefore should be excluded from their view).

Service Catalog

Nel nostro webinar “DORA: Increase Operational Resilience with Service Catalog and Dependency Mapping” (vai here per guardare il replay) mostreremo un business case calato in un contesto bancario/finanziario.

Visto che entro gennaio 2025 le realtà del settore dovranno adeguarsi al regolamento europeo DORA (Digital Operational Resilience Act), approfondiremo con esempi concreti come un Service Catalog ben definito aiuta le istituzioni finanziarie a comprendere quali sono i servizi digitali critici e le loro interconnessioni, a beneficio di una migliore gestione dei rischi operativi e una maggiore resilienza in caso di interruzioni e malfunzionamenti.

Se vuoi sapere di più sull’argomento, guarda il replay sul nostro canale Youtube!

02-s pattern02

Would you like to receive support on Service Mapping Perimeter Analysis?