Get ready, the Robots Are Coming

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 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 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.
• 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.

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. 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.

Analyze the results

This information should be gathered centrally, and presented as a dashboard highlighting the best candidates for each technology.

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, 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.