What Automation Should Be
What do you think of when you hear the word automation? Robots assembling cars on an assembly line? Computers filling in forms on web pages by themselves? Or maybe you think of ChatGPT writing an essay or creating a Van Gogh-like painting?
In the enterprise context of knowledge work, automation typically refers to taking a business process consisting of a sequence of human tasks that leads to a business result and replacing the human tasks with software-driven ones.
The twin notions of a business process as a sequence of tasks and process automation as completing human tasks with software have indeed been with us for decades, as one generation of technology after another has tackled process automation in different ways.
And yet, with every generation of technology, we seem to be moving away from the crux of what we mean by a business process: what it means to get work done. Human work.
How did we get here? And what will it take to dig ourselves out of the process automation technology hole that we’ve managed to fall into?
How Did We Get Here?
Every generation of process automation technology has helped us model, understand, and simplify business processes – but from different starting points and with differing levels of success. Let’s take a look.
Let’s start with service composition!
In the 2000s, software vendors put their heads together and came up with standards like Web Services Business Process Execution Language (WS-BPEL) with the idea that organizations could represent business functionality as Web Services (XML-based software endpoints). Compose those Web Services following the WS-BPEL standard, and automation would result.
The entire idea quickly fell over, as WS-BPEL was too limited and technology-centric to help the process analysts do anything, let alone address process automation goals.
Let’s start with screen-scraping!
Contemporaneous with low-code is the explosive rise of Robotic Process Automation (RPA). RPA humbly began as screen-scraping tools that would automate a human’s interactions with a form-based user interface on an application or web page.
RPA thus dramatically simplified mind-numbing, error-prone data entry tasks, enabling organizations to save buckets of money as they shifted data entry personnel to other roles.
The screen-scraping bots, however, faced two core challenges: they were brittle and added to the organization’s technical debt.
As a result, the leading RPA vendors branched out into other types of process-related technologies, leading to a mishmash of capabilities Gartner refers to as hyperautomation.
Nevertheless, RPA remains at the core of hyperautomation, and so too do its shortcomings.
Let’s start with low-code!
Low-code tools seek to bring visual, ‘drag and drop’ abstractions to writing software code, simplifying the work of professional developers and opening up application creation to a wide range of less technical ‘citizen developers.’
Most low-code tools combine process modeling capabilities with the software functionality necessary to automate the workflows that the models represent. The result is a user-friendly, flexible approach to building and maintaining process-based applications.
However, low-code’s strength is also its weakness. Such tools focus on building and running applications, rather than helping people to get work done. Sometimes low-code applications are up to the task, but for many processes, they fall short.
Approaching Process Automation from a Different Direction
Instead of layering on more technology, let’s start with what process automation should have been: a better way to get the right work at the right time to the right people.
Whether the work itself leverages technology is largely beside the point. Instead, organizations manage and optimize their processes by leveraging technology to help people do their jobs, rather than trying to replace humans and their activities with automated tasks.
In today’s information overload environment, automation should center on giving human participants exactly what they need to complete a task efficiently and effectively – and no more. Such automation must keep track of time, motion, and context in addition to the work itself.
By focusing automation on routing people’s work, they retain the power to complete that work as they see fit. While such work might consist of a linear sequence of tasks, more likely than not it will involve collaboration and conversation – often in parallel.
Each of these activities may leverage technology fit for each purpose, but the interactions between humans and computers are only a small part of the overall process automation landscape.
Traditional automation vendors don’t take this human work-centric approach. iGrafx is one of the few process automation vendors who looks at process automation as centering on routing the right work at the right time to the right people.
Such automation requires process visibility into how the organization actually gets work done, as well as process modeling capabilities that allow for the diversity of work – capabilities that iGrafx provides.
iGrafx also helps people optimize the routing of work in their organizations – not by taking tasks off their plates, but by empowering them to make the best decisions about their own processes.
The Intellyx Take
iGrafx rarely replaces low-code or RPA tools. Far more often, its products complement the application creation and task automation applications in place at its customers.
More than anything else, iGrafx helps its customers understand their own processes beyond simply the question of how technology can automate them. Just as organizations are more than their processes, process automation is more than technology.
The missing pieces: people. People do the work of the organization, not technology. Technology is a means to an end, but never the end in itself.
An Intellyx BrainBlog for iGrafx by Jason Bloomberg, Managing Partner
Copyright ©2023 Intellyx LLC. Intellyx is solely responsible for the content of this article. As of the time of writing, iGrafx is an Intellyx customer. No AI chatbots were used in the writing of this article.