Robotic Process Automation (RPA) is an innovative technology that can also be used to automate company processes in service more easily than before. In the future, this could eliminate some back-office activities, enabling a leaner and more effective organizational structure. Detlev Penven is a freelance management consultant who specializes in supporting clients in implementing strategies in the field of RPA. We want to delve a little deeper into the topic with him. - An interview with Detlev Penven.
Hello Mr. Penven, first of all, you can't avoid talking about the prevailing topic in these times: How is the current corona crisis affecting your consultancy work?
The situation is of course tense in many areas. I can't complain at the moment. I used to travel to the customer about 1 or 2 times a week. That's no longer possible and I'm completely working from home. It works quite well for my job. Other sectors certainly have bigger problems.
We want to talk about a topic of the future. You help customers to realize and implement RPA projects. How did you get into this line of work and who are your customers?
I have been working in IT for a long time and have come into contact with various fields. Somehow I came to the topic of RPA via test automation. Most of my customers today come from the accounting departments of companies. There are already many standardized processes there and a great need to automate them. But I also work in the call center sector. Here, too, there are a lot of manual activities that have to be carried out again and again by clerks. This is where RPA solutions come in handy. Many industries are represented, from regional municipal utilities to large steel groups. As the back office processes in companies are similar, the use of RPA makes sense in almost all sectors.
The topic has also been present in the service sector of industry for some time. In practice, however, you still see very few committed implementations. What could be the reason for this?
The problem does not only exist in relation to RPA. It is time-consuming at the beginning to familiarize yourself with this topic and to build a good solution together between business and IT. People often sit down together and say: this is what the process looks like and this is how it should work in the future!
In reality, however, the discussed process has many more degrees of freedom and the will is not there to spend money on maturing a solution. In turn, the employees get upset about the half-baked solution and the whole project is doomed to failure. RPA is then seen by the department as a solution to break away from IT. As many possibilities as RPA offers, implementing it requires the necessary expertise and a certain willingness to invest.
In your opinion, what are the biggest hurdles and difficulties in implementing this in companies?
Among other things, the lack of an agile mode is a major problem in many companies. RPA is ideal for making short-cycle, rapid adjustments to automation in order to develop a suitable solution iteratively. Many companies are not set up for such procedures on the project side and are used to managing large, long-term development projects. Agile approaches are usually more effective for RPA projects.
However, there are also other difficulties in some cases. Many IT employees view the topic with suspicion and do not perceive RPA as a real option. RPA seems to them to be too short-sighted to really appeal to them. In fact, it is initially relatively straightforward to automate a process with RPA. You go through the entire process once, program your robot and it then reads out the desired Excel sheets, for example, and enters the information in a mask. It usually only gets trickier in an error situation. What happens then? Does the robot simply abort processing? Does it save the current status and inform an employee?
A relatively large amount of process and IT expertise is then quickly required. As a rule, the specialist department can no longer manage this on its own and is then left with a shambles. The department hopes that RPA will make it somewhat less dependent on the IT department. In the vast majority of cases, however, this is not successful in the long term and IT is understandably unhappy if it is only called in when it is actually already too late.
Recommendations for action on the topic Automation in service We have already provided information on this elsewhere. What are the right levers for implementing projects? In which areas is automation even worthwhile?
We have now identified three main difficulties in the implementation of RPA: firstly, the lack of agile mode in companies is often a problem. Secondly, both IT and business departments need to be involved in a meaningful way and thirdly, the project is often underestimated by those responsible. Did we get that right?
Yes, but there is an additional problem: it often happens that specialist staff are unable to fully abstract and comprehensively describe the process. During implementation, I then come across variances that the team is no longer even aware of. Every RPA team should have someone who can not only work through the process to be automated, but can also describe and document it correctly and completely from A to Z. If no one thinks about this in advance, you will have problems when it comes to implementation later on. And this is a task that I as an implementer can only take on to a limited extent. The customer has to contribute the process know-how.
How do you rate the level of knowledge about RPA in companies? Is there still a need for clarification?
There are often very unrealistic perceptions of RPA here. The perception is also strongly influenced by the promises made by solution providers. You can supposedly automate your entire back office with the help of RPA. And everything is totally simple, quick and inexpensive to implement. I don't see that!
RPA offers many advantages in the field of automation. But only certain processes are suitable for this. Those that are very rule-based and therefore easy for the robot to solve. The processes should also have a high repetition rate, otherwise the investment in your RPA project is often wasted and the ROI is a long time coming. You will also run into problems with anything that involves heuristics. Where human interactions are irreplaceable and complex decision patterns arise. In other words: when the rule set becomes too complex. Very volatile process environments are also not advisable for RPA approaches for the reasons mentioned.
What is the best way to approach the implementation of RPA projects?
RPA cannot be a final solution; in the long term, there must be an integrated solution. In the short term, however, RPA can take the pressure of suffering and implementation off the specialist departments and IT.
There are two main options for this. On the one hand, you can build up the complete RPA environment and the necessary know-how directly and comprehensively internally from the outset and only seek external support for process implementation on a selective basis. This is the approach I am currently using to set up a competence center for a customer.
On the other hand, you may also be able to start small. Pick a labor-intensive, highly repetitive process and start a pilot. For example, you can initially have a certain proportion of less complex cases processed automatically by the robot and the rest will be handled as usual by one of your clerks, who will take a closer look at the process. This 50 to 60 percent solution for this process often helps enormously.
The department then takes a closer look at the remaining cases and gradually finds solutions for these as well. Over the course of a few weeks, you can then turn this into a 95 percent solution. And then you move on to the next process. However, according to Pareto, each additional percentage of automation is more expensive than the previous one, so a healthy balance must be struck.
What are the disadvantages of tackling the issue step by step?
If you want to build a solution yourself with some support, you must also be prepared to throw away all your work in between and start from scratch. You often reach a point during development where you may only have a small additional requirement for automation, but it is still more difficult to develop the robot further in this respect than to start again with the specialist and technological knowledge you have gained. Unfortunately, this is difficult to argue with customers. The robot is fully developed and you then need a few more developer days to implement this new technical requirement or to rectify certain errors.
The decision-makers often don't want to play along and you live with the inferior solution until it is no longer viable and produces more work elsewhere. In principle, however, it is already possible to start an initial pilot with 5 to 10 person days from an expert, which will already significantly reduce your workload. You can then build on this foundation.
Is the technology already mature or will we see further developments in the future?
I estimate that around 75% of all applications can currently be automated with RPA. This proportion will increase over time. There are simple applications that the robot can operate very easily. For others, it still sits in front of a pane of glass.
In addition, the field of artificial intelligence still offers a lot of development potential. However, this does not apply to process automation as such. You still have to work through the process in the tried and tested way. However, AI technology makes your robot more powerful, enabling it to handle more complex processes with heuristic decision trees.
Ultimately, you can connect all kinds of features to the robots, be it OCR, AI, natural language processing or machine learning features. However, the actual RPA automation always remains the same. Manufacturers are currently competing with terms such as hyperautomation, intelligent process automation or cognitive process automation.
Thank you very much for the interview!
Management consultant and specialized in the implementation of RPA technology
Self-employed, Cologne
