Free ebook on rpa

Introduction To Robotic Process Automation
Introduction
Robotic Process Automation
To
Get Started With RPA
ABHINAV SABHARWAL

2
Abhinav Sabharwal is an industry veteran with over 13 years of experience in various domains like HR, Supply chain,
CRM, Pharma & Healthcare, Fashion & Retail. He has implemented over 24 projects and is expert in various
methodologies like Waterfall, Agile & V Model of software development life cycle. He also speaks at conferences
at regular intervals and mentors youngsters in industry.
School Of RPA Was started in May 2017 when I left Capgemini to start RPA consultancy, however I was soon
Frustrated by the lack of information and standardization of practices on RPA based projects. Lots of clients were
using same old software development methodology to implement RPA projects.
This led to failure of RPA projects as these new age RPA projects were a misfit in existing IT landscape. To remedy
this situation I started doing my own research on methodology and best practices. Soon I discovered the correct
way to do RPA projects and realized that this knowledge needs to be shared with other likeminded people.
In the beginning training was provided to individual students over the web, using GoToMeeting like tools. Today
we have classroom training in Kharghar Navi Mumbai, you can find us at
I hope this book takes you on a wonderful journey into the world of RPA and clear the questions in your mind
that you have about the field of RPA, but if wish to learn specific tool like Blue Prism or Ui Path then please do
come at the above address and meet us and talk to us. I promise you that RPA is a technology of the future and
learning it will make your carrier recession proof, We’ll Let the journey Begin.
ABOUT THE AUTHOR

3
Table of Contents
Digital Transformation 4
Corporate Archeology 5
The Fourth Generation OF Work 6
The Impact OF RPA Today 7
What is robotic process automation (RPA)? 8
A Simplified Definition OF RPA 9
What Is Robotic Desktop Automation? 10
The Automation Spectrum 11
The RPA vendor landscape 12
Differences Between RPA And Other Tools 14
The Importance Of ROI 17
The seven benefit types 18
The Triple Win Model 20
Don’t forget the cost of ownership 22
Identifying Opportunities For Automation 23
Efficiency Drivers For Automation 25
Prime Opportunity Areas For Automation 27
Process Reengineering 29
Key Stakeholders In Your RPA Journey 30
Start Small But Don't Think Small 32
RPA Is Not About The Robot 33
Don’t Forget The Fundamentals 34
leveraging A Center Of Excellence 35
Tips For Success From The Front Lines 37

4
Robotic process automation—software-based robotics that emulate work that people do—is poised to
change the way we work. Using this exciting technology, organizations can digitize and transform an array of
business processes and functions. In this book we takes a deep dive into RPA, explaining what it is, what it's
not, and what to keep in mind when adopting it in your organization. Here, we shares information that can
help a variety of stakeholders—from executives to IT professionals—grasp the key benefits of RPA, as well as
best practices that can help their organization succeed at both the process and enterprise levels. We will
explore real-world context to the concepts covered in this book by providing examples from global companies
that are implementing RPA.
Digital Transformation
Let's get started by looking at how RPA can fit into
the digital transformation of your
organization. These days, it's pretty obvious that
the World is becoming increasingly digital, or
digitized. The largest and most well-known
companies today, like Google, Netflix, and Amazon
owe much of their success to fully capturing the
digital trend. In fact, new startups these days are
often digitally centered. On the consumer side of
things, think of ride-sharing apps like Uber and
Lyft, which have taken advantage of digital
platforms to disrupt the taxi industry.
If you like travel, you've most likely used
Airbnb. And are familiar with how their digital
platform has disrupted the traditional hotel
industries. These digital-native companies are
often racing against more traditional firms who are
now scrambling to launch digital transformation
efforts in order to keep pace. So, it's clear that aside
from being another buzz word, the digital concept
is absolutely a force that is moving markets and
transforming the services we use in significant
ways. Please note, there is a significant amount of
depth we can go into around the digital concept.
But, that's not the prime focus of this book, if you're
interested in exploring further levels of detail, you
should definitely check out the book titled: Digital
Transformation by Abhinav Sabharwal. So, how
does RPA fit into this story? Well, digital
transformation of businesses is happening
everywhere you look and happening at an
accelerating pace driven by a perfect storm of
increased customer expectations, more capable
technology platforms, and heightened competitive
dynamics. Like, global competition, wage
inflation, and new market entrance.
The challenge for many businesses in this
environment is that they are a natural product of
their history. If they've been around for more than
a few hours, chances are good their tangled in
legacy systems and processes that often
prevent them from being nimble and adaptable. As
a result, organizations across the World are
looking for ways to adapt and survive. RPA is one
way to accomplish this. In the last couple of years
many enterprises have begun to tinker with
RPA. And a few have matured beyond thinking
about and testing RPA, to implementing and
expanding use of it across their organization.
Whether your company has already put RPA to
work, or if this is the first time you're hearing the
term, this book will have valuable information for
you. Because there's no doubt that RPA will
become pervasive in the next three to five years as
automation and digitization take hold in the
business world. One of the most important things
you can do for your organization's future and for
your career is to learn the basics of RPA. And
beyond that, to firmly understand how to
succeed in this exciting, new world of work. But
before we get into the details, let's put RPA into

5
context in the bigger digital transformation
concept.
Corporate Archeology
As you'll recall, I described organizations as a
natural product of their history. What I mean
by that is, as organizations naturally grow,
expand, acquire and evolve, they inherit
complexity. They do this in order to support
the business as it grows, often by
implementing systems, software, processes,
and teams where necessary. What results is
often a spaghetti of systems and processes
that consume a great deal of time to maintain
and support. What comes to mind are,
immense enterprise applications that are often
pulling from even older mainframe
systems, are altered by modular Bolt-On
applications, enhanced by necessary
Homegrown plugins and patches, all to
support inefficient workflows that have
evolved organically over the years.
If any of that sounds familiar, rest assured,
you’re not alone. This is the scene I've
encountered countless times before. As I study
a company's current state, I can't help but
imagine an enterprise archeologist digging
down layer by layer, uncovering historical
artifacts and evidence of prior eras as they
go. Working with an organization can bare
similarities that actually are not so
absurd. Depending on the industry and
business function, it's not uncommon to come
across mainframes, green screens, fax
machines, COBOL, and a raft of Homegrown
Excel Macros, Access databases, and even
Post-it Notes documenting everything from
passwords to work procedures.
To deal with this excitement, enterprises
employ people. Passionate, hard-working
people who do what we call swivel chair
integration. Manually receiving and
transcribing faxes, executing wrote
transactional processes, and performing
repetitive tasks. But, the fact remains. These
tasks have to get done. It's just how businesses
run. And in the last two decades,
organizations have looked to solutions like
shared services and out-sourcing to handle this
work effectively and efficiently.
Now there's a new disruptive option available.
By using a class of automation technologies,
including RPA, the routine, mundane, and
transactional are all ripe candidates for digital
transformation. Enterprises realize there's a
huge opportunity to unleash value by
conducting this work a different way. In a way
sometimes referred to as the fourth generation
of work.

6
The Fourth Generation OF Work
There's a brief story I want to cover before we
get into the details of RPA. It's the story of how
technology has historically upended society
and work as we know it. As a quick note, this is
overall a good news story, but one that's
predicated on change. If you want to get right
into the meat of the course on RPA, feel free to
skip the next two chapters, but if you want
some cool stats and stories that make you fun
at cocktail parties, stick around personally find
this topic fascinating. So, what was work like
decades ago? Obviously, if you rewind 100
years, the workplace was quite a bit different
than it is today.
No computers, no fax machines, no Internet,
and no software running every element of an
organization. Fast-forward from 100 years ago
to 20 years ago, and you'll find computers, and
those fax machines we talked about, but only
just the beginnings of the Internet, email, and
Ethernet connecting everything everywhere.
Fast-forward to today, and you find enterprises
scrambling to adapt to and adopt cloud
hosting, software as a service, and the
connection of almost everything.
As you can imagine, this environment has been
a very challenging one to keep up with. In fact,
since the year 2000, 50% of the traditional
companies on the Fortune 500 have
disappeared.
Why? Many failed to stay relevant and
competitive in the digital economy, and were
phased out. You won't remain a successful
company if you can't scale and adapt. More
companies will likely cease to exist or face
increasing competition as we move deeper
into the era of digital disruption, or what the
World Economic Forum refers to as the Fourth
Industrial Revolution.
So, what are the four revolutions? The First
Industrial Revolution was marked by the use of
steam engines, which allowed for the
mechanization of textile and iron factories.
During that time, Europe saw a boom in
growth as people migrated away from a rural
lifestyle and moved to cities, where the jobs
were. The Second Revolution was powered by
electricity and supported by a boom in
manufacturing and production lines. This led to
the specialization of work, as tasks could be
split apart and optimized for costs. The Third
Industrial Revolution began around the 1980s,
and is known as the beginning of the
Information Age, in which we shifted from
analog technologies to digital ones.
That brings us to today. We are now entering
the so-called Fourth Industrial Revolution. This
stage of industrial change is predicated on a
new range of technologies that are driven by
interconnectivity, such as autonomous
production, artificial intelligence, analytics, and
the exciting world of Internet of Things. More
importantly, everything will produce data, and
data will mean everything
.

