We at WorkFusion often find that customers feel trapped in analysis paralysis on how to begin their automation initiative. They want the best use case with the highest ROI and most impact to be prioritized first, and they spend weeks and months chasing this ideal. However, aiming too high may set you up for disappointment. The best use case is always a completed and delivered use case. It’s important to not lose the forest for the trees, particularly in the beginning when getting momentum is more important than getting it right.
1. Having realistic expectations
As a very first step, you need to set realistic expectations. Robotic Process Automation (RPA) is not a magic bullet that will fix all your efficiency and cost issues, instead, RPA initiatives should be positioned as a tactical effort to automate legacy systems and digitize manual tasks. Many business teams can benefit tremendously from RPA, and it has proven to be especially beneficial for operations, finance, HR, and IT. RPA is designed to perform manual tasks or user interactions and ultimately improve the quality and speed of these processes.
2. Identifying good RPA use cases
RPA is useful for high-repetition, highly manual use cases with minimal process changes. Be wary of processes that are set for large-scale IT integrations within the next 6–9 months. Embrace processes that use non-custom applications, and include business process management considerations and exception handling––remember that your bot doesn’t need to automate 100% of an underlying process to be effective. When you evaluate implementation, keep in mind that RPA is most successful when it’s used with processes that are well-defined with a minimal rate of change.
3. Getting early management buy-in
The enterprises who have the most insight into focus areas for improvement via automation are those who have recently undergone a large-scale audit in preparation for a merger or IPO, or have a process transformation and reengineering office in place. In such cases, use cases may have been vetted by senior business leadership and some initial groundwork may be laid to quickly establish the scope of work required. If you don’t already have that advantage, it’s important to identify process champions who are willing to take a risk and will support and cheerlead the project through the initial stages. If you’re starting to look within a specific business area, identify those champions and target their use cases first. Later, once you’ve achieved momentum and broad internal support, you can work on building out a broader book of work tied to a larger strategic initiative.
4. Focusing on generating benefits early
Automation is best delivered in an agile approach, because it gets working software into production for quicker feedback. Customers’ expectations and requirements on the end goal for automation may not stop at automation itself. Automating a bad process without considering whether it should be done at all, can lead to diminished value in the overall build. An agile approach constantly assesses which imminently most valuable component should be built for the end customer. Unlike traditional software development methods, where the completed requirements are produced upfront, and a project contains rigid phases, agile accepts that while requirements can change, and priorities may shift, the delivery system should be flexible enough to adapt and respond to the change in a nimble fashion.
5. Seeing how BPM and RPA work well in tandem
Existing business processes and RPA should complement each other. If you already have a Business Process Management (BPM) tool in place, RPA can complement and enhance it. There are three ways that RPA can impact process transformation while integrating with existing business processes. For example: RPA can be executed within an existing BPM, “replacing steps that may currently be manual in the process. Another scenario could be to execute RPA upfront and feeding resultant data (i.e. candidate information for HR or self-service requests for IT) into business processes. On the other hand, with WorkFusion’s RPA you don’t necessarily need a BPM tool to orchestrate the process, as you can use the BPM capabilities of our end-to-end automation.
6. Understanding potential changes going forward
Remember that RPA doesn’t replace underlying business systems. RPA should not require changes to underlying systems, and in the case of systems/processes marked for upcoming de-commission, RPA should be implemented with caution. If underlying business systems are up for decommissioning in the near future, determine where new functionality will be migrated. It’s important to identify any possible changes that could invalidate an automation initiative at this time.
If you have any questions about RPA and cognitive automation, please get in touch with us at firstname.lastname@example.org.