Never outshine application business logic

Reliable systems that produce trust worthy results are foundation to efficient business operations. One of the best ways to be consistent in IT systems outcome is to practice single source of truth. To be consistent and meaningful, data must be subjected to change using same set of business logic. Enterprises practice single location business logic implementation using either specialized systems such as ERP or through objective driven custom implementation. Duplication is avoided by ensuring same functionality is not implementation in more than one application. When business logic changes this approach ensures changes are isolated to specific application. This practice must be retained even in case of RPA implementation. The BOTs or RPA processes should mimic workforce and never try to outshine applications by duplicating their business logic. Such an implementation make system vulnerable to change.

Cells 1, 5 & 9 represent automation grey areas. These business use case would require changes in both application logic and RPA implementation. What sets aside such use cases is lack of clarity due to dual automation opportunity. The best approach in these scenarios would be to assess application changes first and then consider RPA.

Cell 2 & 3 are best suited for RPA. Use cases falling in these cells would involve least or no business logic change but are best fit for transforming workforce efficiency – either as supplements or catalysts. Primarily focus here would be to leverage existing business logic to automate either front office or back office business processes.

Cell 6 is a special case where automation benefits are on the higher side of workforce but may need moderate business logic change. One should be mindful to plan RPA implementation only after business changes are confirmed and implemented.

Cells 4, 7 & 8 are clear cases of business applications change. RPA should be considered towards end of application change to ensure RPA itself is not subjected to repeated changes.

In no circumstances RPA should replicate business logic encapsulated in other application, RPA should always mimic end user behaviour.