7
The Impact OF RPA Today
RPA is one of a number of technologies that's
central to this fourth industrial revolution. And
in the last five years, the concept of RPA has
become increasingly popular. RPA digitizes
manual tasks and transforms legacy
processes meaning that it will have a big role
in the transition to a digital era of
business. There have been numerous studies
about this. No matter
where you look, there’s
no doubt RPA will have a
significant impact on
today's enterprises and
the jobs within them. For
example, HFS Research
are reporting that the
RPA market will reach
$1.2 billion in scale by
2021.
While there's no
consensus on whether
RPA will increase or decrease job
numbers, there's certainly been quite a lot of
research on the topic. In one study by Forrester
Research, it's anticipated that over 500,000
jobs will be replaced or significantly
augmented by RPA in 2018 alone. McKinsey &
Company predict that automation
technologies like RPA will have an economic
impact of around $6.7 trillion by 2025. And a
widely cited study by Osborne and Frey from
Oxford University suggests that 47% of U.S.
jobs could be automated by 2030.
You'll find optimists and pessimists who
differing their job automation predictions. But
from my experience, I'm an optimist. Because
I've seen how businesses are using these
technologies to adapt and grow creating more
opportunities for their people to
contribute. I've also seen how jobs have
evolved and have been redesigned to take
advantage of what people are best at,
judgment, communication, customer care, and
critical thinking. Chances are good if you're
reading this book, you may work in a shared
services or outsourcing environment.
Having come from this industry myself, there's
no doubt RPA will have an impact on the
workforces around the world. Today, the size of
the global outsourcing industry is over $365
billion and it employs over five million
people. A significant portion of these jobs may
well be automated as businesses turn to tools
like RPA to improve efficiency and cut
costs. And make no mistake about it, this trend
is only just beginning. RPA will be a huge
disrupter in the next few years. As I said in the
beginning, change will happen and I think it'll
be good.

8
What is robotic process automation (RPA)?
And now let’s discuss, what you've all been
waiting for, what is RPA? Well, lucky for us, the
concept's been around long enough and some
very good definitions have been developed. I
myself have used several definitions but for this
course, I've chosen a more comprehensive one to
help illustrate several critical points. Here we
go! RPA is a configurable software tool that uses
business rules and sequences of actions to
automatically complete processes in any number
of different applications the same way a human
would, with the help of people for exception
management.
If you understood that, then you're set. But
there is a lot covered in that definition so
let's unpack it a bit and take a closer look at
some of the elements. I'll be focusing on the
bolded terms as they're the key to this
concept. First, configurable
software. Configurable software is out-of-
the-box software that comes with built-in
functionality and doesn't involve writing lines of
raw code. Think of Microsoft Excel. You don't
write a spreadsheet application every time you
need it, you just build macros and models using
the existing features that come out-of-the-box.
Second, business rules. Business rules are the
decision criteria or constraints that determine
how a process is to be executed. These are the
bread and butter of getting your complex
processes done right. For instance, in accounts
payable, if the product you ordered is
received, then the firm pays for it. The rules are
pretty simple. Third, sequences of actions. This
consists of a series of steps taken to complete
actions across multiple systems. RPA can handle
sequences of actions ranging from simple tasks
such as creating and updating reports to more
complex tasks such as managing work
absences or balancing taxes on erroneous
invoices.
This concept is fundamental to identifying the
right processes to automate. I'll cover this topic in
more detail in a later chapter. Fourth, automatic
means that the completion of tasks is done
independently. Once the rules are
programmed, the processes are just carried
out. Fifth, the definition references operating
across different software systems. I'm willing to
bet that your organization is running on
thousands of systems. In fact, this is the inside
joke almost every firm makes to me when I'm
supporting them.
That's a reality that's not changing anytime
soon. Teams interact with
and integrate across
these systems to get work
done. The key is that RPA
mostly operates on the
front end of
applications, similar to
the way that people use
them. Like I said, there are thousands of these but
for illustration, think of mainframe terminals or
SAP, Oracle, BlackLine, Internet Explorer,
Windows, and so on. Finally, exception
management.
As capable as RPA is, there will be times when a
person needs to step in. Exception management
is when employees are tasked with resolving
unforeseen events, or contributing their
judgment or discretion. Sometimes this is a full
intervention in which a person takes over a
transaction. Sometimes this is just a small request
for input, after which the automation continues
on its merry way. Okay, we've spent a lot of time
on this definition but it's time well spent. Now
let's revisit the whole definition one more
time and put all the pieces together.
RPA is a configurable software tool that uses
business rules and sequences of actions to
automatically complete processes in any number
RPA: A class of software that allows you to
transact in any IT application or website typically
in the same way a human would, to perform
complex Rule-based work.

9
of different applications the same way a human
would, with the help of people for exception
management. In summary, RPA is a versatile form
of software automation that allows businesses to
relieve teams from many of the repetitive, rule-
based actions, and processes that might
otherwise exist as pinpoints within the operation.
A Simplified Definition OF RPA
The definition presented in the last chapter was
comprehensive, but was also a bit technical. So
I'd like to introduce a real world analogy that
often helps me to explain RPA to enterprises
just getting started. Imagine you've just hired
someone new to your team. It’s your role to
train them on how to perform their new job. On
their first day, you might start by covering the
high level mission of the team. For instance, if
you run the payroll team, the mission is to pay
the staff, and to do so accurately and on
time. You might, then, move on to teach your
new team member which
systems are necessary to
perform their job.
Next, you'll teach them
how to log in to the
systems. Over time, you
teach them the rules and
actions they need to use to
complete more complex
transactions. Depending
on the process, you'll also
want to train them on
events that happen less
often. In this case, like
bonus payments or final
paychecks for anyone
leaving the company, or
other more esoteric
transactions. Eventually,
your new hire will have learned their job, and
will be fully self-sufficient. And hopefully they
remember how to do each process as you've
taught them.
But you know that, somehow, everyone starts
to deviate from the proper procedure, and
we've only discussed one team member. The
same set of skills and procedures has to be
taught to each new person who joins your
team. In comparison, RPA can be a much better
solution. The same rules and job
procedures can be configured into an
automated agent, or digital laborer, as some
are calling it. This new digital team member is
then able to perform a process faithfully and
accurately every time. And if you need to grow
the team to handle higher transaction
volumes, you simply replicate the
configuration, scaling up or down as needed.
Think of RPA like a
process flowchart or
something you
might see illustrated
in Visio.
Just like in work
procedures, you
have a start, actions,
decisions, and a
resolution.
All the potential
outcomes are
determined by the
programmed rules,
so they won't
deviate by
themselves.
So, a less technical definition of RPA is simply
this. It's a class of software that allows you to
transact in any IT application or
website typically in the same way a human
would, to perform complex rule-based work.

