Robotic Process

Automation
(RPA) Insights
A practical guide to strategy, planning and working
practices to consider in deciding whether and/or
how to execute an RPA program

Author: Dean Smith Version: 1.3

© AssuringBusiness – all rights reserved

Table of Contents

What is RPA? ................................................................................................... 3

RPA vs RDA ..................................................................................................... 4

RPA Vendors and Procurement Considerations .......................................................... 4

The Role of Artificial Intelligence ......................................................................... 5

Business Goals & The Bigger Picture ...................................................................... 5

Disposable Robotics ........................................................................................... 5

The Business Case ............................................................................................. 6

Learning the Lessons of Others .......................................................................... 10

Delivery & Organization Models .......................................................................... 11

The People Perspective ................................................................................... 16

The Future of RPA .......................................................................................... 17

Conclusion .................................................................................................... 18

For information of RPA services offered by AssuringBusiness:

https://www.assuringbusiness.com/robotic-process-automation-rpa-services/

2
© AssuringBusiness – all rights reserved
1
2
The digital workforce has arrived. These guys don’t sleep,
eat or take leave. They will do exactly what you ask without
fail, day and night. Robotic Process Automation (RPA) has
evolved to enable radically innovative and cost-effective
workforce planning…
What is RPA?
Robotics is not new – ‘industrial robots’ have been
deployed in various industrial environments for
years, probably the most well-known being in
automotive manufacturing. But the unattended
automation of clerical/administrative processes
that do not pick things up and assemble them has
now also come of age with RPA.
RPA comes in various shapes and sizes. In fact some
process automation companies seem to be
rebranding themselves as RPA tools now too. So, to
help identify the real McCoy, probably the most
crucial differentiator is that RPA tools can interact
with other applications via the User Interface (UI)
as if a human were using the systems. Yes, many
RPA tools can also interact at the Application
Programming Interface (API) level too, but this is a
common standard for most applications these days.
The ability for an RPA tool to read and input via a
screen/UI is what makes RPA special and capable
of taking on traditionally human process tasks.
Simplifying and sifting the types of RPA into four
broad buckets we would have:
Basic: Rules based systems that do exactly what is
configured based on structured data and business
rules defining decisions and actions. These form
the workhorse of the RPA stable and are now being
widely deployed. They also form the core of most
of the augmented ‘smarter’ solutions currently on
the market.
© AssuringBusiness – all rights reserved
Enhanced: combining basic RPA with common
Artificial Intelligence (AI) based tools, typically
Optical Character Recognition (OCR) and similar
digitalization technologies to enable processing of
various structured and unstructured documents.
Note that older OCR technologies are not really
considered AI tools any longer (as they are
routinely available and used) but the more
advanced tools enabling extraction and digitization
of data from unstructured sources and handwritten
texts would often be in the ‘enhanced’ bucket.
Cognitive: Combing the above with cognitive
engines that enable inputs (text, voice, images
etc.) to be ‘understood’ for rules based action.
Different levels of comprehension (and therefore
application) exist depending on the sophistication
of the technology utilized. Advanced cognitive
tools will be able to interpret, for example, the
tone or mood of an input and potentially treat the
item differently from others with similar content,
e.g. push aggressive customers to special handlers.
Intelligent: Stepping up from mere understanding
of content to full interpretation where decisions
and actions are made ‘intelligently’. Intelligent
RPA will have strong AI at its core and will learn
from mistakes and human guidance, adjusting
future approach. It will evolve decision quality
based on inputs and outcomes observed.
Apart from fully automated (unattended) RPA you
will also see attended robotics under the Robotic
Desktop Automation (RDA) banner.
3
3

RPA vs RDA
As the name suggests, RDA is focused on supporting a user in their daily operating activities
on their desktop and would typically operate under their personal user-ID acting as a local
tool connecting applications that they normally access directly. Calling an RDA process to
run can be completely manual (e.g. press a button on screen) or be linked to some other
activity (e.g. triggered when entering a value in a specified field of an application).

RDA may be very useful when having to combine inputs from various systems but maintain
human engagement or control within the process. These are ideal for lower-governance
requirements such as collating data from various systems and presenting as a single summary
prior to a customer contact, e.g. collections calls. Or writing notes to numerous systems and
only entering once. Or any situation that requires multiple copy-pastes. Etcetera. RDA can
also be used for more extensive processes but then you must examine the robustness of the
environment, extent of human interaction and governance levels as an unattended or
staggered RPA deployment may suit better. RDA licenses also tend to be less expensive than
RPA and can run on lesser specification hardware.

RPA is typically deployed in a ‘no-touch’ process execution, replacing the need for human
engagement until the process is complete or triggers another automated activity – known as
‘unattended’ or even ‘headless’ automation. Clearly, however, human interaction can be
configured within its build if required, e.g. in a staggered RPA deployment where two
process parts are separated by a human approval step. Human engagement in these
activities is rarely value-add so it’s wise to really look at the process and determine what
can actually be automated to avoid bottlenecks.

RPA is typically deployed in server environments (and there are various hosted, virtual and
in-house options here) and may stack many robots on the same kit, or have the robots
executing various processes, capacity and process serialization permitting.

Understanding the technical infrastructure needs and limitations of RPA tools is an important
consideration and may have a significant bearing on costs and returns. Hence, direct
involvement of your IT infrastructure and security functions is essential during procurement
and design stages. I would also recommend that you seek direct proof of operability in the
preferred technical deployment environment, either through previous deployment
references or testing in the target environment. With a rapidly evolving state of the game,
claims and theoretical fit do not always pan out as expected!

In this paper I collectively refer to RPA to include RDA, and hope to point out any significant
differences or considerations that affect RDA as they occur.

RPA Vendors and Procurement Considerations

There are many different vendors of specific RPA tools and tools that were fulfilling other
automation functions that are now adjusting their positioning to capitalize on the RPA trend.
Although in essence the differing tools on the market should provide similar core
functionality, the nature of the interface to build/configure robotic processes does vary and
there will also be differences in exactly how certain functions work. Configurator usability
may depend on some degree of technical skill supplementary to simple user training, for
example, so best to identify and test the hands-on aspects to assess the people development
requirements that accompany the tool.

Personal preferences, or history with existing suppliers, will no doubt steer RPA tool
selection unless there is a thorough procurement process – highly recommended if you
intend to embed operations directly into your organization.

However, if you are seeking a ‘managed service’ type of operational deployment then the
tool itself should not be as important as you will focus more on outcomes; costs and
benefits. Naturally, specified requirements for a managed service will ensure technical fit to
your IT and security needs, but there will likely be various RPA tools that would fit the bill.

Another particular reason for a thorough procurement process is that there are a wide
variety of commercial frameworks available from small-start, incremental build to large-
scale enterprise positions. A well-designed Request for Proposal (RFP) process will ensure
that technical, operational and commercial considerations are defined and balanced to
produce competitive tenders that in turn drive positive results in fit and commercials.
Especially if tools are bundled with services. In fact, the key to success is rarely the tool 4
© AssuringBusiness – all rights reserved
4
5

