In a recent article, I wrote about why Record-Replay is not a preferred approach to RPA. I briefly touched upon the Design centric approach to RPA in that article. In this first part of a two-part series article, I would like to take a deep dive into exploring the Design centric approach to RPA, and bring out insights as to why this is the right approach for strategic RPA implementations in complex enterprise environments. Based on my research on various pure play RPA tools, I previously mentioned about Blueprism and Jidoka RPA tools that have adopted product strategies focused on the design centric approach to RPA. The ideas expressed in this article are applicable to these tools and any others that align with this approach in principle. Enterprise customers and professionals involved in RPA implementations will find the content presented in this article beneficial.
But first, let’s look at some of the broad trends and issues faced by the RPA market today as it is going through its take-off phase and as many industry analysts are predicting- RPA market will continue to grow at a rapid pace for the next 5-7 years before it starts to level-off. As with the growth of any new technology market, there is a flood of different RPA product variants that have emerged with multitude of ideas about what the customers want. As more and more RPA products are getting pushed out into the market, it’s increasingly the case that this does not create new products but instead has created new product categories such as pure-play RPA- attended or unattended, cognitive RPA, and AI powered RPA. Although, there are tall claims being made about RPA product offerings, to create a further 40-50% efficiency on the traditional BPO costs, the demand is still inchoate especially in the case of cognitive and AI powered AI where a lot of innovative activities is going on at the moment as the products mature.
Given all the hype, an ever-growing variety of products and categories on offer and an inchoate demand, the RPA market is going through its evolution with some products prospering and others falling apart. As more and more customers across industry sectors are trying out RPA products and conducting POCs, consumer needs are getting more articulated and specific. And as this continues to happen, the coming year or two will result in a sizeable shakeout to possibly reduce the number of providers and stabilize the RPA industry.
Until that happens, there are number of broad issues faced by the consumers. Firstly, the biggest is the confusion over how to approach RPA implementations as there is a lot of misunderstanding in the market created by RPA products sales pitches. Should you go for a product that sound cheaper early days but offers quick, tactical POC outcomes automating simplistic processes using approaches that fall into the record-replay trap?
Or should you go for a product that forces you to look at business process automation in a holistic way across a large operational area? This may sound higher investment and effort early days but so would be the resultant RPA ROI and efficiency gains over time. It’s a tactical vs. strategic choice for RPA implementation approach. As many of the implementation cycles are in early days and as more and more enterprise customers are trying to make sense of RPA benefits, many are struggling with the RPA product choice they’ve made and are finding it difficult to realize acceptable ROI from RPA implementation beyond the early POC stage.
Secondly, should you be developing bots that require very proprietary development & maintenance skills? Many RPA products are claiming to offer code free development of bots that the front-line operations users can carry out themselves using the pre-built capabilities offered in the tool. But seldom such RPA implementation tactics work and soon customers find themselves in a state where they have to bring in skilled RPA developers in the chosen tool from outside.
The situation is not helpful as many of the pureplay RPA tools don’t necessarily provide or support standard software development kits (SDKs). As such, getting skilled software programmers, say in Microsoft or Java technologies for example, does not work. And finding resources locally that have been in operations and have become power user in proprietary features offered by an RPA tool is difficult. This problem is widespread for customers and one solution is to have their operations teams undergo training and acquire the necessary skills in the RPA tool they’ve chosen. But this doesn’t provide implementation expertise to begin with, as needed for complex implementations, and is dependent on the availability of good quality training programs for the chosen tool. Instead, should you look to implement an RPA tool that applies industry standard development techniques for building software robots and does not create skills gap? It’s a choice between highly proprietary methodologies vs. industry standard development practises for RPA implementations.
Thirdly, because of the implementation approach and development technique employed based the chosen RPA tool, should you push bot development fully into operations teams? Does RPA tools offer such silver bullet that RPA implementations be done without involvement from IT teams.
A direct consequence of this is the failure to scale RPA implementation efforts beyond the POC stage. Another, and on a more serious note, is to do with the level of technical quality of the solution in terms of robustness, modularity, security, scalability and maintainability. Or, should you look to adopt an RPA tool that inspires a collaborative effort between both the operations and the IT teams for building process bots? Thus, the resultant RPA implementation delivers not only the much-needed operational efficiency but is of high technical quality as well. In a technology world where collaborative approaches like Agile, DevOps are a new normal for Digital transformation with in businesses, it is not advisable to take a step backwards when it comes to implementing RPA and end up creating a silo between the operations and IT teams. Its a choice between a collaborative vs. siloed approach to RPA implementations
To re-iterate, the 3 broad issues facing RPA implementations are- 1) Not taking a strategic approach to RPA implementation resulting in low ROI, 2) not employing industry standard development techniques leading into skills gap, and 3) not implementing RPA projects as a collaborative effort between operations and IT teams causing implementation failures with some industry analysts stating this to be as high as 60% in late 2016- early 2017.
Design centric approach to RPA-
Let us now look at the Design centric approach to RPA implementation and analyse how that helps to solve the broad problems facing the RPA industry that we’ve discussed above.
Design centric approach to RPA implementations focuses on taking a top down approach for automating the business processes within an enterprise. It’s about starting with designing high-level workflow for processes to be automated in a language that is understood by the domain experts, and not focusing straight into the technical implementation details by attempting to record an isolated bot for example in a bottom-up fashion. The processes to be automated are designed in their entirety by Operations SMEs. The high-level process flows are made deterministic to ensure all possible exceptions and recovery paths are covered. The whole idea follows the principle that Design is not coding and coding is not design.
The high-level process flows for automation are modeled using the standard design patterns for business process modelling. The process steps are considered as domain events and are labelled using a common language that describes the application domain. This lays the foundation for an object-oriented layered solution architecture.
As business processes are modeled using a common domain language, the process steps that represent domain events once implemented in code provides a library of automated reusable modules or business objects that can be re-used across multiple automated process bots. This reduces the level of maintenance needed once automated process are released into production. Any change to a domain event can be made only in the corresponding automated module to reflect in all applicable bots.
As processes within an operations area of a business are being automated and a library of domain specific automated process components starts to emerge, this provides for scalability in the RPA implementation to automate much greater number of processes within the enterprise with minimal additional effort.
Implementation of automated process bots is done using industry standard object-oriented programming techniques. OOPS concepts are applied such as building objects to model application attributes and behaviour as needed for RPA implementations. The technical implementation details are abstracted from the high-level process workflow. The technical details of object attributes (such as UI object locator attributes) are encapsulated from misuse and duplication. Inheritance is applied to implement more sophisticated custom actions extending the raw API calls provided by the RPA tool for complex implementation requirements.
Layered Solution Architecture
The high-level process flow represents the top layer of the automated solution. The actual implementation of the process steps as a software robot is done in one or more bottom layers. Typically, the implementation of domain events as reusable process components is done in an application specific techno-functional middle layer that sits in between the business domain specific top layer and the technical base layer provided by the RPA tool. The base layer provides the technical API that the RPA tool uses to perform actions directly on the application/s under automation (for e.g. Web, Windows, Citrix, Excel, SAP, etc.). The below diagram depicts the layered architecture of RPA solution.
The use of standard development technologies allows for extensibility to utilize proven external APIs or libraries, or by building custom libraries to enhance the existing solution and fulfil specific technical implementation requirements.
The business process to be automated is first designed as a high-level process workflow by one or more process SMEs, who are experts in the given operational area within the enterprise. The process workflow is created in the workflow designer provided by the RPA platform. An automated bot is then created by implementing the domain events in the process workflow as object-oriented code. This is done by one or more automation developers in the IDE provided by the RPA tool, decoupled from the high-level process flow. The automated implementation in the form of object libraries and methods are then published to the RPA platform. Process SMEs are then able to map the domain events in the process flow to the automated components, test the automated process and release it into production. Both, process SMEs and automation developers, work in collaboration to deliver the automated process bots. The automation developer ensures the technical quality of the solution whilst the process SME ensures that the automated process bots are accurately designed to deliver true operational efficiency to the business.
The below model summarizes the key aspects of a Design centric approach to RPA implementations.
Model for Design centric approach to RPA
The second part of this two-part series article will demonstrate how the Design centric approach to RPA implementation can be applied in practical using the Jidoka RPA tool. And based on that, i would be reflecting on how the broad RPA implementation issues discussed in this article can be effectively resolved.
Please share, express your comments or feedback if you like the content of this article, or find the ideas expressed here thought provoking.