xPA: Clearing confusion through any-process-automation

Do you need RPA bots or DPA platforms? Do you need to modernize your BPM with AI decision intelligence, build low-code apps, or make your automated testing frameworks more process-aware?

Enterprises face a buzzsaw of buzzwords when entering this forest of process automation options. Leading analyst firms have identified several unique technology spaces relating to the automation of business processes, but the lines between them become blurrier every day.

Looking at the amount of investment and sales hype happening in process automation, along with the analyst, consulting and platform vendor activity of segmenting so many products into arbitrary markets, it’s not hard to see why all this jockeying for position is happening. There’s a lot of money to be made in prescribing innovative solutions to fit such complex problems.

Clearly, any business must become more agile, responsive and efficient in every operational aspect of fulfilling customer demand in order to face down competitive pressures.

Every business process consists of many tasks, where automation would benefit the business if the work happened faster and used less resources to complete. And every automation approach must execute these tasks in a way that maintains context and respects the business goals of the process.

Therefore, I’d like to posit a way to see both the trees of automation, and the forest of process complexity at the same time.

Proposing xPA: Any-process-automation

xPA (where x means ‘Any’ process automation, or even eXtreme process automation, if that’s your style) is not another software market segment.

xPA is the practice of understanding and codifying commonalities between all process automation tools and the enterprise’s application estate, in order to produce more reusable process automation assets.

Whereas RPA bots or some test automation scripts might operate against a web or application UI, and DPA might broker human requests and system-to-system processes against API services, xPA is not defined by its automation interface or the venue it operates in. The more application and service stops a given business or system process must make, the more relevant xPA becomes.

xPA can be informed by any combination of inputs:

• Human input/intervention, whether defining, guiding or responding to the automation.
• Invocation, how do you call the automation into existence, how do you end the automation, and what person or system can make such requests.
• Process, a captured or codified procedure or set of steps to execute.
• Branching, how to define alternate processes -- it’s a lot more complicated than a set of if-then statements that might have been stored in existing process silos.
• Integration, defining the infrastructure for hosting or running the automation agent or workload, whether as a service or locally, and declaring how it communicates with other services.
• Feedback, monitoring for status conditions and metrics gathered to continuously improve the process automation system, and help humans make better decisions.

These seem like rather generic inputs, but that’s intentional. While a specific business process definition and data within workloads may remain part of the intellectual property of a company and its customers, xPA automation itself should be open and understandable, making xPA inherently portable and reusable across interfaces and application silos.

Inheriting a bill of materials for xPA

Going back in time, xPA has many ancestors that contribute the best of their process automation lineage and capabilities to this practice. [If you were to try and make an acronym out of them, it would be ‘RPATAIADPALCNCBPM,’ which isn’t nearly as catchy as xPA.]

RPA. Robotic process automation often employs semi-autonomous ‘bots’ to replay the actions of human users on a web or application interface. RPA is a hot, high-growth space and extremely useful for imitating manual work. While dynamism is being introduced to leading tools, the rote nature of some captured tests can lead to brittle bots and excess maintenance work if back-end changes affect the presentation layer.

Test automation. At its heart, a test is really just a script for invoking an intended process and gathering results. It’s no wonder that much of the intellectual property we know in xPA comes from advanced automated testing tools and continuous testing disciplines.

Testing happens at the UI layer, as well as invoking services through APIs and back-end integration processes and simulating real-world conditions and data for testing. Test automation is built into xPA because the business needs to ‘cause the cause’ within the software process to validate success or find failures. Ideally this happens as early as possible.

IA. Intelligent automation uses AI-like features for understanding work inputs and data, and reactively reassembling tasks and workflows on the fly, to reduce the need for human-attended automation. While a promising growth area for augmenting the capabilities of any flavor of process automation there’s still a lot of research to be done in this arena.

DPA. Digital process automation offered the next step beyond BPM in that it could possibly conduct process and data mining of more distributed processes that cross multiple services and invoke complex business processes at messaging and API layers, as well as some UI functionality, usually from a shared central application or SaaS.

Low-code or no-code. Low-code is a huge technology category with its own galaxy of vendors –that of ‘app builders’ which non-engineering citizen developers can intuitively leverage their business expertise and leverage easy integration hooks to other systems to create applications. While not pure automation, the ability to create an application that replaces costly development and manual work is certainly a relevant contribution.

BPM. Business process management has evolved for decades, but BPM systems are still commonly thought of as a centralized repository and process engines for procedural workflows which other applications could reference to get instructions or next steps.

Even unrelated fields like cybersecurity and authorization play some part in this dance of xPA -- so that the process wherever it runs inherits the appropriate permissions to ensure the automation workloads are operating safely.

The Intellyx Take

There’s a big difference between process and automation. A process should be a differentiated aspect of how a business functions, whereas automation is simply the means by which that business function is scaled to run anywhere it is needed. Automation doesn’t need to be proprietary at all.

Technical debt is an IT management measure of the cost of repairing and refactoring old code and obsolete applications, and it has a parallel in process debt. Any process automation that takes more effort to repair than its utility value represents process debt and becomes a great candidate for an xPA transformation effort.

Don’t worry though. With so many options for process automation productively employed within enterprises, there’s no reason to pursue a ‘rip and replace’ strategy to ‘do xPA.’ Since xPA is a practice and not a tool, adoption means taking the time to rethink automation artifacts as resilient automation assets going forward.

© 2021,Intellyx, LLC. Intellyx retains editorial control over this content. At the time of publishing, Robocorp is an Intellyx client.