An Intellyx BrainBlog for iGrafx by Jason Bloomberg, Managing Partner
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.
Read the entire BrainBlog here.
