Organizations everywhere have some concept of workload automation. Documented or not, a service desk cannot operate efficiently without underlying knowledge of which teams should handle various Service Requests or what steps are taken when each Incident is received. Decisions that feed into this knowledge could be basic: “Judy in Level 3 Support knows who this should go to”. Or complex, like involving multiple teams and actions. The list goes on.
Unfortunately, most companies do not take the time or effort to (1) build out these processes into their ITSM systems, or (2) when they do it is built out as a one-off branch in the development processing. The result of these methods is often lost time and resources. An action such as creating a task for Judy wastes valuable time in the resolution of the ticket. Moreover, it doesn’t just spend resources on Judy or the support agent getting a hold of her. The developer who modifies the configuration when a new service is added or changed typically spends significant time configuring these changes, even before reaching a UAT stage.
A centralized workflow process can do wonders for the maturity level of an organization. By creating a workflow process that is adaptable and scalable, an organization can offload the decision making to the system. This is expanded further than just “The classification of the request determines what team it goes to.”, instead it says, “The classification and details of the ticket determine who is responsible for the ticket and who should be receiving tasks for each portion of its completion.” Depending on the ITSM tool used, you can turn this workflow automation process into a table or object that can be referenced through relationships, which makes it adaptable to serving the needs of multiple types of tickets, which in turn makes it centralized.
By configuring a centralized workload automation process:
Judy gets a task automatically without the support agent manually calling her or taking the time to enter a task for her.
If she had input into the design process, she may not need to receive a task at all. Instead, it goes directly to the team based on the ticket details and her knowledge.
In the complex example given earlier, workload automation can create task dependencies so that the teams and people don’t get their tasks until needed.
Since this is all determined via relationships and a table, developers spend much less time with actual configurations and can make changes with much less overall effort.
A process that has been given a lot of thought can also account for “conditional” activities, like onboarding processes where someone may or may not request a desk phone as part of it, or one where Application A needs different tasks depending on the access level/user rights requested.
By saving the effort on this limited list above, and then expanding it to other services as they are reviewed, organizations can save potentially hundreds or thousands of hours of employee effort each year, depending on the size of the organization. The benefit would be an iterative, meaning a repeatable reusable process, that can be developed for other processes throughout the business in a similar fashion. Through identifying where in your process most time is spent and how to automate it, it’s well worth the effort and it fuels maturity forward.