Process automation software companies provide toolkits for building an electronic workforce to support or replace a wide range of existing manual tasks. Many of the process automation software products available currently have extensive functionality off the shelf, offering a rich and capable toolkit for your organisation. However, the products are likely to require localisation and customisation, ongoing management and maintenance.
Can a process automation solution truly be reused successfully in different settings, for different organisations? And what else should we be mindful of as we start to adopt process automation tools?
Myth: you can use existing automated processes as off the shelf solutions, as is
It’s hugely beneficial if organisations can work collaboratively and share ideas for common business change requirements. Standardising operational workflows and data formats can go a long way to helping your organisation meet the NHS interoperability challenge.
But processes will be different in different organisations. For example, no two A&E departments are the same – they may look the same, have the same roles within teams, use the same applications for processing patients, but operational processes and human workflows may be different.
In another example, two organisations might use the same PAS, but they may have different authentication requirements, different selection item content within fields, different IT environments – all these need to be factored into the process automation solution.
The greater the number of differences between organisations, the larger the likelihood for increased effort needed to reuse, and there will be a tipping point where it would be cheaper and quicker to start from fresh.
Unfortunately, many organisations that buy off the shelf automation solutions discover the processes don’t work as expected. More time and investment are then needed to re-configure it.
We have seen this happen when one acute trust shared with another their automated process for registering babies. Both organisations had the same hardware and software configurations, so it was thought that what works for one should work for both.
In reality it wasn’t so straightforward to simply copy the original automated process and re-use it because both trusts had very different processing rules and data capture augmentation behaviours. These resulted in the need for re-configuration of the reused solution.
This is one of the reasons why a review of your processes, systems and governing rules is essential before assuming any automated process will work elsewhere and can be shared. If your operational processes are not the same as those of a neighbouring organisation, even when using common software products, your configuration locally will need to be specific.
Myth: automated processes don’t need ongoing technical maintenance
Once your processes have been automated and are operational, you’re good to go and there’s no need to look at them again. Not quite. Let’s go back to the PAS example. The RPA toolkit will have been configured to run processes at a point in time, against a certain version of the PAS. This PAS will undergo regular supplier updates to fix bugs or make minor improvements and means that new versions of the PAS will be introduced at regular intervals.
What happens to the process that has been written for your robots?
Your organisation will have application managers and supporting teams whose task will be to validate the new versions for form and function. In the same way, your automated processes will also need to be checked. Elements of the process may need to be tweaked to work alongside the latest version of your PAS.
The process automation products available offer many ways to interact with the applications your organisation has, so ensuring your automated process continues to work in a robust manner is imperative.
Myth: you don’t need technical expertise to create and maintain automated processes
There’s an ongoing discussion around the level of technical expertise needed to develop as well as maintain processes and the automation solutions. Some say that only a basic level of knowledge is needed – and this is certainly demonstrated in the many online videos shared by suppliers and vendors.
If the system in which your automated process is working becomes unavailable due to downtime for maintenance mid process, it will have an impact. For example, if it was processing a spreadsheet, how will you track where it got to and how should you restart? You may not be able to simply carry on, as the steps completed successfully may have to be rolled back – row by row by row (speaking from previous experience when automating a finance process).
It’s a bit like searching YouTube for a fix-it video, finding a step by step guide for a similar product and giving it a go yourself. What you find halfway through is that you’re not making the same progress as the video is suggesting, and there’s no advice to tell you what to do. It is what’s not apparent at the outset that can trip you up.
The greatest opportunity for organisations to save time and money by leveraging such products is to look at reuse of developments internally by creating a library of interactions which will help to prevent the need to build from scratch every time.
- Conduct a thorough review of your processes, systems and governing rules before assuming any automated process will work elsewhere and can be shared.
- Be mindful that any bug fixes or upgrades to systems could have a potential impact on your automated process so factor in time and resource to review this as standard protocol for any system change. Check how often your solutions are updated and be prepared.
- Even basic processes can be subject to ‘oops’. Appropriate configuration of simple as well as complex tasks may require a more advanced level of knowledge and experience to build effective and robust processes around your workflow. It takes time, study, experience, and a level of technical expertise to build effective and robust process around your workflows.
- When you talk with a vendor about purchasing an RPA solution, remember to challenge. Ask questions. Even if your vendor says everything will be fine when you implement their solution, ask how much effort, how much technical capability, it would take if the plug and play doesn’t work in the desired way. Find out what skills were needed to design initially. Understand what the worst-case scenario could be so you are prepared and have no unexpected or hidden costs.