Myth # 3:
Senior Management looks for automation
tools to drive staff reductions
Although the current economic climate leads one to consider the potential for a given project to result in reduced operating costs, taking a step back, the reality is quite the contrary. Indeed, organizations that excel at implementing automation tools and efficiency programs are able to consequently invest more in innovation. These companies will gain market share, leading to more, often higher paying jobs.
The benefits of RBA are that of improving business agility and operating efficiency. It is critical that an automation program centered on RBA should have the benefit objectives clearly articulated, both in order to measure those benefits to obtain continued investment and to ensure organizational buy-in. An inventory of prospective processes should be created and ranked according to their respective costs and benefits. When determining the benefits of a specific automation, the following metrics are a good starting point for measuring outcomes:
- The time it takes to complete the process manually
- The skill level it takes to complete the process manually
- The # of minutes of effort it takes to complete the process manually
Advances in automation technology provide a unique opportunity for IT professionals to keep their jobs from succumbing to the forces of labor arbitrage. Jobs that are higher skilled, and less manual, repeatable, and predictable are less likely to be outsourced to a lower skilled, lower paid labor pool.
Thursday, February 25, 2010
Tuesday, February 23, 2010
Myth # 2: Debunking the Myths of IT Process Automation
Myth # 2:
It’s all about the process, stupid
When organizing and planning to achieve the benefits of Automation, it is often tempting to identify overarching IT processes and focus time, money, and energy on process analysis efforts. Whereas this approach works well when building or customizing an application to model a structured process, it does not work as well with 3rd level automation.
Indeed, we have found that the focus of the effort should be on cataloguing a discreet set of manual tasks. Usually clustered around multiple application workflows and prioritizing tasks that are highly repetitive.
The process analysis work here is very minimal. We focus on highly repetitive, simple tasks.
In one pilot we conducted with Resolve at a large bank, the first Run Book helped create what equated to a savings of 4,000 hours of manual work. [Of course, the pilot turned into a global rollout with 30+ Run Books at the publish date of this paper.]
But, what about more complex tasks?
The answer, as it turns out, is that it’s really all about the people, not the process. Any approach that requires discreet, separate design efforts will ultimately hit an immovable ceiling of diminishing returns and stagnate into yet another application silo that has marginal incremental returns to the business.
In building a successful RBA program, we must:
(a) Build internal momentum /awareness/funding
(b) Offer a platform that is extendible to a broad set of content automation contributors (SMEs. etc)
(c) Offer a platform that encourages collaboration and re-use across the organization
It’s all about the process, stupid
When organizing and planning to achieve the benefits of Automation, it is often tempting to identify overarching IT processes and focus time, money, and energy on process analysis efforts. Whereas this approach works well when building or customizing an application to model a structured process, it does not work as well with 3rd level automation.
Indeed, we have found that the focus of the effort should be on cataloguing a discreet set of manual tasks. Usually clustered around multiple application workflows and prioritizing tasks that are highly repetitive.
In one pilot we conducted with Resolve at a large bank, the first Run Book helped create what equated to a savings of 4,000 hours of manual work. [Of course, the pilot turned into a global rollout with 30+ Run Books at the publish date of this paper.]
But, what about more complex tasks?
The answer, as it turns out, is that it’s really all about the people, not the process. Any approach that requires discreet, separate design efforts will ultimately hit an immovable ceiling of diminishing returns and stagnate into yet another application silo that has marginal incremental returns to the business.
In building a successful RBA program, we must:
(a) Build internal momentum /awareness/funding
(b) Offer a platform that is extendible to a broad set of content automation contributors (SMEs. etc)
(c) Offer a platform that encourages collaboration and re-use across the organization
Sunday, February 21, 2010
Myth # 1: Debunking the Myths of IT Process Automation
Myth # 1:
If you build it, they will come
If you build it, they will come
Building a sustainable platform that ensures adoption of your process automation goals is not easy. Everyone knows a lot of manual work occurs that essentially should be automated.
But, why isn’t it?
Some challenges include:
-Scripting, or heavy customization of existing applications. This is difficult to accomplish unless the right technology platform is in place.
-Understanding the manual activities required to Automate at a sufficiently granular level, requires both good interviewing and listening skills.
There are 2 fundamental approaches to achieving the benefits possible through Automation 2.0 solutions. The first approach considers treating automation as a new process and functional area, with supporting technology and people. This approach does not take advantage of recent advances in collaboration technologies and the changes in how people interact with technology.
A more strategic approach to achieving the benefits possible through Automation 2.0 is that of integrating Automation tools and techniques into each existing process.
Making the tools ubiquitous drives adoption and places the onus of and the power to automate in the hands of the SME. Take the process of Event and Incident Management. Treating Automation as a discreet project or separate function leads to an almost certain pattern of innovation and then stagnation. The only way to sustain an underlying technology architecture that perpetuates automation is to place the tools and techniques in the hands of the level 2 and level 3 engineers for developing automation content. Additionally, Help Desk and Level 1 operations personnel become more empowered with a richer set of activities they can perform because of the increased depth of operational documentation.
Making the tools ubiquitous drives adoption and places the onus of and the power to automate in the hands of the SME. Take the process of Event and Incident Management. Treating Automation as a discreet project or separate function leads to an almost certain pattern of innovation and then stagnation. The only way to sustain an underlying technology architecture that perpetuates automation is to place the tools and techniques in the hands of the level 2 and level 3 engineers for developing automation content. Additionally, Help Desk and Level 1 operations personnel become more empowered with a richer set of activities they can perform because of the increased depth of operational documentation.
Friday, February 19, 2010
Intro: Debunking the Myths of IT Process Automation
Introduction
“But Lo! Men have become the tools of their tools.” –Thoreau
In this paper, I focus on the question of why after much innovation, engineering and hard work, do Enterprises continue to spend more precious resources on operating existing computing infrastructure, rather than investing their resources in the development of new and innovative ways to apply technology towards the advancement of their business and the service of their customers?
The Reign of the Application Engineers
When computer scientists began to develop applications for automating critical business processes, such as tracking inventory and processing customer orders the applications were designed around a simple business model.
As Enterprises continued to grow more complex and business processes became more streamline, so have the applications that endeavor to model and ultimately drive the underlying business processes. Most business applications designed today mimic a structured human workflow and contain a sequence of steps required to accomplish a specific job.
The result is a modern Enterprise, which contains thousands of business applications that enable millions of jobs. These applications serve to automate much of the paper driven flow of information and activities across the core business processes.
One of the challenges of the modern enterprise computing infrastructure is the need to reduce the stranglehold on the bottom line, which this considerable technology footprint has left us with. The sheer size and complexity of the modern enterprise application architecture is daunting. Some of the challenges include:
Leveraging Data Across Multiple Applications
Managing the Impact of Changes
Cost Effective Operational Processes
Furthermore, all Enterprises share a common root in the need to be able to perform work across the silos of structured workflows and enterprise applications.
IT Process Automation is a Third Level Automation Problem
The first level of Process Automation is modeling a task within an application to streamline processing and workflow.
If you are attempting to automate a process across several structured workflows, approaching the task using traditional application development and systems engineering principals will lead to serious challenges.
The EAI paradigm is good for a certain class of integration problems, but is not sufficiently flexible for building viable solutions within the areas of IT process that span highly dynamic infrastructure and operational process.
For example, one Communication Service Provider took a classic EAI approach to developing an OSS platform which covered “rigid” integration points between billing and provisioning. As a result this provider struggled to handle the automation of high volume testing and diagnostic procedures.
The nature of most IT processes is very dynamic in both the workflow rules and the architecture of the underlying components acted upon.
Subject Matter Experts are the Key
The Systems Engineer is in some sense the biggest bottleneck to many automation programs. Provide the Tools for the SME (Subject Matter Expert) to capture the repeatable steps in their work processes and you have reached the holy grail of automation.
The challenge of course is providing a platform that empowers the SME to both document the most mundane of their daily activities and leverage automation tools without requiring a large team of developers to support the effort.
So, early stages of Runbook Automation and IT Process Automation have been focused heavily on the high pain areas of IT Operations. But, the initial platforms used to action this problem and produce automation did not account for the critically important role of the SME in the ongoing advancement of the automation goals. Thus, very little progress has been made with the first entrants into this application space.
“But Lo! Men have become the tools of their tools.” –Thoreau
In this paper, I focus on the question of why after much innovation, engineering and hard work, do Enterprises continue to spend more precious resources on operating existing computing infrastructure, rather than investing their resources in the development of new and innovative ways to apply technology towards the advancement of their business and the service of their customers?
The Reign of the Application Engineers
When computer scientists began to develop applications for automating critical business processes, such as tracking inventory and processing customer orders the applications were designed around a simple business model.
As Enterprises continued to grow more complex and business processes became more streamline, so have the applications that endeavor to model and ultimately drive the underlying business processes. Most business applications designed today mimic a structured human workflow and contain a sequence of steps required to accomplish a specific job.
The result is a modern Enterprise, which contains thousands of business applications that enable millions of jobs. These applications serve to automate much of the paper driven flow of information and activities across the core business processes.
One of the challenges of the modern enterprise computing infrastructure is the need to reduce the stranglehold on the bottom line, which this considerable technology footprint has left us with. The sheer size and complexity of the modern enterprise application architecture is daunting. Some of the challenges include:
Leveraging Data Across Multiple Applications
Managing the Impact of Changes
Cost Effective Operational Processes
Furthermore, all Enterprises share a common root in the need to be able to perform work across the silos of structured workflows and enterprise applications.
IT Process Automation is a Third Level Automation Problem
The first level of Process Automation is modeling a task within an application to streamline processing and workflow.
The EAI paradigm is good for a certain class of integration problems, but is not sufficiently flexible for building viable solutions within the areas of IT process that span highly dynamic infrastructure and operational process.
For example, one Communication Service Provider took a classic EAI approach to developing an OSS platform which covered “rigid” integration points between billing and provisioning. As a result this provider struggled to handle the automation of high volume testing and diagnostic procedures.
The nature of most IT processes is very dynamic in both the workflow rules and the architecture of the underlying components acted upon.
Subject Matter Experts are the Key
The Systems Engineer is in some sense the biggest bottleneck to many automation programs. Provide the Tools for the SME (Subject Matter Expert) to capture the repeatable steps in their work processes and you have reached the holy grail of automation.
The challenge of course is providing a platform that empowers the SME to both document the most mundane of their daily activities and leverage automation tools without requiring a large team of developers to support the effort.
So, early stages of Runbook Automation and IT Process Automation have been focused heavily on the high pain areas of IT Operations. But, the initial platforms used to action this problem and produce automation did not account for the critically important role of the SME in the ongoing advancement of the automation goals. Thus, very little progress has been made with the first entrants into this application space.
Wednesday, February 17, 2010
Blog Introduction and Approach
I will be using this Blog to offer my thoughts and papers surrounding all things Run Book Automation. Additionally, I will endeavor to provide links to resources I've found valuable in my own research as well as my personal editorials of work that I have come across. If you share my passion for this space, please do send me information to share with other readers.
Subscribe to:
Posts (Atom)