What Is Robotic Desktop Automation?
At this point, we've been pretty
comprehensive about defining RPA. But you
may have noticed, the type of automation
we’ve been discussing is described as capable
of taking over the tasks people have been
doing. What about assisting people, by
handling specific tasks in a larger process?
Well, this is also commonly referred to as RPA,
but there's an interesting twist. For software to
react quickly to a person calling it into action,
it most often needs to reside on the person's
desktop. So as a result, this form of automation
is becoming known as robotic desktop
automation, or RDA for short.
Our definition for RDA is as follows. RDA is
configured software that works in real time
with a human operator by presenting a
predefined set of information coming from
different systems to assist the operator with
the completion of operator-generated
workflows or tasks. If you refer back to your
notes, you'll notice the RDA definition shares
many similarities with the definition of RPA, but
there were a few key differences, so let's
double click on them.
First, RDA works in real-time with a human
operator. So as mentioned, this is a tool that
presents functionality to a person who is in the
act of performing their job. Second, the
definition says RDA delivers a result or service
to assist operator-generated workflows. This is
the key to this form of automation. A person is
an active participant in the initiation of an RDA
automation. A person uses their judgment and
passes work off to this form of automation, if
and when needed.
You'll remember from the RPA definition that
humans got involved there, too, but it was only
when exception management was
required. Humans are always involved in the
RDA scenario. An example of where you might
see RDA used is in a front office or call center
environment. We've all called to check on a
credit card balance or to book a flight with an
airline. RDA are at work making the agents we
speak to more efficient by handling rote tasks
at the command of the agent, so that they may
tend to us and our needs rather than be
bogged down with chasing up data or
conducting discrete tasks that automation can
handle instead.
So remember, when you hear people discuss
RPA, there is a good chance that they're
referring to both RPA and RDA. This distinction
is useful to keep in mind. Unless you're a
stickler for absolute nomenclature
accuracy, the RPA term gets the job done, but
it's worthwhile to know the difference

11
The Automation Spectrum
We've established that RPA, including RDA, is
software that automates rule-based tasks. To some,
that can sound a bit simplistic, so why is the entire
world of work getting so darn excited about
RPA? Well, let's stop and think a moment. If you've
had any exposure to business operations, like
human resources, finance and accounting, logistics
and supply chain,
for
example, you'll
know that much
of the work that
goes on in an
organization is
rule-based,
routine, and
defined by work
procedures. In
fact, you wouldn't
want it to be any other way.
People making up their jobs as they go would be
worrying. Many employees spend a good portion of
their day on procedural tasks, clicking boxes,
waiting for the next screen to load, completing
forms with tens to hundreds to thousands of minute
steps that are almost all rule-based. Some research
suggests that as much as 80% of a person's job can
be described as rule-based. This is exactly the sort
of work that RPA is fit to perform. Automation of all
types is perfect for those tasks that make you
basically feel like a robot.
Think of routine, monotonous, structured data
entry that requires no creative input. Believe me,
when we show teams the power RPA has to relieve
them of this drudgery, they're thrilled. But
remember, RPA is able to relieve people from
drudgery in two ways. As was highlighted in the
differences between RPA and RDA, this class of
automation can assist or take on tasks. You'll hear
this described in several ways. The assist scenario is
sometimes referred to as assisted automation.
You also may hear it called attended automation. In
this scenario, the automation augments
employees. It assists them in doing their jobs, and
does so upon user activation, almost like an
extension of their toolset, or like a digital assistant. A
person is able
to trigger a
robot as
needed to
automatically
perform the
discrete
task it was
programmed
for. For
example, a
customer
service agent might give a ticket ID to a robot which
validates the data and closes the ticket in the
database, saving them valuable time and allowing
them to focus on the customer interaction.
The second form of RPA, unassisted automation, is
completely autonomous, meaning that the robot
does not sit waiting for a person to activate
it. Instead, the robot can live on an internal server, or
it can be hosted in the cloud, operating all day if
need be, except during periods of maintenance and
update. An unassisted automation can be activated
by a person, but most often, they're scheduled from
a control room or triggered by a set of priorities set
by the business. In the end, one type is not better
than the other.
Choosing between assisted automation and
unassisted automation will depend on a variety of
factors, including the type of work, automation
goals, the amount of structured data, and the
scope. I'll leave the more detailed factors for
later. For now, simply understanding the distinction

12
I just outlined is enough to serve you when
educating stakeholders in your organization, and
for evaluating which RPA tools will best serve your
project needs.
The RPA vendor landscape
You'll remember that I mentioned at the
beginning of this course, this is not a technical
how-to. Part of the reason is, over time the RPA
vendor landscape has expanded and
evolved, and it would be impossible to pick
one, or even a few tools to highlight here. Plus,
there are tool-specific trainings and academies
for this. What I do wanna highlight, is the depth
and breadth of the dynamic RPA-software
industry. The RPA landscape has grown
considerably in the last few years, and there are
now over 20 tools that you may come
across, and many more popping up every year.
I find this both fascinating and encouraging.
The vendor market is a vibrant space, that's
sure to play a significant role in the future of
work for decades. Now, while I won't be
making any tool recommendations, there are a
few key leaders at the moment. I've provided
with comprehensive list in the exercise files. As
the Everest Group PEAK Matrix
highlights, you'll most likely consider
Automation Anywhere, Blue Prism, NICE,
Thoughtonomy, and UiPath. Similar research
by other analysts also places these firms as
leaders.
You may also consider other tools, including
Koufax, Kyron Systems, Pegasystems, and Soft
motive. Which software is right for you, and
your organization, however, isn't as easy as just
picking the top of the list. Each software has
different strengths. There are several
characteristics I use when helping enterprises
interpret the differences, and relevant features
of a particular tool. The first is software
architecture. As our definition stated, RPA is
preconfigured software. This means that the
way the tool is designed influences what sort
of tasks it will be well-suited to handle.
For example, some vendors, like NICE, for
instance, specializes in assisted automation, in
the sense that, their software is built for
simultaneous processing, and listening for
user-driven events. This would be ideal for
automating routine tasks, like those handled
by call-center employees. On the other hand, if
you end up needing a tool that autonomously
executes large-scale processes, you may
consider Blue Prism, or the Thoughtonomy
platform. And then, there are some tools that
can handle both assisted and unassisted
solutions, including Automation Anywhere,
and UiPath.
I also wouldn't be surprised to see other tools
evolve this dual-state capability in the near
future. Software architecture also determines
how well RPA tools will integrate with certain
applications. For example, UiPath uses the .NET
framework, which makes configuration
easier for more experienced developers.
Thoughtonomy has a modular design, that
easily incorporates cognitive tools with RPA.
And most leading RPA tools now give
credence to an ecosystem approach,
supplementing their capabilities through close
partnerships with firms able to handle
character recognition, workflow management,
machine learning, and more.
As with any software tool that's used
frequently, you want an RPA tool that provides
a good user experience. RPA interfaces vary
quite a bit, despite their functional
similarities. Take Blue Prism, for instance. Its
development interface is based on workflow
diagrams, similar to those you might see in
business-process management tools, making it
straightforward for non-programmers. Then
there's Automation Anywhere's interface.

13
Their workflow studio resembles a list, where
the steps are sequentially ordered.
UiPath's interface works a bit differently. Its
development involves a three-layer design, in
which the bottom layer contains specific action
items, the middle incorporates sequences of
actions, and business rules, and the top layer
controls the process flow from start to
end. Notice, I don't suggest that one is better
than another. They just happen to be
different, and it will be up to you, perhaps with
help, to identify the right tool for your firm. You
will also want to consider the
available configuration features that come with
an RPA tool.
While most tools use design-based
configuration, some also come with a recorder
feature that copies the user's steps to simplify
configuration. Other features to consider are
version control, collaborative tools, debugging
assistance, and credential vaults. As you learn
more about the nuances of RPA tools, you'll
come across even more considerations. For
instance, aside from the factors I just
described, subtleties in security, exception
handling, and license structure, are important
topics that you'll want to have on your list.
One note of caution. It is easy to get caught up
in the numerous features found in each RPA
tool. I urge you to take a different
approach. I've seen this tool fascination lead
too many firms down the wrong path. I'll cover
this more in a later chapter, but for now, just
know that I think you shouldn't start your RPA
journey by selecting the tool. Instead, start with
a plan. Focus on the problem you're trying to
solve, or the digital operations vision set for
your organization, and let this vision inform
your tool selection.

