ITSM Back To Basics – The Service Catalogue

Introduction

So here’s the thing. I’ve worked in IT forever and in ITSM for over 15 years and it never fails to amaze me how many failed or unused Service Catalogues there are kicking about out in industry. As a consultant I’ve seen and heard horror stories of clients paying upwards of £60,000 for a Service Catalogue they were told would solve all their problems only to be presented with a 2 page spreadsheet listing a few business services at the end of the engagement. As an Irish person who remembers the halcyon days of the Celtic Tiger, I’m calling this the ITSM industry’s very own “ah here” moment.

So what is the Service Catalogue and does it deserve all the hype?  ITIL defines the Service Catalogue as a database or structured document with information about all live IT services, including those available for deployment. The Service Catalogue is part of the service portfolio and contains information about two types of IT service: customer-facing services that are visible to the business; and supporting services required by the service provider to deliver customer-facing services. In other words the Service Catalogue is a menu of all available services available to the business. It also provides the real link between the business and IT; it defines the business processes based on IT systems enabling IT to focus on ensuring those services perform well. Not too scary so far right?

Purpose:

The Service Catalogue has two main purposes:

  1. To provide and maintain a single source of consistent information on all operational services and those being prepared to be run operationally; essentially acting as a menu for the business to order IT services from. An ex collegue of mine (waves to Pink Elephant UK) used to say that the first rule of ITSM is “always make it easy for people to give you money” aka the Hubbard – Murphy law of ITSM. How can we make it easy for customers to give us lots of lovely money? By giving them a sparkly menu of course.
  2. To ensure that it is widely available to those who are authorised to access it; in order to be effective the Service Catalogue needs to be front and centre of your IT operation so that it’s used consistently. Let’s think about it logically for a moment, if it’s not being used by the business, then what value is it adding? Exactly.

Scope:

The scope of Service Catalogue Management is to provide and maintain accurate information on all services that are being transitioned or have been transitioned to the production environment ie anything that’s live or about to be very shortly.

Value to the business

  • Provides a central source of information about the IT services delivered by the service provider organisation.
  • The Service Catalogue maintained by this process contains:
    • A customer-facing view of the IT services in use
    • A description of how they are intended to be used; in clear business centric language; there’s a time and a place for technical jargon and the Service Catalogue isn’t one of them. et’s not frighten the horses here.
    • A list of the Business processes they enable (this should be fron and centre – remember – make it easy for people to give you money, right?)
    • A description of the levels and quality the customer can expect for each service, preferable one that links to the appropriate SLA, OLA or contract.

Different Views

  • The Business Service Catalogue  – This contains details of all IT Services delivered to the Business (in Business language and available to the Business if required). The Business Service Catalogue should contain the relationships with business units and business processes that are supported by each IT Service. Typically these are in the forms of Service Level Agreements (SLAs).
  • The Technical Service Catalogue – This expands the on the Business Service Catalogue with relationships to supporting services, shared services, components and Configuration Items necessary to support the provision of services to the Business (typically this is an internal document so it’s not available to the Business). The Technical Service Catalogue focuses internally on defining and documenting support agreements and contracts (Operational Level Agreements and contracts with external providers or third parties).

 

OK, so that’s the basics covered, come back soon for our top tips on implementing a Service Catalogue successfully.

 

Image Credit

Rob England: What is a Technical Service Catalogue?

Amtrak 14th Street Coach Yard (Chicago, IL, US): A railway provides other functions: track gangs who maintain the trackwork, dispatchers who control the movement of trains, yard crews who shuffle and shift rolling stock. It is clear that these are not services provided by the railway to its customers. They are internal functions.

We are looking at railways (railroads) as a useful case study for talking about service management.

Last time we looked at the service catalogue of a railway.

We concluded that first and foremost, a service catalogue describes what a service provider does.

How often and what flavour are only options to a service or package of services.

ITIL refers to a technical service catalogue (TSC).  Where does that fit?

One thing everyone agrees on is the audience: a TSC is for the internal staff of the service provider, to provide them with supplementary information about services – technical information – that the customers and users don’t need to see.

But the scope of a TSC – what services go into it – is a source of much debate, which can be crudely categorised into two camps:

  1. TSC is a technical view of the service catalogue
  2. TSC is a catalogue of technical services

Those are two very different things.  Let me declare my position up front: I believe the answer is #1, a technical view of the service catalogue.  ITIL V3 was ambiguous but ITIL 2011 comes down clearly with #2.  This is unfortunate, as we’ll discuss.

