 I decided to write this article because I have often heard questions about the meaning, difference, similarity and complementarity of things such as workload automation, job scheduling, robotic process automation, business process management, and so forth. When exploring the world of market trends and IT evolution around these topics, I found different explanations for the same word or acronym, and also different acronyms or definitions for a given concept: “Vive la difference”, even if you disagree with the terminology I use in this article, the reasoning you will find may help in your own analysis. Not pretending to shed necessarily any light with respect, I find it useful to resume my understanding of the subject, after doing a personal and inevitably limited investigation among the people I know and the document I found on the web. This article is, therefore, a resume of my knowledge on Robotic/Intelligent Process Automation, Workload Automation and Business Process Automation/Management. I’ll focus on describing what contexts makes sense to use each term. It is not a pure academic curiosity, rather something that has concrete applicability because SW vendors use similar terminology to describe their products, and companies need to understand what solution matches what need. IPA AND RPALet’s begin with a conclusion: to me RPA is a subset of IPA, in the sense that that IPA is the smart coordination (some sources I have read use the expression “to choreograph”) of several individual activities, some of which are done by humans and others by robots. A concept I have found recurrently, and that therefore I consider a key aspect of RPA, is that it refers to activities with strong human characteristics such as activities that are, used to be or could be carried out by humans.  It adds automation to tasks that could be as well be accomplished by a person, those tasks are called RPA when automated, boresome-time-consuming-work otherwise. Therefore, RPA is the automation of an atomic task that somebody has been doing till today, and it consists in the imitation of that somebody interacting with a GUI. The simplest example of RPA I can think of are the rules I set in my mail client to archive emails into proper folders according to some filters. A more sophisticated and popular RPA is a chatbot with AI on a web page. RPA is then literally “a robot interacting with a user interface”, to which Artificial Intelligence and Machine Learning capabilities are added, as well as the ability to read-write or listen-speak as needed. These abilities to learn and communicate with humans are often referred to as “Cognitive Agents”.  A typical use of RPA is within an IT service desk, where users interacts with a chatbot that assists them on level-1 calls or inquiries, and that can execute predefined runbooks, or open tickets. These bots are intended to reduce the number of calls to human service desk operators, while cutting down the resolution time of the inquiries. When there is some coordination of multiple activities (providing answers, opening tickets, executing runbooks, passing the call to an operator, …) then I call it IPA. IT service desk is a typical domain where RPA and IPA produce noticeable effects.  As stated earlier, RPA mimics humans, and IPA coordinates RPAs with real manual activities. An example is a cognitive agent that identifies specific keywords or hashtags inside tweets and routes them in email format to specific human operators, who in turn take further actions. Or a semi-automatic process where a human puts his digital signature on a document, and emails it to a specific mail account, where a robot files it, updates an excel file and produces a report that is sent to another human. To summarize, IPA and RPA are usually intended for human-like activities, freeing up real people from the burden of non-creative repetitive but still needed work. The advantage is that human errors are almost eliminated, waiting times are reduced, and people can be assigned to more valuable activities. When IPA is implemented in a customer facing area also the customer satisfaction can be improved. WORKLOAD AUTOMATIONThe previous section identified IPA and RPA as solutions that do what people could do, with the advantage of a faster execution and the lack of human errors. Also, these solutions are often intended to interact with human end users or customers. Still, this is far from covering the range of operations that can be automated. Modern companies have already developed and adopted many IT processes and applications, where human intervention is already very limited or null. I am thinking for example of bulk data processing, like the payroll of a huge company, the money transfer processing in a bank, or the inventory management of a big retail firm. Not to mention IT maintenance operations (backups, SW updates, reboots…) that are supposed to occur as silently and transparently as possible. Many of the processes of a modern company occur, in effect, in systems that don’t interact with humans, but rather receive input from and provide output to other systems. These are what I call batch jobs, and usually systems are perfectly capable of running them with no human intervention… except that somebody needs to start them, check the results, and decide what to start next. Traditionally, jobs participate in a chain of activities where the output of one is the input for another, and so forth. These chains reflect the business process design of a company and, as digitalization takes over in many industries, more and more chains consist of jobs that could never be done by humans. Now, I should not really use the word chain, because a process can have many conditional branches and parallel executions or multiple dependencies among jobs, so it’s more properly a workflow. Even with batch jobs, the activity of