Differences Between RPA And Other Tools
Let's wrap this chapter up quickly by
addressing some of the most commonly asked
questions I've seen in the market because I'm
pretty certain you're either thinking them or
you'll soon be asked them. The first is, isn't RPA
the same as screen scraping or just macros on
steroids? The second is, how is RPA
different from business process management
tools? And finally, one I'm certain you'll
encounter, how is RPA different from artificial
intelligence? The macros on steroids
description has been around for a while and
even though it sounds negative, I think it's
actually somewhat helpful.
First, because people understand what a macro
is. When presented with a task they need to
repeat over and over again in an application
like Microsoft Excel, they build a macro to
emulate the actions they've been taking with
their keyboard or mouse. So to that extent, RPA
bears a resemblance to macros, but they can
do a heck of a lot more, hence the on
steroids. RPA is able to control a massive
catalog of applications and integrate between
them. And most RPA tools have out-of-the-box
capabilities to handle complex logic,
calculations, and sophisticated workflows.
So yes, to some degree, RPA is like macros on
steroids, but if capability, control, and security
are important, I'd choose RPA every time. As
for screen scraping, hopefully it's clear that the
sophistication I had just described also
highlights that RPA can do quite a bit more
than simple scraping of data from screens.

15
Next, we have business process management
tools. BPM isn't a specific software tool, but
more of an approach to streamlining business
processes to create efficiency and value.
It's a deep look at how processes are
operating, highlighting areas for improvement
and building solutions usually from the ground
up. RPA, on the other hand, is designed to
operate processes as a human would so it
exists in more of a surface level. As we've
already covered, it's often faster to
implement, works with almost any software,
and is easily adapted to the changing
application environment. RPA and BPM are not
necessarily in conflict with one another.
Instead, they share the same goal, just with
different implementation strategies.
Finally, artificial intelligence. This is a huge
topic. For the sake of this course, I'll try to be
concise. AI is an umbrella term. It's used to
describe a spectrum of capabilities that
includes machine learning, natural language
processing, complex pattern recognition,
hypothesis generation, and the iteration of
algorithms as they learn from more data. Think
of the Netflix Show Recommendation
Algorithm for example which learns from your
browsing habits over time.
You may also hear the term cognitive in your
research. It's a subset of AI and the term has
been applied to tools we've long known as IVR,
Voice Recognition, and OCR, Character
Recognition. It's these cognitive tools you'll
most often encounter especially as
supplements to the RPA capabilities you'll get
out of the box from most leading vendors. PA
is not typically labeled as cognitive or AI
because the underlying technology is
different. With RPA, a developer creates a rule-
based process that the robot fully conforms to
and follows.
You saw examples of this in the previous
chapter. The rules won't be adjusted unless a
developer reprograms them. This means that
everything RPA does from beginning to end is
completely dependent on how it was
configured. So RPA by itself cannot be
considered intelligent. And while it prompts
some to call RPA robots dumb, I can't disagree
more. They're just well-behaved and it's their
consistency that makes them so incredibly
valuable. Plus, the well-behaved RPA is only
just the beginning.
As you get more advanced, you'll find you can
combine RPA with specialized cognitive tools
to achieve intelligent digital labor. For example,
RPA lays a foundation for other tools down the
road such as machine learning by creating
copious amounts of transactional data to feed
the machine learning algorithms. Having the
proper outlook can allow you to proactively
accommodate these technologies when
they're enterprise ready, fit to be part of your
future of work toolkit.
So remember, RPA is not macros on steroids,
it’s like it but much more capable. It's a
complement, but not a replacement to BPM.
And RPA is not the same as AI, but it will serve
as an invaluable precursor to applying
cognitive tools to your organization. I'm often
telling enterprises that to build your cognitive
castle, you must first lay a digital foundation.
PA is that digital foundation on which you can
employ more advanced technologies when the
time is right and if the solution requires.

16

17
The Importance Of ROI
Now that we've gotten a good handle on the
definition of RPA, let's dive into what makes it
so exciting for businesses today. To put it
simply, the return on investment, or ROI, for
automation projects has the potential to be
significant. While I've seen a lot of hyped and
inflated expectations, and frankly, some crazy
ROI claims, the fact still remains. Handling tasks
using digital labor can make a lot of sense, and
save a lot of dollars and cents. What's more,
chances are very good that your executive
leadership is already aware of this.
Recently, I've been fascinated by what I'm
calling the top-down mandate. This is a
situation where CEOs, CFOs, or others from the
C-suite are beginning to set automation
goals for the organization. Big, bold goals that
effectively say, "We must save X, "and we will
achieve this thanks to process automation. “For
example, in May of 2017, Wells Fargo, the huge
US bank, publicly announced a goal to reduce
annual expenses by $2 billion by the end of
2019.
In the analyst day presentation, the CEO stated
that this savings would partially be as a direct
result of using, quote-unquote, digital
technology to automate manual processes. In
similar fashion, the CEO of the large European
bank Deutsche Bank stated a mandate to bring
down their cost of revenue ratio from 86%
down to 65% by 2020, in part by cutting 15,000
jobs through, you guessed it, automation.
The list goes on. CEOs of Nordea Bank, Lloyds
Banking Group, Zurich Insurance Group, and
numerous others have declared bold cost
savings mandates for their organizations that
are predicated on automation. It's no wonder
RPA is a popular topic, and if you think this sort
of strategy is relegated to banking and
financial services, think again. Healthcare,
manufacturing, logistics, entertainment, pick
any industry. A CEO is likely declaring
automation-oriented mandates in it so they
can survive under increasing operational
pressures.
So, if you find yourself the recipient of such a
top-down mandate, the first thing you'll need
is a plan backed up by a solid business case. As
you saw from the examples I just cited, the
business case will often be heavily oriented to
headcount reduction, because tallying
headcount is a quick way to get to solid
estimates of benefits, or what we call cashable
benefits. However, I mentioned, I'm an optimist
about the impact of automation on jobs. It's
because I actually rarely see headcount
removal as a result of RPA.
Instead, forward-thinking businesses are
considering how best to reallocate and
repurpose their qualified staff to perform
higher value-adding tasks. You may hear this
referred to as hours back to the business. The
actual benefit equation is far more interesting,
as there are many more nuanced ways that RPA
adds value. You'll want to know the numerous
types of benefits you should look for if you
plan to make a case for RPA.

The seven benefit types
So, we've touched on the major cashable
benefit quantified in the hours a business can
save through automation, but I also mentioned
that there's a far richer list of benefit types that
must be considered. Everyone has their own
breakdown here. I'll run you through the one
I've most often used. One of the most
straightforward benefits is an increase in
speed. With RPA, process turnaround times are
often significantly reduced because tasks can
be completed much more efficiently when
digitized. The impacts vary widely depending
on process complexity, but I've seen processes
that once took two weeks be completed in less
than two hours thanks to RPA.
The
next
benefit is better compliance. Since RPA acts
according to programmed rules and
conditions, it can faithfully complete tasks that
meet regulatory standards and protocols.
Remember, RPA is not dumb. It's just well-
behaved. For example, internal audits and
quality checks can be greatly simplified
because RPA can have built-in compliance
measures. What's more, I've seen audit times
shrink drastically because organizations can
quickly and easily prove compliance.
On the customer side, RPA can help improve
overall quality of service. There is certainly no
harm in reducing the number of service errors
thanks to efficient automation. Unless of
course you're a customer who enjoys battling
companies over incorrect billing statements.
Another key benefit is operational agility. If an
organization needs to adapt to new process
rules, the reduced overhead of automated
processes makes it much easier to adjust and
scale compared to traditional hiring and
retraining. And for industries that have high
cyclicality, think Christmas for retail or open
enrollment for healthcare.
The ability to rapidly scale a digital labor force
rather than hire temporary workers can save
literally millions. This agility also extends to
times of uncertainty. For instance, I saw a bank
avoid tremendous operating costs when major
flooding put demands on their home lending
team that would have been solved with
people if they had not already had RPA at

