29. 11. 2024
Atlassian, Service Management
23. 08. 2022
Mirko Morandini
Service Management
Should I Implement a Complex or a Lightweight Service Catalogue?
Creating a “Service Catalogue”
What do you do all the day in your IT department? You provide services, in this case IT-related services, to the employees of your company. This includes the personal services for each employee, depending on his/her position and tasks (computers, software, internet connection, etc.) and all the strategic services for running the company, from the mail client to the ERP system, from servers to the network infrastructure.
As the years go by, the typical IT department gains more and more responsibilities, including for “borderline” IT activities, such as door openers, the alarm system, the delivery of mobile phones, etc.
Have you ever tried to list all the services that your department offers? No?! Well, you’re not alone… Give it a try! I’m sure that you offer many more services than you imagine you do. Let’s try to categorize them:
- All business applications (ERP, BI, CRM), plus other specific applications needed in your company
- Networking and communication services, from mobile to internet connections, VPN, and VoIP
- The employee’s personal workplace with PC, monitor, accessories, the standard software, etc.
- Printing, scanning, and copying devices
- Meeting rooms with their multimedia and VoIP devices
- The IT infrastructure which keeps many of these services running
- One aspect of facility management such as access control, alarm systems, the server room, etc.
With just these categories you’re probably able to cover most of the services you provide (however, this is just one out of many possibilities for grouping your services).
At this point you could go into much more detail: listing all your business applications, involving your colleagues in the process as well (I’m sure the list will be much longer than you would expect!), the hardware that someone might request for their workspace (What about headphones? Drawing tablets?), all communication devices and software, etc.
TL;DR just jump to the next section 😉
Now that we’ve got a huge list of services, we’ll need to get some additional information about each of them in order to build our service catalogue:
- A description of the service and its boundaries (Is your department responsible for replacing printer toner, too?)
- Who is responsible for running the service, for improving it, for restoring it after an interruption
- The cost of the service and the impact of service outage to your company’s business
- Service Level Agreements (SLA): interruption times, times for resolving a request on it etc.
“Huh, that’s too much work! Who would ever write down such a detailed service catalogue?”
Probably nobody in small to medium companies… however it’s a must for large companies where services are provided by a collaboration of various departments, where costs of single services and outages need to be quantified and charged, and where the service catalogue is the only source of truth for an outsourced service desk.
“So, that’s useless for me!?”
Not at all! You clearly need to formalize the services that are outsourced and the services that you yourself provide to external customers.
“And all the rest?”
Prepare the list of services and define who is responsible for each group of services, and who will provide support for them. Keep this list up to date, it will be essential for your department!
The Service Catalogue in an IT Service Desk System
Now that you’ve created a list of services, how detailed should it be, and how should it be integrated in an IT Service Management (ITSM) application?
In most ITSM Applications, a customer request (“ticket” or “issue”) can be categorized with a service and a request type (i.e. the “ITIL” types Incident, Service Request and Request for Change). The categorization needs to be done manually by a service desk operator or, ideally, by the customer.
Categorizing the tickets can be a rather heavy task, depending on the structure and the granularity of the implemented service catalogue. But why should you categorize a ticket? There are several reasons to do that:
- To automatically dispatch incoming tickets to colleagues or departments
- To create reports
- For problem management
- In a self-service portal, to guide the requestor, to provide templates, FAQs, etc.
And this is the source of the main question that made me want to write this article:
Should I implement a slim or a detailed service catalogue in my ITSM System?
Is it “better” to have only 10 simple, general services for a fast and simple categorization, or a complete catalogue with 50 or 100 services?
I’ll answer this question according to the four purposes identified above:
A. Automatically dispatching work to colleagues or departments
This is essential. Here, the granularity of services needs to respect the areas of competence in your IT department to be able to dispatch requests correctly. However, in an SME you probably won’t have more than a dozen of areas of competence.
B. Creating Reports
Long lists of services are often motivated by the need to create reports. However, in a very detailed catalog, there’s not enough data for the single services to show representative statistics and the error rate is high. Most reports will finally group services to generic categories, so keep the number of services low!
C. Problem Management
“I would like to know which service gets the most information requests, so I can organize trainings.” I often get such requests, but it’s usually not enough to rely on the service catalogue for this – the services are usually too different from each other. Thus, this shouldn’t be the main reason for forcing anyone to categorize each request in a huge catalogue.
D. A Self-Service portal
If you offer a self-service portal to your customers or colleagues for opening tickets, they need to be able to find the “right” place to easily submit their requests. Would it be better to have a lightweight or a detailed service catalogue to aid the customer in their selection, to promote the use of the portal, and to ensure a correct classification? The self-service portal is a main driver for the definition of the service categories an ITSM system! Let’s look at it in detail.
The service catalogue in the self-service portal
Ideally, a customer should be able to classify a request correctly by him- or herself. There should be no need for time-consuming corrections and completions. This implies that a customer should be able to find what he or she needs, not only in a short amount of time, but also with confidence and without ambiguity. Of course this depends not only on the catalog, but also on the visualization and searching possibilities provided by the software. Let’s look at a few examples:
A very small catalogue:
A very small catalogue could for example just contain three entries reflecting three competence centers (to be able to dispatch the request correctly) of the imaginary company ACME: “business apps”, “personal workplace”, and “network and infrastructure”. This grouping of services may be clear for the IT staff, but a normal employee won’t know e.g. that Outlook is handled by the “personal workplace” group. Moreover, he will never know which services are offered. Would it be correct to ask the ACME IT department to replace the toner for a printer? To bring paper? To bring coffee?
A heavy catalogue:
Here, you can find everything, you just have to search for it. And this can be time consuming, depending on the type of interface: a plain list, cascading dropdowns, a search bar, etc. However, when you find it, you can be confident that your request will be placed correctly. But if you don’t find it, then with high probability it was either under a different name, or it was just plain forgotten. Some people may get discouraged and after that refuse to use the portal.
The verdict
What conclusions can we draw from all these considerations? As so often, “it depends”!
In applications that also manage heavy catalogues, keep it simple and group your services together! In a hierarchical structure, two to three levels should be enough. Be aware that the reasons B (reporting) and C (problem management) mentioned above should never be something that leads to complexity and loss of time (exceptions prove the rule 😉 )!
In applications that just offer the concepts for a lightweight catalogue, it’s still important that reason A (dispatching) is fully covered, and that users are able to place their requests with confidence that the requested service is covered. For this, the catalogue can be greatly improved by adding a visual description for each service. If the application offers a search functionality that includes these descriptions, in my experience the resulting catalogue can be surprisingly simple and complete at the same time. This is exactly the case with Jira Service Management:
These Solutions are Engineered by Humans
Did you like this article? Does it reflect your skills? We often get interesting questions straight from our customers who need customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth Phoenix.
Mirko Morandini
Mirko Morandini, PhD, is part of the EriZone team since 2015. As a consultant, he guided the implementation of EriZone in various projects in the DACH area and in Italy.
Author
Latest posts by Mirko Morandini
23. 12. 2024
Asset Management, Service Management, Uncategorized
GUI-based setup of GLPI Network Inventory: The Agent Toolbox
16. 12. 2024
Asset Management
GUI-based GLPI Network Inventory Setup with the “GLPI Inventory” Plugin
01. 07. 2024
Asset Management, Unified Monitoring
It’s Time to Move from OCS to GLPI Agents + Exclusive GLPI News for You!
14. 12. 2023
Service Management
EriZone Servicedesk: Upgrade to RockyLinux9/RHEL9 (CentOS7 EOL in June 2024)!
06. 12. 2023
Asset Management, Service Management
Würth Phoenix is a GLPI Gold Partner! Exclusive News from GLPI Partner Day