Neven Zitek As an IT Service Provider, according to best practice principles, you should have a list of services you provide. This document is called the Service Catalogue, and it’s the first thing you must have in order to be in the business (you can get more information on the topic from our following blog posts: Service Catalogue – a window to the world and Service Catalogue – Defining the service). Yet, I’ve seen many examples where IT service providers (mostly internal IT departments) don’t follow this practice, and the Service Catalogue is partial, outdated, or completely missing.
While it’s relatively simple to create a Service Catalogue, you may notice that each service consists of many parts that have to be individually managed in order to provide the service in question, and which are completely invisible to the customers. And this is the topic of today’s blog post.
Customer-facing services
Let’s look at the following example: as a customer, you’ve purchased an e-mail account that consists of a unique e-mail address, the ability to send and receive e-mail messages with other e-mail users, and a certain amount of server storage space in order to save your messages. Once that storage space is full, you lose the ability to send and receive new messages until you delete old messages or purchase more storage space. In the case of any issues with the service, you as a customer will contact service support and expect issue resolution within the guaranteed time frame. These are terms and conditions you accepted when you purchased e-mail service from your favorite e-mail service provider.
From the service provider’s perspective, e-mail may be just one of the services they provide. They may also provide user environment, an application store, printing service, network service, data protection service, backup and restore service, etc.
All of these are customer-facing services, listed in the Service Catalogue, available for end-users to purchase and consume. More importantly, these are the services that the Service Provider provides support for, and are subject of predefined service level agreements (SLAs – related topic: SLAs, OLAs and UCs in ITIL and ISO 20000).
Supporting services
What customers don’t know, and aren’t interested in, is that the e-mail service they use is dependent on various service building blocks, which may be other services as well. The whole IT (and non-IT) infrastructure required to actually run e-mail server software is completely obscured from end-users.
The e-mail server’s ability to exchange e-mails with others on the Internet is dependent on the Internet connection, which is provided by a local ISP. The service provider protects their user’s inbox from malicious programs, viruses and spam by using commercially available anti-spam / anti-malware filters, and they have the responsibility to prevent their users from becoming spammers as well.
These services aren’t visible to the customer, but the customer-facing services depend on them, and that’s why they are called supporting services. The whole purpose of supporting services is to use them as building blocks for customer-facing services.
Technical Service Catalogue vs. Supporting Services
The purpose of the Technical Service Catalogue (TSC) is to map the technical building blocks with customer-facing services. There is a flaming discussion within the ITSM community regarding how the TSC fits with the supporting services concept, as ITIL 2011 describes supporting services as “IT services that support or ‘underpin’ the customer-facing services. These are typically invisible to the customer; such as infrastructure services, network services, application services or technical services” – which implies that technical services are part of the supporting services.
Personally, I’m on board with that description, as it roughly describes the Underpinning Contract (UC), or Operational Level Agreement (OLA) – depending on whether supporting services are provided externally or internally. However, the issue arises for the technical services we (as an IT department and service provider) provide for customer-facing services. Does it mean we need an OLA between ourselves (individual department groups, e.g. between networking and server group) for each technical service we provide as part of the customer-facing service?
Figure 1 – Supporting services vs. Technical Service Catalogue
I’d say no, and I’ll borrow the Figure 1 from my earlier article ITIL Service Level Management – making sure that what you want is what you get in order to explain it bit better.
The bubble around the infrastructure represents supporting services that may be provided internally, by a third party, and/or even “core” technical services that make customer-facing services what they are (Service A, Service B, etc.). However, some of them (mainly core infrastructure services) are not services according to the ITIL definition, but configuration items (CIs), and this is where confusion arises. Can our daily jobs in managing the CIs be considered services? Not in strict ITIL terms, but for service design purposes, we may refer to them as “infrastructure services,” which consequently would mean they are merely supporting services.
Today’s IT business is getting more and more service-oriented, and technology and technology-based solutions are getting proportionally obscured from customers’ view. What we used to label as core infrastructure is, from a customer’s point of view, nothing more than supporting service hidden from his eyes. As IT service providers, we should nourish that point of view and embrace it. Technology is great, but what we do with it in order to bring actual value to our customers is what matters. And that’s the definition of the service.
You can also check out this free sample of the Service Catalogue Management process.