itself; it is the way that the tools are delivered that
makes the biggest difference. We shall look at the
delivery and operational aspects later in this paper.
The Role of Artificial Intelligence
You should note that there are many AI variants and
a quick search of Wikipedia will enlighten here! AI
plays a major part in the evolving RPA landscape,
with ‘deep learning’ being a new mantra for vastly
iterated machine learning, usually employing multi-
layered neural networks or other AI protocols. In
essence deep learning provides for better
interpretation and decisions and is currently being
applied in particular to enhanced cognitive and
‘computer vision’ components. It takes us closer to
the human experience in terms of understanding and
decision-making. One could argue that with greater
consistency and an ability to incorporate vastly more
information in an AI-RPA decision process, outcomes
would ultimately be significantly better than those
of a human-managed process. And with speed and
cost considerations, the future of such technology is
certain to be deeply engrained in many aspects of
our lives. As AI evolves, the need to ‘partner’ with
basic RPA components (as is often the case to enact
process, decision branches etc.) will likely lessen as
the decision making process will inevitably become
‘more human’ and may in fact learn process from
training data and other inputs rather than defined
‘hard coded’ business rules. We shall explore some
applications for this technology variant in later
papers.
Business Goals, Challenges & the
Bigger Picture
Yes, RPA can deliver significant benefits, but if you
are not ‘thinking strategically’ you can also
jeopardize a future business case for more
fundamental change, inhibit business flexibility and
increase operational costs at the same time.
enabling an early opportunity trajectory to be set
and leveraged, whilst maintaining the need for, and
momentum of, strategic system and process
improvements.
It’s tempting to consider RPA as a ‘silver bullet’ to
many challenges, but in fact RPA can cause more
problems if poorly conceived, planned or deployed.
There are many examples of businesses trying RPA
then abandoning after a poor initial experience.
Maintaining direction and drive towards strategic
goals is an imperative whilst you deploy and operate
RPA to a well-considered priority structure.
Communicating the original problem and
performance indicators as a continuous reference
point becomes essential to help ensure that the
strategic needs are not de-prioritised or forgotten
altogether. Parallel activity is a must to drive robust
improvements with long-term sustainable benefits;
core systems and process improvements in
particular.
Disposable Robotics
Tactical use of RPA whilst progressing strategic
change is a great option to consider: ‘disposable
robotics’. It’s a pragmatic approach to leverage
short-term gains targeting process options with
shorter Return on Investment (ROI) cycles whilst
continuing the strategic improvements to systems
and processes. Although some will argue that RPA
might be a distraction from the strategic
improvement plan, in reality parallel RPA activity
has been found to provide insights that usefully feed
the strategic roadmap. Insights that would not
normally be visible without the deep-dive that is
needed for RPA success.

As I am sure those that have leveraged Business

Process Outsourcing (BPO) partnerships in low-cost
delivery centers can testify, once the cost-arbitrage
of a ‘lift and shift’ process drop has been realized,
the cost-benefits of subsequent process
transformation can be harder to demonstrate. As
business priorities will continue to change, a promise
of future commitment to such a focus is often not
realized for very practical reasons of priority. A
more logical stance would be to re-engineer process
prior to BPO, but when cost pressures mount, quick-
wins are often taken when they present themselves,
accruing benefits until larger changes mature.

In the context of RPA, the same sort of issues can be

There are many common
generated if you’re not careful. Deploying RPA on business goals that RPA can
clunky legacy systems and inefficient processes will
often bring about rapid cost and quality benefits assist with…but it’s important
irrespective of how poor the target processes are.
Clearly not an ideal situation as we should ‘in to keep your eye on the
theory’ be fixing processes first. So the balance to
strike here is one of immediate pragmatism, bigger picture.
5
© AssuringBusiness – all rights reserved
6
7

The more fundamental strategic

changes will often reduce the need
for resultant human or RPA
activity, so recognizing this as a
longer-term benefit goal whilst
squeezing the RPA lemon in the
mean time can present a powerful
business case. And what’s more, in
this way, you will learn the ropes
of RPA, enhancing the delivery
engine and building business
engagement with tangible
outcomes. This tactic leads to a
very efficient and effective
delivery regime to ensure that
longer-term ROI cycles can be
considered alongside the core
systems and process changes being
progressed.
But then there are the soft-
benefits to consider too…
quality, cycle times, error
eradication, complaint and
escalation reduction, enhanced
consistency and controls etc.
Often these soft-benefits
present a compelling business
justification in their own right
and direct FTE cost savings may
be reasonably demoted or even
ignored.

Of course, in reality, most robots are not ‘thrown away’ when no longer utilized, they are
redeployed/recycled against new target processes, or refined to the changed workload or
re-engineered process. Similarly, the technical infrastructure used to host/operate RPA is
also generally recyclable. But it makes for a simpler business case to consider ROI in
‘disposable’ terms.

The Business Case

Whilst keeping in mind the disposable option, some businesses will have a disposition
towards a more ‘normalized’ ROI and deployment strategy for RPA. Typically these
businesses will be process-centric and already have strong Lean, Six Sigma or Continuous
Improvement mechanisms embedded and matured. Accordingly, RPA can then be focused
on optimized processes, perhaps with a longer-term ROI cycle. However, the majority of
businesses are not in this position and therefore a more tactical or hybrid approach may
be useful.

By far the most common challenge for RPA is in maintaining the balance of dynamic and
‘light’ delivery practice with appropriate governance. By their very nature, some
processes will require stringent governance in aspects of delivery (e.g. where values are
calculated or loaded, payments approved or made etc.). However, it’s very easy to kill or
cage RPA through over-governance, which is why some of those that have attempted RPA
programs have walked away very early in the lifecycle experiencing higher than expected
delivery costs. We shall talk more about this balancing act later in this paper.

With systemized and well-considered RPA delivery practices it’s possible to achieve ROI
within a few months or even weeks of deployment against certain target processes.
Depending on the location of resources saved (low-cost locations providing a higher FTE
target) anywhere between 1 and 6 FTE saved could result in a cost-benefit (maybe less for
RDA). But then there are the soft-benefits to consider too… quality, cycle times, error
eradication, complaint and escalation reduction, enhanced consistency and controls etc.
Often these soft-benefits present a compelling business justification in their own right and
direct FTE cost savings may be reasonably demoted or even ignored.

In any event, there are numerous costs and benefits to consider. I list the most common
items here but of course every business is different and so the business case needs to
reflect the reality of the unique business landscape. Where possible, try to quantify the
hidden costs and soft-benefits too – this not only helps to overcome many potential
engagement barriers on the RPA journey, but also provides insight to the actual ‘total cost
benefit’ position.

Costs

