Robots, in the form of robotic process automation, have made the move from the factory floor to the office, promising increased quality, reduced costs, and human liberation from repetitive, mundane and unsatisfying tasks.
In 2015, Gartner predicted that:
“By 2018, 45 percent of the fastest-growing companies will have fewer employees than instances of smart machines”
So, what is Robotic Process Automation (RPA) and how can companies take advantage of its capabilities?
What is RPA?
RPA is often hyped as the silver bullet that will finally deliver on all the promises made for Business Process Management (BPM).
Well, it isn’t and it won’t be.
However, RPA will address repetitive, rule-based activities that – due to complex business rules or interaction with multiple legacy back-end systems – have resisted automation.
RPA does not address the strategic solution (automate those rules and replace those back-ends), but it can provide a quick and cost-effective interim solution, improving productivity, efficiency, throughput, quality and scalability.
As with any new technology, there are challenges and risks – especially in removing human decisions – in applying RPA. To reduce the risk, start with small, low risk activities to prove the technology, and then move onto the activities that promise the most improvement for the least cost.
Understand your current state
The first step is to understand which activities would benefit from robotization, and which from increased use of a fully deployed BPM as part of a strategic modernization.
To do this, you need to be answer these questions:
- Are your processes mapped?
Without this, you cannot identify opportunities to gain benefits.
- Have all variants (different legislatures, products, etc.) been identified?
Each variant increases cost, and decreases benefit.
- Are the relevant metrics (volumes, costs, cycle times, quality, risk) captured?
If not, there is nothing to measure any potential improvement against.
To create an accurate and sound foundation for moving forward, your answers should be based on empirical data – your true ‘As Is’ state (see example process model below) rather than an idealized ‘To Be’ state.
Capture Empirical Data
Next you need to capture high quality empirical data from your application events logs and databases – however well you think you understand your processes, these sources know more and must be used.
Process mining provides for the capture and analysis of this information, as a means to generate:
- A first-cut map of a process, showing all the activities that actually take place and the frequency of the paths between them (see example map below).
- A comparison of real-world activity with an existing formal process map, to find the variants you didn’t know existed.
- Detailed real-world volumes, work and wait times, costs – and re-work percentages (see example stats below).
Armed with detailed files and a real understanding of your processes, you are ready to move forward.
Identify candidate processes
The next step is to identify the activities most likely to benefit from either RPA or BPM.
From the information you already have, you can tell at a glance the points in any process responsible for the highest pain – take the process map, this will highlight those that are performed by users (see example report below). Then for each process, pick out all the user activities with the highest pain, and move on to the next step.
Investigate the pain points
Once you know the pain points, identify which might benefit from either RPA or BPM using a set of questions, such as:
- Are multiple systems used for this step?
- Are all inputs and outputs digital?
- Are all decision points defined and documented?
- Would it benefit from running longer than is viable with human resources?
- Is there a high error rate? Or a high risk should an error occur?
Many answers should already have been captured in the process definition and mined data. Others can be provided using a standard questionnaire form (such as the one in diagram X below).
Analyze the results
This information should be gathered centrally, and presented as a dashboard highlighting the best candidates for each technology (see example dashboard below).
RPA candidates will typically be self-contained screen-based activities, currently performed by people and combining high degrees of repetition; a strong need to ensure data accuracy; and an enforced continuing reliance on legacy back-end systems.
BPM candidates (other than the wider processes within which these and other activities operate) will be those for which there is less dependency on legacy back-end systems.
It is important to consider both of these together to avoid duplicating work: a short term RPA fix that is later replaced by a quick win BPM fix represents wasted effort.
Build ‘what-if?’ scenarios
You can now map one or more potential future states, replacing each selected pain point with a robotized version.
With the help of your chosen or shortlisted RPA and BPM vendors, you should be able to generate relevant metrics such as:
- One-time installation, configuration and decommissioning costs
- Recurring fees
- FTE savings
- Risk reduction
You can then read off the resulting (from the metrics provided) TCO and ROI from the process output, enabling you to make informed decisions.
Monitor ongoing effectiveness
You can use statistics automatically gathered from your RPA and BPM tools to monitor the real ongoing effectiveness.
Statistics should then be presented in an Enterprise Dashboard (see examples below), showing:
- Actuals (volumes, costs, cycle times, quality, risk, etc.) against expected
- Actuals against pre-automation metrics
- Any deviations, along with early warning of any possible effect on TCO or ROI
- Quality and Risk heatmaps, with user-definable alerts
Following these steps you should be able to identify candidates for RPA and then implement solutions that deliver RPA-based benefits.