At Ashling Partners, we are constantly looking for ways to better reuse our previously created scripts. After all, why should we start developing from scratch when there’s a similar process already scripted? In theory this should be a simple exercise; locate the existing reusable code and copy over the bit needed. However, unless the original script was developed with both modularity and reusability in mind, it will likely bug out.
Reusability in RPA can be difficult for several different reasons including, but not limited to:
- Element selectors being too specific or generic
- Hard coding variables which should be passed in / out as dynamic arguments
- Differences in application speed
- Performing data manipulation, parsing, and / or process flow logic in an inappropriate location
- Throwing process specific business exceptions
- Differences in development style
To avoid these reusability pitfalls, developers must work together with business analysts and process owners to group and order the process backlog BEFORE beginning development. This analysis, while secondary to ROI, is necessary to help the developer decide whether to enhance the dynamic capability of the script. The up-front knowledge of the process application’s organizational use and number of future automatable processes in the backlog will dictate the development effort spent on analyzing the target application’s behavior, editing selector properties, modularization, etc.
For example, there is a proposed process automation to bridge the gap between a legacy application used for lease management, Application A, and the enterprise wide ERP system, Application B. Application A is used by only two functional groups: legal for excerpting and uploading lease agreements and accounts payable for extracting each week’s lease payment run. Application B which records the lease payments and facilitates check cutting is used by functional groups across the organization. In addition, there are credentialing and homepage navigation steps common to all Application B users. The business analyst also noted that a majority of the proposed processes in the backlog require one or more touchpoints with Application B.
Given these facts and circumstances, the RPA developer can and should approach scripting differently for the two applications. Since the legacy application is siloed and only touched by one process in the backlog, development may forgo some of the wrinkles associated with reusability. While scripting Application A’s user interface navigation and element selectors, the RPA developer does not need to account for any future processes which may share the same UI route and / or selectors. On the contrary, Application B’s script can be leveraged for numerous future automations. Any ‘action’ scripted for this application should be examined for reusability. Specific attention should be given to logically modularizing all actions so that they become interchangeable when a future automation needs to reperform. This is a front loaded and time-consuming exercise, but necessary given the potential benefits.
Reusable code is an important concept for engagement teams to be mindful of. If the backlog of processes is thoroughly analyzed for reusable components during planning, benefits such as lower time-to-market, development consistency, less time-consuming change requests, and easier debugging can be realized.
