What do we mean with Robotic Process Automation. Is this just the execution of a regular business process by a robot instead of a human workforce? And therefore RPA does require another business process design approach? On the basis of an experiment, we searched for the differences that might exist when we design a business process that is executed by a robot. In this article we describe the experiment and our findings.
Marco Kelderman, Business Architect, LAB27, marco.kelderman@gmail.com
Marco spoke on this subject at the Enterprise Architecture & Business Process Management Conference 2017 this past October
Robotic Process Automation
According to Gartner Robotic Process Automation is at the peak of the Gartner hype cycle for business process services and outsourcing (T.J. Singh, 2017). Computable, a Dutch digital computer magazine says, “Robotic Process Automation will turn the world upside down, it is as big as the Internet and is comparable to the industrial revolution” (R. van Heur, 2016).
Robotic Process Automation is a natural fit for banks, insurers and other Financial Services Institutions (FSIs), because of the numerous repetitive tasks these company’s workforces perform. Shifting those tasks away from humans towards Robotic Process Automation can result in significant efficiencies (Accenture).
Latest research says that 46% of the current jobs in de US could be done by Robotic Process Automation (Breen, Jeroen, 2017) And Robotic Process Automation would help FSIs comply with increasingly stricter regulatory demands for auditability, security, data quality and operational excellence (Olivier Gillerot, 2017).
Opportunities
But what is the definition of Robotic Process Automation (RPA)? The term RPA may suggests that physical robots wandering around the office performing human tasks. But in the domain of RPA, a “robot” is the equivalent of configuring software to do repeatable tasks that previously were done by people (L. Willcocks, 2015, p. 3).
RPA could replaces those workforces who spend an inordinate amount of time completing bulk, routine, repetitive, rules-based tasks that are most of the time initiated by a digital trigger and supported by digital data. Software robots often can perform these tasks much faster and more accurately than humans do. And for obvious reasons these robots are becoming the preferred workforce. Because a robot;
• is never sick or tired.
• does not complain, while executing repeatable tasks.
• works 24/7 and not get paid for overtime.
• doesn’t need training.• does its work exactly as told,
• supposed to be 100% error free.
RPA is a technology for highly automated business processes. And because RPA can lower (operational) costs, increase flexibility, and improve process accuracy, it’s a hot technology that’s being adopted by many organizations (Chappell, 2016).
Software robot 3.0
RPA is just at the beginning of its own life cycle. We call, the RPA of today, Robot 1.0. Excellent in executing rule-based instructions, such as insert data into a database, make rule-based decisions and taking simple actions. In this stage RPA is four to five times faster than humans and does not require to touch legacy IT systems. RPA can quickly be implemented and often pays for itself within a few months (Brown, David, 2015).
The next stage, robot 3.0, will be using more sophisticated technologies involving “cognitive machine processing” and elements of artificial intelligence. Increasing the RPA applicability significant. A 3.0 robot can execute increasingly complex tasks, even those involving speech and vision, often in microseconds (Gerbert, 2017).
Business processes
Blue Prism – a company that develops Robotic Process Automation software – defines a structured process for designing business processes that are executed by robots. The result of this process is a so-called process design instruction, comparable with a library, which contains standard process assets such as: activities, actors, artefacts and business rules.
According to the implementation method of Blue Prism a design team creates a process design instruction for each business process that will be executed by a robot. Because this document will be used as a solution design it must specify the complete business process. Including what exceptions might happen, what to do for each exception, and more. This well-documented business process becomes the foundation for a software robot. (Chappell, 2016).
Process Maturity
But how well are the business processes documented in enterprises? Research of the process maturity of Bulgarian FSIs, in 2013, shows that 68% of the enterprises have process maturity level 2 or lower (Nikolova, 2013). At level 2 the organization begins to embrace processes, trying to define their core or most commonly used processes. At this stage, they don’t conceptualize the entire enterprise as a set of processes represented in process architecture.
And while the enthusiasm about RPA rapidly is growing, organizations are struggling to adapt or re-shape their business due to their low level of process maturity (MacLennan, 2010). And as well-documented business processes are the foundation process design instructions that RPA requires, there is a direct relation between RPA and process maturity.
Overall, the major conclusion is that process maturity is going to be a critical leverage point for the enterprise deployment of Robotic Process Automation, as business process are the foundation for RPA. The development of a process architecture will help organisations keep pace in implementing RPA (Nikolova, 2013), (Process maturity model can help give business edge, 2017).
Figure 1: RPA implementation.
Business Process Design, for Robots
So, well-documented business processes seem to be a good starting point for implementing RPA. And documenting and/or designing business process with BPMN is then an obvious choice. The use of the Business Process Modelling Notation 3.0 (BPMN) makes it easy to design and the designs are easy understood by the stakeholders from the business. (Silver, 2011), (Object Management Group, 2017).
Although a 3.0 robot will be able to determine business processes independent, and using more sophisticated technologies, the 1.0 robot will use BPMN.
Our experiment
So it seems that a well-documented business process design is a precondition for the use or implementation of RPA. But are these designs exactly the same as the designs that we use now a day?
We think it is time for a small experiment! The first step is the design of a simple business process “Claim handling” that will be executed by a human workforce. The process, could be something like this:
On Sunday the customer hands in a claim request via a standard web form. The claim request is registered on Monday by an employee of the insurance company in the role of claim handler #1.
This claim handler reviews the claim request and if there is certain data missing then additional data is requested. Otherwise the claim handler #1 reviews the claim documents that accompany the claim request. If there are documents missing additional documents are requested.
Then the claim handler #1 analyses the claim, and determine the claim settlement or rejects the claim. Claim handler #2 reviews the validation or rejection.
The review takes place on the hand of some decision rules. But when it is Monday, the Claim handler #2 grumbles that his salary is to low, he has too much responsibilities and the weekend was obviously too short! Sounds like a bad hair day.
So instead of “When the validation is approved by claim handler #2, on every Monday he is more strict on validations and rejections then the rest of the week.
Then the claim settlement is sent to next business process. But when the claim is rejected, claim handler #1 has to notify the claim requester (customer).
The duration of the whole process is max 10 working days. To meet the compliance regulations (ISAE3401 & ISA3402) the claim settlement has to be validated by a so-called “four eyes principle”.
The activity claim settlement involves assigning a monetary amount. And that’s why there are 2 extra risk regulations assigned to this process. The amount of the claim settlement may not exceed the limit of 1,500 euro’s. This is covered by the IT system. And every 30th claim there is a sample check, executed by a risk controller.
When we design this business process design with BPMN, the model could look like this:
Figure 2: BPMN model of “Claim Handling”
Basic Elements
The most basic elements that are used to create this process can be grouped into four basic categories of elements; flow objects, connecting objects, swim lanes and artefacts. And the majority of the designed business models contains pools and swim lanes, (zur Muehlen & Recker, 2008). Swim lanes are used to group activities into separate categories for different functional capabilities or responsibilities (e.g., different roles or organizational departments). A robot will execute all these activities by him self. And we presume that all the activities are still needed to gain the process result. So the design of a business process for a robot will not contain roles and swim. This is our first step in our experiment.
Figure 3: With a robot, no swim lanes.
Decisions
According to the research of (zur Muehlen & Recker, 2008) 77% of all the processes designed with BPMN contains data-based XOR gateways. An XOR gateway is always modelled prior to an activity, which defines the business rules (van Nuffel, Huysmans, & de Bruyn, 2014).
BPMN includes a so-called business rule task, which should better be named decision task. This task refers to a decision that needs to be made, and the outcome of the decision allows the subsequent exclusive gateway to route the flow. Using the Decision Model and Notation (DMN) for modelling and executing decisions that are determined by business rules is very helpful for the robot as well for humans. In step two of this experiment we use DMN in a BPMN model, and replace XOR gateways for a decision task. Which results in visual less complex business process.
Figure 4: Introducing DMN.
Checks
Humans evaluate and interpret data, bending the rules, which not results in a linear outcome. During the case handling the outcome may even be influenced by factors such as: the tone of voice of the claim, the weather, harassing colleagues or the high workload. To gain a more linear outcome, checks such as the 4-eye control, is introduced in the process design. This check pattern is necessary to rule out human feelings and gain more linear results with no steps omitted and no checks neglected.
As Prast says: “Academic literature shows that people systematically “diverge” from the relational model. This applies to their preferences, their judgment and decision making”. (Prast, 2017). Luckily robots operate 100% error free. In other words there is no reason for a second robot to check the activities that has been executed by a robot. So the third step in our experiment is to remove all the activities that are related to controls (see also figure 4).
Fine-grained
A rule of thumb is that a regular business process contains max 10-15 activities to avoid complexity, tiredness and loss of human focus (van Nuffel, Huysmans & de Bruyn, 2014). But the tireless nature of the robot means that a process design can be designed to take full advantage of the opportunities that robots are offering.
Thus, much more repetitive and granular level of activities in a business processes can be design. To arbitrary degrees of precision, beyond what a human can be reasonably expected to do.
When we add this knowledge to our experiment, the fourth and last step is decomposing the design process into several smaller, more repeatable so called “micro-processes”.
The idea behind micro processes is that processes are easier to design and maintain if they are broken up into small, collaborative parts. Each business process is designed separately, after which it is divided into more fine-grained parts. These micro-processes are not meaningful for a customer when they are separately executed.
Figure 5: Decomposing into Micro-processes.
A Customer-2-Customer process is simply the sum of specific micro-processes. This differs from a traditional C2C design, where everything is being designed as a monolith. The use of micro processes could be becoming the standard for Robot Process Automation.
A fresh approach
Our experiment started with the question: “Would a business process design, executed by a RPA, differs from a traditional business process design? And the answer is Yes. During the experiment we have seen that there is only one role involved. This RPA role – or robot – is executing all the activities making the use of swim lanes unnecessary.
However, the execution of one or more micro-processes must always have a context. In our experiment the context was claim handling. To define a context the concept of a pool in BPMN is used. This pool has gained the function similar to the concept of an Actor, when the BPMN model is executed by a RPA (van Nuffel, Mulder & Kervel van, 2009).
During our experiment we experienced that XOR gateways still may explicit be presented in the process design, but are partial replaced by decision tasks. This task refers to a decision that needs to be made, and the outcome of the decision allows the subsequent exclusive gateway to route the flow. The correct modelling pattern for processes design executed by robots is: decision task followed by an activity task.
Another outcome of our experiment is fine-grained micro processes. Which from a human perspective are less meaningful compared to the “old-school” business process. Logical grouping of these fine-grained micro processes can easily be done using the decision-modelling notation. The decision task is the activity that a robot uses, to conduct the orchestration of micro-processes also known as “process orchestration”.
Table 1: Process orchestration.
Logical grouping and visualisation of these micro-processes in a business process design would be done with the connecting element pool. Doing this, the pool is representing: the context of the business process, grouping specific micro-processes and representing the actor role. Which in this case is the robot!
Our first experiment led to several interesting findings, which needs further research. But we can conclude that a fresh approach is needed when business process are designed for Robotic Proces Automation.
Marco Kelderman is an independent Business Architect at LAB27. Marco looks at problems from a different perspective and has a strong focus on reducing complexity to simplicity. He challenges people’s thinking, to get them out of their comfort zone into thinking about ideas and possibilities.
Copyright Nothing in this publication may be reproduced, or distributed in any form or by any means, either electronically, mechanically or by photocopying, recording, or otherwise, without the prior written permission of the author (or LAB27).
BIBLIOGRAFIE
Blueprism. (n.b.). Robotic Process Automation Increases Data Quality. BluePrism Product Insight (p. 5). Newton-le-Willows: BluePrism.
Breen, Jeroen. (2017). The Pension Expert & Change. PensionTech Summit 2017 (p. 16). Amstelveen: Koninklijk Actuarieel Genootschap.
Brown, David. (2015, October 5). KPMG Global Sourcing Advisory Pulse. Robotic Revolution: Separating Hype From Reality. KPMG.
Chappell, D. (2016). Understanding Enterprise RPA. San Francisco: DavidChappell & Associates.
Gerbert, P. (2017, Augustus 1). Artificial Intelligence, Robotics and the Future of Corporate Functions. LinkedIn, p. 2.
Nikolova, V. (2013). Lumen International Conference Logos Universality Mentality Education Novelty. Process Maturity Analyses of the Bulgarian Enterprises (pp. 632-636). Plovdiv: ScienceDirect.
Object Management Group. (2017, Agustus 3). Business Process Modeling Notation (BPMN) Version 1.0. Retrieved from BPMN.org: http://www.bpmn.org/
Olivier Gillerot. (2017, Augustus 1). Robotics a good fit for financial institutions insurers. Retrieved from Insuranceblog accenture: http://insuranceblog.accenture.com/robotics-a-good-fit-for-financial-institutions-insurers
Prast, H. (2017). De psychologie van pensioenkeuzes. Netsparbrief, 27.
Process maturity model can help give business edge. (2017, Augustus 1). Retrieved from Business process management bpm: https://www.isixsigma.com/methodology/business-process-management-bpm/process-maturity-model-can-help-give-business-edge/
R. van Heur. (2016, November 25). Robotics Processing Automation. Opgehaald van www.computable.nl: https://www.computable.nl/artikel/achtergrond/digital-innovation/5886848/1444691/robotic-processing-automation.html
Silver, B. (2011). BPMN Method and Style. Cody-Cassidy Press.
T.J. Singh. (2017, Maart 31). Hype Cycle for Business Process Services and Outsourcing, 2016. Retrieved from www.gartner.com: https://www.gartner.com/doc/3396631/hype-cycle-business-process-services
van Nuffel, D., Huysmans, P., & de Bruyn, P. (2014). Engineering Business Processes. Comparing Prescriptive Guidlines From EO and NSBP (pp. 87-173). -: Springer International Publishing.
zur Muehlen, M., & Recker, J. C. (2008). How Much Language is Enough? Theoretical and Practical Use of the Business Process Modeling Notation (p. 16). Montpellier: Springer.
Accenture. (2017, Oktober 9) Opgehaald van www.insuranceblog.accenture.com; https://insuranceblog.accenture.com/robotics-a-good-fit-for-financial-institutions-insurers
van Nuffel, D., J.B.F. Mulder, S.J.H. van Kervel, Enhancing the Formal Foundations of BPMN by Enterprise Ontology. Advances in Enterprise Engineering III, 5th International Workshop, CIAO! 2009, and 5th International Workshop, EOMAS 2009, held at CAiSE 2009, Amsterdam, The Netherlands, June 8-9, 2009.