Discovery & Design. Key to optimizing delivery and outcome is the preparation:
opportunity identification, assessment and delivery planning. Cutting corners here, or
applying shallow practices, will inevitably increase costs and frustration. Systematic
evaluation combined with expertise in process analysis and teasing out the detail from
6
© AssuringBusiness – all rights reserved
8
9
Subject Matter Experts (SMEs), Process Owners
and/or process actors is all-important to arrive at
the correct opportunity prioritization and specific
process components to automate. Structuring the
approach using supporting tools (e.g. structured
process data capture and evaluation criteria
spreadsheets encompassing weighted scores for
component elements) to enable discovery and
‘truthful’ evaluation will reduce costs (much can
be done remotely), improve cycle time to decision
and help to ensure transparency for optimum
selection decisions.
License/Subscription. Most RPA tools are annual
subscription based, but it is also possible to
negotiate enterprise license deals. Pricing has
already become very competitive for basic RPA
tools. Augmented RPA will attract higher costs
depending on the capability and availability of the
augmenting component, e.g. some basic OCR
software is open source, ‘shareware’ or included
in other applications, whilst the latest cognitive
and AI components are still quite pricey (for now).
Also worth noting that many vendors will not
charge for licenses that are not used in
production, i.e. development, training and/or
Business Continuity ‘ready state’ mirrored RPA
capacity would not attract license fees.
Some vendors will also consider gain-share
arrangements, particularly those that provide
delivery and operational management capability.
But beware, gain-share can be a minefield to
define and articulate contractually such that there
is no ambiguity and reason to ‘fall out’ when the
gains start flowing.
Infrastructure. Your IT functions will play a critical
part in deciding the infrastructure that may be
utilized. In-house local servers, company server
farms/data centers, remote/cloud hosting etc.
will be included in options and even deployments
on desktop PC’s for RDA or as pilot infrastructure
for RPA may be feasible. Don’t forget that the
right thinking behind tool and deployment
infrastructure may enable or disable scalability,
and significantly affect cost-benefits, so think
ahead and ensure the approach fits to your future
needs.
Security, Continuity & Compliance. Many
businesses seeking to deploy RPA will be operating
in a regulated environment that may dictate
specific compliance requirements. But in any
event, information security and business
continuity are essential practices that carry a cost
to ensure the right balance of risk prevention,
mitigation and effective response/recovery in the
event of an incident. There are usually particular
needs regarding processing of ‘personal data’
and/or policy/preferences as to where data is
stored or processed that need to be factored in to
architectural and operational designs. With some
business critical processes likely to be automated,
security and continuity take a prominent position.
© AssuringBusiness – all rights reserved
With some business
critical processes
likely to be
automated, security
and continuity take a
prominent position
Remember that as you automate more, there is
likely to be a drain on resources with in-depth
knowledge of the processes automated. High-
quality documentation of the process design
should help to counter this risk to some extent,
but you should bear this in mind as the ‘human
fallback plan’ as a continuity option might not be
possible without a bench of spare or immediately
usable resources. Better to consider your
existing IT business continuity plans seriously and
look for suitable options. Where multiple hosting
sites are used for RPA, there may well be an
option to spread the recovery capacity over
surplus-to-requirements hardware/disk space at
alternate sites to reduce the cost of full mirroring
for example.
With a seemingly endless thread of cyber attacks
in the news, protecting the operational business
processes automated via RPA, whether in-house
or outsourced, might be considered a major
hurdle to extensive automation. However, with
an appropriate risk assessment and control
framework, such risks are readily managed and
should not present as a red line.
Implementation & Testing. Needless to say the
more complex a process, or the more exceptions
requiring build, the longer a deployment is likely
to take. Ensuring expected outcomes and
operational quality will fall to the testing stages.
It’s important to ensure that test evidence is
appropriately captured and recorded for audit
and ‘go live decision’ purposes. Again, bear in
mind the need to balance heavy and light
governance and seek ways to lighten the load to
reduce costs here.
Business Engagement. Sounds obvious I know, but
this can be a significant hidden cost. Many larger
businesses will have politics at play creating
significant lags in alignment and delivery. The
sheer size and scope of operations being
automated will play a major factor in
engagement effort required; the more process
touch-points and functions involved, the greater
the need for proactive and sustained
engagement. Additional (for RPA) FTE
calculations as a percentage of a role’s activity
should be assessed for this element.
7
0

Delivery Governance. Even small and simple pilot projects require governance. When
you get to company-wide initiatives, involving complex, high-risk or sensitive
processes, governance can become a beast – and for good reason – there are many
factors to optimize and control in such a program. The key is to strike the right
balance and avoid the cost of governance stripping away the benefit.

Maintenance & Change. It’s great having an automated process that works. Keeping it
working is the next rather critical step! Things change. Often. Processes, policies,
core systems, UI layouts, reference data etc. all contribute to the change
management cycle. If any factors that cause frequent re-working of the RPA
configuration or connectivity exist then these should be considered at the discovery
stage and evaluated as to their fit for automation before starting.

Tight integration to IT and business change management processes, working ahead of

the curve, is essential to avoid being blindsided. Resources and governance practices
are required to keep the RPA maintenance process effective and the FTE needs to be
factored into costs. Remember that a dynamic business will require dynamic (rapid)
change and RPA maintenance practices should enable this. However, as change
practices already exist, the piggyback nature of RPA engagement should mean a
relatively low incremental management cost. The RPA (re-) configuration/change and
testing tend to be most prominent costs with magnitude related to frequency and
scope; assessing these historically (for each process) and relating to future business
and technology strategy is the best starting point for maintenance cost assessment.

Benefits

Quality & Consistency. Operational errors can be a thing of the past with RPA. Basic
RPA, with its clearly defined decision and activity paths, ensures complete
consistency. Whether it is customer or partner engagements, or internally focused
processes, consistency and quality improvements will positively affect the level of re-
working, complaints and escalations. Although rarely quantified and measured as a
normal cost of business, with a little effort these common issues are relatively
straightforward to appraise. Determining current costs in cash terms (e.g. average
monthly re-work, complaint and escalation management time for cases using
associated FTE costs, plus any actual monetary impact such as lost payments or bank
charges) plus reputational or Net Promoter Score (NPS) impact (e.g. assessed via
proactive engagement or activity feedback loops) really can produce quantifiable
benefits here.

Speed & Productivity. Transaction/process cycle times can be dramatically improved.

With a robot potentially working 24x7, providing there are no designed-in
bottlenecks, productivity will sharply increase. Current metrics should be readily
available or if not they are easily measured with some simple time and motion
sampling. High-level measures may be calculated from deployed FTE and
process/transaction volumes. Assessing post-RPA targets may leverage a vendor’s
previous implementation examples and/or should become evident during the design
stage looking at the ‘to-be process’. In any event, testing and operational use will
provide exact data – just make sure you build the metrics into the test and
operational reporting frameworks.

