READIN TIME: 7 MINUTES
Using Robotic Process Automation as a technology together with Lean Six Sigma to release bottlenecks, increase capacity and processing speed, and reduce errors is no-brainer. It’s not a trivial question though on how to use Lean methods while building RPA solutions or how RPA can use it to improve its own outputs. Nevertheless it worth giving this topic a thought or two.
1. Processes on Macro-level
It’s a widely known misconception that RPA should only focus on task automation. If that would be true, we should call it Robotic Task Automation, but we don’t do it for a reason. RPA Teams have to know how their solutions will fit into the wider landscape of enterprise processes.
This way, they should not only transform the tasks the business area wants to get automated, but have a say in how to modify front-to-back processes too, so the organisation can avoid having siloed processes that would result in no significant throughput improvement, as the system as a whole will still be just as slow as a sloth.
2. Processes on Micro-level
To quickly switch focus from macro to micro, the robotic solutions’ underlying tasks should be as lean as possible too. Robotic solutions should almost never replicate the processes the exact same way humans can do it, for two different reasons: our robotic capabilities can either do more (calling APIs, processing faster) and less (cannot improvise and deal with ambiguity) than their human counterparts. Let’s see what we should consider when we discover and document our processes, and design our solutions.
2/A Dig to the Core
It’s far not enough to know just as much from the processes as the person who’s performing it currently. Most often than not, they don’t really understand why those tasks have been designed the way they are executing them in their current states. So we must be more knowledgeable than that in all circumstances, since we are looking for the core business intention of the process.
Core business intentions are always the most simplistic description of a process we should adhere to. Maybe during the years, those tasks changed due to various reasons, but we need to dust them down to find why that process is designed to do and whether it’s still necessary.
When we find the core of the process, we won’t be arguing about details that don’t matter (like what colour should the fonts have when the solution sends out alerting e-mails), but we can rethink the entire setup. You wouldn’t believe, but there are undocumented processes, where they cannot recall decision points in the right execution order, so we need to detect and correct logical errors to comply with the core business intention.
2/B Cut the scope
“We want to get everything automated!” – Hold on champ, you probably don’t have the budget and time for that. So are we gonna just automate “the happy-path”? It’s not that simple either. Let’s consider the 80-20 rule. 20% of your process scenarios are executed for 80%+ of the items processed. If that’s not true, your process is either not standardised (go and reengineer it), or cannot be standardised. Either way, you shouldn’t deal with automating that in a condition like this.
So for the sake of saving development time and budget, and not overcomplicating our solutions, we need to focus on thoroughly discovering and documenting that 20%, and try to find ways on how to detect the rest, so we could send them for human handling. Scoping our processes right is not just saving time, but makes the maintenance more sustainable as well, if we don’t need to make sure that our solutions can properly process improbable scenarios that occur once in a decade at best.
2/C Technology optimisation
Due to robotic solutions’ better IT integration and capabilities, we can rethink the way a process can be conducted. For example no human can fruitfully use API calls, and generating XML/JSON files instead of using the application frontends. Captchas are there for a reason too, the data providers often forcing organisations to subscribe to the content they provide via webservices.
We shouldn’t tweak Excel files from the MS Excel UI, and we shouldn’t do that with Access databases or any MS product with appropriate interfaces either. Robotic solutions should only consume and output well structured data. If we can clean up a file’s format in order to achieve that, we should definitely go for it. No messy files or data structures are acceptable.
2/D Keystroke optimisation
In my opinion this could bring the least value for our solutions, but brings some value regardless. Keystroke optimisation is achievable if you know the core systems capabilities better than the person who’s executing the tasks on them. Knowledge about shortcuts within systems comes with time, when similar subtasks are getting automated spanning across various processes, and one team knows a better way on how to conduct them than the other. Reusable robot components play a big role in increasing developer efficiency in such scenarios.
3. Delivery Methodology
When we talk about Robotic Process Automation, we shouldn’t just take a look at business processes that should be automated, but the delivery methodology RPA uses to handle robotic solutions’ discovery, design, development, testing, deployment, operations and maintenance.
It’s somewhat true that every handover points could decrease the quality of the final solution. This is simple due to loss of information or misunderstanding the whole concept of the process that is about to be automated. Better documenting our own solutions is just one part of the solution, cutting the handovers by merging roles is another way to speed up deliveries. Of course having combined solution designer and business analyst roles has its cost, but the benefit of that is exceeding that at least double fold, as the maintenance cost will be significantly lower in the long run.
We should not just avoid the quality deterioration, but in every stage, we should focus on increasing the quality by documenting the process better than it was previously detailed, creating a better robotic solution design than the current state of process design, and developing it better than it was executed before. This will enable us to have more stable operations than we had before using RPA.
To sum it up, even if we don’t use the lean methodology in its classic form, the core mindset is still critical for the success of Robotic Process Automation.
In case your RPA program seem to have got stuck or you are about to do it first time right let’s talk!
Original article: https://www.linkedin.com/pulse/what-should-lean-rpa-balint-laszlo-papp/
