We have all heard catchy quotes on robotic process automation (RPA) bots, right from “Augmenting human efforts” to “Robots don’t need coffee breaks”, but there is nothing worse than a production robot gone awry during production hours.
After all, these are software agents working on pre-defined business rules. But, what if the rules of the process changed too frequently? What if the UI changed?
We will address these questions and others that must be considered at the process assessment stage of any robotic process automation implementation.
What if the process rules change too frequently?
During the assessment stage this is one of the key parameters that must be considered by the assessors. If the processes change rapidly the process touchpoints where the changes finally impact must be clearly elicited. A cost benefit analysis at this stage as well as the requirement gathering stage for the process will help in factoring the cost of potential changes within the maintenance contract giving rise to a zero surprise framework during maintenance of the potential RPA solution.
As thumb rule, the business stakeholders must be made aware of the potential change request cost estimates that may arise due to a frequently changing process as part of the assessment report. The stakeholders can then make an informed decision on whether to automate the process.
What if the UI changed?
We developed a bot to run on an HTML-based web application for a client but a recent vendor transition changed the web page properties significantly. In this case, the question really is “Will the robot be able detect the changes?” The answer a resounding ‘No’.
A bot is a software agent working on predefined rules using elements of the UI as unique identifiers. It is the combined responsibility of the client and the development vendor for the RPA solution to create a governance mechanism apprising any component changes within the UI which the RPA bot uses to automate processes.
A system baseline therefore becomes an imperative step in a process assessment that can likely help in determining the automation probability and complexity. This should be followed by providing a governance mechanism for any changes related to the systems where the client will be responsible to communicate any changes, incremental or one-off, within the systems to the RPA vendor.
Generally, SAP and mainframe-based systems add to the overall complexity of the development and maintenance processes and must always be factored in during the process assessment.
The complexity arises from the fact that the underlying ‘objects’ that must be fed within a bot code are difficult to mine in SAP and mainframe-based systems and consume a considerable amount of coding effort compared to web based applications.
If the above analysis is not done during the assessment phase, it will be difficult to justify additional costs being incurred during development and maintenance stages later.
What if the expectations are unrealistic?
During an assessment, it is important to ensure that the RPA implementation goals are realistic and achievable. The “metrics that matter” to the client which the RPA solution will deliver must be clearly defined in the assessment stage as part of the due diligence.
RPA implementations do not work immediately like other SaaS, Point/Native automations and Cloud based services. We are talking about consultative deployment of software agents which require professional expertise to deploy, onboard, and maintain in the future, and are labor-intensive behind the scene.
The stakeholder expectations must be handled expediently to drive an RPA solution to successful closure during the assessment stage.
What if the expectation is to automate the entire process?
RPA solutions have ‘orchestration’ capabilities that allow the bot to interact with multiple technologies and processes. By judging this capability at face value, a client might just outright ask for an end-to-end RPA solution. Committing to such an expectation could be a major pitfall as most potential candidate processes for RPA implementation are 70 to 80% automatable. However, automating the remaining 20 to 30% might turn out to be more expensive than automating a process up to 80% as the additional 20% might require a code that is more complex than the code required to automate up to 80%.
Leveraging business process redesign/re-engineering along with process improvement methodologies keeping human touchpoints in the ‘to be’ design with exceptional edge cases during the assessment stage will help in bringing the operational efficiencies expected out of an RPA solution. This approach helps in rectifying the inherent inefficiencies within a process before delving into an RPA implementation.
To know more, click here!
