Stakeholders team up
Define the purpose
People in charge
The moment you start designing plan for the automation is the time to come up with priority areas. You will need to decide which processes you want to focus on first – which ones can save you most resources when fully or partly automated. The following two rules are very helpful when prioritising. Focus on short, frequently recurring and simple processes. This will allow you to achieve early results with minimum resources and interruption, inspiring you to continue implementing automation in other areas. Do not force your way into areas with the highest resistance to change and/or lowest benefits from automation. The change needs to come within – these employees will join later themselves after seeing their colleagues being more happy with their workload.
The C-level champion and implementation must have a joint plan of action to win organisational hearts and minds over to an authentic and proactive adoption of the RPA journey. There is a big difference between buying from a company who uses robots, and working alongside one. The fear that workers will be replaced by robots is a sensitive subject, and should be handled tactfully. For automation to be embraced internally, company leaders need to help workers understand how it benefits them. Businesses should also review their goals from an ethical standpoint before deciding to automate. The more common it becomes, the more automation will be accepted by consumers and employees alike.
The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.
Unfit vendor selection
Over-complex proof of concept
The point of a POC is not to confirm if RPA technology does what it claims to do. The primary POC purpose is to test business case assumptions, validate the best implementation model and assess RPA integration and technology partners. Yet confirming RPA capabilities remains the POC goal for many organisations. This mistake typically leads to a circumstance in which POC proves little, is not actionable and often slows down RPA momentum. It is not actionable because a POC validating RPA does not provide insights into how it might work within that specific organisation. Momentum is hurt because there is not an obvious next step. The POC should be designed to lay the foundation for the much more definitive Pilot step in the journey, and provide the answers and validations needed for approval to move onward to the Pilot.
Some organisations get so caught up with the idea of a fully automated end-to-end process they overlook the reality of diminishing returns. Others become so focused on automating complex process steps, while what’s actually needed is eliminating those steps with redesign. It is important to remember the low cost, low invasive nature of RPA. Unlike other automation technologies, it can generate a high ROI with only a partial automation of process steps. Attempting to extend automation too far into a process can lower ROI by significantly increasing implementation costs. Likewise, process optimisation is often a smarter route to savings than configuring a robot for complicated rules.