Types of Tool Automation

Types of tool automation

The fundamental difference between a software tool and most types of tools is that software can be programmed to automate one or more tasks. Most other tools do not automate work at all, only extending the capabilities of the wielder of the tool. Certain mechanical tools can automate a task, but, without software they can do only what they were built to do and nothing else.

IT service management tools are essentially software tools, so their value is in their ability to automate. We can examine automation from two different perspectives. The first perspective concerns the automated processing of volumes of information that would be difficult, or very time-consuming, for humans to process. The second perspective concerns  the automation of specific tasks the humans perform too slowly,  or in a manner that is prone to error or tasks where it would be extremely inefficient to have human staffing to perform the task.

Processing volumes of information

Even the simplest of service management tools are adept at processing large volumes of information—volumes that would be difficult or extremely time-consuming for humans to handle. The simplest example of this would be the volume of incidents or the volume of events to be managed. In a typical IT organization, there are anywhere from 10⁵ to 10⁷ incidents per year. The number of events is at least two orders of magnitude greater. No single person can assimilate and handle such a large amount of data. The same is surely true of the number of changes and, for a more mature organization, the number of problems and known errors handled.

This observation is so obvious that even the simplest of software tools tends to be able to handle large volumes of data. (I distinguish between typical volumes of service management data and what has come to be called Big Data, which requires more specialized tools to handle appropriately.) Unfortunately, most IT service management tools hardly provide any more benefits than do these simple spreadsheet and database tools. They all allow for:

• recording large amounts of data in a structured format
• ensuring a certain level of validation of the structure, the integrity and the coherence of that data
• basic sorting, grouping, aggregation and calculations of that data.

 Automating human actions

The second type of automation takes specific actions that a human might perform and allowing the software tool to perform that action on behalf of, or instead of, the human agent. Most service management software perform a large number of such automations. However, the vast majority of these automations are trivial in nature. They are generally of the sort of lookups in related tables to return data based on a foreign key.

For example, a service desk agent types in the name of a caller and the software finds the person and enters that person’s organizational and contact details. A CI identifier is recorded in a change or an eventand the software finds that CI’s category and name of the support group (and how to reach that support group).

Sometimes, the software goes a step beyond, looking up relations from the related tables. A common example of this would be determining the agreed service level for a user based on the SLA in place for the organization of that user. But we immediately see that the reality is usually much more complicated than the simple lookups that software performs. It is easy enough to find the agreed service level for a single user; it is much more complicated to find the most constraining service level for all the users who are probably impacted by a given incident.

Indeed, some software is perfectly capable of making such calculations. Unfortunately, most of the organizations using this software are unable to configure the software to make the calculations correctly. And among those organizations that succeed in configuring the software correctly, even fewer are well enough organized to maintain that information correctly, in the face of constantly changing organizational structures and agreed service levels. In short, a very large number of service management tools are long on usability and short on utility. A few tools have some additional utility, but their usability tends to suffer.

This is part of the reason why a service provider organization periodically replaces its service management tools with a tool set that requires much less administration, and therefore costs much less to use. Unfortunately, such decisions are generally based purely on considerations of cost, ignoring completely the much more important criterion of value.

The Limits of the Human Automation Model

When tool automation is based purely on the model of how to help humans do their individual tasks more quickly and more accurately, such tools quickly reach a value barrier. This is due to the fact that work based on a human model iswork depending on a human brain, a human’s bilateral symmetry, a human’s hands with their opposable thumbs, the limits of human vision, hearing, touch, taste and smell.

There are historical reasons why technology generally replaces humans in a piece-meal fashion, thereby requiring that technology to emulate the humans work. But, as soon as the people are largely out of the picture, the technology is no longer constrained by the model of automating the way people work. Instead, the technology can focus on achieving the ultimate goals based on methods that the technology is good at. What does this mean from a service management perspective?

Much of the debate about choosing service management tools centers around the question of how to choose tools that support the processes in use. When an organization takes its first steps in using specialized service management tools, it can hardly avoid this question. In my experience, either an organization does a serious analysis of how it wants to work and then chooses appropriate tools to support that way of working, or it completely avoids that issue, making such spurious claims as “the tool will structure our way of working.” In the former case, there is a possibility for measuring the value of the tool, assuming some baseline is determined before the tool is implemented. In the latter case, the general outcome is a severe case of muddling, if not outright failure. There is no hope of measuring the value of  the tool.

Automation based on a machine model

From the moment that we imagine a future way of working that is not constrained by our current, human-dictated processes, then we can start to realize the true value of software automation. Instead of making productivity gains on the order of -50% (tools that make us work harder, without corresponding benefits) to +200% (tools that allow us to do in 1 second what would have taken 3 seconds), we can truly start to benefit from the historical promise of software automation. Measured in terms of productivity, automation should allow us to makes gains of 1000% to 10000%.

The so-called “best practice” service management processes are severely constrained by the weaknesses of the human organizations and individuals upon which they depend. Instead of trying to use tools to emulate feable humans, we should be trying to develop self-healing systems, which render the existence of incidents invisible; self-adapting systems, which recognize that the availability and capacity management disciplines advised by “best practice” are simply not fit for use (why else would hardly anyone use them?); automated testing changing systems that reduce risk by several orders of magnitude and make negative impacts trivial.