19
work. Importantly, RPA provides better insight
into automated processes. For every action
completed, there will be an audit trail of
important time stamped data that can be used
for interrogation and improvement.
RPA literally gushes forth valuable information
that can be modeled, mined, and interpreted
for insights into customer behavior,
operational performance and much, much
more. And finally, one area I find truly exciting
is the impact RPA can have on experience and
the experience of a wide cast of characters.
Whether you're a customer, an employee, a
patient, a citizen, a vendor, or a partner, it's
clear that service that is better, faster, more
accurate and more painless is cause for
celebration.
No matter the recipient of the service
automated, quality of user experience is greatly
impacted by RPA. I've seen this materialize as
higher net promoter scores, lower customer
churn, lower employee attrition and more. Like
I said, the experience benefit is truly
exciting. So note, while some of the
benefits may have very clear cost savings or
cashable benefits, others are softer or what we
call non-cashable benefits. Interestingly, while
the cashable benefits are often the ones that
feature heavily in a business plan, it's often the
non-cashable benefits that have the greater
impact in the long run.
When building your own business cases, it's
important you keep in mind and consider both
cashable and non-cashable benefits. Also, I
urge you to consider other potential areas of
benefit like cost avoidance for instance. You'd
be amazed at how much savings I have
discovered in this often overlooked
category. This can include reduction in fees
paid by an airline, avoidance of penalties levied
on a bank, reduced audit costs, reduced legal
fees, reduced over payments and more. Now
that we've covered the various benefits, next
we can look at the recipients of the benefits or
the benefactors.

20
The Triple Win Model
The benefactors of any RPA program are those
groups who receive the value. One way to
represent this to your organization is through
the Triple-Win Model, this model is discussed
in a book written by professors Mary Lacity and
Leslie Willcocks. Prominent authors in the
research of process automation. In this model
the benefits of RPA are divided into three
separate benefactor categories, benefits for
the organization. Benefits for employees, and
benefits for customers. On an organizational
level, many RPA initiatives aim for baseline
improvements in accuracy, process speed and
output quality as we discussed before.
But further there are often other
benefits that process
transformation and automation
unlock creating shareholder
value. For example, the rules-
based nature of RPA can be
leveraged to maximize
compliance or for operational
agility in the face of surging
demand. Automated processes
can be performed around the
clock and can be scaled against a large and
flexible workforce. All are good things to tell
investors, shareholders and executive
leadership, so keep this in mind when building
your business case.
The impact of RPA also translates to benefits
for employees who might have had mundane
or repetitive tasks simplified. For example,
employees who find the most time consuming
and frustrating portions of their work
automated will have more time to dedicate to
high-value work like customer interaction,
higher quality work can ultimately result in
benefits like higher employee satisfaction and
lower employee attrition. For those concerned
about the impact of RPA on jobs, take note,
Lacity and Willcocks found that employees
whose jobs were affected by RPA were happy
to transition to more interesting work and learn
new skills and I've personally seen this in
projects where, by automating mundane tasks
we've reduced employee attrition rates quite
simply, people like their jobs more so they quit
less.
And then there's the factor of extra time, I like
to call it the extra hour scenario if you were to
ask a team what would you do with an extra
hour in your day? I guarantee you no one
would ever say ehh, nothing we're good. We
don't need the extra hour you can have it
back. What they actually say is
goodness! If we had an extra hour
we could finally do those proactive
calls we wanted to do! Or we could
improve the quality of our data or
work on that customer experience
initiative we keep talking
about! The list goes on, and so with
RPA enterprises are creating and
unleashing that extra hour.
With routine tasks out of the
way there are so many more critical and value
adding nice to haves that they can attend
to. You may be asking how big can the benefits
be? While I tend to shy away from rules of
thumb and ranges, they're often too specific to
particular companies, industries or process
scopes I can say this, it's not uncommon to
see in-year savings from RPA projects. I've seen
firms achieve anywhere from 300% to 1,200%
ROI in three years, all because, as we've
discussed the significant cost reduction and
value creation of process automation creates
both cashable and non-cashable savings that
continue to create value long after a project is
complete.

21
So ask yourself, if you could have say, 30%
more capacity in your team, could you be more
productive? Could you focus on growing
sales? Emphasize customer
experience? Improve regulatory compliance, or
recalibrate to work on getting better insight
from the operations and data that you're
collecting? In order to transform your
business. I'm going to chance a guess here that
the answer is yes, yes, yes, and yes and don't
forget the customers.
One of the main goals of RPA should be to
translate the advantages of automation and
digitization to the improvement of a customer
journey. As we've discussed faster turnaround
times, improved quality, around the clock
availability and improved consistency will be a
cornerstone of your defensive strategy to
compete in an ever-digitizing world.

22
Don’t forget the cost of ownership
We've now covered the potential benefits and
values of RPA in some detail. Use these
parameters in developing your own business
cases. They'll serve you well. But before we
move on from the discussion of benefits and
benefit calculations, I wanted to touch on the
other side of the business case equation, the
costs of an RPA program. Each organization
will have its own business planning approach
and metrics. So this is meant to be more
directional than prescriptive. But no matter
your process, you'll want to remember a few
important, broad categories. The first is the
technology involved.
You will be purchasing RPA software licenses
that can have terms of up to three years, in
which you pay for the software license each
year. But there are many variations on this
theme. Some vendors have platform fees.
Others have different fees for their different
robots, attended and unattended. And if that's
not enough, the space is rapidly evolving.
Expect to see many as is service and utility-
based pricing models in the near future. Now
that you have the software accounted for,
you’ll also need to be sure that you have the
right hardware and IT infrastructure for the tool
that you're using.
Each tool vendor can help suggest the best
infrastructure for their tool. And finally, don't
forget to account for the time from the
business partners, IT partners, and perhaps
service providers to help set up your
technology environment. The second area to
include is the operational labor to run your
program. You'll need to decide if you're going
to fully dedicate resources to implement your
automation, or will this be quote, unquote,
other duties as assigned, for someone in the IT
or operations group? You may decide to have
business analysts, continuous improvement
professionals, or project managers as part of
the team.Using a partner to help you set up
your RPA program or run for you, is also
something to consider. More on that
later. Third, an area too often overlooked is the
ongoing costs. Without a good grasp of these,
you won't be able to calculate the total cost of
ownership of RPA in your organization. Your
digital workforce needs ongoing monitoring,
maintaining, and retraining when processes
change, and they do change. This is not set it
and forget it technology. You'll need to know
how you're going to care for your new digital
labor.
And the rules of thumb on exactly how many
people you need to do that are not exact. They
often don't consider how to include the costs
of process upkeep, how many bots you have
running, or what times of day your robots
run. For that reason, I don't subscribe to rules
of thumb here. You'll need to figure this out
over time or with help from an expert. Finally,
there are other things to consider, as well. If
you choose to deploy your own RPA, you need
to factor in the cost of basic, advanced, and
applied tool training for your team. You'll also
want to approximate job redesign and
reskilling costs, if you plan to reassign those
who have seen their work automated.
And you'll want to think about having a budget
for a formal communication plan as you roll
out your RPA program. Communication is yet
another area that is often forgotten. But rest
assured, we'll cover that in a moment. We've
explored a lot of material in this chapter,
including benefit types, benefactors, and cost
categories you should consider in your
business case. We'll make these available to
you as a handout in the exercise files. So now
that you've considered all of the parameters
you need to calculate the ROI of your RPA
initiative, the next step is a crucial one.
Picking the right processes to automate.

Identifying Opportunities For Automation
Now that you have a good grasp of RPA as a
technology and the benefits it affords, we can
introduce some RPA implementation concepts
starting at the process level, after that we'll
move on to some of the enterprise level
concepts. Both are equally important.
Identifying good candidates for automation is
one of the first steps in your journey and
frankly one of the most important.
In my experience
once you look at the
organization
through an RPA lens
you'll find an
abundance of
potential
opportunity which is
exciting but also
daunting. At this
stage of your
journey, you need a
framework to
measure how good a
particular process is
for automation and
how much impact
the automation
might have on the
business, take note of what I just said.
Just because a process may be a spectacular
candidate for automation doesn't necessarily
mean that it's worth automating. Given the
chapters you've learned in this course it now
becomes your responsibility to rank candidate
processes with this in mind. So what makes for
a good candidate process? I like to imagine
sliders to visualize the degree to which certain
factors contribute to process candidacy. Far
right means you have a good process. Far left
not so much.
Let's take the nature of work for example, a
process where employees follow a strict set of
rules is more automatable than one that has
decisions open to employee discretion and
judgment. As I mentioned before RPA is great
for automating the routine and rule based
where you have employees doing swivel chair
integration to execute those rules. On the other
hand where decisions have to be made in the
approval of a loan or the treatment of a
particular exception to a rule for instance you’ll
still need people to perform these tasks.
Now one quick aside, from my experience
teams often feel that the work that they do is
special and too complicated to modeled or
boiled down to simple rules. While the work
they do may be important my experience
suggests that once a task is atomized into its
smallest constituent parts you'll find that much
of the work in an organization can be classified
as highly rule based and therefore highly
automatable. The next slider is inputs and
outputs involved in a process.