Go back to what a service catalogue is: a description of what a service provider provides to their customers (and hence their users).  A good way of thinking of a service in this context is as something that crosses a boundary: we treat the service provider as a black box, and the services are what come out of that box.  A service catalogue is associated with a certain entity, and it describes the services that cross the boundary of that entity.  If they don’t come out, they aren’t a service, for that entity, depending on where we chose to draw the boundary.  To define what the services are, first define the boundary of the service provider.

Think of our railroad example from last time.  A railway’s service catalogue is some or all of:

  • Container transport
  • Bulk goods transport (especially coal, stone and ore)
  • Less-than-container-load (parcel) transport
  • Priority and perishables transport (customers don’t send fruit as regular containers or parcels: they need it cold and fast)
  • Door-to-door (trucks for the “last mile”)
  • Livestock transport
  • Passenger transport
  • etc etc

A railway provides other functions:

  • track gangs who maintain the trackwork
  • dispatchers who control the movement of trains
  • yard crews who shuffle and shift rolling stock within the yard limits
  • hostlers who prepare and park locomotives

It is clear that these are not services provided by the railway to its customers.  They are internal functions.

A railway provides track, rolling stock, tickets and stations, but these aren’t services either: they are equipment to support and enable the services.

A passenger railway provides

  • on train security
  • ticket collectors
  • porters
  • dining car attendants
  • passenger car cleaners

and a freight railway provides

  • container loading
  • consignment tracking
  • customs clearance
  • waybill paperwork

These all touch the user or customer, so are these services?  Not unless the customer pays for them separately as services or options to services.  In general these systems are just components of a service which the customer or user happens to be able to see.

So why then do some IT people insist that a technical service catalogue should list such “services” as networks, security or AV? (ITIL calls these “supporting services”). If the networks team wants to have their own catalogue of the services that only they provide, then they are drawing their own boundary around just their function, in which case it is not part of a technical service catalogue for all of IT, it is a service catalogue specifically for the networking team.  It is not a service provided by IT to the customer.

A technical service catalogue should be a technical view of the same set of services as any other type of service catalogue for the particular entity in question.   The difference is that it provides an internal technical view of the services, with additional information useful to technical staff when providing or supporting the services.  It includes information a customer or user doesn’t want or need to see.

A technical service catalogue for a railway would indeed refer to tickets and porters and stations and yard procedures and waybills, but only as components of the services provided – referred to within the information about those services – not listed as services in their own right.  I’m all for “supporting services” to be described within a service catalogue, but not as services.  They are part of the information about a service.  Supporting services aren’t services: they are component systems – CIs – underpinning the real services we deliver to our customers.

By adopting the concept of “supporting services” and allowing these to be called services within the catalogue of a wider entity that does not provide these services to a customer, ITIL 2011 contradicts its own description of “service”.

Service Design 4.2.4.3 says:

Supporting services 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.

Yet the in the prior section 4.2.4.2, such IT systems are clearly not a service:

IT staff often confuse a ‘service’ as perceived by the customer with an IT system.  In many cases one ‘service’ can be made up of other ‘services’ and so on, which are themselves made up of one or more IT systems within an overall infrastructure…  A good starting point is often to ask customers what IT services they use and how those services map onto and support their business processes

And of course it contradicts the generic ITIL definition of a service as something that delivers value to customers.  This is important because the concept of “supporting service” allows internal units within the service provider to limit their care and concern to focus on the “supporting service” they provide and allows them to become detached from the actual services provided to the customer.  There is no SLA applicable to “their” service, and it quite likely isn’t considered by service level reporting.

A railway ticket inspector shouldn’t ignore security because that is not part of his ‘service”.  A yard hostler should make sure he doesn’t obstruct the expeditious handling of rolling stick when moving locomotives, even though rolling stock isn’t part of “his” service.  The idea of “supporting service” allows and encourages an “I’m alright Jack” mentality which goes against everything we are trying to achieve with service management.

It is possible that Lou Hunnebeck and the team writing Service Design agree with me: that they intend there to be a distinction between supporting services and IT systems.  If so, that distinction is opaque.   And they should have thought more about how the “internal” services model would be misused- the problem I’m describing was common before ITIL 2011.

There is the case where the supporting services really are services: provided to us by a third party in support of our services to our customer.  For example, a railway often pays another company:

  • to clean the carriages out
  • to provide food for the bistro car;
  • to repair rolling stock
  • to provide the trucking over “the last mile”

Where we bundle these activities as part of our service to a customer and treat them as an Underpinning Contract, then from the perspective of the services in our service catalogue – i.e from the perspective of our customer – these are not services: they are CIs that should not be catalogued here.  If this – and only this scenario – is what Service Design means by a “supporting service”, I can’t see that called out explicitly anywhere.

Technical service catalogue should be a technical view of the services that we provide to our customers.  I wish ITIL had stuck to that clear simple model of a catalogue and kept IT focused on what we are there for.

Photo Credit