2. Motivation and bias

This above all: to thine own self be true

William Shakespeare

In this post I will enumerate and lay bare all my biases relating to process automation and outline my motivation for creating this series about process integration.

Through the various posts in this series, I will attempt to explain and logically argue my motivations and biases. This post, therefore, is only an index.

I use the word “bias” to refer to negative opinions that I have about certain things, and I use the word “motivation” to refer to the positive aspects that I intend to promote.

I agree that sometimes opinions can be subjective and relative — my perceived negatives could be someone else’s positives and vice-versa.

I respect the fact that everyone has a right to vend their wares; and in doing so they may promote certain positions and world-views. Some of the biases that I list below may sound harsh, especially to those who are currently invested in activities related to the topics that I may criticise — RPA vendors, analysts, IT decision makers etc. While I respect their position, in these articles I offer, with reasoning, my world-view on these topics.

Some readers may find that it challenges their current job or job-functions. If my views resonate with yours, you may find some benefit in the details covered in the posts and articles. If you disagree, that’s fine too. You can move on to other sites. But do check if your disagreement is primarily because the idea under contention poses a disruption to your current job, income sources, or investments.

So, here’s the list of my biases: (those having knowledge of contemporary RPA will be familiar with the terms mentioned in the list. It is okay if you are not familiar with RPA and the other abbreviations listed below. Through the course of this series, I will be describing these biases and terminologies in more detail. So wait until to you read those posts.)

1. I believe that UI-Automation (a.k.a robotic process automation, or RPA), which has gained widespread popularity in recent years suffers severely due to lack of technical rigour.
2. RPA’s technical positioning is currently driven by “fluff” and a whole lot of airy-fairy nomenclature such as “intelligent automation” and “cognitive automation”, authored by technically clueless “analysts”.
3. The latest in such nonsensical nomenclature is the term “hyperautomation”.
4. It is a pity that technology evaluators and implementors – CIOs, VPs, Directors – the people who are getting paid to invent and discover better data processing techniques for their organisations – are relying on hype that is churned out by marketers, and marketers masquerading as analysts.
5. There is nothing “intelligent” about “intelligent automation” in its current incarnation (circa 2022).
6. Mixing “AI” (artificial intelligence) and “ML” (machine learning) into RPA does not make it a hot solution to any automation problem.
7. Computer Vision and OCR (optical character recognition) techniques to read scanned documents and then feeding this to RPA will lead you into a mire. These techniques should be used very carefully and in limited scenarios. Relying on this method for partially successful automations will keep the industry forever in the medieval ages of partial digitisation.
8. Process mining using keyboard-mouse recordings being fed into AI-based and rules-based engines will not lead to anything more than anecdotal successes. You are not going to be able to handle really complex “fan-out” of screen flows arising out of minute scenario variations.
9. “Attended RPA” should no longer be encouraged. Many RPA use cases started off in the early days as attended automations. We have evolved beyond this now and attended RPA should be laid to rest.
10. The concept of having a “bot per employee” is total nonsense. It is a grossly inefficient mode of automation; it discourages full automation by facilitating this half-baked state of attended-RPA; and worse still: it is a clever sales ploy to peg “bot” sales to employee count.
11. Despite more than half a century of active deployment of data processing systems, we have still not realised the full potential of this technology. The primary reason is that automated data processing in organisations is fragmented; and these fragmented automations themselves are not suitably automated by a higher layer in a well defined manner.

I will update this list and add links to the posts that discuss my position on these topics.

My motivation for expanding my research and thought into process integration is for the following reasons:

1. Enterprise software integration and process automation remains technically incomplete despite nearly half a century of active thought in this area. We need to sort this out permanently. There has to be a reasonable solution that can address software process integration and automation not only for past and present technologies, but also for future waves of enterprise software.
2. We need to concentrate our efforts on being able to provide seamless integration and interoperation of heterogeneous, de-centralised data processing systems. Organisations should not aim for monolithic systems in order to achieve “better” integration.
3. Straight-through-processing (STP) should be the ultimate goal of all data-processing systems. If human interventions are required, these should be integrated into the STP workflow and triggered in real-time, as opposed to the more common offline, pull-based approach that is prevalent.
4. A desirable state to achieve would be to dynamically compose process flows and reduce the time-lag between physical business changes and their reflection in software systems.

The posts in this Process Integration Trilogy will take a journey through these biases and motivations.