From experience, there are several factors which will contribute to the smooth development and successfully introduction of an RPA Bot.
Staff buy-in
Without buy-in from human employees, the introduction of RPA can be challenging. For example, if someone is at risk of being made redundant because of the introduction of the bot, and they are also the Subject-Matter-Expert (SME), it is not surprising if important process details might be missed in the RPA specification (Process Design Document). As a result, the bot might be missing important steps.
The best situation for RPA introduction is where processes are being automated because they are difficult to recruit for, or the employee is being reployed to another role in the business.
Alternatively if the process being automated only forms part of a human employee’s role, and the human does not have the time to do it, this means there is no tension during the RPA implementation process.
Successful RPA introduction comes when the company’s leadership has consulted with the human workforce and has made a firm commitment that there will be no redundances because of the bot’s introduction, and by agreement is reallocating staff to other roles within the company. If you treat the workforce right and they see that after its introduction, the robots are no threat, further process automation in other business areas will also be easier.
Importance of the PDD
The quality and accuracy of the development document or Process Design Document (PDD) makes the RPA development much easier, and we would advise not to skip this part of RPA introduction, unless the process is very simple.
The PDD frames the process, and the act of documentation sometimes highlights issues, challenges and areas of improvement, even before RPA development and coding begins. In addition later on, when the process needs maintaining, the PDD acts as a reminder of the process steps and expected outcomes to the developer.
Initial Process Improvement – If possible, Simplify then Automate
It is not uncommon for the PDD to help the company see the process in a different light, and the ‘wood from the trees’ in a sense. Accordingly, sometimes it might be worth simplifying and improving a process before automation. Automating a bad process will make it more efficient, but it is still a bad process and suboptimal. Improving it might mean less process steps, and less development time also.
Proof of Concept (POC) ?
A process earmarked for automation doesn’t necessary need a POC before development starts. However even for seasoned RPA professionals, there are times when processes might be tricky and a challenging area for the developer. An example might be the accuracy of OCR in reading a particular document.
This was the situation with the Garage Case Study, and consequently the business analyst and developer wanted to prove that the automation was possible before the main programming took place.
With Autane, the POC is really part and parcel of our process, since the client doesn’t pay the setup fee until we have proved the process can work.
Data Security
First of all, it is important to note that in a sense RPA Robots are ‘emotionless’ objects, and do not share what they see with others. This means they are naturally more secure than humans doing the same tasks in the first place.
That said, data security should be paramount since apart from the obvious issues of an accidental data breach, the level of perceived data security affects confidence in the RPA robot, and without confidence, the RPA project might be a non-starter.
Consequently, it is important to ensure the following guidelines are followed regarding data Security:
- Development
- Ensure Code never contains sensitive credentials, and that confidential data is only referred to as a variable name (for instance, email_password) with the data secured in a local crediential manager, or cloud vault.
- Development only takes place on Dummy/Test data, or a select number of transactions, and not on ongoing live data until its production release.
- Cloud Orchestrator
- Cloud servers are from reputable providers. Our partner, Robocorp, hosts its servers on Amazon Web Services (AWS) with SOC2 and ISO 27001 security compliance certifications maintained.
- Access is restricted and layered (access rights restricted for some users).
- Consider whether developers need to have access to non-encrypted credentials.
- Bots are permanently monitored for malicious tampering.
- Robot-Worker-to-RPA Orchestrator connection (if the Bot is running on a local desktop)
- All communication is encrypted on the transport layer using TLS.
- Artifacts stored and transferred from the Robot Worker are backed up by Amazon S3, and data encrypted at rest using AWS-provided methods
At Autane, we are very conscious that in part the future of our business rests on our ability to provide and maintain a secure infrastructure for our customers, hence we are continuing reviewing and improving our security measures.
Maintenance Expectation
RPA can be brittle at times, mainly because it is not possible to control the whole environment where the RPA robot operates. So, for instance if a software application is updated, and the HTML (webpage structure) changes also, the bot might be expecting to click on a button whose location has changed and will then fail.
An expectation that this and other potential issues will happen every now and then, and that RPA bots need maintenance and cannot be left alone, is an element in successful RPA deployment.
Ongoing maintenance of RPA Bots ensures that benefits are long term.
We estimate the clients should expect to pay 10-20% of the RPA Bot’s initial development costs per year to keep the automation running smoothly. With our RAAS (Robots-As-A-Service) pricing model, maintenance is included in the monthly RAAS service charge.