Branimir Valentic Let me introduce you to Alex, a young engineer who proved his competence and became an important member of his organization’s IT Service Management (ITSM) team. He got a new assignment – to create the Service Catalogue.
Although being thrilled with the respect and reward that his superior showed, very soon he asked himself – What now? Where to start? It’s one thing to be involved in the operational processes and functions like Incident Management or Service Desk, but creating a Service Catalogue sounds like something completely different. And, it is.
Where to start?
That’s (always) a good question. And an important one. Namely, you don’t have to be a multinational company to have different types of customers, an extensive internal IT organization, various processes in place… etc. These days, even in smaller companies that’s a common situation. Luckily, if the organization and its processes are based on ITIL principles or ISO 20000 Service Management System (SMS) requirements, there will be clear interfaces as well as inputs and outputs that can be of great use while setting up the Service Catalogue. One thing is important – once you create the first version of the Service Catalogue, those people responsible for maintaining it have to be aware of all possible changes in inputs to that Service Catalogue. Four main sources to get necessary inputs are:
Business – that’s the reason for the existence of both the organization itself as well as its IT organization. See it from two angles: internal and external. Internally, I’m sure that your organization has a strategy and/or financial plans that generate requirements for IT services. Usually, the management of the organization is responsible and highly involved in such plans through financial planning activities and the organization’s strategic plans and developments. Externally, the customer dictates your proceeding; i.e., they will set requirements for their service provider (your company).
Change Management – here I don’t mean changes that are the consequence of incidents, i.e., problems with the existing services. What I mean is that changes create new functionalities or significantly change existing ones. Since the Service Catalogue is your “menu” for your customers, all those changes must be integrated into the Service Catalogue. Otherwise – what’s the point of implementing an excellent (new) functionality on one of your services, if your customers don’t know about it and can’t order it?
Service Portfolio – this is, at least in theory, the most common source of information for the Service Catalogue. Namely, services that are in the pipeline, i.e., the development phase, will be chartered to the Service Catalogue with all relevant information about the service. But, that won’t happen automatically; the handover has to be well defined and prepared. This includes internal organization (processes and organization involved in service design and transition) as well as communication towards customers or the market in general (e.g., an announcement of a new service).
Other processes – they all exist to support your services in various phases of the IT service lifecycle. That means that every process has the possibility to influence your services, and that automatically affects the Service Catalogue. For example, Service Level Management is responsible for negotiation with the customer and service levels need to be entered into the Service Catalogue, or Demand Management defines service packages (two or more services offered together) and helps Service Catalogue Management to enter that information into the Service Catalogue. And, I would say, it’s unavoidable that Service Asset and Configuration Management ensures that the Configuration Management System (CMS) is up to date with all relevant information about the services and their assets (HW, SW, people, documentation… etc.).
Whom to involve?
Actually, you should involve everyone who can contribute with service-related information. It’s easier to gather the data needed for the technical part of the Service Catalogue (that’s the Technical Service Catalogue, i.e., a description of your supporting services; read the article Service Catalogue – a window to the world to learn more about different types of Service Catalogues). That would be your colleagues from Technical Management or Application Management functions or Product Managers for particular services.
More complex is the Business Service Catalogue, where you have to describe the services in easy-to-understand business language. Be careful – that’s the document that your customer uses. So, all colleagues involved in the business side of the services are your source of inputs. These are, e.g., people from Business Relationship Management, Service Level Management, or even Supplier Management. They have a business view and understanding of the services, usually speak business language, and are in contact with your customers.
Relevance of the resources
As you can see, there are a lot of resources to create your Service Catalogue. That’s good, but it hides potential pitfalls. The biggest one is a bunch of information that could overload the catalogue. That means that you have to be aware of what’s important (and to whom, i.e., for people inside your company or your customers) and avoid inserting a lot of information that no one uses. Another pitfall could be making the process of creating and maintaining the Service Catalogue too bureaucratic. Many processes, many different parties, and high complexity of the services can easily extend the process with unnecessary steps and information that are of use to – no one.
So, with all that said, Alex (remember from the beginning of the article) has an excellent foundation for his new task. But, life is not simple in general, and that’s true for Alex as well. Once he gathers all the information, the real work starts. And the headaches, too. What information is relevant, to whom, how to structure it… etc. And he can’t make any mistakes internally, towards his superiors, but even more important – externally, towards his customers. They know how to deal with un-useful information.
If you would like to check your compliance with ITIL/ISO 20000 requirements regarding the Service Catalogue, use this free ITIL Gap Analysis Tool and ISO 20000 Gap Analysis Tool.