Governance, Compliance & Auditability. In the early days audit and governance
functions were a little wary of RPA. There was a huge mistrust; I think because of a
belief that the risk of configuring incorrect process steps or dodgy dealings in a ‘black
box’ setup would be feasible and may lack transparency. In fact the opposite is true –
RPA provides excellent transparency into processes and detailed audit logs of all
activity (plus those of core systems engaged with the robot). It is true that the design
needs to be validated and tested, then access-locked when in use, but that is the
same for any process or system implementation. The fact that RPA consistently does
exactly what is asked has brought most of the original naysayers on board. More
recent conversations with governance and audit functions now tend towards a
positive view of RPA: enhanced process design and execution, access to detailed audit
data and process reviews now taking less time and effort to complete.

Workforce. Usually quantified in Full Time Equivalent (FTE) costs, workforce planning
can now change in many ways. Firstly, all new processes can be designed automation-
first; right-first-time principles and zero people impact (no one is employed that
8
© AssuringBusiness – all rights reserved
1

needs to be replaced). The ‘opportunity benefit’ (not employing resource, zero errors
etc.) will form a major part of the business case for new processes. Note – RPA alone may
not be the right automation approach – see the bigger picture comments earlier in this
paper.

Secondly, where existing processes are retrospectively automated there may be FTE
savings. The business can then decide whether to ‘cash-in’ and reduce operating costs or
shift resources (if appropriate capability) to other activities. When assessing the business
case, one-off costs such as redundancy or re-training should also be considered. FTE
savings potential should be calculable from the improved processes and productivity
metrics incorporating any hidden costs that would also be reduced (re-processing,
complaint management etc.).

Thirdly, the business can readily develop a refreshed lean and dynamic culture through an
automation program thread. This approach will bring significant Human Resource/talent
management strategy changes end-to-end; recruiting to a different competency and
capability bias; virtual, digital and distributed workforce management practices replacing
traditional waterfall management structures; career management recognizing the digital
workforce impact; and so on. Ultimately this should mean a modernized HR practice with
reduced team size that can be quantified. See also ‘People Perspective’ later in this
paper.

Shared Services and Business Process Outsourcing (BPO). I mention Shared Services and
BPO separately as there are distinct and quantifiable benefits here. Despite best
intentions to move towards outcome-based engagements, many BPO contracts remain
driven by FTE-based charging models (…another subject and paper). Accordingly, applying
RPA to a process that is outsourced or operated in a shared service center may reduce or
negate the transactions/activity that the operations center would normally manage.
Reducing operations center inputs would have a direct impact on FTE, and therefore
costs, and may negate outsourcing altogether especially if RPA is undertaken as a design
re-think prior to a BPO shift. Assuming existing contracts allow for change and charge
adjustments, there should be significant financial (and quality) benefits to target here,
readily quantifiable. Note that where resources are located in a low-cost location, the
number of FTE saved would need to be higher than in high-cost locations.

Like many who have commented of late, I believe that RPA will have a major impact on
shared service and BPO operational models over coming years; those that take a lead
should avoid a ‘Kodak moment’ and may even forge a strong first-mover position in truly
automation-led operations. More on this topic in future papers.

There are specific BPO-centric delivery considerations discussed later in this paper.

Information Technology. In working with IT business partners there have been some
interesting benefit opportunities stemming from RPA. First, many businesses will have
‘legacy’ systems that are increasingly difficult to maintain and integrate to new solutions,
often because of a decline in relevant skills/knowledge but also as older systems may not
include API capability. RPA can help overcome some of these challenges providing a UI-
based capability to Extract, Transform and Load (ETL) data to/from legacy. Most
enterprise ETL tools do not operate at the UI level so RPA can provide a cost-effective
workaround to integrate a legacy system with new systems and/or RPA components.
Structuring RPA based ETL well could make it relatively easy (and cheap) to maintain,
even for complex architectures.

Second, master/reference data management can be greatly enhanced by RPA; a common

deployment theme. Automating a ‘single version of the truth’, deploying a ‘golden copy’
of data across systems and reconciliation of data differences or gaps is readily facilitated
by RPA. This capability can be applied to many aspects of an IT landscape, not just
business/user managed data components.

Third, RPA has forced a new way of thinking around systems architecture and application
management. Some of the old challenges are no longer as significant (e.g. cost of
upgrading a core system to automate certain tasks) and, as with the ETL option mentioned
above, new dynamics come into the design sphere to enable solution architects to better
automate a process end-to-end (e2e); surely a more satisfying and ultimately cost-
effective solution for their internal (and external) stakeholders.

9
© AssuringBusiness – all rights reserved
2
3
Fourth, the utilization of ‘seat’ based application
licenses is improved with the huge productivity
increases likely with RPA, which can have a
significant impact on business cases for system
procurement or expansion. But I suspect some
enterprise software providers will also be looking
to counter this ‘opportunity’ any time soon.
Learning the Lessons of Others
Vastly increased automation is inevitable for most
businesses that ‘suit’ RPA. Right now basic robots
can readily take on board repetitive process
activities; this is often where a major portion of FTE
cost lies. However, tools further up the value-chain
will enable far more sophisticated deployments;
examples in use include drafting/validating complex
cross-border legal contracts, automatically assessing
damage to vehicles from photographs and
quantifying insurance costs/claims, digesting
medical reports to assess and approve health
insurance claims, engaging with customers via chat
to resolve queries and disputes etc. The list of
possibilities is very long even with today’s
technology; imagine what will be possible in the
next 5-10 years!
So my view is that there is significant benefit in
creating an angle of trajectory sooner rather than
later for a well-considered RPA program:
Assess & Plan
Pilot & Prove
Learn & Apply
Systemize & Deliver
Taking the plunge will enable early learning and
adaptation of practices towards a systematic
delivery mechanism, which is where the pot of gold
really lies. There will always be a reason to put it
off, there will never really be a perfect time, but
that is merely delaying the inevitable and forgoing
the benefit that could be aggregating every day.
Some businesses will take a stance that they will
only consider RPA once their processes are
optimized, leading with Operational Excellence (or
similar) functions. A great position if it’s easy to do,
but pragmatically this will suit few. Although it’s not
ideal to automate a poor process, and it may ‘feel’
wrong, doing something quicker, more consistently
and with fewer resources may well be considered
better for the business than the current (albeit non-
optimized) error prone and labor-intensive position.
Moreover, there is a great opportunity to drive
process improvement in parallel with RPA and
optimize the process-centric talent that is necessary
to succeed. RPA delivery necessitates a process
deep-dive and improvement opportunity assessment
so driving process change whilst delivering RPA is a
credible option. If you look at RPA as a vehicle
towards process improvement (rather than the other
way around), then the resources needed to drive
process change are better utilized harnessing both
© AssuringBusiness – all rights reserved
process and RPA knowledge via the automation
thread. See also some further comments later in this
paper regarding the Process Re-engineering Loop.
Business ownership of an RPA program is a common
question; where should it sit? The most commonly
held view is that it is not owned by IT. Although
there is a need for application connectivity and
technology infrastructure, the nub of RPA is process
centric. RPA does not require the same delivery
framework or technical capability as other IT
projects. There are two main options to consider;
embedded within the units or functions themselves,
or centralized ownership in some form; see the
delivery model comments later in this paper.
However, it is important that there is CXO
sponsorship for an RPA program and this might
typically sit in the COO or CEO camp. If there were a
CXO charged with innovation and change, then
perhaps this would be a good home. All CXO’s are
likely to be affected in a wide-ranging program and
will need to be aligned on the strategy; the key is to
ensure that it gets focus and momentum.
In any event, it’s important to start the RPA journey
as ‘right as can be’; there have been several
examples of failed RPA programs. From my
discussions with those that suffered this fate it
appears that the majority did not have the
opportunity to learn from the lessons of others and
so fell into similar traps. Common issues to avoid
include:
Overly-complex, high-exception rates or
change-prone processes targeted as a pilot
or initial implementation
Unstructured or shallow process discovery
and design leading to process gaps and
multiple RPA configuration cycles
Attempting to configure the entire process
100% rather than applying the 80/20
principle and automating the highly
repetitive tasks first, avoiding or eradicating
exceptions (see tips later in this paper)
Ill-conceived technology infrastructure
leading to inflated costs or risks
Inappropriate stakeholder engagement
and/or alignment; failure to bring security,
risk, compliance and audit functions on the
journey; politics driving barriers to success
Poorly defined roles, ownership and
accountability of program and delivery
components; assumptions not validated;
overlaps with BAU or activities in other
functions causing conflict
Over-zealous business case targets (usually
stemming from points above); ignoring ‘soft
benefits’ which in fact can be a key business
win.
10
4

