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:
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:
“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!
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:
And this is the source of the main question that made me want to write this article:
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:
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.
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!
“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.
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.
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 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?
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.
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:
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.