14. 12. 2023
Service Management
If you don’t work in the field of IT service management, you might suppose that a service desk, and especially an IT service desk, is something quite standard… having similar services and a similarly structured support staff structures across all companies.
However, despite having (apparently) a very similar goal and trying to follow a common terminology and guidelines such as the ITIL standard for IT service management, each company has its own specific demands and processes put into practice for providing service to both their internal and external customers. These processes differ on the type of service given, the number of service requests, their distribution among services, the complexity of requests, etc. In addition, the level of expertise of the support staff members, the internal organization of the (IT-)department, and the concepts and architecture of the supporting tools have a decisive influence on the service processes being implemented.
All these parameters can of course evolve over time due to a changing market, staff turnover and management decisions. Often, these requirements also vary because they are initially not well defined, since stakeholders are uncertain or unaware of them.
“Self-Adaptive Systems” was one of the buzzwords during my years in research in software and requirements engineering. For two years now I have been “in industry” implementing service desk systems, mainly for medium- to big-sized companies (of course, relying on WürthPhoenix EriZone). Adaptation can be defined as a “change of system properties and behavior at runtime in response to dynamically varying user needs and resource constraints [1]”.
In this article I want to do an academic exercise, fusing the implementation of service request processes with ideas from self-adaptive systems. This article merely elaborates on this idea and does not put forth any scientific evidence. That’s why I have entitled it “Towards…”, reminiscent of the papers that are characteristic for Ph.D. students at the beginning of their research career (myself included: my first “Towards…”-paper, published in 2008, already has 111 citations 🙂 .
For an adaptive system, you need at least several different, well-defined system configurations (in our case, service request processes), and a set of decision rules that drive the selection of the right configuration when requirements and environmental conditions are undergoing change.
Thus first I define three basic configurations for service request (SR) processes, based on a 2-level-support paradigm:
- The canonical service desk as proposed in many guidelines:
- A skilled 1st-level support tier with a target of 70, 80 or 90% of resolution
- Second level experts that try to resolve the remaining complex requests and critical incidents for a customer, keeping the 1st-level staff in the loop
- The second-level-centered service desk:
- A 1st-level staff that manages the initial communication with the customer, but resolves only the simplest requests and incidents, and dispatches a large portion of them to the second level
- The (nearly) single-level service desk (call it 1st or 2nd level as you prefer, “1st” being probably the proper one, but “2nd” sounding much better to the experts providing the service).
- Requests are ideally dispatched to the right group of experts automatically and immediately after classification.
There are various reasons for selecting one process or another – they depend e.g. on the kind of requests, on the skills and organization of the staff members, and on the availability of documentation. As an example, I list here some of the properties of an organization that may lead to the selection of one process over another:
Process 1:
- A very strong team of 1st level service desk staff members
- High quality, thorough documentation and knowledge base
- A large number of SRs but with limited average complexity
Process 2:
- A smaller, less trained 1st-level support team
- Very specific requests where expert-level assistance is often needed
- Poor quality documentation
- Requests that need to be dispatched by hand to different experts or that need often to be split into sub-requests
Process 3:
- Mostly very specific and complex requests where experts are frequently needed
- The possibility of having a clear separation of services and a clear association between services and experts, to automate the dispatching of requests
- Few requests and/or no dedicated service desk staff
These are some parameters that can be used to decide which service-desk structure and process to adopt in a company. Of course, these parameters may change over time because of changes in the environment (organization, staff, services, type of requests), or because initially the requirements may have been imprecise or misunderstood. To implement an optimal solution for the changed situation, a new analysis would potentially lead to selecting a different process (or an intermediate variant).
The characteristics written above can be synthesized as a set of parameters, e.g. the average complexity of a request, the number and experience of staff members in the 1st and 2nd level support teams, the comprehensiveness of the documentation, etc.
Together with a set of decision rules, these parameters could be used to drive the selection of a service desk process variant. With these prerequisites a tool could be built to monitor changes and recommend a transition from one variant to another whenever substantial changes to the assumptions occur dynamically, allowing the organization to transit from one variant to another. This adaptation could in principle occur also semi-automatically.
With a smile, as in a classic “Towards…”-paper, I’ll just write that the quantification of these parameters and the definition of rules based on an empirical process is left to ongoing and further research. I’m happy however for any comments and thoughts on this subject. I would also be happy to receive comments on the three basic support structures presented and their respective selection parameters.
References:
[1] Mahdi Bashari Ebrahim Bagheri “Engineering self-adaptive systems and dynamic software product line” In Proc. 17th International Software Product Line Conference (SPLC) 2013.
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
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
04. 01. 2023
Asset Management, Unified Monitoring
Using GLPI with the Metabase Open Source BI Tool for Visualizing Rich Reports and Dashboards