RPA vs Business Process - how to balance the two
RPA can become the sticky plaster of the business process world. It’s great in the short-term but nobody wants to wear plasters forever.
2019-04-26 16:32:47
Amongst the major buzzwords at the moment, RPA - or Robotic Process Automation - is right up there. Against the backdrop of blockchain, artificial intelligence and machine learning, it also has probably the fewest barriers to entry. Modern RPA toolkits, such as UIPath, are designed to be used by anyone and offer the well-heeled ‘no code’ environment that business managers' dreams are made of - the sales pitch is that there should be no direct dependency on a technical resource - anyone can build and release a robot! And it’s not entirely untrue - RPA on the market today does enable some fairly rapid efficiencies to be had.
The inclusion of ‘robotic’ in its name has people either deliriously excited or cowering under a blanket in the corner. Let’s be clear: there are no robots in the 'Sony-walking-dog' sense of robots or glowing red eyes, Skynet-style. The term robotic is only included because it's catchy - the emphasis in RPA should be on the A - the automation aspect - and finding ways and means of automating processes - processes which otherwise would typically be performed manually and are associated with being labour intensive or repetitive.
The benefits of this are that many of the processes that RPA can be utilised for are performed by humans - which is expensive, laborious and prone to error. By automating it - robotically, if we must - we can do more work, more efficiently and more reliably - and, bonus - free up that valuable human to do something worthwhile.
The go-to use case is automating some repetitive, laborious process that is currently fulfilled by a human. Most of the sales fodder will show Excel, a web search and pumping the information in to a CRM system (with some email in there for good measure.)
But better examples of where RPA is genuinely useful are for example where the process involves some legacy system that does not support the modern methods of data integration (APIs, web services, etc.) and thus there are genuinely few alternatives to data entry on this system other than keying it.
Or there is some new regulatory demand - "check through all of your files and find all those that meet x criteria."
RPA in this case makes sense - a robot can be trained to perform the correct actions / activities / keystrokes in the correct order such that high-volume data entry does not need to be keyed manually by a human. Actual, measurable efficiencies can be had - quickly.
The cynicism in the tone is intended - for effect. It is not a reflection of the quality of the tooling because modern RPA is powerful and readily enables businesses to put it in to action, with demonstrable ROI. That an average user can in just a short time cobble together the activities to automate certain tasks is an interesting technological feat.
But - just because you can, does it mean you should? Having the capability or opportunity to implement RPA doesn’t automatically (pun intended) make it the right thing to do in the context of the strategic direction of the business. There is a real danger with the powerful capabilities of RPA that badly designed processes become even more engrained than they already were.
RPA has the potential to become the Excel of the future - where entire companies run on a set of fragile processes loosely linked together.
As technology consultants, we spend much of time looking at ways to properly replace situations where Excel has become a core business system - the scenario where some temporary solution lasted a lot longer than anyone expected and then became the system - in essence, mitigating the “we’ve always done it like that” scenario.
In other words: automating bad processes is worse than doing nothing at all.
Nintex1 is a workflow tool, masquerading as a (lightweight) business process tool. It is not a real BPM tool in the truest sense because it is a technical tool that creates runnable workflows / business processes. It started life as a Sharepoint extension but has grown considerably, and having used it extensively over the last 10 years would highly recommend it to anyone looking to do workflow in Sharepoint. But - the news they had acquired an RPA vendor called Foxtrot - made me sad.
Why? Because Nintex is currently a fantastic workflow tool and I don’t want them to fall in to the trap of confusing business process and workflow with RPA. There is a role for each; but they are distinct.
Bad analogy time, #1: RPA can become the sticky plaster of the business process world. It’s great in the short-term but nobody wants to wear plasters forever.
Bad analogy time, #2: RPA is great at putting out fires; but nobody wants to be on fire forever.
(Fingers crossed Nintex nail the integration of the RPA and workflow tooling and we end up with the best of both. That would be good.)
So in our view, here’s how these things hang together. A scenario we commonly encounter is one where a well-established business has many processes, is at capacity (in terms of staff availability), is facing technology pressure to consolidate and minimise sprawl of legacy systems, is exposed to genuine business risk through things like Excel and, just for fun, is facing increasing competition from more nimble companies.
The way to approach this is to separate and prioritise the issues in to a set of short-term tactical and long-term strategic objectives.
Short-term, tactical, objectives:
In this case you might:
Long-term, strategic, objectives
In this case you might:
RPA has great potential to give organisations quick, tactical wins. If you’ve got an auditor, regulator or parent company telling you to just get it done; then there’s not often to time to sit down and plan it all out properly - and RPA can help in this situation. But the risks of deploying RPA must be recognised.
With properly designed business processes, there should be no need for RPA2. So at the time you deploy RPA, you should have a clear strategic plan of where RPA fits in the big picture and, ultimately, how you are going to turn it off again.
1: Cortex are certified Nintex partners (and the only certified Nintex partners in Guernsey in the Channel Islands.)
2: At least in the guise that is currently being rolled out - "brownfield" deployments. RPA in a greenfield environment is a really very interesting proposition.
But what is RPA?
The inclusion of ‘robotic’ in its name has people either deliriously excited or cowering under a blanket in the corner. Let’s be clear: there are no robots in the 'Sony-walking-dog' sense of robots or glowing red eyes, Skynet-style. The term robotic is only included because it's catchy - the emphasis in RPA should be on the A - the automation aspect - and finding ways and means of automating processes - processes which otherwise would typically be performed manually and are associated with being labour intensive or repetitive.
The benefits of this are that many of the processes that RPA can be utilised for are performed by humans - which is expensive, laborious and prone to error. By automating it - robotically, if we must - we can do more work, more efficiently and more reliably - and, bonus - free up that valuable human to do something worthwhile.
Use case(s)
The go-to use case is automating some repetitive, laborious process that is currently fulfilled by a human. Most of the sales fodder will show Excel, a web search and pumping the information in to a CRM system (with some email in there for good measure.)
But better examples of where RPA is genuinely useful are for example where the process involves some legacy system that does not support the modern methods of data integration (APIs, web services, etc.) and thus there are genuinely few alternatives to data entry on this system other than keying it.
Or there is some new regulatory demand - "check through all of your files and find all those that meet x criteria."
RPA in this case makes sense - a robot can be trained to perform the correct actions / activities / keystrokes in the correct order such that high-volume data entry does not need to be keyed manually by a human. Actual, measurable efficiencies can be had - quickly.
Great! Why so cynical?
The cynicism in the tone is intended - for effect. It is not a reflection of the quality of the tooling because modern RPA is powerful and readily enables businesses to put it in to action, with demonstrable ROI. That an average user can in just a short time cobble together the activities to automate certain tasks is an interesting technological feat.
But - just because you can, does it mean you should? Having the capability or opportunity to implement RPA doesn’t automatically (pun intended) make it the right thing to do in the context of the strategic direction of the business. There is a real danger with the powerful capabilities of RPA that badly designed processes become even more engrained than they already were.
RPA has the potential to become the Excel of the future - where entire companies run on a set of fragile processes loosely linked together.
As technology consultants, we spend much of time looking at ways to properly replace situations where Excel has become a core business system - the scenario where some temporary solution lasted a lot longer than anyone expected and then became the system - in essence, mitigating the “we’ve always done it like that” scenario.
In other words: automating bad processes is worse than doing nothing at all.
Review your business processes before you automate them
Nintex1 is a workflow tool, masquerading as a (lightweight) business process tool. It is not a real BPM tool in the truest sense because it is a technical tool that creates runnable workflows / business processes. It started life as a Sharepoint extension but has grown considerably, and having used it extensively over the last 10 years would highly recommend it to anyone looking to do workflow in Sharepoint. But - the news they had acquired an RPA vendor called Foxtrot - made me sad.
Why? Because Nintex is currently a fantastic workflow tool and I don’t want them to fall in to the trap of confusing business process and workflow with RPA. There is a role for each; but they are distinct.
Bad analogy time, #1: RPA can become the sticky plaster of the business process world. It’s great in the short-term but nobody wants to wear plasters forever.
Bad analogy time, #2: RPA is great at putting out fires; but nobody wants to be on fire forever.
(Fingers crossed Nintex nail the integration of the RPA and workflow tooling and we end up with the best of both. That would be good.)
Balance workflow and RPA
So in our view, here’s how these things hang together. A scenario we commonly encounter is one where a well-established business has many processes, is at capacity (in terms of staff availability), is facing technology pressure to consolidate and minimise sprawl of legacy systems, is exposed to genuine business risk through things like Excel and, just for fun, is facing increasing competition from more nimble companies.
The way to approach this is to separate and prioritise the issues in to a set of short-term tactical and long-term strategic objectives.
Short-term, tactical, objectives:
- Resolve technology issues
- Mitigate risk (e.g., Excel documents); information silos
- Relieve staff capacity issues
In this case you might:
- Centralise and version control key documents/spreadsheets in something like Microsoft Sharepoint Online
- Utilise RPA (such as UIPath) to relieve staff capacity issues and as a documentation exercise of existing processes by automating data entry to legacy systems
- Consolidate legacy systems on to a single platform such as Sharepoint
Long-term, strategic, objectives
- Drive efficiencies by removing overheads and redundant processes
- Consolidate IT estate to tightly integrated set of services
In this case you might:
- Perform business analysis to document, re-engineer and consolidate processes
- Review options for upgrading / building modern systems, utilising cloud technologies and the advances in e.g., machine learning
- Ensure business process automation (using workflow) is built-in to these systems
Summary
RPA has great potential to give organisations quick, tactical wins. If you’ve got an auditor, regulator or parent company telling you to just get it done; then there’s not often to time to sit down and plan it all out properly - and RPA can help in this situation. But the risks of deploying RPA must be recognised.
With properly designed business processes, there should be no need for RPA2. So at the time you deploy RPA, you should have a clear strategic plan of where RPA fits in the big picture and, ultimately, how you are going to turn it off again.
1: Cortex are certified Nintex partners (and the only certified Nintex partners in Guernsey in the Channel Islands.)
2: At least in the guise that is currently being rolled out - "brownfield" deployments. RPA in a greenfield environment is a really very interesting proposition.