Delivery & Organization Models

A well-structured and systematic delivery framework is the key ingredient to success. Way
more, I believe, than the RPA tools themselves. It is pretty much the same for most
applications; you can have the best tools in the world but if they are poorly implemented,
configured or used then payback will be harder, and stakeholder feedback tougher! And
we all know that a poor craftsman will blame his tools…

The example delivery framework depicted above is one developed in practice and refined
through various projects and engagements. But this needn’t be the model you adopt.
Every business should develop a framework that fits to their needs and integrates well to
existing business practices. RDA delivery protocols may well be ‘lighter’ than this RPA
model. But in any event, with many potential steps in the delivery chain it’s essential to
work towards a smooth, consistent and systemized practice else costs will spiral and
business cases go out of the window. Early pilot and initial implementations should
manage stakeholder expectations such that lessons will be learnt, mistakes will be made;
this is normal. It's almost impossible to plan in detail every nook and cranny of a delivery
process on paper without trying it out and learning some of the environmentally-unique
and hidden points to build in. And it’s really important to review and update the delivery
mechanism regularly, especially in the early days, to achieve a smooth, systematic and
cost-effective practice.

The Process Re-engineering Loop in the diagram above is worthy of special mention. At
all stages of an RPA program we should be seeking to improve what we do. By combining
improvement thinking within the RPA delivery framework we can bring about structured
and rapid change:

On-the-fly. Typically small changes that are completely within the

responsibility/decision scope of the function/process being automated. Such changes
can be rapidly assessed and implemented into the to-be process RPA configuration.

Small/Medium. Change of more substance or that may require approval from process
touch-points up- or down-stream. In environments that have strong cross-business
engagement, it may be possible to integrate changes into day-1 RPA deployment.
However, some changes may require more time to approve or design and would be in
the ‘do soon’ bucket. Make sure you have somebody allocated to drive these changes
forward.

Major/Strategic. Longer-term and/or more costly changes. We will often identify

significant (more fundamental) improvement opportunities that rely on changes to
core systems or other processes. It’s important to document and track these to identify
the best delivery options and timing, incorporating with other change initiatives where
appropriate.

11
© AssuringBusiness – all rights reserved
5

Organization Models

There are various organization models in use to deliver RPA programs. The main variants
include:

Center of Excellence (CoE). A popular model with specialist RPA resources grouped into
global, regional or country hubs working to a single framework (maybe with limited
local variances to suit special requirements). It’s reasonably common for businesses to
recruit and retain their own skills, but given the relatively strong growth of RPA
currently, directly employed talent availability with direct experience may be limited.

Pros: Scalability, utilization rates and talent management are major benefits to a CoE
model. Resource attrition should also be more manageable with a more extensive (co-
located) resource pool.

Cons: By nature a CoE will likely be distant from the target processes, and in-depth
local or process knowledge will often not be inherent in the team. Accordingly, travel
costs could be relatively high and delivery schedules a little longer.

A CoE serving cross-business functions would also be subject to prioritization of

projects and resources which would often mean that the less sexy functions (typically
middle- or back-office functions such as Finance Operations) may get less than their
perceived ‘fair share’ of focus; remember that these functions have cost and quality
targets too so a mechanism to enable ‘managed universal access’ to the CoE should be
considered.

Embedded. Maintaining RPA talent directly in the location or function is quite

appetizing to many and often the default evolved structure for a business that does not
have a well-thought-out automation strategy. The exact nature of deployment may
vary; specific functional teams or countrywide teams for example.

Pros: Proximity to the deployment process and landscape could help improve process-
specific delivery quality, timeline and costs. Flexibility and focus on localized priorities
(not competing for CoE resources).

Cons: Potentially a very fragmented resource pool company-wide leading to wide

variations in delivery practices hence rarely achieving delivery best practices or
benefits of process and technology alignment on a wider scale.

Hybrid. Taking a hybrid approach is likely to be the format of choice for geographically
widely dispersed businesses. Typically this model blends a mix of locally (or
functionally) recruited RPA talent, or existing Operational Excellence (or similar) teams
enhanced with RPA expertise, with a centralized pool of resources to mange a best-
practice delivery model and provide supplementary resources for back-fill of local
resources or high-priority projects. Hub-and-spoke type of structures may combine
local functional with group (e.g. Shared Services) units.

Pros: Best of both worlds – leveraging a standard (continuously improving) delivery

model with localized resources, focused on locally agreed priorities also reflecting
company goals. Talent management plans could also take advantage of the wider
business RPA opportunities for personal development.

Cons: Maintaining a lean and effective centralized team that integrates well with local
teams can be a challenge. Ensuring local talent or business units do not feel that
group/central functions are dictating approach and ignoring local/functional needs.

Governance

All RPA delivery models should include governance. There are various governance
activities, strategic and operational, that will require attention at all stages of the RPA
program, concept through to operational maintenance. Typical governance structures will
include a Steering Group for program direction and key decisions, and an Operational
Forum to deal with detail and day-to-day issues. These groups can be integrated to
existing business/change groups where there is scope, but again it’s important to ensure
that the group has the bandwidth to perform this function.