WORKLOAD AUTOMATION VS IPA, WHY NOT BOTH?At the end of the day, should a company look for an IPA or a WA tool? In the last section of this article, I present my point of view that companies should combine IPA and WA tools to get a comprehensive BPM solution. It makes sense, then, to clarify here what IPA and WA tools can do. Note: In some readings I also found the terms Business Process Management (BPM) or Business Process Automation (BPA) presented as synonyms of IPA, even if I personally prefer to make a distinction (see next section). When evaluating a solution that claims to be BPM, check if it actually IPA. The main difference between IPA and WA are:
Besides, several WA solutions offer additional controls, like:
 In any case, there’s no golden rule to help you decide if you need an IPA or a WA solution, or both. All I can say is that, among all possibilities and business needs, on one end there are cases that imply direct interaction with an end user and involve relatively small amounts of data or iterations, and on the other hand there are bulk operations over massive amounts of data that produce data to be used by a program. Those two ends are clearly IPA and WA respectively, for all the other cases you need to evaluate, and possibly try, before taking a decision. Once more, probably both kind of solutions are needed: there is little overlap between de domains of IPA and WA, and I am aware of no single solution that would fulfill all the automation requirements and opportunities for a business.  This image depicts the domains of the two approaches, where the area of applicability of both is probably wider than what companies perceive. There are processes that are experiencing many errors or delays, and those are the automation needs or pains to be solved. These are the reason why companies look for IPA or WA tools. Then, once learnt the power of those, it is quite natural to explore areas where things are working well, but that could work even better (faster, with higher throughput, with lower operating costs, less errors). This is what in the picture is shown as opportunities. In the end, both IPA and WA can be adopted by a company, not simply because they are not competing, but especially because they complement each other, and can be combined to work together, where for example IPA interactions can trigger a WA workflow in real time, or feed a database that a WA workflow will process later on. An example of WA and RPA cooperation? Think of a BigData project that collects and processes bulk data to maintain a DB with the best airline prices worldwide, and a bot that answers to travelers’ queries to find the best promotion for their trips. It is extremely important that the DB is always up-to-date (this is a typical WA scenario) and that every traveler is served promptly to retrieve the latest prices from the DB (and this is a typical IPA scenario). Creativity is the only limit to the space of possibilities. MULTIPLE INTERPRETATIONS AROUND BPA AND BPMThe terms BPA and BPM (Business Process Automation and Business Process Management) are often used as synonyms, even if -sticking to the etymology of the words- “Automation” is not necessarily “Management” nor even “Monitoring”. BPA is sometimes described as the analysis, definition (or correction) and automation of the processes used by an organization to run its business. In modern industries, and especially in the context of this article, these are digital processes, i.e. the collection, transformation and presentation of (often a large amount of) information, by a series of steps performed by IT applications. From this perspective, BPA is related to, but different from and definitely wider than IPA or RPA. BPA is actually closer, and often confused with Workload Automation (WA). The main difference between BPA and WA relies in the “definition/correction” of the processes, which implies a certain level of business consultancy in BPA (as opposed to Workload Automation that is supposed to automate processes that are already well defined). Actually, in some papers I have read that business process design is also an element of a discipline called Intelligent Process Automation, so my personal conclusions are that there is no unanimity among the experts on how to interpret these terms, and that in any case definitions are there to be used, not to be used by them. The boundary between these definitions of BPA and WA are actually subtle, because even if an organization processes are accurately designed and blue-printed, their automation by mean of an IT tool often implies the replacement of some human activities by a machine, so it requires organizational changes that step into the area of the pure business organization. WRAPPING UP MY IDEAS ABOUT RPA IPA WA BPA AND BPMHaving reported different definitions of all these terms, let me wrap up my findings and present my own interpretation, with a sort of inside-out approach. I will disregard hereafter any consideration about designing the processes of a company, and will focus on what RPA, IPA, WA, BPA and BPM can do with well-defined processes. The reminder of this section is a drill down on the ideas resumed in the next picture.  AUTOMATIC FRONT-END PROCESSING (RPA AND IPA)RPA – Robotic Process Automation is the imitation, by a robot that may have intelligence and learning capabilities, of human interactions with a GUI. The counterpart of such interaction is usually a real person or another RPA. Some RPAs are expected to communicate verbally or textually using natural language. IPA – Intelligent Process Automation combines multiple activities that simulate humans or that are actually performed by humans. Still the main focus of IPA is with automatic interactions with some kind of user interface, even if respect to RPA there’s the added value of the coordination among different interfaces. RPA and IPA are often the evolution of automatic GUI testing tools, where literally the tool takes control of the mouse and keyboard. Nowadays there are more sophisticated solutions, but often the principle of imitating and interacting with people is respected. There may be some data manipulation involved in RPA and IPA, but generally limited to the strictly necessary for real time processing. For the rest, usually these activities rely on data that has been pre-processed by some other application. AUTOMATIC BACK-END PROCESSING (SILOED-WA)Batch jobs run unattended and basically produce data and a return an exit code. Batch jobs need to be concatenated one with another, and usually do not interact directly with humans or UIs (with few exceptions). Job Scheduling is the simplest form of automation of batch jobs. It can be achieved without any commercial tools just relying on the scheduling capability of the hosting platform, but it adds little value respect to the modern business needs. WA – Workload Automation. This term is widely used in the IT industry, and consequently can be interpreted in several ways. Here I confirm the definition given above in this article: it’s the clever coordination and monitoring -according to a logic that evolves over time thanks to machine learning capabilities- of a series of unattended tasks performed by IT resources, each task modifying information received by one or more previous tasks. The evolution of the logic and the resulting coordination of the activities require little or no human supervision. Many legacy or industry leading solutions (like the most popular ERPs) come with their own Workload Automation, which is often good enough to carry over day-by-day operations, but still requires human low-value activity to monitor the workflow and coordinate it with other systems. These are what I call siloed-WA, where many separate apps concur to run the business, each automated internally and independently from each other, but the end-to-end business as a whole is not automated. AUTOMATED END-TO-END WA (BPA AND BPM)The best for any company would be to have their operations automated with no human control, so that people can spend time in real value-adding activities. This is still an ideal situation difficult to reach. Though the benefits from a theoretical point of view are unobjectionable, in reality the complete automation of the business needs to be approached carefully, and in some cases may not be possible or even desirable. BPA - Business Process Automation. My definition of BPA is the automation of all the processes that compose a business, like the “example of RPA and WA cooperation” described earlier in this article. Front end processes are automated and drive back-end processes, and vice versa. On the backend side, a workflow combines the execution of tasks from heterogenous applications, on different platforms (including multiple clouds). BPM – Business Process Management. This is the extension of BVA with added-value capabilities, to provide real automatic business management. Among the most popular capabilities of these tools we have:
I have knowledge of no one tool that does a real BPM, but of several that offer al the above-mentioned features for back-end processing (plus some limited capability on the front-end side). I am confident, though, that once processes are properly blue-printed, the adoption of proper back-end and front-end solutions, and the correct integration among them, can yield BPM on those Lines of Business where it makes sense. WHERE DOES HCL WORKLOAD AUTOMATION FITS IN THE PICTUREFinally, I am adding this section to map this overall discussion onto the features and capability of HCL Workload Automation (HWA). HWA is a full featured solution, and despite the terminology Workload Automation it really encompasses most of the characteristics to be a sound BPM solution. The 35+ plugins, and the REST APIs support, make HWA an end-to-end orchestrator for all kind of batch jobs and applications, and the what-if analysis tool, together with the ability to alert about unexpected duration of jobs, are example of features that allow a proactive and intelligent business management. Except for the GUI automation tasks, those who imitate a human with a mouse and a keyboard, that are typically delegated to a separate RPA tool, HWA is actually designed to match all the functions of Business Process Management, to the extent of the definition given in this article. Full BPM that includes front-end and real time operations can be easily achieved by integrating with an external RPA tool over REST or other common APIs. The following picture resumes it all: 
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
Archives
August 2024
Categories
All
|
RSS Feed