RPA (Robotics Process Automation) is the new way of improving processes. Robotics as a whole is the new trend you have to be in if you want to show you are proactively improving your processes, more or less in the same as organizations were starting Lean Six Sigma journeys 25 years ago, or OPEX programs 10 or 15 years ago. As an OPEX leader, I came to the idea that RPA has become the trendy evolution of OPEX and BPM. In my mind, RPA is the same operational excellence approach, but with the means we have today, obviously a lot more advanced from a technology perspective than what we had when Lean Six Sigma was a revolution on its own. The whole world is adapting to new technologies, so do OPER leaders.
However, I do see a true shift in the mindset of OPEX leaders, compared to what could be observed 10 or 15 years ago. The most obvious evidence of this mindset shift is in the measurement of success. Any OPEX leader knows well that success is not measured by how many people you train, or how many processes you have improved. The success is measured by the outcomes of the process improvements on the business: how much time you save, how many defects you reduce, how much you have increased your customer satisfaction indicators… Close to 50% of the OPEX programs could be considered failing, even though they have improved 100 processes. However, one of the measurement of RPA programs success is actually how many processes you have automated, and how many people are able to develop RPAs in your organization… these KPIs speak by themselves, and the outcomes to the business seem to be a side tracking exercise, rather than the true measure of success. What a paradox for an OPEX leader ! It somehow means that the simple fact of having an RPA program in place is guaranteeing the success to the business. Or in other words, the challenge is to get started, but once you start, you are almost certain to come up with successful outcomes… If that is really the case, the interesting question that comes next is: what are the key inputs to bring to an RPA program to ensure the processes are automated. Because if you succeed in implementing RPAs, you know you will make a positive impact to your organization.
So, after observing and hearing the lessons learnt from others, here are the five key inputs that an OPEX leader should bring to an RPA program to help drive success.
- The OPEX leader should come as a facilitator to identify the appropriate RPA opportunities
In my view, the foundation to successful RPA is to appropriately define what processes are good candidates for RPAs. In two ways.
First of all, since RPAs is still a relatively new technology, some process owners do not see the opportunities lying in front of their eyes. They have not seen enough cases or examples of RPAs to translate into terms meaningful to their day-to-day. As a result, they are unable to identify their own RPAs potential cases. Here, the OPEX leader should come and help the subject matter experts and process owners to unveil the opportunities lying in front of their eyes. It can be a challenge, as the OPEX leader is seldom an SME who knows the processes as well as the process owners. Yet, the OPEX leader must help find a way for the process owners to DEFINE their day-to-day problems, and identify the right solution to fix them – be it RPA or something else, by the way. The exercise between the OPEX leader and the process owner is an alignment of the language – on one hand, what does RPA mean in practice; on the other hand, what are the true business problems and what is the adequate solution to resolve them.
Then, the OPEX leader should come with a challenging mindset to prevent the process owners from forcing the RPA solution into any business problem. It often happens when a major trend such as RPA is coming in an industry. People want to be trendy, so as soon as they have a problem, they will jump onto the trendy solution, even though it is not necessarily adapted to resolve their problems. When it happens, the outcome would be an automation of the inefficiencies, hence creating a black box that the process owner cannot act upon anymore in the future. As an OPEX leader, encourage the process owners to truly challenge whether the manual and systematic processes can be improved first, before considering any automation of any kind. OPEX leaders know that well, but the process owners do not necessarily have that step back attitude when they have a solution in mind. And I truly believe that it is the role of the OPEX leader to help identify the right solution. Sometimes it is RPA, sometimes you would rather fix the problem in the old way – get rid of the wastes in the process, streamline with simple common sense, and only automate what cannot be simplified by plain streamlining.
- The OPEX leader should help building a customer centric business case
OPEX leaders know well that when an improvement initiative is driven by anything else than customers, it is doomed to fail, as the teams are going to spend hours working on something that the customers would not pay for. Well, the same attitude should be kept in mind with robotics in general – not just RPA for that one.
The business case, the rationale why the automation should be done, should rely on customer needs – not just on doing it because it looks good to do robotics, or to aim at cutting costs. We know that cost cutting driven programs fail in less than 2 years. The OPEX leader has the responsibility to remind that benchmark to the process owners and SMEs raising their hands for RPAs. Keep in mind that RPAs should help you get the team focused on value added tasks, so that the customers can be better taken care of. RPA should not be an initiative aiming at reducing team sizes. Such an approach would only scare the teams and keep them away from proposing RPAs ideas and creating true value to the business. Instead, keep them well aware that bots are just tools that will eventually help them better serve their customers.
- The OPEX leader should drive the team in establishing process standards
In any process improvement program, the OPEX leader knows well the steps: define the problem, the CTQs (Critical To Quality) or success factors, the business case, and… map the process! Well, similarly, when you start an RPA project, people tend to just take a video, hand it over it the developer, and jump into automating the sequence of tasks seen in the screen. To me, it means the same thing as improving a process before going through MEASURE and ANALYZE.
As an OPEX leader driving automation of a process, make sure the team spends at least an hour or two to look at the process, and meaningfully challenge what they visualize on the map. You would not have let your project team move to IMPROVE before going through MEASURE and ANALYZE. So when you drive automation, keep the same good principles in mind and in practice.
In an RPA project, this step of mapping the current process and challenging the current situation will ensure that the team establishes good standards in the process before automating it. This will in turn ensure that the bot being developed does not become a new black box that nobody understands in less than six months.
- The OPEX leader should help the team validate the outcomes of the automation
Taking again the analogy to any process improvement program, when a process has been improved, a key step at the end of the IMPROVE phase is to validate the results. This is when 50% of the process improvement initiatives fail: you come up with great ideas, but find out that they do not really work as expected in practice. Then you decide to drop the improvement, or to adjust it to make it work.
Once again, as an OPEX leader, ensure the same good practices are applied when you automate a process. In RPA, the drop rate is commonly close to 25 to 30%, and in robotics in general, the drop rate can often reach 75 to 80%. If you had had any such drop rate in a classic improvement program, the program would have been called off in less than six months. So why are we accepting such a high drop rate in robotics, and more specifically in RPA? Well, I believe that it is because we are aiming for the low hanging fruits, and forget to validate the results once a bot has been developed. The step aiming at validating the results – with numbers – will force the team to challenge if the way the bot has been developed in the best way. Maybe by slightly adjusting the bot, you could reach amazing results, and avoid wasting all the efforts done earlier. I am not saying to be afraid of the drop rate – you only improve if you accept to fail and learn from failing. I am not either saying that you should persist until you reach the initially expected outcome – it would result in wasting time on opportunities that cannot reach a good outcome. I am simply saying to spend the time to validate the results once the bot has been implemented, which will force the team to neutrally challenge if the bot has been developed in an optimum way, and as a result, the team will also decide to potentially adjust the bot, or to complete it with a macro or another process improvement that can change the whole outcome.
- The OPEX leader should ensure a Control plan is in place when the improvement is done
When a process is automated, the tendency is often to think that the system then does it all, and the process owner quickly forgets the underlying process, which becomes a black box in just a few weeks. The OPEX leader knows well that a process improvement project should end by putting the right opportunities in the right places: ie having an accountable process owner, equipped with a control plan giving him or her the means to manage the new process.
Once more, this operational excellence practice should be kept when developing a bot. A bot is nothing but an automated and accelerated way to perform systematic steps in a process. There is no real intelligence in it. And the human process owner is still accountable for the outcome of the process. As such, the process owner must know what to do and how when the outcomes of the process go out of the control limits. This can only happen with a good control plan in place, ensuring the process owner still understands the process, manages the process within its control limits, and knows what to do when it goes out of control.
To conclude, RPA is nothing to me but operational excellence with the tools we have today, keeping in mind that the old tools should not be forgotten. As such the key pillars of the OPEX mindset must be kept well alive by the OPEX leader when developing RPAs. In brief, keep well in mind the key steps of the OPEX approach: DEFINE, UNDERSTAND, RESOLVE; keep the customer centric view when building the business case and all along the project, as it can only be successful if the outcome is beneficial to the customers; keep the good practices of OPEX active at the end of the project, ie validate the outcomes in numbers, adjust the bot if necessary, and build a control plan before closing the project. These are nothing but the reflex any OPEX leader is used to in operational excellence program. As a well versed OPEX leader, keep these practices well alive for any RPA initiative, as RPA in simple terms is OPEX with some new tools available to us today.
The Process Excellence String of Ariadne 