24
Processes that use structured standardized
inputs are better candidates than processes
that use unstructured inputs. Structured inputs
are things like formatted spreadsheets
databases, JSON files, CSV files, XML and other
electronic feeds. Because of their digital and
structured nature they're a better fit for RPA
than unstructured formats like scanned
documents, faxes, handwritten forms or
emails. In terms of integration options consider
user interface as the lightest form of
integration if you will and APIs as the deepest.
Processes in which people navigate and control
applications to perform a task are the sweet
spot for RPA. Which simply emulates the set of
activities. RPA can work with APIs but it's less
common, API integration is often a bit more
complex than working directly with the user
interface but it largely depends on the
application. We often say if you have an API,
use it. There may be no need to copy its
functionality using RPA. Although that decision
should be made in a case by case basis.
As a site note, the fact that RPA uses the
interface is a big deal, it means the underlying
applications can be maintained and preserved.
Effectively, you're not messing with enterprise
systems this should be a huge selling point to
your IT team. Lastly, the type of data in a
process should be considered RPA works best
with text and numbers since it can guarantee
accuracy when programmed correctly. Image
interpretation is possible in rare cases but it's
usually not an ideal use case.
You might encounter images when a process
calls for signature verification for instance. Or
the interpretation of a scanned PDF. RPA is not
the tool you'd use here, instead you'd
supplement the solution with some form of
cognitive image recognition capability. These
factors determine how well suited a process is
for RPA, and you'll want the sliders to become
second nature as you scan your organization.
For that reason we've made the sliders
available to you in the exercise files, but you're
not done yet! Next you'll want to think about
the aspects of the process that influence the
degree to which a project might deliver
benefits.

25
Efficiency Drivers For Automation
Let's explore what makes for a highly impactful
automated process. First, stability, some
processors depend on applications and
systems that are constantly updating, or
changing, or frankly, just aren't that stable. This
requires the automation solution to be
continually updated and maintained. As a
result, it is often more efficient to automate
processes that change in minor, or predictable
ways. Second is connectivity. You should
consider the type of connectivity involved,
whether the applications being controlled are
remote or on premise, can affect what RPA
features are applicable.
And does your organization use virtualization
methods like Citrix? Tools like Citrix are good
at securing applications when used by
someone outside of your organization, but
they present the applications as a flat image
making it harder to automate the controls in
the application. But note, it's not impossible.
Some RPA tools are quite capable of handling
Citrix. This was a necessary feature when I got
started with RPA since so many of the systems
being automated in the outsourcing industry
sat behind Citrix.
Next is speed. I'm absolutely certain you've had
a customer experience situation in which the
agent says, I'm sorry, the computer is slow
today. Well, sadly, the computer is slow every
day. An RPA uses the system in the same way
the person does so system latency will slow
down your digital labor just as it slows down
your teams today. So plan ahead for this and
manage expectations as it relates to underlying
constraints that are not related to the RPA
solution.
And you'll want to take note of this. I guarantee
you, as you work through debugging and
testing your automations, you’ll need to tweak
wait times and slow down certain steps the
robot takes in order to account for slow
underlying systems. Finally, complexity, as I
mentioned earlier, no matter how complex a
team feels its work is, chances are good, the
work can be defined in rules. So complexity is
not a bad thing. In fact, as you progress, you'll
want to find highly complex processes because
these are where the untapped value lies.

26
I've seen automations that incorporate
thousands of business rules and thousands of
exceptions. The configuration work took many
months but the ROI was significant and more
than justified the project. Basically, RPA eats
complexity for breakfast as long as it's rule-
based. Now remember, all of the factors I've
just described are by no means binary. We use
sliders for a reason. Real-world processes can't
all be perfect for RPA. But if you do your
homework, you can certainly find ones that will
net greater benefits than others.

27
Prime Opportunity Areas For Automation
Now that you know the key drivers of
automation potential, you might ask yourself,
“Are there functional areas I should focus on”
“where RPA will make the most impact?" and,
"Do opportunities for automation vary by
industry?" These are great
questions which I help
enterprises answer all the
time, but not knowing
which function or industry
you're from, I'll provide
more general answers that
you can use as a launching
point. First, what sort of
functional areas are best
suited for RPA? If you've
been paying attention, you
probably already know, but
the short answer is, that
RPA can be applied to pretty much any
transactional process.
Some examples of where I've seen RPA
implemented are, customer service, human
resources, procurement, finance and
accounting, data management, and internal
auditing. In each of these areas there are
repetitive and transactional tasks that are
prime opportunities for RPA. To expand on
that, the functional areas in which I've seen the
most RPA opportunities are, human resources,
finance and accounting, and procurement. To
start, HR and payroll processes are prime
candidates for RPA.
In fact, the entire hire to retire spectrum is ripe
with opportunity. This is because HR tends to
require information management and
standardization across a large variety of
systems and applications. Think of a talent
acquisition process, for example, which might
involve several applications itself, ranging from
personnel databases and file managers to
salary and compensation analysis tools. Payroll
and pay integration are also great candidates
for automation.
They're often full of rote calculations on legacy
systems like mainframes. There are also vast
opportunities in finance and
accounting where the
processes are also rule based,
requiring high degrees of
accuracy and speed, which RPA
is designed for. Some common
F and A areas are order
management, billing,
regulatory
compliance, accounting, and
reconciliation. Finally,
procurement is a prime
area thanks to the abundance
of structured documents and
data.
Think of work like invoice processing, spend
data management, purchase order
management, and contract management,
which often involve communicating and
validating data across different databases and
ordering systems. I'll stop there, but I hope you
get the point. If you understand RPA well, you’ll
see opportunities everywhere. On to the
second topic of this chapter. How do
opportunities vary by industry? As I described
earlier, all companies today are part
technology companies in the sense that they
rely on technology to compete and survive.
This means that opportunities for RPA are
abundant. To give an example, I've seen RPA
campaigns flourish in the banking and financial
services industries, where a bulk of
transactional back office processes are ripe for
automation. Some of the largest banks in the
world are using RPA to automate account
opening and closure, reconciliations and report
generation. I've also seen RPA pay dividends

28
and regulatory compliance, where automation
solutions help them meet deadlines and avoid
fines.
And in anti-money laundering and know your
customer checks to validate customer data.
The healthcare industry is also a large adopter
of RPA. Many of the largest hospital systems
are using automation to simply information
management and payment cycles, which
translates well to the overall patient
experience. For example, there are many use
cases of RPA around care delivery support,
such as the automation of patient reports and
information management for clinicians. If
you've worked in the back office of a
healthcare organization, you know there's tons
of different applications and databases that
need to be crosschecked and referenced when
working with patient data and this is to say
nothing of revenue cycle management,
insurance claim processing, and account
reconciliation.
All are ripe for RPA. In addition to healthcare
and finance, I've seen RPA add significant
value in supply chain verticals, travel
companies, logistics firms, entertainment
studios, police forces, and many, many more.
Again, not knowing the industry and functional
area you're from, I hope I shared enough
examples to inform you and inspire you to go
hunting for opportunities in your own
organization.

29
Process Reengineering
And now it's time to share a secret with you.
You're not taking this course to learn how to
deploy robots. You're taking this course to
learn how to redesign your organization. When
enterprises go full-robot crazy, it creates
myopic thinking and tunnel vision as everyone
scurries about trying to figure out where they
can plug in bots. Instead, use this as a chance
to redesign process, to take advantage of the
full capabilities of your team, and of your new
digital labor. Now remember when I said that
an RPA lens would reveal an abundance of
potential opportunity? Be prepared for this.
Some of the potential candidates you'll
unearth may at first seem like great
candidates, but will end up failing some of our
slider tests. Others will truly be great
candidates. And then you'll have a third
category in the middle, or potentially great
candidates. These will be processes that could
be good but need some work first. For
example, I work for the financial services firm
where we identified a secured lending
processes an ideal target.
There was a large volume of thousands of
requests per week worked on by a large back-
office team. Many of the requests were
received through digital means, which meant
that the data was relatively structured. Closing
the requests was a rule-based procedure that
could be implemented with RPA software. On
the face of it, this was a great candidate.
However, this only addressed the structured
input, which was a subset of the incoming
requests that included telephone calls, faxes,
and snail mail.
Rather than dismiss the as-is process as not a
good end-to-end candidate because of the
unstructured inputs, we approached this a
different way. In order to structure a larger
percentage of the input, there was the
opportunity to build and deploy a web-based
portal to capture different case formats and
convert them into structured digital data. This
approach significantly improved customer
experience, speeding up the turnaround time
for requests from two days to 30 minutes. This
example demonstrates how businesses
benefit from reimagining the overall process,
rather than simply automated that which they
could.
To sum it up, don't just use RPA to speed up
your mess for less. Take it as an opportunity to
rethink processes from the top down.

