Skip to main content

11 lessons learned from automation rollouts

Written by laura robertson on . Posted in Articles.

It is written based on my RPA project and programme experience over the last 5 years rolling out RPA with vendors such as UiPath, Pega Open Span and Thoughtonomy.

It is intended to give both higher level and more detailed lessons of what can go wrong (and right) in automation/RPA rollouts.

Lesson 1

Prioritisation and choice of the right process is key

This means a definitive Process description, plus the formulation of a questionnaire to assess automation feasibility using higher level and lower level questions as you go through the automation lifecycle. This evolves as more becomes known about the process. If the process to automate has not already been chosen this helps assess viability, but even if it has been chosen, this step can assess how appropriate the “as is” process is for automation

  • Process assessment Roadmap leading onto an automation plan should follow. This should help embed the changes for the longer term and lay the building blocks for building a Centre of Excellence, which is where RPA, along with other initiatives can be done at scale
  • Most importantly: Celebrate successes and build RPA from there – don’t start with the most complex process just because this has highest ROI – you will fail!

Lesson 2

Ensure you are solving the right problem, with the right toolset.

To be successful, you must first understand your success criteria. There is more than one reason to perform an automation project – to achieve better transparency of work in progress, to automate hand-offs between teams in an end to end process, to improve consistency and quality of processing, to increase capacity or to reduce cost. Understanding the outcome desired, and how this will be measured, is critical.

If you only have a hammer, every problem looks like a nail[1]. RPA is not the only automation approach available and will not always be the most appropriate. However, where legacy systems are involved, which do not have easily accessible APIs, where people play an essential role as the ‘glue’ between a number of systems, RPA may provide a quick and cost effective approach to automation.

[1] https://en.wikipedia.org/wiki/Law_of_the_instrument

Lesson 3

Don’t do change management as an afterthought.

I have developed a “5R model” for this purpose based on my experience and learnings. The model looks to not only assess if the organisation is ready for change, but also whether reverting back to old habits/bad processes might occur. Are you really ready for this?

Lesson 4

RPA is rapid but it is not a miracle worker

You don’t have to have all the answers as an SME, but it helps to bring in an Automation Expert that does have the practical experience. Understanding RPA and its benefits will not turn a PM or a technical domain expert into an overnight developer. Get R&R quickly defined up front, a lot of the vendors suggest templates for that very reason. Ensure the training plan is clearly defined and realistic in the timeframe available

Lesson 5

Re-engineer first, if you can, but there is still a role for tactical initiatives

In the words of Michael Hammer, “don’t automate, obliterate”[2]. The greatest value comes from considering the end to end process – what changes upstream can eliminate the need for downstream work altogether. Indeed, automating just one isolated component of an end-to-end process might actually lead to ‘sub-optimisation’ problems. Ideally then, before considering automation we should take the opportunity to re-engineer our processes. The trouble is, process re-engineering and process improvement projects are most effective when they have access to objective process data. This may not be available. There is an argument to performing a tactical process automation project, perhaps implementation of BPM software for an existing process, to help gather empirical data about current process performance. This can provide the objective data that will facilitate future process improvement projects. A project may implement something “throwaway”, and still add considerable value.

[2] Michael Hammer, “Reengineering work: don’t automate, obliterate.” Harvard business review 68.4 (1990): 104-112

Lesson 6

Where possible become involved right at the start of the sales process.

  • Ensure you have a very clear understanding of how the project has been sold by the sales lead or the consultancy itself including timeline promises, deliverables, different pricing models offered and quality metrics
  • You need to get past the sales speak of the automation vendors and understand exactly what type of documents can be read and interpreted and which cannot. There is still a lot of development going on in this area and still a lot of over selling, not always by the vendors themselves

Lesson 7

Ensure you are aware which vendors operate at enterprise level versus those that are better catered to smaller offerings/SME.

Make a decision as to whether this digital initiative is a one off or something longer term and chose the automation vendor appropriately. Likewise does the vendor have extensive experience of enterprise applications like SAP. Is there agreement on how will changes in upstream systems be managed?

Advertisement
[widget id=”custom_html-68″]

Lesson 8

Beware of averages and snapshots; choose effective metrics

