Robotic Process Automation RPA Strategy and Practice v1.3
Robotic Process Automation RPA Strategy and Practice v1.3
Robotic Process Automation RPA Strategy and Practice v1.3
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
Conclusion .................................................................................................... 18
2
© AssuringBusiness – all rights reserved
1
2
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.
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 enabling an early opportunity trajectory to be set
makes the biggest difference. We shall look at the and leveraged, whilst maintaining the need for, and
delivery and operational aspects later in this paper. momentum of, strategic system and process
improvements.
The Role of Artificial Intelligence
It’s tempting to consider RPA as a ‘silver bullet’ to
You should note that there are many AI variants and many challenges, but in fact RPA can cause more
a quick search of Wikipedia will enlighten here! AI problems if poorly conceived, planned or deployed.
plays a major part in the evolving RPA landscape, There are many examples of businesses trying RPA
with ‘deep learning’ being a new mantra for vastly then abandoning after a poor initial experience.
iterated machine learning, usually employing multi- Maintaining direction and drive towards strategic
layered neural networks or other AI protocols. In goals is an imperative whilst you deploy and operate
essence deep learning provides for better RPA to a well-considered priority structure.
interpretation and decisions and is currently being Communicating the original problem and
applied in particular to enhanced cognitive and performance indicators as a continuous reference
‘computer vision’ components. It takes us closer to point becomes essential to help ensure that the
the human experience in terms of understanding and strategic needs are not de-prioritised or forgotten
decision-making. One could argue that with greater altogether. Parallel activity is a must to drive robust
consistency and an ability to incorporate vastly more improvements with long-term sustainable benefits;
information in an AI-RPA decision process, outcomes core systems and process improvements in
would ultimately be significantly better than those particular.
of a human-managed process. And with speed and
cost considerations, the future of such technology is Disposable Robotics
certain to be deeply engrained in many aspects of
our lives. As AI evolves, the need to ‘partner’ with Tactical use of RPA whilst progressing strategic
basic RPA components (as is often the case to enact change is a great option to consider: ‘disposable
process, decision branches etc.) will likely lessen as robotics’. It’s a pragmatic approach to leverage
the decision making process will inevitably become short-term gains targeting process options with
‘more human’ and may in fact learn process from shorter Return on Investment (ROI) cycles whilst
training data and other inputs rather than defined continuing the strategic improvements to systems
‘hard coded’ business rules. We shall explore some and processes. Although some will argue that RPA
applications for this technology variant in later might be a distraction from the strategic
papers. improvement plan, in reality parallel RPA activity
has been found to provide insights that usefully feed
Business Goals, Challenges & the the strategic roadmap. Insights that would not
normally be visible without the deep-dive that is
Bigger Picture needed for RPA success.
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.
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.
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
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.
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.
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.
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 process and RPA knowledge via the automation
licenses is improved with the huge productivity thread. See also some further comments later in this
increases likely with RPA, which can have a paper regarding the Process Re-engineering Loop.
significant impact on business cases for system
procurement or expansion. But I suspect some Business ownership of an RPA program is a common
enterprise software providers will also be looking question; where should it sit? The most commonly
to counter this ‘opportunity’ any time soon. held view is that it is not owned by IT. Although
there is a need for application connectivity and
Learning the Lessons of Others technology infrastructure, the nub of RPA is process
centric. RPA does not require the same delivery
Vastly increased automation is inevitable for most framework or technical capability as other IT
businesses that ‘suit’ RPA. Right now basic robots projects. There are two main options to consider;
can readily take on board repetitive process embedded within the units or functions themselves,
activities; this is often where a major portion of FTE or centralized ownership in some form; see the
cost lies. However, tools further up the value-chain delivery model comments later in this paper.
will enable far more sophisticated deployments; However, it is important that there is CXO
examples in use include drafting/validating complex sponsorship for an RPA program and this might
cross-border legal contracts, automatically assessing typically sit in the COO or CEO camp. If there were a
damage to vehicles from photographs and CXO charged with innovation and change, then
quantifying insurance costs/claims, digesting perhaps this would be a good home. All CXO’s are
medical reports to assess and approve health likely to be affected in a wide-ranging program and
insurance claims, engaging with customers via chat will need to be aligned on the strategy; the key is to
to resolve queries and disputes etc. The list of ensure that it gets focus and momentum.
possibilities is very long even with today’s
technology; imagine what will be possible in the In any event, it’s important to start the RPA journey
next 5-10 years! as ‘right as can be’; there have been several
examples of failed RPA programs. From my
So my view is that there is significant benefit in discussions with those that suffered this fate it
creating an angle of trajectory sooner rather than appears that the majority did not have the
later for a well-considered RPA program: opportunity to learn from the lessons of others and
so fell into similar traps. Common issues to avoid
Assess & Plan include:
Pilot & Prove
Overly-complex, high-exception rates or
Learn & Apply change-prone processes targeted as a pilot
Systemize & Deliver or initial implementation
Taking the plunge will enable early learning and Unstructured or shallow process discovery
adaptation of practices towards a systematic and design leading to process gaps and
delivery mechanism, which is where the pot of gold multiple RPA configuration cycles
really lies. There will always be a reason to put it
off, there will never really be a perfect time, but Attempting to configure the entire process
that is merely delaying the inevitable and forgoing 100% rather than applying the 80/20
the benefit that could be aggregating every day. principle and automating the highly
repetitive tasks first, avoiding or eradicating
Some businesses will take a stance that they will exceptions (see tips later in this paper)
only consider RPA once their processes are
optimized, leading with Operational Excellence (or Ill-conceived technology infrastructure
similar) functions. A great position if it’s easy to do, leading to inflated costs or risks
but pragmatically this will suit few. Although it’s not
ideal to automate a poor process, and it may ‘feel’ Inappropriate stakeholder engagement
wrong, doing something quicker, more consistently and/or alignment; failure to bring security,
and with fewer resources may well be considered risk, compliance and audit functions on the
better for the business than the current (albeit non- journey; politics driving barriers to success
optimized) error prone and labor-intensive position.
Poorly defined roles, ownership and
Moreover, there is a great opportunity to drive accountability of program and delivery
process improvement in parallel with RPA and components; assumptions not validated;
optimize the process-centric talent that is necessary overlaps with BAU or activities in other
to succeed. RPA delivery necessitates a process functions causing conflict
deep-dive and improvement opportunity assessment
Over-zealous business case targets (usually
so driving process change whilst delivering RPA is a
stemming from points above); ignoring ‘soft
credible option. If you look at RPA as a vehicle
benefits’ which in fact can be a key business
towards process improvement (rather than the other
win.
way around), then the resources needed to drive
process change are better utilized harnessing both
10
© AssuringBusiness – all rights reserved
4
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:
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.
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.
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).
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.
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
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.
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.
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.
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 priorities are fairly assessed, plans are optimized
gaps in operational detail will result in a and implementations delivered with integrity and
negative impact on the RPA program. quality.
5. Ensure that your RPA and/or BPO governance Another good use of specialists is in driving an
teams have an approval point in any BPO RFP and/or supporting commercial negotiation
driven improvement initiatives. Again, this with larger delivery firms or technology
should be contracted. providers. Most have ‘been around the block’ and
will have direct exposure to other examples of
6. Steer away from utilization of BPO delivery approaches, commercial frameworks and
proprietary tools as this will tend to make the pricing that will bring solid, long-term benefit.
relationship a little too sticky. I’m a big fan
of using off-the-shelf tech to drive The nature of the delivery and resource model
performance gains and not have to bind should be considered very carefully. In larger
ourselves to service regimes with increased businesses it is unfortunate that politics will
cost of exit. typically be a major factor in play and considering
how to overcome these natural ‘environmental’
3rd Party Generalists. The larger challenges will be time well spent. Excellence in
consulting/advisory and/or technology firms can governance and communications, transparent
provide excellent resource pools. They have built discovery and opportunity assessment models,
sizable practices around RPA that will continue to systemized delivery and honest declaration of
evolve. There were some steep learning curves value/benefits tend to help dilute common
early on, but the worst is behind us (I hope). And challenges.
we’ve all heard the narrative “you won’t get
sacked for hiring {stick the name of your favorite The People Perspective
big-co here}”. Certainly some truth to this, but
also beware that the need to maintain practice Businesses often struggle with the overall positioning
growth does result in some clients becoming a of an RPA program as they see this has the potential
training ground, where you may well pay for the to ignite conflict and concern within the workforce.
training. My advice: be proactive, transparent and timely.
Methodologies will vary but ultimately the Hiding such programs rarely has a positive impact.
individuals deployed in the program are the key People feel deceived. Even bad news, if delivered
to success, not necessarily the firm (or with integrity and clarity, tends to be better
methodology) used. It’s imperative, therefore, to received than late or cloudy information. In fact,
ensure that you understand the resource mix and there is much good news in a well-considered
quality being deployed and that you retain the automation program helping to sustain the business
right of veto or change as appropriate, especially (and therefore employment) for years to come.
in key positions.
However, you also need to recognize that the
One major potential downside is cost…the larger message has to be shaped with meaning to be
firms tend to have high resource rates. However, useful; what is going to happen, when and to whom.
where low-cost CoE resources are available (e.g. Not all of this information will be available when the
India or Eastern Europe) then you may find an concept is agreed. A staged and open
interesting and cost-effective overall resource communications plan is therefore a good idea.
mix is feasible in larger programs. Build the
business case with a whole-cost model in mind Nobody can argue that the business should not
and you will see what stacks up. improve quality and productivity, reduce error rates
and complaints, enhance customer and stakeholder
3rd Party Specialists. There are now many experience, remove job drudgery and better manage
businesses and individuals providing expertise as its costs. After all, the competition will be doing
RPA specialists or as industry specialists with this; better to stay in business with well-considered
strong RPA knowledge. From strategic advisory to automation than to become uncompetitive and risk
hands-on RPA configuration – it’s covered. Overall all. With an inclusive approach, many team
I find these specialist providers can provide members will be supportive recognizing that there
excellent value for money and tend to be more will also be some opportunity for enhanced roles as
flexible in terms of engagement models and a result; new things to learn, new career paths to
commercials. explore. But of course, many will be concerned
about their positions. Businesses with strong talent
A particularly good use of specialist providers is management and HR practices will already be able
to put them ‘in-the-mix’ with ‘generalists’ or to deal with such issues; potential re-deployment,
your own RPA program resources to maintain a options for re-skilling, support for career change or
balanced, independent perspective on strategy, alternative employment positioning etc. Those
delivery and operations. Specialists will often act businesses that do not have robust people practices,
as a great enabler and challenge point for you (or well, I suggest that you develop some!
your larger partner firms/BPO), ensuring that
16
© AssuringBusiness – all rights reserved
2
3
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.
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:
Improved process risk; robots will not commit fraud or steal your information.
RPA is not unionized; they will do exactly what is asked without challenge.
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
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.
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)
19
© AssuringBusiness – all rights reserved
Partnering in
Profitability
Strategy | Design | Execution | Advisory
www.assuringbusiness.com
[email protected]