12
© AssuringBusiness – all rights reserved
6
7
Finding the right talent is not as hard as it may seem.
Attitude and aptitude make great fodder for re-skilling,
whilst 3rd parties enable immediate kick-start resourcing.
You may even choose to outsource the whole RPA program.
Whatever the governance structure implemented,
documenting Terms of Reference (TOR) will be a
useful step to ensure all members are on the same
page. Membership should be carefully considered to
ensure that they have appropriate
ownership/accountability and authority to decide
and act at that forum (and not continuously defer to
others). This is where the politics of progress will
really be dealt with, so strong communications and
collaboration within these groups is essential.
Permanent and specialist/occasional members may
be considered where needed.
The governance regime should ensure that it is able
to drive and visualize the pipeline, prioritize
opportunities, approve resources and budget,
deliver to plan (time, cost, quality), report on
progress and value, manage risks, issues and
escalations, and align with relevant cross-business
policies and activities.
Governance can enable or disable RPA. It’s a tricky
balance to strike and the more systematic the
delivery framework becomes, the lesser the need
for intervention or correction via governance.
Hence, working hard to systemize the delivery must
be a key priority of any program.
Delivery Resources
There are several potential resource pools available.
Discrete and blended models are being deployed and
there is no right or wrong approach, merely the one
that best-fits your immediate and future needs.
When planning the delivery framework and
organization structure, the source and nature of
resources to drive RPA are equally important to
consider.
© AssuringBusiness – all rights reserved
Let’s take a look at the key roles that may be
included in a typical RPA delivery structure:
Strategic Lead
Key Purpose: Strategic vision, business planning,
senior stakeholder management & alignment,
delivery framework ownership (including SLA’s),
business case management, steering group chair
(final escalation stage), value and progress
ownership and reporting.
Considerations: Could be integrated to another
leadership role (e.g. Operational Excellence,
Innovation etc.) but care should be taken not to
dilute focus as ‘edge-of-desk’ rarely works well. A
new or combined function to drive RPA as a
component of overall innovation and proactive
change discovery/delivery is ideal. Role holders
should be extremely competent in communications
at all levels and passionate about the opportunity to
drive real change.
Program Management
Key Purpose: Pipeline management, business case
and budget coordination, Project Manager
management, program delivery risk and issue
management, cross-business and/or supplier
resource planning, escalation management, cross-
business change coordination.
Considerations: Program Management requires a
senior status individual, one that can support and
drive the Strategic Lead’s vision well. A talented
communicator and exceptionally strong motivator is
needed here. Well organized and ideally with strong
project and program management experience.
13
8

Project Management

Key Purpose: RPA project delivery. Cross-business and/or supplier resource delivery
management, project issue and risk management, maintenance planning.

Considerations: Project Managers are quite a common resource. Finding one with the
passion and communications skills that make a great PM is more challenging. Although it
will help to have a PM that has been RPA tested, it is not essential providing they are
willing to listen and apply the lessons of others who have been on the RPA journey. Being
meticulous with detail and not assuming that the many moving parts in the delivery
framework will work smoothly without significant nurturing are important attributes.

Note: where 3rd party resources are used they may also employ a PM or Single Point of
Contact (SPOC); in such cases it is imperative to ensure alignment, tight planning and
frequent open communication.

Process Improvement & Design

Key Purpose: Discovery, analysis, improvement and RPA opportunity assessment, to-be
process design/architecture.

Considerations: There are many potential talent profiles to target here, e.g. Lean, Six-
sigma, Process Engineers/Architects etc. that may already exist in the business, especially
those with Operational Excellence or other performance/innovation focused teams.
Detailed process decomposition, design and documentation skills will be essential. They
will have to work well with Subject Matter Experts and Process Owners from the various
business functions in review. Above all they should drive new thinking and ways to
improve existing processes, working towards common standards where feasible and
permitted.

RPA Configuration

Key Purpose: RPA build, configured library management, testing (unit and stage), testing
support (SIT and UAT), maintenance planning support.

Considerations: Apart from the obvious logical and structured mind needed to take
process into the selected tool(s) – along with training and certification in those tools - the
ability to spot process improvements and/or risks during configuration is a great asset.
Clearly you do not want a configuration to keep stalling, but somebody that can capture
and present opportunities and risks for review of the expert process team would be a very
valuable addition. After all, these guys should be doing a lot of RPA grunt work and they
will come across many example processes; with the right attitude and capability they are
likely to add increasing value over time.

Note: Configuration Quality Assurance (CQA) may be considered as a separate role. Often
CQA may be outsourced to the RPA vendor or 3rd party specialists. The purpose would be
to review and validate the RPA construct and ensure optimized configuration prior to
deployment. Feedback would often provide insights to people development paths and/or
the delivery framework itself.

General Resource Comments

The RPA program will also need inputs from IT (various units, e.g. architecture, access
control, infrastructure, operations etc.), audit/regulatory/risk/security/compliance and
process/function-based resources at different stages. It is most likely that these inputs
will be from current team members with related scope, rather than new roles. Preparing
the ground for an RPA program should take account of the need for these resources (and
functions) to understand the RPA opportunity and avoid potential roadblocks. In fact,
many will significantly enable the program with the right engagement.

In smaller businesses or programs it is likely that some of the roles specified above will be
combined, e.g. Strategic Lead and Program Management, or Program and Project
Management etc. Again a key consideration here is to ensure that there is enough role
bandwidth and focus to deliver the quality required.

Sourcing from within teams and processes targeted for automation may provide some
interesting opportunities, but often we find that many of the people deployed within
14
© AssuringBusiness – all rights reserved
9

these teams currently have a different capability set that does not really lend itself to the
RPA roles needed. But every business is different and with a significant footprint of
Shared Services centers around the world, where talent is often highly educated, then
these may prove to be fruitful hunting grounds.

There are several potential resource pools to consider:

Internal. Harnessing the existing talent pool is a logical first step in most cases,
especially as there is likely to be a reduction in operational FTE. There may be
challenges with re-skilling but as many RPA aspects are essentially non-IT/technical
then there could be opportunities. However, you should really ask what type of
delivery structure you want as a business to provide the right balance of key skills
availability, flexibility, attrition management and quality; often these are best
delivered with a balanced resource plan combining internal and external resources,
especially to start.

BPO. Working with your existing BPO partners for RPA may be worth considering; either
as 100% delivery function (for your e2e needs), partially (working solely on the
processes they operate) or integrated to a business-led e2e or targeted process
program.

The approach will vary depending on the nature of the contract that you have with the
BPO. Where BPO is contracted to deliver guaranteed cost-savings, e.g. via set
FTE/volume pricing discounts each year, then it is clearly in the BPO interest to drive
economies with improvements such as RPA. Who pays will also depend on the nature of
the gain and business drivers.

Despite much of the BPO sector driving outcome based engagement models this past
couple of years, FTE/volume based models remain a significant current footprint and
even a high-proportion of new contracts seem to favor this old state. It’s a little
strange as outcome based solutions would tend to provide a better win-win scenario
rather than a ‘cheap option’ that can compromise quality. But more of that in future
papers!

Some contracts may also include a gain-share clause that enables both the BPO and the
client to benefit from performance gains above a defined threshold. Transparency of
the gain metrics is critical in such cases and a good Measurement, Reporting and
Insights (MRI) regime will ensure that these are present across all BPO, business and
process performance/outcome areas. Where they do not exist, then sampling and
reviews will have to form the initial basis with new metrics being added to the
operation to track continuously (rather than having to keep sampling).

