Service Catalogue\u2026 it\u2019s always an interesting, but controversial topic. There are many different ideas and views on the topic. It\u2019s hard to say which one of them is right and which is wrong. And, that\u2019s a good thing, because every organization is different, and so are the services (and the way) they provide.<\/p>\n
ISO 20000<\/a> does not set many requirements regarding the Service Catalogue, but ITIL<\/a> is more comprehensive. A lot of \u201chow\u2019s\u201d and \u201cwhy\u2019s\u201d can be found (you can learn more about the Service Catalogue according to ITIL in the article\u00a0Service Catalogue \u2013 a window to the world<\/a>. But, despite existing practice, the Service Catalogue Management process<\/a> (and the Service Catalogue document) put many challenges in front of the organizations and individuals who are involved.<\/p>\n Based on my experience with customers, there are a few challenges that most of the customers face while setting up the Change Management process<\/a> or trying to build the Service Catalogue<\/a>.<\/p>\n What are the services<\/strong> \u2013 that\u2019s what comes even before you start working on your Service Catalogue. You have to be aware of what kind of services you have (see the article ITIL Customer-facing vs. supporting services<\/a>\u00a0to get help with that), how many of them, and where they come from (learn more in this article Service Portfolio Management \u2013 Services, where do they come from?<\/a>).<\/p>\n Content of the catalogue<\/strong> \u2013 OK, so you have your Service Catalogue<\/a>. Are you sure that data (content) in your Catalogue precisely defines the services you provide? I used to find that customers have several systems where the data about the services are stored (including more than one ITSM tool). This leads to scattered data, which are a common source of error.<\/p>\n Usage<\/strong> \u2013 while I was responsible for the IT organization, I noticed that agreements with customers were made without taking the Service Catalogue into account. The point is that in the Service Catalogue you will describe the service, but also some parameters that are important while running the service, e.g., how to order certain functionality, what are the service hours, what is the escalation procedure, etc. I have witnessed situations where sales is usually trying to satisfy every customer need and often promising too much.<\/p>\n Keeping it up-to-date<\/strong> \u2013 changes are not avoidable. That\u2019s a fact and, I\u2019m sure, no one is challenging it. What\u2019s important is that all changes that happen with the services are documented in the Service Catalogue. Namely, your\u00a0services<\/a>\u00a0are also subject to change, because of, e.g., changing business requirements or additional functionality. So, it\u2019s important that all changes are included in the actual version of the Service Catalogue.Challenges \u2013 What are they?<\/strong><\/h2>\n
\n