Service Catalogue is a single term that is interpreted and used in a number of different ways. It is a key area of ITSM that has grown in importance and relevance in recent years – both to define and manage IT Services and value, plus also as a means to automate and speed up service fulfilment.
Many organisations have embarked on projects and initiatives to build service Catalogues or one sort on another – in particular this has been supported (and in some ways driven) by the vendor market who have improved their capability and offerings in this area
There are a number of different terms and varied taxonomy in use in this area, particularly around different areas of Service Catalogue – e.g. technical service Catalogue, business Catalogue, user Catalogue. In fact these are different outputs and ‘views’ – basically of the same data.
‘Service Catalogue’ is quite a specious term that can be applied to a number of different entities. This can be a source of confusion and also of misplaced criticism of the actual Catalogue concept.
Essentially the Service Catalogue can be defined as follows:
- An automated portal for self-service and request fulfilment by users – this help to reduce lead times for e.g. IT ordering and can help to open up access to the IT organisation (and increasingly other departments)
- A strategic business level view of IT Services – that can help to clarify IT priorities and used as the basis for prioritisation, service reporting and service level management
- A technical repository of ‘supply chain’ information for the IT Service provider to use as the basis for management and delivery of services. This includes knowledge management, supplier and contract information, internal support and departmental responsibilities etc.
Detractors of the Service Catalogue fall into 2 main areas:
- ‘Old IT’ cynics who have been running IT for many years and can’t see what value the Service Catalogue can add, particularly if they’ve tried and failed to implement SLAs with their customers.
- Futurists who see no need to try to define services when technology and business has already moved on from the concept of IT Services.
So, let’s look at three key issues around the Service Catalogue that detractors like to make.
1 – We already know what to deliver
IT departments can argue that they already know what to deliver, so what’s the point?
Often they can’t say what they do or what value they deliver – so it’s helpful and vital from a strategic / business perspective. And the automation of request fulfilment speeds up customer response and reduced lead times, plus usually cuts support costs. Business level reporting cannot realistically be achieved without some service-based definition of what IT does.
At a simple level the Service Catalogue helps IT to be clear on its priorities and what it is there to deliver.
2 – It’s already been surpassed
The futurist view is that Service Catalogue is already out of date and unnecessary, given that everyone buys IT and we don’t need to try and shoehorn everything into an IT Service…
Service Catalogue as currently defined will probably be transitional — it probably won’t exist in 5–10 years’ time. The process of defining and developing a service focus is still useful for IT departments as part of a learning / development process. And self-service and automated fulfilment are essential and will continue to be areas for development.
3 – It’s often misunderstood
Certainly, the practical steps to implementation are not well defined. This is an area where ITIL training doesn’t provide much direct help. Also the multi-level nature of the subject can make it prone to misinterpretation.
As a general rule it’s good to be clear on taxonomy and local definitions/variations from the start. The simplest definition is where Service Catalogue is seen as the ‘live’ services actually running as part of the wider IT Service Portfolio.
9 top Service Catalogue tips
- It is not one single document or tool – the Service Catalogue has a number of stakeholders and outputs, so can be manifest in many forms. SLM is a process and approach rather than a single document or tool. ‘Service Catalogue’ is definitely not just ONE thing or ONE type of document or system. This is because organisations and individuals have different needs, different focus and also different entry points.
- The value is achieved from engaging with IT customers and IT departments – to work towards demonstrably common goals. Customers should be engaged to discuss service improvement, not SLAs or Service Catalogues.
- Successful implementation requires a collaborative approach – a service is in affect a supply chain that may cross several reporting lines. Customers/users need to be consulted and involved, as well as stakeholders across the IT ‘supply chain'.
- Workshops are a good way to get people involved with consensus and momentum – they are also a good way to achieve common understanding and e.g. agreed definitions/taxonomy around SLM and Service Catalogue concepts.
- Start simple and strategic – complexity will come. It is a good idea to aim for a single page view of services initially, in order to focus on overall end-to-end services and outcomes delivered, rather than starting at the technology level.
- The corollary to (5) is that some vendors and organisations do start at the unit technology level – this will work in order to develop a fulfilment catalogue but will not deliver strategic end-to-end service value.
- Most vendors provide not just tools but also useful data and content for Service Catalogue. This can save a lot of time in creating service records and data.
- A visual representation of the service (catalogue) structure is useful to build understanding – a picture can be vastly more descriptive than a 20 page document.
- Get started – too many organisations dither and prevaricate on this topic. The result will change and will probably never be perfect so it is useful to just get started and learn how to develop this by doing it…