What Most Automation Pilot Failures Have in Common

For organizations looking to start a digital workforce, the Pilot or Proof of Concept (POC) becomes a “make or break” point in their journey to intelligent process automation.

There is a lot of chatter about both successful and failed programs. So, what sets them apart?

Failures of Pilots or POCs have been studied by several academic and consulting groups. The conclusions lead to a couple of primary fundamental mistakes.

"Business-led"

It is critical to, first, understand that Intelligent Process Automation is a business-led program and not an IT project.

"Business process logic"

In every IT project, the organization is purchasing a piece of software that has some kind of business process logic coded into it. When you open the box of Intelligent Process Automation software, you are looking at something I call a “Box of Possibility”. Why? Because it does nothing for the enterprise when you install it and configure it. It is only after the software is installed that the business can begin the process of building “bots” or “applets” or whatever you want to call them. THESE pieces of automation contain the business process logic that actually does the work that creates value.

The Intelligent Process Automation platform provides a way to build and manage these.

"Returns depend on deployment"

There is no way in advance to determine what the “R” (or Return) is on the “I” (or investment) in an Intelligent Process Automation purchase. This leads to utter confusion with both procurement and IT.

Both of these organizations are driven by an ROI or business case to make a purchase decision. That’s not how it works with Intelligent Process Automation. The tool does nothing by itself. It is only when the business builds an automation COE and begins to deploy bots, that value begins to materialize.

In approximately 80% of failed programs, the primary failure was the lack of recognition that this is a different animal. In these failed exercises, you often find that procurement used its tried-and-true IT software purchasing process. It built a list of requirements, held a beauty pageant and selected a winner. IT then took what was usually a highly complex process with 25 different exception paths and tried to build a bot. Not surprisingly, this didn’t work.

"Where is the business?"

Procurement spent six months selecting a product and IT spent another six months building the first bot.

But where was the business?

Again, Intelligent Automation is a business led event. It is using digital labor (bots) managed by an Intelligent Automation platform to do real work.

In order to create a business case that fits the traditional mold of IT procurement and projects, an inappropriately complex process was chosen in order to make the “business case” work. What should have happened was the business showing up with its list of a dozen or so appropriately simple use cases that in aggregate solved for the necessary ROI to make procurement and IT happy.

The total value of an Intelligent Automation platform is actually not known and could be considered nearly infinite. It all depends on the business leading the development of an increasing number of digital laborers (bots). You don’t get “bots” out of the box when you purchase Intelligent Automation software, though. You are buying the ability to develop bots.

"You are buying the ability to develop bots."

This fundamental lack of understanding of the difference between Intelligent Automation products and traditional enterprise software is at the heart of failed programs.

[inlinead]