Some good-practice advice for dealing with BPO in such matters include:

1. Ideally ensure that the RPA tools and deployment infrastructure are the same in
BPO as your own business (if your business has selected a standard). Should you
need to transfer operations later, transition is simplified. Bear in mind, however,
that different tools may suit different needs so there will be cases where having
more than one vendor in operation fits better.

2. Retain IP of the RPA configuration/scripts and related tools. IP retention will avoid
you being held hostage in future contract negotiations. If this does not already
exist in your contract, I highly recommend building in specific clauses. If there is a
reference clause but it is deemed ambiguous, work with your legal and
vendor/contract management teams to clarify interpretation with BPO in writing
that would form an adjunct to the contract, or could be incorporated into
revisions. Such an approach is necessary to avoid costly and lengthy disputes later.

3. Build and maintain a fully-transparent RPA pipeline that includes potential business
and BPO projects to manage priorities and overlaps. There’d be problems if BPO
had spent significant effort automating a key process within their scope only to
find that the business had also automated resulting in the to-BPO workflow ceasing
or being dramatically reduced.

4. Collaborate closely on BPO operated processes. They have the current hands-on
knowledge and these details are imperative to RPA design and success (remember
though, do not try to implement all the exceptions at first). Relying solely on
15
© AssuringBusiness – all rights reserved
0
1
retained team knowledge with their inherent
gaps in operational detail will result in a
negative impact on the RPA program.
5. Ensure that your RPA and/or BPO governance
teams have an approval point in any BPO
driven improvement initiatives. Again, this
should be contracted.
6. Steer away from utilization of BPO
proprietary tools as this will tend to make the
relationship a little too sticky. I’m a big fan
of using off-the-shelf tech to drive
performance gains and not have to bind
ourselves to service regimes with increased
cost of exit.
3rd Party Generalists. The larger
consulting/advisory and/or technology firms can
provide excellent resource pools. They have built
sizable practices around RPA that will continue to
evolve. There were some steep learning curves
early on, but the worst is behind us (I hope). And
we’ve all heard the narrative “you won’t get
sacked for hiring {stick the name of your favorite
big-co here}”. Certainly some truth to this, but
also beware that the need to maintain practice
growth does result in some clients becoming a
training ground, where you may well pay for the
training.
Methodologies will vary but ultimately the
individuals deployed in the program are the key
to success, not necessarily the firm (or
methodology) used. It’s imperative, therefore, to
ensure that you understand the resource mix and
quality being deployed and that you retain the
right of veto or change as appropriate, especially
in key positions.
One major potential downside is cost…the larger
firms tend to have high resource rates. However,
where low-cost CoE resources are available (e.g.
India or Eastern Europe) then you may find an
interesting and cost-effective overall resource
mix is feasible in larger programs. Build the
business case with a whole-cost model in mind
and you will see what stacks up.
3rd Party Specialists. There are now many
businesses and individuals providing expertise as
RPA specialists or as industry specialists with
strong RPA knowledge. From strategic advisory to
hands-on RPA configuration – it’s covered. Overall
I find these specialist providers can provide
excellent value for money and tend to be more
flexible in terms of engagement models and
commercials.
A particularly good use of specialist providers is
to put them ‘in-the-mix’ with ‘generalists’ or
your own RPA program resources to maintain a
balanced, independent perspective on strategy,
delivery and operations. Specialists will often act
as a great enabler and challenge point for you (or
your larger partner firms/BPO), ensuring that
© AssuringBusiness – all rights reserved
priorities are fairly assessed, plans are optimized
and implementations delivered with integrity and
quality.
Another good use of specialists is in driving an
RFP and/or supporting commercial negotiation
with larger delivery firms or technology
providers. Most have ‘been around the block’ and
will have direct exposure to other examples of
delivery approaches, commercial frameworks and
pricing that will bring solid, long-term benefit.
The nature of the delivery and resource model
should be considered very carefully. In larger
businesses it is unfortunate that politics will
typically be a major factor in play and considering
how to overcome these natural ‘environmental’
challenges will be time well spent. Excellence in
governance and communications, transparent
discovery and opportunity assessment models,
systemized delivery and honest declaration of
value/benefits tend to help dilute common
challenges.
The People Perspective
Businesses often struggle with the overall positioning
of an RPA program as they see this has the potential
to ignite conflict and concern within the workforce.
My advice: be proactive, transparent and timely.
Hiding such programs rarely has a positive impact.
People feel deceived. Even bad news, if delivered
with integrity and clarity, tends to be better
received than late or cloudy information. In fact,
there is much good news in a well-considered
automation program helping to sustain the business
(and therefore employment) for years to come.
However, you also need to recognize that the
message has to be shaped with meaning to be
useful; what is going to happen, when and to whom.
Not all of this information will be available when the
concept is agreed. A staged and open
communications plan is therefore a good idea.
Nobody can argue that the business should not
improve quality and productivity, reduce error rates
and complaints, enhance customer and stakeholder
experience, remove job drudgery and better manage
its costs. After all, the competition will be doing
this; better to stay in business with well-considered
automation than to become uncompetitive and risk
all. With an inclusive approach, many team
members will be supportive recognizing that there
will also be some opportunity for enhanced roles as
a result; new things to learn, new career paths to
explore. But of course, many will be concerned
about their positions. Businesses with strong talent
management and HR practices will already be able
to deal with such issues; potential re-deployment,
options for re-skilling, support for career change or
alternative employment positioning etc. Those
businesses that do not have robust people practices,
well, I suggest that you develop some!
16
2
3
Motivating in-process resources to support RPA is
often a challenge given the potential outcome. The
‘new opportunities’ option will typically only
motivate a few people, so you need to find other
mechanisms to drive support and avoid untimely
process crashes, customer experience impact or
poor RPA delivery. These mechanisms will rather
depend on the nature of the business and culture in
place (and whether a direct employee, contractor,
BPO or agency employee etc.), but might include:
Ensure managers and supervisors are
passionate and engaged; this will enhance
team motivation (or destroy it if they are
opposed).
Make RPA deployment interesting and
engaging for all. Communicate well.
Active talent development; including
resources in the e2e RPA delivery framework
for hands-on experience, maybe
supplemented by special training.
Cross-functional deployment/cross-skilling;
seek opportunities for talent to undertake
stints in other areas of the business where
they express interest.
Performance rewards; maintaining or
improving performance during a significant
change period deserves recognition.
Retention and exit bonuses; can be financial
or other reward but based on time served or
milestones reached.
Human and robotic workers
should not be seen as being in
conflict. Automation will
increase dramatically, so it’s
best to find the path to
coexistence. Planning for a
hybrid workforce is a must.
© AssuringBusiness – all rights reserved
Automation should be considered as a primary
workforce component alongside humans.
Recognizing the inevitable, it’s also important to
hire new people with the right attitude and
aptitude. They should be aware of the dynamic in
the business from the start of their engagement.
And taking on people that have an aptitude for such
things will increase the options for future
employment flexibility and their drive to help the
business succeed; people that join on this basis are
typically more enthused by such changes.
All HR, workforce and talent management strategies
should be in review right now. The increasing
prevalence of the digital worker will affect your
business in one way or another, so it’s best to be in
control of the policy and messaging that drives your
culture and business performance. Many aspects of
people policy and practice will be affected, and
continue to be affected as the socioeconomic and
governmental positions evolve accounting for
(dramatically) increased automation in business. You
must be ready to engage with your employees on
the topic proactively; after all, they are listening to
this subject almost every day via their many news
and social media channels, including examples of
other businesses going through similar change.
Standing still, even if you do not currently have a
defined automation strategy, is not a good idea for
HR functions. Get ahead. Get your people ahead.
Manage your own evolution to optimize the
outcomes; life will be better for all concerned with
a proactive approach.
The Future of RPA
RPA is here to stay. ‘Automation-first’ will likely
become the normal thinking for new-build processes
and business operations in all industries, saving costs
and impact on people being employed that could
later be affected by automation projects. Although
RPA is focused on business processes, these tools
will work hand-in-hand with some of the physical
robots we see being developed and deployed in
many aspects of our lives, including manufacturing,
logistics, retail, finance, leisure etc. The prospect of
a fully automated operation of some functions, and
maybe even whole businesses, with people making
strategic decisions and focusing on necessary
human-human interactions, is not all that far off.
AI and augmented technologies will certainly be a
major driver in how robotics generally, and
specifically RPA, evolves. With basic RPA tools likely
to retain a core systematic execution purpose,
sophisticated AI tools will continue to evolve to
human-like standards of learning, understanding,
interpretation and decision-making.
As an example, AI is driving enhanced ‘computer
vision’ where images or video can be interpreted,
not just identifying what objects are, but also their
status, e.g. degree of damage, and therefore what
to do with them, e.g. repair or write-off (and
applications even estimate the cost of repair).
17
4

