Having been in the RPA universe for some time now, we have witnessed the proliferation of solutions whose value proposition lies in providing the users with tools that automate processes with a “DIY” (Do It Yourself) approach, enabling people to build their own software robots. The idea behind these solutions is in recording the steps that a user performs when he uses a computer application and then a robot reproduces them every time it is required… it’s that simple. And what is better, without the help of any computer specialist! A really captivating idea, who doesn’t want to be able to record his own software robot? The next step will be building cars or spaceships!
But business reality is not always so simple and predictable, as you can find out reading studies on successful projects in RPA published by reference consulting firms like HfS. “Recorded” robots can work for isolated activities or simple tasks, but they have important limitations when it comes to executing complex and interrelated processes.
Also, in the daily operations of most businesses there are multiple exceptions, conditions, and unexpected changes for which a “recorded” robot in the majority of cases does not have a valid answer. And if you need to ask the IT department to adapt a robot to the changing circumstances of a process, it is probably better to do it from the beginning, letting the developers build it with a programming language that allows, for example, implementing workflow design. Developing a software robot is about making a program, implementing thousands of lines of source code following the design standards accepted by the industry, a program that can comply with the requirements of software quality, and above all, that facilitates the support, maintenance and the evolution of the automated business processes.
Design Centric RPA Approach by Deepak Sharma
When, in August 2016, I decided to write the article “Record or develop software robots? That’s the issue in RPA”, there were hardly any references to the programming approach of robot development. In fact, the terms RPA and source code seemed antagonistic, as if behind a software robot there was magic instead of code.
But it seems that in the last year something in the market has changed. Excellent articles that advocate the same approach have appeared. Among them, certainly stands out the study “Design Centric RPA Approach”, developed by Deepak Sharma, independent consultant with ample experience in automation. In addition to detailing the keys and benefits of the RPA design centric RPA approach, Deepak has chosen Jidoka as the solution that best meets this paradigm.
As Deepak explains, this approach requires a more holistic and integrated automation methodology that supports the joint work of the IT department and process managers, both parties having a basic and irreplaceable role in RPA projects.
To learn more about the Design Centric RPA approach, you can download the full white paper for free here: Design Centric RPA Approach.