Post by : Deepak Sharma
In this part 1 of 2-part article, I’m introducing a Robotic Process Automation (RPA) implementation methodology that builds upon the Design-centric RPA approach white paper I published last year. The essence of this methodology is “Collaboration between business and IT to deliver RPA implementation” and hence the name “The BusOps-IT RPA Methodology”.
BusOps-IT RPA Methodology is centered around the theme of collaboration between business and IT to deliver RPA implementation
But before getting into the details of this methodology, let me first explain why this is so very needed for successful enterprise scale RPA implementations given the current state of RPA provider industry-
Why highly proprietary, record-replay, business only silo-based RPA implementations are bad for RPA adopters?
Implementing an efficient and effective Robotic process automation requires sound software engineering discipline. The fallacy of creating automation using record and playback techniques alone being promoted as a “speedy and cost-effective approach needing no coding skills so that the business users can themselves create software robots” is now fairly well understood.
Record and replay follows a “linear scripting” approach where each process is run manually and the tool records the sequence of actions. This generally results in one large script for each robot. Recorded robots may be edited for improved readability and further enhanced using the features in the tool. Although this can be used to automate business processes, it is not a good technique to use when a large number of RPA robots are to be produced. One major reason for this is the high maintenance cost associated with this approach when changes occur to the business applications being automated. Even a small change in a business application UI may necessitate many changes in the recorded robots given that this type of automation is non-modular and does not follow common software reusability and modularity principles.
High maintenance cost is not the only disadvantage, another key problem associated with record and replay automation is the high proportionate time required to create software robots, and that there is not much scope for decreasing the time required for building new robots. This is because by using such linear approach to automation, the amount of effort required to automate any business process will be mostly dependent on its size i.e. the number of actions or steps required to perform it. Thus the 100th robot to be automated will take a similar proportional amount of effort as the 10th robot.
And lastly, making the argument that business users can create software robots themselves by applying record and replay technique without needing any programming skills, this only ends up creating a silo between business and IT teams within the organization. It does not speed up or reduce the cost of building software robots by having to do it away from development teams in IT. Instead, it results in low grade RPA implementations that are unable to scale and fail to deliver expected ROI.
The BusOps-IT RPA Methodology
Implementing Robotic process automation requires both Business and IT to work together in collaboration-
If business is to design and manage software robots, IT is to develop and maintain them. If business is to provide the domain expertise and define what the robots do, IT is to provide technical expertise and deliver how the robots do what they are supposed to do
I want to provide an interesting example of such Business and IT collaboration how BiModal RPA white paper got created that John Slagboom and myself co-authored, with additional contributions from a number of other IA experts. John comes from a Business Ops background leading RPA implementations from the front in the managed healthcare sector, and I come from a IT development background specializing in solution architecture and development of automation projects. We both in a sense reflected a true Ops-IT collaboration case in point and it was amazing what we could accomplish as the theory for Intelligent Automation Ops Dev and Dev Ops models presented in the BiModal white paper bringing both are expertise together.
Both John and I agreed that an “Ops and IT co-led RPA” as the best model, as depicted in the RPA dominant design model below, that on one hand allows for efficiency, scalability, and incremental gains, but on the other hand also lets experimentation, innovation and radical transformations to take place when it comes to RPA implementations.
The BusOps-IT RPA essentially provides methodology to achieve the Ops and IT co-led RPA. Instead of using the term “Ops-IT”, I’m using the term “BusOps-IT” to emphasize that Ops here refer to Business Operations, and not to confuse with the Ops in the term “DevOps” which essentially means IT Operations.
The Design centric RPA approach, that I published earlier, provides the basis for development of software robots by following a top-down design done by the Ops SMEs using business process modeling standards, and is followed with object-oriented development of the robots done by the automation developers applying industry standard software engineering practices. This lays the necessary foundation for a collaborative process between Business and IT for RPA robots development.
BusOps-IT model extends this collaborative foundation between Business and IT to provide a fuller RPA implementation lifecycle model covering not just the development of software robots, but also their actual usage in day to day business operations as well as their ongoing maintenance & continuous improvement.
BusOps-IT model applies collaboration between Business and IT as the foundation to provide a fuller RPA implementation lifecycle methodology covering the development, usage, maintenance & continuous improvement of software robots
The following diagram provides a pictorial view of the BusOps-IT RPA Methodology which is further explained briefly for each of the phases depicted in the model-
Design
This is the starting phase where business SMEs/domain experts design software robots using process modeling techniques in a top-down fashion to define fully deterministic robots covering all the exceptions and recovery paths. Reusability and modularity principles are applied to allow for scalability and adaptability having to create greater number of software robots within the enterprise.
Plan
Planning phase follows the design phase once a robot has been fully designed. Release planning of software robots development cycles is conducted using iterative agile practices to be performed as a collective effort between Business SMEs, developers and testers. This is nicely explained in the Bimodal whitepaper in section “What is Operations IA Ops Dev” courtesy Pavel Gimelberg – expert in agile RPA implementations.
Develop
Once development iterations are planned, software robots are developed using highly agile modern day IT development practices by seasoned software developers as object-orientated code in a mature IDE. Implementations are layered to abstract complexity and maximize code reuse. Industry best practices for coding standards and fuller debugging capabilities are applied.
Test
Technical Testing is a performed both at the unit and integration level as the code for software robots is being developed to ensure production grade technical quality. Acceptance tests are performed to ensure end to end functionality of the robot. Industry standard testing models are applied to allow greater number of unit tests, followed by integration and fewer acceptance tests.
Release
This is the phase where once the software robots have been developed and tested, they are being packaged and released to the Business operations for acceptance and deployment into production. Release phase follows latest software configuration management, build, release and packaging standards and processes in line with continuous integration and continuous delivery practices.
Deploy
Once a release candidate of software robot is published, Business conducts a user acceptance testing to ensure the robot meets the necessary business requirements. Business operations then deploy the robot for production usage by defining the necessary controls such a roles, permissions, users, data needed for robot execution in production environment.
Orchestrate
After deploying the robots, Business Operations team schedules software robots to execute on underlying execution infrastructure in the desired sequence and with necessary triggers as needed for the day to day business operations requirements.
Monitor
As the software robots are executed in production, they are monitored by the Business Operations team making sure they perform as desired by the business both in terms of speed and accuracy. Metrics are collected and analyzed to identify bottlenecks and continuous improvement initiatives
The below table summarizes the ownership, activities, skill requirements and roles for different phases involved in the BusOps-IT RPA Implementation methodology-
In part 2 of this 2-part article, i would delve into how the BusOps-IT RPA Implementation methodology as presented above is applied in practice taking the Jidoka RPA tool example. Please like or comment below if you find content of this article or the model presented as thought provoking.