30
Key Stakeholders In Your RPA Journey
The key to success in any venture is getting the
right people aligned and on board. It's the
same with RPA programs. In fact in my
experience, RPA requires a greater level of
cooperation than usual so heed this call. The
key to RPA success is collaboration and
communication. If there's one area where I
spend a lion's share of my time, it's here,
helping firms design their teams, select the
right players, develop the capabilities and
organize centers of excellence. Let's review the
key stakeholders you'll want involved.
At the highest level, we'll discuss business
stakeholders and IT stakeholders. Let's look
first at the business and process side. One role
you'll always see is the Subject Matter Expert or
SME. SMEs are the employees who are
experts at the process you're automating. They
know the process inside and out and it's their
job to teach the RPA team what each step
is and then validate that all the relevant
information has been captured faithfully. The
SME also plays a critical role later on in user
acceptance testing.
Now in some deployment scenarios, the SMEs
are the RPA team. Enterprises have the SMEs
learn an RPA tool and then automate their own
processes. This individual do-it-yourself
approach much like the era of Excel macros is
not something I generally suggest unless the
initiative is highly structured and governed and
closely managed. When working at the
granular level of complex processes, validation
from all parties involved is crucial. This is why
team leads or similar roles like process owners
are important.
Team leads are the people who manage the
SMEs. They often provide a higher level of
process validation. Team leads also support by
helping collect process metrics using their
expertise to ensure that the needs of the
business are met. Then we have your project
managers. Like any other business project,
these stakeholders help interface and
communicate all things project-related. Project
managers are essential to facilitate
progress during development and to handle
important issues when they're raised.
Now as I mentioned, your IT team is another
critical set of stakeholders. I always emphasize
the importance of early IT involvement and it's
for a good reason. You don't want to surprise

31
your IT team here. From my experience, senior
IT managers can be skeptical of RPA and will
have lots of questions about how it interfaces
with the existing technology and complies with
their security standards and protocols. So I
repeat, IT stakeholders must be involved at the
earliest stages of an RPA program. There are
several roles that may be relevant to your
initiative.
One is infrastructure support staff. This team is
responsible for running the servers and
machines that RPA requires, making sure that
the automated solution has a stable
environment in which to operate. Similarly,
application-specific personnel are responsible
for the upkeep and development of individual
software applications in play. Information
security personnel are always good to have in
the loop as well. RPA often requires
interactions between user accounts and the
transfer of potentially sensitive data.
As a result, including them in discussions can
help the RPA team align to security protocols
and minimize risks. Then you need to consider
who will maintain the RPA solution once live.
Whether this is handled by an internal center
of excellence or you choose to outsource this
to an external service provider, looping them in
is conducive to a smooth handoff of
responsibilities. Of course, don't forget to keep
project sponsors and executives in the loop.
After all, it's probably their budgets you're
spending. So they'll want to know its being
spent well. With all of these different
stakeholders in mind, it's even more important
for each person to have a good understanding
of RPA and ensure that stakeholders
understand the benefits of RPA and how it can
help to streamline processes and control
costs. One way to accomplish this might be to
get them to watch this course. It's what we
designed it for and remember, your primary
role is education. While robotic process
automation has been a brilliant a name to gain
the attention of a massive global market, it
does still confuse people into thinking
of robotic arms on shop floors or see C-3PO
handling your accounting.

32
Start Small But Don't Think Small
Let's now take a look at several best
practices at the enterprise level. At this stage,
some companies have done meaningful and
productive automation of their operations,
achieving real transformation thanks to
RPAand a huge number have done something
with robots. In fact at this point, I assume every
global enterprise has RPA somewhere inside
it, but few have a lot of it and there's a reason
for that. They started small and they thought
small. What do I mean by that? Let me paint a
picture for you.
For many early adopters of RPA, the beginning
of the journey began when a manager came
back from a conference, having just heard
about RPA. This manager calls up her
operational lead and says, "I just learned about
RPA." "We need it, go figure it out." The
operational lead, having never heard of RPA
before, hits Google to figure out what to do
next. With the knowledge they gleaned they
pick a tool. They then find a quick process to
automate, one that's really close to them, and
they hope they can deliver an easy win.
What ends up happening is that the RPA
solution is hosted on their desktop because
that's the simplest way to get it up and
running. The initiative is probably hidden from
IT this whole time because who wants to jump
through all the technical hoops just to get a
simple automation running. In addition, the
team skips process documentation and just
automates what they initially found as the SME
dictated to them, hoping for the best. After the
process is, hopefully, up and running
quote/unquote technical person in the
group is assigned to care of it in their free time.
And that's how the company's first RPA
solution is created, without regard for future
improvements, maintenance, or ongoing
upkeep. The result? They got RPA, but very
small amounts of it because they thought
small.
So how do you avoid this and think big? First,
you take time to match the features and
capabilities of RPA tools to your needs before
simply picking one. You'll want something with
robust capabilities and a good track
record that can last well into the future.
Then, you pick a process that matters to the
goals your business has set out to achieve. One
that scores high on all of our sliders. In both
scenarios, you've created a small test
deployment and in both scenarios, you may
well have proved the value of RPA to the
organization, but one set you up for success
and the other forces you to redesign every
step if you hope to scale it in the future. So start
small, but please, don't think small.

33
RPA Is Not About The Robot
RPA has robot in its name. You've got to admit
that's cool, and it's no doubt one of the
reasons the RPA concept has caught the
attention of so many. But I want to share a few
thoughts as it relates to the concept of the
robot. First, the tool is important, but it's not
the central player. You've heard me say this
before, but I say it for a reason. I was lucky
enough to be in the right place at the right
time, and have enjoyed being part of the RPA
community since its earliest days. I've watched
with fascination as enterprise after enterprise
begins their RPA journey by seeking proposals
for software.
Many have not yet thought through who will
own the initiative, where they'll house it, what
processes they'll prioritize, not even what the
success criteria are. I liken this to buying a
hammer before you're clear on the task at
hand. The coolest and shiniest hammer won't
do you any good if your task ends up requiring
screws. Next, while picking a good tool is
certainly important, a great RPA tool deployed
without solid communication, change
management, stakeholder management, and
change control is destined to fail.
Trust me, I've seen this happen too often. Don’t
miss the forest for the trees. Now, this next one
might shock you, but robot is a meaningless
measure of scale, scope, and transactional
capability. You might have 50 assisted robots
on desktops, and I might have two unassisted
robots hosted in the cloud. That doesn't tell
us who's accomplished automating more
complexity, nor whose added more value to
their firm. Stating a goal about how many
robots you want to deploy in the next year is
not very useful, yet the number of robots that
you have seems to be the unit of measure that
people are wielding as their credibility badge.
It shouldn't be about how many robots you
have. In fact, it should almost be the opposite.
If you can transform and digitize an operation
on a small footprint of technology, then you
may be in a better place then somebody who's
deployed thousands of robots. The point is, it's
about realizing the benefits we covered
earlier. Finally, while the robot concept sets you
up to buy cool clip art, fun T-shirts, and lots of
desk toys, it can have the effect of scaring the
wits out of the enterprise delivery teams.
In the early days of RPA, we would hide the
name in fear of raising the ire of HR or labor
unions. RPA is somewhat more accepted today,
but tread carefully, and be conscious of the
fact that people are sensitive about
automation impacting them. Be aware of this
when branding and announcing your efforts.
I’ll finish this topic with one final point. Perhaps
one of the most interesting things I’ve seen in
organizations that adopt RPA is how they treat
their new digital labor colleagues.
Without fail, every single organization that I've
helped adopt RPA does one thing in common.
They name their robots. So start brainstorming
names now, and yes, Rosie is already taken.

