Speak then to me…

5. Origin

5

Where did creation have its origin? Who is the One that created it or did the One not create it?
That One alone perceives all from above and knows the beginning, or maybe doesn’t?

Rg Veda 10:129

An Automaton is a machine that performs a range of actions based on pre-configured instructions. Throughout history there have been various recorded descriptions of automata. Jacquard’s loom was a landmark automaton that helped to automate the process of weaving cloth. Electro-mechanical calculating devices created during the nineteenth century provided momentum for even more complex calculating devices that emerged in the first part of the twentieth century. Automata Theory provides the theoretical foundation for computing. von Neumann’s stored program computer (c 1941) is the basic reference model for all modern computers. Thus began the computing era.

As the benefits of stored-program computing devices became more evident, they were used for processing, storage, and retrieval of data. In the 1960s, database systems such as CODASYL and IMS were introduced. This led to the adoption of computing devices for performing various business support functions. The invention of relational model for databases by E.F. Codd provided a solid mathematical foundation for query algebra and calculus. As a result one could algorithmically convert a collection of data attributes into related groups called tables and devise mathematically precise queries to reconstruct the required data, based on parameters. Such advances in software and logical modelling technologies, supported equally by advances in hardware technologies — accurately predicted in the widely acclaimed Moore’s Law— resulted in the proliferation of computing systems in enterprises.

A previous article described business processes and explained how computer based data processing systems are now the primary mechanism of performing information-related business functions as well as control of machines. Hence the phrase “data processing and control systems”, which further evolved to “information technology systems” or “IT systems”.

Terms such as “process automation”, “robotic process automation”, “hyperautomation” have been widely used in recent times (c. 2013 to present/2022). In the previous article, I introduced the concept of “process integration” and set the stage for deep dive into this topic. How are these terms related? Are they the same?

To understand this we need a nuanced definition of the term “automation”.

We know that automaton and automata theory provide the underlying principles of computer-based systems. We also know that execution of business processes are accomplished via these IT systems. From that perspective, it can be concluded that any business process that is executed through data processing systems is in fact an automation.

When a piece of work is accomplished via an automaton — a machine that follows instructions, and if the work thus done has reached such deep levels of complexity and tedium that it can no longer be performed in a sustained manner by humans, then according to me, it should no longer be called an “automation”.

For something to be an “automation”, there must exist contemporaneously an equivalent “manual” method for the same thing, that can be performed by humans; and the system should be able to function indefinitely in that manual mode if required.

Business processes today are completely driven through IT systems. There are no equivalent manual processes of ledgers and physical record-keeping in most enterprises. There may be some fringe, anecdotal cases where, for example, a front-end POS (point of sale) system fails, thereby causing staff to manually create bills and accept payments. Such manual switch-overs may be possible for small operations; large retail outlets will prefer to shutdown the store until the IT systems are back online. We therefore conclude that enterprise business processes that are performed via IT systems can no longer be called “automations” — since there is no contemporaneous and parallel manual equivalent to those processes.

But we often hear of the term “business process automation”, “process automation”, “intelligent automation”, etc. Why then do we need methods and techniques to further automate business process execution, since we know that business processes are based on IT systems and thus automated?

The reason is because, as described in a previous article:

  • business processes evolve and often are complex compositions of simpler processes;
    • through the passage of time, there are can arise complex business processes that contain “gaps” that are not fulfilled by an existing simpler process that can be utilised to compose the higher-order processes; and
      • this leads to the use of humans to “bridge the gaps” and try to perform the missing actions by hand, that is, by performing actions on user interface (UI) screens of available software.
        • The use of humans to intervene in business processes by operating software (most often) via their user interface screens (UI) is called Software Driven Labour.

Breakdown in straight through processing due to software driven labour

The figure above depicts this situation. A complex business process may be composed of simpler components PA1, PA2, and PA3. However, it also requires some steps to be performed for which there are no software defined process flows. But it seems that the required steps can be performed if a human operates on the user interface screens of some of the available software systems. We can call that manual flow PM1.

From this it emerges that although data processing systems have proliferated the business process execution world, there are numerous cases where a new form of manual labour has developed — one in which humans manually operate on the very machines that are supposed to implement process automation.

Therefore in order to achieve straight-through-processing of business activities, we need to address the segments of processes that are performed as software driven labour.

The transformational approach to addressing software driven labour is to eliminate it by transforming the software applications in such a way that the necessary data and control will flow easily between the affected software applications thus replacing the manual steps completely. The transformational approach is usually very costly and if multiple software systems are affected, then significant planning and foresight would be required to facilitate long-term multi-application integration.

Alternatively, software driven labour can be viewed as a “manual” mechanism, which could have an equivalent “automated” version. If the component software applications continue to have user interfaces that can enable humans to interact with them, then it is possible for the manual and automated versions of the process to exist contemporaneously.

We started the series to discuss process integration. In this article we defined automation and traced the origin of process automation to the need for finding ways to address manual software driven labour.

In the next article, we will trace the evolution of various approaches to process automation.

About the author

Madhav Sivadas

Add comment

Leave a Reply

By Madhav Sivadas
Speak then to me…

Discover more from

Subscribe now to keep reading and get access to the full archive.

Continue reading