Facial recognition systems have also evolved with ‘whole person’ recognition and tracking
solutions on the market that consider multiple attributes of a person to identify and/or
track them via CCTV, e.g. clothing items, gait, actions taken etc. Already these
applications are being used to detect street crime and instigate appropriate responses
(Police, ambulance etc.) including the tracking of perpetrators. Recently Samsung has
announced that their new automated assistant ‘Bixby’ will feature computer vision
capability, e.g. to identify an item of clothing and where you might buy it for the best
price.

These are all current applications. When considering the future of business processes, we
should clearly be considering the more advanced cognitive and intelligent robotic
potential that is rapidly evolving. Structured process automation utilizing basic RPA is
already established as a winning strategy, but when we consider the augmentation
potential within our business processes, and how that can help us further improve our
customer experience and profitability, then the future is very interesting indeed.

Of course, as AI takes a firmer grip of complex processes and engagement practices, we

shall see some human-like ‘adjustments’ required as they train and evolve within each
process, but that should be a relatively minor stepping stone to a level of consistency,
quality, speed and cost that simply cannot be met by a human workforce in many
operational areas.

Conclusion
Robotics will be a game changer in many aspects of our lives. RPA has set-in to radically
change the way we plan workforce and deliver business operations. The workplace is
changing. Permanently. Freeing humans to focus on what we do best – directing strategy,
engaging with other people (customers!) and building the systems to automate the rest–
makes a lot of sense in many cases. Our digital replacements bring a lot of benefits:

Consistent, zero-error execution.

Productivity; significant cycle time and volume management improvements.

Complete and accurate auditability.

Improved process risk; robots will not commit fraud or steal your information.

Full e2e automation opportunity across many functions, especially when

considering cognitive and intelligent solutions.

Flexibility and scalability; rapid up- and down-sizing of workforce facilitated.

Develop once, deploy many.

Significant FTE reduction feasible whilst simultaneously improving process

execution standards.

Significantly reduced workforce lifecycle costs; no cost of recruitment or

redundancy, and much lower ongoing costs per resource unit. No ongoing direct
employee government contributions (yet)!

No attrition challenges; RPA tools can be recycled.

RPA is not unionized; they will do exactly what is asked without challenge.

Reduced management overheads (including HR).

The delivery process should discover and drive other business improvements; a
very useful feed to a continuous improvement mechanism.

Resilience; back-up RPA tools may be kept in ready-state without license charge
(depending on vendor).

Improved IT dynamic and costs; enhanced legacy work-around options, core IT and
data management opportunities. Optimizing per-seat licenses of interacting
applications.

18
© AssuringBusiness – all rights reserved
5

Claims of up to 80% FTE

replacement and first-year
(even weeks or months)
payback are common in RPA
projects. Considering that RPA
will also improve quality,
customer and stakeholder
experience, and productivity, it
is being seen as a truly
disruptive and transformational
technology.

To some, RPA can also seem

too good to be true; something
to avoid until others prove the
way. It is true that unless you
learn and apply the lessons of
others in building your RPA
program, it will be challenging. But RPA is here to stay, and being proactive and positive
in driving change can deliver real value. Delaying the inevitable is merely reducing the
value that could be aggregating daily, helping to drive your business forward and better
compete in increasingly challenging markets.

Ask yourself this: whilst those around you move ahead with RPA, can you afford not to?

If the answer takes you closer to implementing RPA, then consider these key points:

Think strategically and leverage RPA in view of the bigger picture. Pay particular
attention to core system and process opportunities that bring about a cleaner and
more efficient business landscape longer-term.

‘Disposable RPA’ can help to bring short-term benefits and learning whilst
delivering core business change; residual (stickier) RPA deployments will later
enable longer ROI terms. The RPA delivery process will also enable discovery and
execution of the more fundamental changes needed – no need to wait until your
processes are optimized – you can use RPA to drive efficient parallel action.

Deploy an operational model that works for your needs: cost, quality and business
dynamic. Consider how best to use your internal and external resources available;
the model may evolve over time so it’s okay not to have the day-1 approach set in
stone.

Systemize the delivery framework and seek a balanced governance perspective.

With these critical pillars, you will be able to achieve low-cost and efficient RPA
implementations.

Harness the future; evolving cognitive and intelligent technologies will enable a
more complete opportunity reaching areas of business operations that basic RPA
cannot.

It simply remains for me to wish you all the best in designing and deploying your RPA
strategy. I hope that some of the insights shared here help you to achieve the results that
you desire.

“The best time to plant a tree was 20 years ago. The second best time is now”.
(Chinese proverb)

For information of RPA services offered by AssuringBusiness:

https://www.assuringbusiness.com/robotic-process-automation-rpa-services/

19
© AssuringBusiness – all rights reserved
 Partnering in
Profitability
Strategy | Design | Execution | Advisory

www.assuringbusiness.com
ask@assuringbusiness.com

© AssuringBusiness – all rights reserved