34
Don’t Forget The Fundamentals
Just because you can automate it doesn't
necessarily mean you should. Elon Musk, the
founder of Tesla, is the poster child for
automation and innovation, yet he showed us
that even for the most forward thinking
companies, automation's not always the
answer. Tesla over-automated, which helped
speed up a cash crunch in production delays.
Musk admitted this in a tweet in which he said,
quote, "Yes, excessive automation at Tesla was
a mistake."
He went on to say,, "Humans are
underrated,". This chapter applies to RPA in
spades, after all it is but one tool in your tool
belt. Don't try to shoe horn RPA into solving
problems it's not built to solve, especially when
they might be other solutions available, like
cognitive technologies, workflow tools, or the
most miraculous of all, humans. I've long
asserted that the future of work is actually an
optimal orchestration of a hybrid ecosystem of
tools and people working together.
The critical chapter here is that we often get
bogged down with the buzz words, hype, and
opportunities of automation and we forget to
focus on the business fundamentals. This is
when I see if businesses make the mistake of
looking for symptoms of underlying problems
to tackle, relying on the technology itself to
miraculously fix their problems. Continuous
improvement, change management, strong
program management, talent acquisition,
employee development, and much more.
The fundamentals are still the fundamentals.
Respect the mechanisms that have kept the
business running this long and don't forget to
loop in the black belts, data scientists, and
project managers who have been on the front
lines of change across your organization for
decades.

35
LEVERAGING A CENTER OF EXCELLENCE
You may have heard of the concept of a Center
of Excellence, or COE, before. It's an in-house
entity that provides capabilities for a specific
area of focus. And now, many businesses are
applying the concept to RPA so they can create
standards and scale their transformation
efforts. Leveraging a COE is how many
businesses aim to squeeze the most value out
of their RPA initiatives. As I hope I've impressed
upon you, getting an RPA program right can be
a complex initiative that requires careful
planning and research. But if you're able to get
a capable COE up and running, it can help you
achieve success and can provide
advantages, like economies of scales, reusable
components, and the power of group
purchasing for automation products and
services.
As you can see, having an internal capability
can be a useful launching point for large-scale
development and support. The COE topic is a
rich and detailed one, but for this course, I just
want to touch on the highlights. The functions
in a COE are centered on the needs of the
business, so their focus areas can vary. For
example, one organization might use their
COE for demand generation, in which the aim
is to educate other business units on RPA and
how it can be applied.
Another organization might want to be self-
reliant in RPA development as it scales up its
digital transformation efforts. In this case, they
would use a COE for internal training and
solution design. For many large enterprises,
every RPA solution is handed off to a COE for
continual maintenance, administration, and
risk management, making upkeep as efficient
as possible. Of course, if your organization is an
overachiever, you could feasibly build a
COE that does all of these functions. But no
matter what capability you decide to focus on,
a COE brings scalability and reusability to the
equation. To coordinate all these
functions, governance is a key factor that must
be carefully planned. For example, you'll have
to decide on an organizational structure for
your COE. In my experience, COEs tend to
be either centralized or federated. Centralized
models, which are the most
common, concentrate the RPA capability at

36
one point in the organization, which means
that all business functions defer to the COE for
support and resources.
Federated models are also quite common. This
is when a central COE provides the
framework for different business divisions to
build their own COEs, rather than having one
COE for the whole organization. This is helpful
for more complex organizations, where
business units are more distinct in culture and
processes. There are also, in my experience,
less common models like divisional COEs, but
I'll save those for another course. You'll also
have to consider the point of control.
Do you want your COE to be owned and
governed by a business or IT, or maybe a mix
of both? This will influence the degree of
control over development standards, change
management, and IT requirements. Let me
emphasize that there isn't really a clear,
winning combination of the considerations I
described. And in a sense, they aren't even the
most important part of planning a COE. The
truth is that a COE won't work well unless it
matches the DNA of your organization.
It takes a good understanding of your own
organizational structure to know which COE
model will be the best fit. For that reason, when
helping enterprises think through their COE
strategy, my first question to any firm is, tell me
about the last successful COE your
organization stood up? If you can answer the
question, that's great. You're equipped to
champion, fund, measure, and enable this
capability. If you've struggled to establish COEs
in the past, chances are good that now isn't the
time you're going to crack this nut, be
honest about your organizational DNA.
In this case, instead of developing your own
Center of Excellence, you might choose to
leverage a managed Center of Excellence, in
which a third party runs those services for
youth benefits are that a managed COE
provides cost certainty for the project while
ensuring a high standard of service quality. In
addition, businesses are able to leverage the
expertise of the firm they're working
with, especially if the firm is a specialist in
RPA. So if that fits the bill of your
organizational DNA better than internally built
COEs, then it might just be the most logical
option.
Either way, if you're keen on developing a
COE, I encourage you to ask around and learn
from others' successes and failures. A COE is a
complicated initiative, but when carried out
thoughtfully, it can be very rewarding.

37
Tips For Success From The Front Lines
I hope you've enjoyed this book so far. Before
we wrap up, I thought I'd share some valuable
tips that you might not find anywhere
else. They've been collected over my many
years of exposure to RPA projects across the
globe. While we don't have time for all of
them, I'll go over some of the most prominent
ones that come to mind. If you have completed
the course, you'll know that IT stakeholders are
a critical part of any RPA initiative. This is why
I'll emphasize again that it's essential to
engage relevant IT functions as early as
possible in the RPA timeline. In any business, IT
is responsible for provisioned access to internal
networks, applications, and infrastructure as
well as ensuring data integrity and security.
These are tasks that are better discussed and
set in place earlier than later. You don't want to
end up building an RPA solution that violates
IT protocol and gets you in trouble down the
line. Often, the challenge with getting IT on
board, is that approvals and infrastructure
preparation take time to complete. Sometimes
servers need to be set up, sometimes new user
accounts need to be made and
permissioned. Unfortunately, I have seen
projects stall to the point of frustration because
communication with IT functions was
delayed and important IT needs were held up.
So I urge you to keep communications with
stakeholders tight and especially so with IT
early on. Next, when you're getting into
process design, make sure the existing
process down to the step-by-step level is
clearly understood. I'm talking full process
documentation, written assumptions, and
metric collection. The more the merrier
because this information will come in handy for
benchmarking improvements and finding pain
points. A lot of this information will come from
the subject matter experts.
So you can count on them to be more
accurate than basic assumptions would be. But
sometimes, as we all know, one person might
have a different way of doing things than
another. Meaning that you should probably
crosscheck the information if the process is
complex enough. Again, the data you collect
will be referenced countless times during and
after development. So being meticulous is a
good idea. Lastly, when developing your RPA
solution, test everything. PA will follow the
rules exactly how you tell it to.
This doesn't necessarily mean that there won't
be any errors. RPA can involve many
interconnected systems across various
environments, which means unknown errors or
interactions can creep up now and again. To
make sure you've covered as many bases as
possible, you'll need to prepare for and
conduct comprehensive solution testing. This
course is meant to be introductory so I won't
go into all of the various testing strategies I've
seen. But one guiding principle I'll say, is to
align your test and production environments as
closely as possible.
Having test cases and test systems that are
identical to production ones will make
deployment smoother and reduce risk. That's
all from me for this chapter. If you want a full
list of chapters learned from the front lines, feel
free to download the full list form the Exercise
Files. Many organizations don't embrace and
defend these tenants until they've learned the
hard way. But I'm sharing them with you
anyway, may they help avoid even a few
potholes along the way.

38
Key Takeaways
Thanks so much for reading this book. I sincerely
appreciate you spending your valuable time with
me. We covered a lot of ground together, from
definitions and benefits to opportunities and best
practices. I hope you now feel more prepared and
confident to get started, and that this course sets
you and your organization up for a successful RPA
journey. You have the benefit of starting at a time
when there are far more RPA resources than when
I got started. This book for instance, is the
culmination of over two years of experiences, and
hard work
.

Free ebook on rpa

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Similar to Free ebook on rpa

Similar to Free ebook on rpa (20)

More from Abhinav Sabharwal- Business Analyst Mumbai

More from Abhinav Sabharwal- Business Analyst Mumbai (20)

Recently uploaded

Recently uploaded (20)

Free ebook on rpa