In-Depth
Debunking IT Process Automation Misconceptions
Due to macroeconomic conditions, nearly every vendor promotes its products as offering cost savings, but the ROI calculations for IT process automation are overwhelming and simple.
by Travis Greene
IT process automation (ITPA) technologies currently save companies around the globe millions of dollars by eliminating repetitive manual operations and security tasks. Yet there is still significant skepticism surrounding this technology, keeping many organizations from achieving the benefits it can deliver, including proven return on investment (ROI) -- usually in less than twelve months -- as well as continuous, additional ROI with each new automated process.
Many are still unfamiliar with ITPA, although analyst firms such as Gartner (which calls it run book automation or RBA) have tracked it for years. Gartner goes so far to say that RBA will reach mainstream adoption in less than two years in the recently updated Hype Cycle for IT Operations Management (see Note 1). Conversations with analysts, customer meetings, and speaking engagements have reinforced my experience that after IT managers are introduced to the concept, some common concerns routinely arise.
This article addresses these misconceptions surrounding ITPA and details the realities, showing that these concerns are unwarranted.
Misconception #1: The cost of implementing ITPA outweighs the benefits
With today’s budget realities, a tool investment must achieve ROI as rapidly as possible, typically within 12 months to justify purchase. Given the timeframes often associated with large process implementation projects, there is concern that the time and cost to build and automate processes could outweigh the ROI.
In reality, the scope and inter-dependencies of IT management processes, such as those defined by ITIL, can be very disruptive and costly to put into practice, but implementing an ITPA tool can target and solve more specific problems. In practice, customers usually see ROI in less than one year with the first two or three automated processes. These processes can be as discrete as managing requests for new virtual machines or auto-resolving a known error.
The advantage of ITPA is that each new automated process improves ROI through manual labor reduction. Once the software is in place, the ongoing cost is primarily the time of staff members assigned to build new automated processes. As organizations automate more processes, ROI continues to grow.
Misconception #2: ITPA cannot be used when processes are not well defined
Because ITPA utilizes terms such as “process,” ”workflow,” and “run books” to describe the technology, many believe they must have mature processes to take advantage of ITPA.
Although it's true that an organization must document a process before it can be automated, the process need not be "well-defined" prior to implementing ITPA. Many processes exist in the minds of administrators or operations personnel and make up the tribal knowledge of the IT organization. These are often micro-level processes that can be readily captured in the workflow designer of an ITPA tool and automated faster than macro or organization-wide processes, such as change management. As an IT organization matures, it can build upon micro processes to better automate macro-level processes.
For example, patching a server can include micro-processes for taking snapshots of the virtual machine, removing it from load balancing, deploying the patch, rebooting the server, testing the functionality, re-enabling load balancing, and updating the request for change (RFC) with the results. One macro process can coordinate these independent micro processes, which is then triggered by an approved RFC that includes all the inputs necessary (such as the patch and machine names). This approach allows organizations to design micro processes (which have their own time-saving value) first, and then re-use them for greater future value.
Misconception #3: ITPA requires skilled staff to design and maintain processes
When deciding on the purchase of any new operations tool, many IT organizations assume that existing staff can take on the additional responsibility of implementing and maintaining it. This is often an incorrect assumption, but ironically, most organizations considering ITPA have the opposite view -- they assume their existing personnel have neither the skills nor the time to design and maintain process automation.
Gaining value from ITPA requires staff dedication to build and maintain the automation, so this time must come from somewhere -- existing staff, a new employee, or a consultant. However, automation also frees up time. In fact, process authors can automate themselves out of other jobs into a full-time automation role.
Also of concern is the skill level required. This is the biggest challenge to overcome. Despite the lip service paid to ITIL, many in IT still consider process a foreign language. Designing good automated processes requires both technical and logic skills, with a dash of ability to communicate effectively with different parts of the IT organization. Finding someone with all these talents may be difficult, which is why some organizations make this a split role -- they assign someone part-time to interview requestors and document process steps, then turn that documentation over to a more technical person who can build the automation on a part-time basis. The backlog of automation requests (and the associated benefits), though, usually results in an obvious decision to dedicate both full time to automation work, enabling faster automation and ROI.
Misconception #4: Staff must be cut to benefit from automation
The key value that automation delivers is reduction in manual labor. Does this mean that staff member reductions must be made to gain ROI from an ITPA implementation?
Although reducing staff is one possible path to ROI made possible with automation, it is not the only way to obtain value. If your organization is growing, you can add fewer staff than previously required. If automation replaces the need for one role in an organization, that individual could be reassigned to another role, perhaps in innovating other new services or cost-saving initiatives.
Cost savings must factor into any tool purchase in today’s economy, but there are other benefits for ITPA:
- Documenting tribal knowledge reduces the risk of knowledge flight
- Enforcing consistent process execution produces higher quality services
- Faster response to service requests makes the business more productive
- Finding process improvement opportunities through ITPA reports enables continuous service improvement
Misconception #5: The political boundaries to implement and automate processes are too great
As ITPA tools interact with different groups and their different tools, there is potential for political boundaries to arise where tool owners refuse to allow integration with “their” tools.
To address this, ITPA embraces the “best-of-breed” approach, allowing each group in IT, such as database administrators or network administrators, to utilize the tools that work best for them. Even so, there are still management requirements to have cross-organizational integration between tools to support efforts such as availability reporting, troubleshooting during incidents, or resource planning.
ITPA integrates at a process level, calling on other tools to execute a step in the process, or populating documentation details only as necessary to support the process. This means that a process to collect availability data and store it in a central database can be run on a schedule without having to grant permission to a manager on every tool in the environment, and without having to replace existing tools that already provide value. Ultimately, this approach of integrating best-of-breed tools can balance management’s desire for centralization with administrators’ desire for local control of tools. Moreover, it is far less disruptive and less expensive than a tool replacement or vendor standardization project.
Misconception #6: Automation will “run amuck” and wreak havoc
While contemplating all the uses of ITPA, an enterprise may question whether their automation effort is the genesis of a rogue antagonist computer (like systems found in science fiction movies). If something is automated incorrectly, is there risk of it making a bad situation worse?
If you automate a bad process, you can make things bad faster. Most organizations that implement ITPA, however, include at least one step in each automated process that requires a manual approval. You could implement a manual checkpoint at every step in the process, but keep in mind there will be some reduction in benefits.
Also, similar to the way programmers utilize exception handling, good ITPA tools include built-in error detection to deal with problems like infinite logic loops. Using these best practices can reduce the risk of automation problems.
Misconception #7: ITPA tools do not integrate with existing tools
ITPA tools leverage other tools already in place to execute processes. The communication and control of these tools is enabled by adapters, but how can ITPA be implemented successfully if there are no adapters to a tool or custom application already in use?
The answer is that no ITPA platform will have an out-of-the-box adapter for everything that an IT organization needs to integrate with, both now and in the future. The use of custom applications ensures that, so ITPA vendors include ways of leveraging common integration methods such as Web services, direct database interaction, and XML file exchanges. Organizations should compare the ease with which one ITPA vendor enables custom integrations versus another.
Misconception #8: ITPA tools will not fit in an existing tool architecture
Many IT operations tool architectures are mature, and IT organizations make decisions on future tool purchases partly based on where and how those new tools fit into the existing architecture. ITPA technology does not have a traditional architectural position; it interacts with tools across the operations spectrum, from the service desk down to specific scripts on individual servers.
ITPA integrates with other tools as necessary to execute processes. This is a different way of thinking than is typically found in most tool architectures. For example, a typical architecture might have monitoring tools feeding a manager of managers, which, in turn, populates tickets.
An ITPA platform might integrate at all three layers, placing monitoring tools into maintenance mode during approved change windows, automatically recovering from known errors when detected by monitoring tools, and performing system-owner lookups prior to populating tickets from the manager of managers. In this example, the ITPA platform works in the background to improve the usefulness and efficiency of each of the other tools without requiring modifications to user interfaces or existing integrations.
Misconception #9: ITPA isn't sufficiently different from the ITIL tools already in place
IT organizations that have invested in ITIL probably have a service desk tool that includes automated workflows for Change Management, Incident Management, and so on. So the question arises, how is ITPA different than the automation that already exists in service desk products?
The automated workflows that exist in service desk tools are essentially “checklist automation.” They ensure that the right people make approvals and indicate process progress, but they do little to actually execute steps in a process.
For example, once a change is approved, an administrator still has to implement the change, potentially roll back the change if there are problems, then update the change ticket with success or failure information. A request for a new virtual machine or snapshot can be approved in a ticket, but a virtual administrator then has to perform the work in a tool such as VMware vCenter. ITPA can assist or even completely automate these steps; service desk tools don’t even begin to approximate the breadth of execution capabilities that ITPA tools possess.
Can you afford not to evaluate ITPA?
Due to macroeconomic conditions, nearly every vendor promotes its products as offering cost savings, but the ROI calculations for ITPA are overwhelming and simple. IT organizations are automating event-response tasks that consume an entire full-time employee and redeploying that individual to work on projects with higher business priorities. Some are able to eliminate contractor positions or outsourced services. Others are able to grow services faster without increasing headcount, or replace a number of point automation tools with associated maintenance and administration costs.
The beauty of ITPA is that it yields compounded cost savings over time with each new automated process. Add the benefits of more consistent process execution, greater IT service availability and faster response times to service requests, and a decision to ignore ITPA can be costly. More information on ITPA, including what to look for in an ITPA tool, can be found at http://community.netiq.com.
Note 1: Gartner, Inc., “Hype Cycle for IT Operations, 2009,” by Milind Govekar et. al., July 14, 2009.
Travis Greene is a service management strategist at NetIQ. You can contact the author at travis.greene@netiq.com.