Hi, and welcome back to 3.6.
Now, we're talking about the Risks and Challenges
for using Robotic Process Automation.
Let's start with a quiz. Why not?
Which of the following describes situation
where RPA may cause trouble
because many people lose their jobs?
A to E, pause the video, have a go.
It's a quick one.
All right, employee morale.
That should be fairly obvious.
So, risk or a challenge.
Data security and hacking.
If we create a particular automation process with code,
then yes it is vulnerable to corruption of some sort
that may be inadvertent,
not anyone's particular fault or mistake made.
Or there is, of course,
the instance of someone being able to get access to it
that shouldn't have access.
Technical issues,
things break, code breaks as well.
System changes.
So, we change the systems.
The organisation gets acquired for instance,
and the new company comes in
and they've got different systems,
and they want to run Oracle,
and the other one ran Salesforce.
And then massive business performance management systems
in a sense, but we've got RPA,
they're doing great,
little jobs here on the side,
and it needs to be able to integrate across.
Easy to say, always harder to do.
We choose the wrong process to do, again,
think about the ones that are not ad hoc,
go after the ones that are repetitive first.
And of course, you've got the problem that you mightn't
have everyone's buy-in and that the people
that you want to help set up the RPA
are the ones that may will be cut out of the organisation
because of it.
That's a real challenge.
So what can you do?
You can make sure that you have good digital strategy
and that you have robust security systems.
Make sure with the technical issues that you do testing.
It's again easy to say,
but anyone who's been involved in IT project knows
that there is a large chunk of time
of user acceptance testing.
You have to do that and you have to do it well.
And when issues arise,
you have to go back sometimes and iterate,
and make the changes.
Unfortunately, it's where timeframes can blow out
when perhaps the business user requirements
or the business case wasn't done as well
as it could be at the start.
And so then you find that in user acceptance testing,
things don't always fall into place.
The system changed,
don't change the system as one,
but I think also we have to reflect that if it was something
like a company being taken over by another one,
you may be forced to operate in larger IT ecosystems,
and they might be different,
and you have to be able to get that RPA to work across both.
Choosing the wrong process,
get your processes right,
get your business case right,
get your problem that you're trying to solve right
at the start and then you won't choose the wrong process.
And look, the best I think you can do with employee morale
is communicate, communicate, communicate.
That is the best chance,
because whether you like it or not,
don't think that everyone will happily go on with,
oh, RPA is here to make me more efficient.
And Jeff and Susan and Raj,
they're all going to get sacked.
You have to be just honest with your employees
and communicate what's going on,
and where people are moved to other roles,
show them how those new roles, those initiatives,
those tasks they're going to need to do
will be valuate to the organisation.
Right, that's a very short section in the study guide
so we're going straight on to 3.7,
Building an effective RPA strategy.
Quiz.
What percentage of initial attempts to implement RPA fail?
Given all the examples we've looked at,
talk about great success.
Pause the video and have a go.
30 to 50%.
Again, it's interesting.
It's not that RPA is not a good solution,
I think it is a brilliant solution,
and I think a lot of industries on the administration side
are far too inefficient.
RPA could make government so much more efficient,
RPA could make teaching more efficient,
there s a whole lot of things.
But isn't it interesting that we have
these automation solutions,
all of these companies that are ready there to offer it,
and to sell you their services
and yet so many of these particular RPAs
don't work in the end.
So, bring us back to part A
because why not put the slide up again?
You've got to be careful with expectations and reality.
And I will always say this,
you go back to the very first step
because it's at step one where you're defining the problem,
you're understanding the root causes for the problem
that you define the ideal outcomes,
the objectives correctly,
and therefore you choose the right process,
so that we don't end up
with our Thomas the tank engine reality.
You got to pay attention to three items
in RPA strategies, all right.
Centralised management of RPA?
Or does each business unit do it alone?
It's not necessarily one or the other,
but it's not going to be both.
It may not work the first time.
That does not mean you chuck it out,
but it does mean that you consider how you're going
to better utilise the next iteration.
How you're going to decide what it was exactly
that didn't work well the first time so you get it right.
And governance is obviously really important as well.
You need good people over the top
with a clear head to actually manage the process
and ensure that things stay on track,
but also that the outcomes and the objectives
are being followed at all times.
So, these are going to be fairly obvious.
The process is high volume and it's repetitive, all right.
Clear rules as I said before,
boundaries that we can see so we don't have all
these outliers because if we do,
it's going to be difficult,
especially to make it unattended RPA.
Relying on structured data, right?
Time sensitive, seasonal, things like that are
important to consider in terms of the success of the RPA.
The 8-step method.
It's like a zillion other planning methods
that are out there that you can read
in business magazines or books.
It's pretty straightforward.
Do the plan, define your objectives,
obtain the buy-in except that maybe not everyone
will buy into this because of the consequences
for employees.
Act, deploy small scale.
That's about being agile.
So do experiments, select a tool,
choose a process,
define what you want to achieve, right?
Then set up the sequential steps that need to be in the RPA,
bot, test it, refine it, test it, refine it.
Step five should just go over and over and over again,
til' you get it right, okay?
You trial for a set time,
you get feedback,
you get qualitative and quantitative feedback,
you analyse and if required,
you go back and you say we didn't get
the process right, okay?
Or you go back and we need to go back
and look at the RPA software process definition
and get that right.
And you have to be able to iterate.
If you do it in that sort of waterfall environment
where every step must be complete,
and there's no sort of being able to loop back,
you will struggle.
You'll really struggle with doing something
like RPA or AI or any of it.
It has to be agile and intuitive.
So, you've got your scale of effort
when you've obtain the buy-in,
you've got to obtain also the resources
to implement it, right?
And the workforce that you might need to build around that,
who's going to monitor the RPA,
who are going to keep building it,
who's going to build the next module
when the first test runs worked?
Always review, measure review, improve.
Here is the RPA maturity model, figure 3.8.
I don't fully understand it myself,
but I'm making sure that you know that it's there
and you can reference back against it.
So, you've got a proof of concept.
That's what POC means down here.
Then you've got a transition,
then you've got a quick wins,
but then you've got another transition,
then you've got an RPA capability or effectiveness.
I think it's trying to say,
as you go along transformation,
you need to be agile across all of it.
I would say that leadership is again,
across both ways, across all of it,
and agility is across all of it.
I'm not entirely sure the different columns,
the particular order,
but let's just say leadership is important
in order for the process to become more mature,
embedded in the organisation as BAU,
and that there'll be transitions at each stage.
Transition from the pilot to a larger scale project.
Transition from a large scale project
to business as usual.
Let's think about it that way.
RPA insurance automation at DKG is example 3.9.
So, their automation goal was to free people
from robotic tasks.
Let the brokers be brokers.
They believed that their brokers
are often spending up to 80% of the time
on repetitive, boring tasks.
Okay, then they looked at the three problem processes
that were heavily manual.
So, they've gone to identify,
and remember we talked about select that one
that looks up 85%, right?
Use the 80-20 rule,
the answer take up 80% of the time.
Even if one of those 20% ones is the one
that everybody hates as a manual process,
doesn't mean it's the right one to automate.
If it doesn't meet the criteria that will give you
the ideal outcome.
So, it's managing debtors, renewing retail motor policies,
and managing claims emails.
Alright, so generating statements and invoices.
Automatic emailing of communications done by the boss,
streamline the renewal process,
which is pretty much done for all of us now.
I get my car insurance,
I can't remember who it's with,
budget direct or someone,
and you know it's automated.
It's come out automatically,
it's up for me to say, no, I've changed cars
or I don't want the policy anymore.
I want to change the comprehensive level on it
or something, right?
Other than that,
it is just spat out of the system.
And the claims emails as well.
Hundreds of claims emails daily,
then how do you file these things in the right area.
Not have someone having to stare at an inbox
and manually move things.
And you'd be surprised how that still occurs a lot
of the time.
All right, we have got to the end of part B.
Congratulations.
It went across these three learning objectives.
All right, remembering that we've got 15 possible marks
out of 75,
where questions will be asked across
those three learning objectives.
Next, we go on and have more of a deep dive
into artificial intelligence in part C.
Thanks for your time.