How long does a task typically take, how much effort is typically involved? Averages provide a convenient summary descriptive statistic, but they may hide interesting aspects of process performance. Rather than presenting averages, understand the distribution of your values. Boxplots provide a useful way to graphically summarise a distribution of values. When trying to understand why current performance of a process is unacceptable, you may need to examine the distribution not just the average.

How does the performance of your process change over time? Too often we think an increase or decrease in performance is noteworthy. Too often, managers provide commentary around things they really have no control over. A simple ‘run chart’ or ‘control chart’ helps you distinguish the true signals in your data, from normal process performance as a result of inherent variation.

This leads to the subject of metrics. The most useful process metrics are those which are leading, measure causes and are controllable. This is because they are measuring things which have an impact down the line, can be controlled/manipulated, and let you find out about them in enough time to be able to do something. In contrast, the very worst process metrics are those that are symptoms that you could never control in the first place, and which you find out about far too late anyway[3].

[3] https://www.linkedin.com/pulse/good-bad-ugly-kpis-ian-g-macleod/

Lesson 9

Build a digital culture.

This means a shared ownership and prioritisation of the automation pipeline. Consider whether your business want to have a name for the new user id (ie the automation id) that will work alongside the human, or if you should choose this. Treat this as a hand off point to more skilled workers when the automation cannot resolve an issue, rather than an “us and them” worker scenario

  • Start a competition for the best automation name!
  • Ensure there is sufficient technical aptitude – plus interest – in your digitalised business to support it for the longer term. Spend time to define back up plans
  • Secure trailblazers and champions who will also come to present their positive experiences to senior management once the proof of concept is complete. These trailblazers should be carefully chosen but as an example could be secured from larger processing areas who are in a lot of pain with multiple customer complaints and potentially flailing SLAs

Lesson 10

Full understanding of automation service support model to ensure longevity and ROI is key

  • Ensure clear understanding of exceptions handling- or the business will make up their own exception rules with little to no technical expertise nor understanding of vendor technical constraints. Best practice (and to ensure proposed ROI) is to ensure a retry at least once by the automation OR to reassign the same transaction to another robot for retry; if the retry is unsuccessful, the task is assigned to a human and a level 1 alert is raised to report the exception.
  • Define your service support model and level 1-3 SLAs with a full understanding of the technical constraints of the vendor, working together with the relevant internal technical architects and IT support teams AND the business.

Lesson 11

Take security requirements into account upfront.

Are credentials stored in a secured repository and available to deployed robots via encrypted channels? Confirm all channels between deployed robotics, UI automation, linked applications and system servers are protected by high level encryption and SSL protocols. Ensure these match your own internal policies and procedures and no additional kit is required to have that security

And finally don’t try to do it alone! Some other articles and thought leaders are:

A bit more about Ian:

Ian is Head of Process Engineering at Insight Investment. He has a bachelor’s degree in Cognitive Science (AI), and a master’s in Technology Management. He is currently pursuing a Doctorate in Data Science, and his research relates to the application of agent based simulation to organisational and process modelling.

Ian’s career spans technology development, consulting, programme management and process improvement roles, in Defence, Investment Banking and Asset Management industries.

Although trained as a lean six sigma blackbelt, Ian’s approach is to adapt and use whatever proves to work. Ian does not believe in ‘cook book’ methods for success – since all organisations are different. Trial and error, systematic use of data, quick feedback cycles and a willingness to admit when you’re wrong, will help you find what works best for your particular organisation.

A bit more about me:

As an Investment Banking Operations SME for 10 years I had always been au fait with algorithmic trading and the benefits it provides through automation. Since 2014 I have been an independent Automation consultant: RPA has impacted my career and the evolving technology around it exponentially. I have recently completed a part time MBA in Technology Management through which I have been able to add even more value to my RPA rollouts. Soft skills are essential in RPA delivery and those who possess both technical and change management skills will feel right at home in this environment. This technology really does have the potential to changes lives. It allows you to partner with some cutting edge companies who are at the forefront of the digital revolution and take ownership of programmes, due to their initial small size, right from the start.

Yes there are still some industry pain points around over selling, security and scaling up, along with media negativity, but hopefully some of the above lessons will help navigate through the fog of information out there. Nobody lost their job due to the proliferation of mobiles – and in my experience to date – automation is no different.

Automation, if done correctly, really does free up humans to do what we were built for – creativity & innovation

Views: 483

Comment