By Jason Bloomberg
Automation has been a reality since the Jacquard loom of the early nineteenth century. And just as its punch card technology inspired Charles Babbage and later Herman Hollerith, automation has itself evolved over the years as technology innovations hit the market.
We could even argue that the point of the first digital computers was to perform automations – albeit mostly of calculation tasks. Be that as it may, even in the early days, there was a distinct difference between the calculation, which the computers performed automatically, and the automation, which humans programmed manually.
For those of us gray hairs who remember manually operating a punch card machine, it’s not difficult to imagine wanting a way to automate that mind-numbing and error-prone process. If only we could automate the process of automation itself, we’d reach a new level of computing power and versatility.
What about RPA?
Techies, of course, have been automating automation tasks since at least the early days of UNIX, as the point to writing shell scripts was to automate interactions with programs that themselves automated various tasks. Shell programming is still a powerful tool, but it requires more or less the same hardcore technical skills it did in the 1970s.
Today, however, one trend has emerged that promises to bring the automation of automated tasks to the average organization: robotic process automation (RPA).
Just one problem: RPA isn’t particularly good at automating the task of automation – largely because the vendors of such products didn’t work through the use cases for such capability.
However, if we step back and consider the situations where we’d like to perform such ‘meta-automations,’ it soon becomes clear that something is missing.
