March 8, 2019 at 22:35Man-made abyss or path from an RPA pilot to company-wide implementation
What is an RPA? You can say to a small child: “the robot will wash the dishes for you and clean the room, and you can spend your time on games and books”, and to the head of a large organization - “this is a powerful but easy tool for making business processes faster, with fewer errors, using fewer resources. "
Robotics have huge potential. Already, the RPA solves a whole range of tasks: migrates data, creates reports, removes routine from business processes, trains new employees, integrates different systems, provides multi-contact contact centers, automates work with primary accounting documents, replaces tools automatic testing and the list goes on for a long time.
RPA technology is not new, in one form or another, it is almost 20 years old, but the boom of development has been in the last two to three years, with the advent of new, strong players and large, successful projects, which saved companies billions of dollars and millions of man-hours.
Almost every introduction of new technology begins with a pilot project. The RPA pilot, as a rule, is easy enough and shows tangible advantages of the approach. But, as with many other technologies that require a major change in the approach to organizing production processes, the next steps for the pilot often cause psychological difficulties.
Often, a pilot RPA project ends with an MKHAT pause, a period of intense expectation, when it is already clear that the matter is necessary, but no one knows how to move from the first attempt to a serious implementation. Problems, primarily organizational ones, create an almost insurmountable chasm on the way, and often there is no clear way to overcome it.
In this article I will list the conditional top 10 problems that arise when implementing RPA and try to give some practical recommendations on how the RPA team can “grow its wings” and jump through this abyss.
So, how can you impede the introduction of new technology?
The mistake is that when solving current problems with the help of RPA, we do not think about the strategic goal of our work.
On the surface, RPA is a lifesaver for those who have a lot of boredom in their work: transfer data from one system to another, compile a report on materials from several databases, automate the routine tasks of an accountant or administrator, etc.
There is a temptation to just keep the toolbox ready and, if such a situation is detected, start to ad-hoc robotize it, or, as they say, "write a script." But, the problem here is that in order to gain weight and significance in the eyes of company management, any initiative must have a clearly formulated global goal and a clear plan to achieve it.
Without such a plan, it is practically impossible to achieve the scale of the initiative, and without scale, no one in the big company will notice that there was anything like that, the RPA will remain a toy in the hands of administrators, who once flew the task of "see what kind of robots these are." But they won’t notice - they won’t help create a team, they won’t give the team money, they will write off the entire direction as unpromising.
To avoid this problem, by the time the pilot project is launched, you already need to clearly understand what goal the company wants to achieve with the RPA, have a high-level strategic plan with milestones, metrics, etc. Why not at the time of graduation? Because the choice of the pilot process, and the evaluation of its results - all this naturally follows from the choice of a strategic goal and methods for achieving it.
The mistake is that RPAs are perceived as a tool for the IT team, and completely transfer the whole initiative there without connecting a business and creating a cross-functional team.
We often see that the inertia of thinking makes people reason like this: “This is a software product, which means he has nothing to do with business. Let experts deal with him. ”
RPA, first of all, solves the tasks and problems of the business, optimizing and automating existing business processes in the company. Only the business knows what, where and how to do it, which means that the team involved in robotics must include representatives of those for whom it works, to know where the most routine and ineffective solutions are worth paying attention to first of all.
The business, remembering that IT people all the time requires answers to various difficult questions and generally hinder progress, decides that RPA can be done both on its own and by external contractors. At the same time, of course, the expectation that there will be no multi-month approvals, it will not be necessary to write documentation, request accounts and everything that interferes with fast and efficient work.
Of course, in almost any large Russian enterprise, the number of administrative procedures required to create a new product or service is amazing. But one must understand that this, most often, is not a whim and bureaucracy, but a real, vital necessity.
Implementing even such an “easy” and “simple” solution as an RPA, you still need to think about security, infrastructure, monitoring robots and a million other things that a business cannot do without IT. It’s not bad when a business tries to look at robots without waiting for them to come up with this initiative, it’s not bad when business users write processes for themselves, but, of course, within the company, don’t involve DIT in the initiative from the moment it starts - this is a catastrophe.
Without IT, you can forget about scaling a solution, about its normal support, not to mention the fact that robots often need to be optimized using APIs, Powershell scripts, integration with Python scripts and other things that are not clear to business.
And still have to overcome the syndrome " Not invented here", and at" IT "he is strong, like no one else.
A common mistake arising from the fact that after the first, successful step, the team thinks that she can do anything. Processes that are difficult to automate are selected, and even worse when they are randomly assigned for political or other reasons, without thinking about why this process gets to the RPA team.
When choosing processes for robotization, you need to dwell on those that can bring the most benefit at the lowest cost. But speaking of the benefits, it is worth considering that this may be one of many factors, the priority of each of which depends on a specific moment:
On the other hand, there are several reasons why it is worth abandoning the robotization of the process, or at least how to think about it:
At the same time, the most important selection criterion should always be one: the complementarity of the process of the strategic goal of the robotization initiative.
In robotics, the Pareto rule is true as never before. Most often, one or another process can be quickly robotized almost entirely, and then another month or two to fight over some “small” piece of it, which turned out to be difficult to formalize, or requires complex technical solutions in order to work smoothly.
In this case, it makes sense to ask ourselves whether we want to have 100% automation of the process or what we have already done is enough to bring benefits to the company and switch the RPA team to another task? It is almost always possible to rearrange the process so that the robot does all the “dirty” preparatory work, transfers its results to a person to make a decision, and then the robot performs routine steps to complete the process. We can say that 80% of automation is more than enough for most tasks.
At the beginning of the path of robotization, when the team has not gained enough experience, it makes sense to choose easily achievable goals that will allow you to gain confidence in your own abilities, gain weight in the eyes of the company, and you should not be afraid of compromise solutions.
An error that occurs when they do not distinguish between projects on, for example, SAP and RPA.
Robotization gives the maximum effect where we spend much less time and effort on it than on “full-fledged” automation. And this means that it is necessary by all means to strive to ensure that robotization is as fast as possible, and the labor costs for it are significantly and provably smaller than other solutions to the same problem.
Most often, in large enterprises, this problem is expressed in the fact that any IT decision has been made to run through a series of checks and approvals, and the entire project should be carried out using a “hard” development methodology, such as RUP.
This approach, which has proven itself in creating and supporting large solutions, crashes on projects where the entire cycle should last 2-3 months. If the process can be automated two to three times faster than making all the necessary approvals, you need to change the approach, provide robots with the opportunity to pass checks faster, accompany them with less documentation, etc.
Where the Agile approach is already being used, at least for some products, it makes sense to find out whether development of robots cannot be attributed to this category either.
Where everything is still “serious” you need to devote a lot of time to training and explaining what robots are, what they eat with and why they need special treatment.
The consequence of the easy-going pilot is creating “dizziness from success”, and it seems that you can go further from victory to victory without putting any serious effort into it.
To create a pilot, you can usually download the free version of the platform from the Internet (for example, UiPath Community Edition or RPA Express ) and start creating. Using a team of two or three people is quite realistic to make and start the first process in a couple of months. But for a large company this is not enough, dozens of processes are needed that robotic business processes in different areas, running on a wide variety of computers, servers, virtual machines.
The beginning of a full-fledged implementation is impossible without gathering the backbone of the team, training specialists, obtaining the necessary resources, etc. etc. So, all this needs to be thought out, prepared and agreed upon in advance, it is necessary to find those to whom the task will be really interesting.
Often the complexity of this task is underestimated at the initial stages of the project, which, in the future, leads to unpleasant disappointments.
The error arises when the effect of implementing PRA is calculated based only on the obvious metric - “FTE savings”. The problem here is that in our realities, where the salary in the regions is comparable to the cost of a robot license, this metric fails, leaving most of the processes below the line when a positive ROI can be obtained in 9-12 months (in the USA or Western Europe this is usually around 6 months).
Here you need to understand that the effectiveness of RPA is measured in a more complex way than just saving man-hours. It is necessary to take into account the fact that the processes begin to work much faster, unloading the multi-week “waiting lists”, and that the percentage of errors that were previously introduced by the “human factor” and the inability to add additional checks to the long and complicated process is reduced.
There are even more difficult to measure indicators, such as an increase in employee satisfaction with their work (which means fewer layoffs, which means less HR workload), improved customer relationships (their requests are processed faster and without errors), better process control and many other factors.
In the short term, it is difficult to create a model for calculating the effectiveness of RPA that fully takes into account all these factors, but this does not mean that this is not necessary and that such a model, although incomplete or preliminary, should not exist from the first days of the existence of the robotic program.
By the way, when calculating the cost, it is taken into account that the robot works 24x7, does not get sick, does not occupy a place in the office, it does not have to pay taxes and deductions to the pension fund, etc. - it turns out that the cost of the robot is quite comparable with the cost of the employee. And this means that living people should bring real benefits, doing interesting work, and not transferring documents from one folder to another.
If decision makers do not understand what an RPA is, why it is needed and why the company is engaged in it, it will not work far along the path of robotics.
Very often, the need for an agreed-upon RPA implementation strategy is underestimated, involving all levels of the company, from top management to the main performers.
This is especially important at the initial stage, when the program has not yet proved itself, and it is necessary to engage in its popularization.
Support must also be obtained from above: for the company to publicly support the introduction of robots, this was discussed at general meetings, units set automation goals, etc. But support is also needed from below: employees must understand that robots do not take away their work, but take away boring routine tasks, do not interfere in solving problems, but simplify their solution. The IT team must understand that their participation is not only necessary, but also necessary, the business must understand that they have a decisive word in how their processes will be robotized, the Security Council must be sure that robots do not create a gaping hole in security and etc.
In general, explaining to important people of the company why they need an RPA and how it will help them is probably the most difficult, but also the most important thing that a team will have to do.
Moving forward, not quite understanding why, where and how we are going to do this, it is a frequent, but, unfortunately, no less important problem.
Strategic development involves a clearly defined goal that the entire RPA team must share and which must be agreed with decision makers.
Such development should have benchmarks that are tightly tied to the time “by 2020 to make 10 processes”, “until the end of Q2'19, robotize HR processes by 50%,” “create a library of at least 50 reused components this month”, “ transfer 20% of automated tests in development to the RPA platform. ”
There should be metrics: NPS, saving FTE, recycling robots and so on.
Roles in the team, criteria for selecting processes, criteria for measuring success, and much more should be defined (or planned to be determined).
All of this, in aggregate, will help not only to understand whether the implementation of RPA in a company is moving well or poorly, but also to convincingly explain this to the interested authorities or the management of related departments. It will be much easier for people to participate in the initiative if they can clearly and clearly explain what it does and how.
So, if desired, the second quote for this item can safely put unforgettable
An RPA can be a powerful tool to help a company transform digitally, which means its robotics strategy should be part of its overall digitalization strategy.
But in order for robots to help the company move along the path to the digital future, it’s not enough to say the magic words “RPA”, “ML”, “OCR”, you also need to work a little bit to ensure that a friendly, motivated and purposeful team is behind these words having a clear action plan and support at all levels of the organization, from management to ordinary employees.
Of course, this is not easy, of course, in real life the abyss on the way sometimes seems insurmountable.
But, concluding the article with another quote from Karl Clausewitz:
In preparing the article used materials
Robotics have huge potential. Already, the RPA solves a whole range of tasks: migrates data, creates reports, removes routine from business processes, trains new employees, integrates different systems, provides multi-contact contact centers, automates work with primary accounting documents, replaces tools automatic testing and the list goes on for a long time.
RPA technology is not new, in one form or another, it is almost 20 years old, but the boom of development has been in the last two to three years, with the advent of new, strong players and large, successful projects, which saved companies billions of dollars and millions of man-hours.
Almost every introduction of new technology begins with a pilot project. The RPA pilot, as a rule, is easy enough and shows tangible advantages of the approach. But, as with many other technologies that require a major change in the approach to organizing production processes, the next steps for the pilot often cause psychological difficulties.
Often, a pilot RPA project ends with an MKHAT pause, a period of intense expectation, when it is already clear that the matter is necessary, but no one knows how to move from the first attempt to a serious implementation. Problems, primarily organizational ones, create an almost insurmountable chasm on the way, and often there is no clear way to overcome it.
In this article I will list the conditional top 10 problems that arise when implementing RPA and try to give some practical recommendations on how the RPA team can “grow its wings” and jump through this abyss.
So, how can you impede the introduction of new technology?
Take a tactical approach to RPA
Tactics without strategy is vanity before defeat.
Sun Tzu, The Art of War
The mistake is that when solving current problems with the help of RPA, we do not think about the strategic goal of our work.
On the surface, RPA is a lifesaver for those who have a lot of boredom in their work: transfer data from one system to another, compile a report on materials from several databases, automate the routine tasks of an accountant or administrator, etc.
There is a temptation to just keep the toolbox ready and, if such a situation is detected, start to ad-hoc robotize it, or, as they say, "write a script." But, the problem here is that in order to gain weight and significance in the eyes of company management, any initiative must have a clearly formulated global goal and a clear plan to achieve it.
Without such a plan, it is practically impossible to achieve the scale of the initiative, and without scale, no one in the big company will notice that there was anything like that, the RPA will remain a toy in the hands of administrators, who once flew the task of "see what kind of robots these are." But they won’t notice - they won’t help create a team, they won’t give the team money, they will write off the entire direction as unpromising.
To avoid this problem, by the time the pilot project is launched, you already need to clearly understand what goal the company wants to achieve with the RPA, have a high-level strategic plan with milestones, metrics, etc. Why not at the time of graduation? Because the choice of the pilot process, and the evaluation of its results - all this naturally follows from the choice of a strategic goal and methods for achieving it.
Implement RPA as a pure IT solution
War is a continuation of politics.
Carl von Clausewitz, On War
The mistake is that RPAs are perceived as a tool for the IT team, and completely transfer the whole initiative there without connecting a business and creating a cross-functional team.
We often see that the inertia of thinking makes people reason like this: “This is a software product, which means he has nothing to do with business. Let experts deal with him. ”
RPA, first of all, solves the tasks and problems of the business, optimizing and automating existing business processes in the company. Only the business knows what, where and how to do it, which means that the team involved in robotics must include representatives of those for whom it works, to know where the most routine and ineffective solutions are worth paying attention to first of all.
Or vice versa, forget about IT
Residents of the kingdoms of Wu and Yue do not love each other. But if they cross the river in the same boat and are caught in a storm, they will save each other, like the right hand with the left.
Sun Tzu, The Art of War
The business, remembering that IT people all the time requires answers to various difficult questions and generally hinder progress, decides that RPA can be done both on its own and by external contractors. At the same time, of course, the expectation that there will be no multi-month approvals, it will not be necessary to write documentation, request accounts and everything that interferes with fast and efficient work.
Of course, in almost any large Russian enterprise, the number of administrative procedures required to create a new product or service is amazing. But one must understand that this, most often, is not a whim and bureaucracy, but a real, vital necessity.
Implementing even such an “easy” and “simple” solution as an RPA, you still need to think about security, infrastructure, monitoring robots and a million other things that a business cannot do without IT. It’s not bad when a business tries to look at robots without waiting for them to come up with this initiative, it’s not bad when business users write processes for themselves, but, of course, within the company, don’t involve DIT in the initiative from the moment it starts - this is a catastrophe.
Without IT, you can forget about scaling a solution, about its normal support, not to mention the fact that robots often need to be optimized using APIs, Powershell scripts, integration with Python scripts and other things that are not clear to business.
And still have to overcome the syndrome " Not invented here", and at" IT "he is strong, like no one else.
Automation of the “wrong” processes
If you want to win, hit the very heart of the enemy.
Carl von Clausewitz, On War
A common mistake arising from the fact that after the first, successful step, the team thinks that she can do anything. Processes that are difficult to automate are selected, and even worse when they are randomly assigned for political or other reasons, without thinking about why this process gets to the RPA team.
When choosing processes for robotization, you need to dwell on those that can bring the most benefit at the lowest cost. But speaking of the benefits, it is worth considering that this may be one of many factors, the priority of each of which depends on a specific moment:
- Saving labor and other company resources
- Employee motivation
- Improving customer service
- Attracting teams that previously did not want to hear about the RPA
- Increasing RPA in the eyes of decision makers
On the other hand, there are several reasons why it is worth abandoning the robotization of the process, or at least how to think about it:
- Unprovable resource savings
- Unformalized business process
- Stealth process for decision makers
- Strong rejection of robotics by those to whom it is called to help
- Technical factors: the complexity of robotics, the system that they are going to shut down soon, problems with information security, etc.
At the same time, the most important selection criterion should always be one: the complementarity of the process of the strategic goal of the robotization initiative.
Try to achieve "total" robotization
War loves victory and does not like duration.
Carl von Clausewitz, On War
In robotics, the Pareto rule is true as never before. Most often, one or another process can be quickly robotized almost entirely, and then another month or two to fight over some “small” piece of it, which turned out to be difficult to formalize, or requires complex technical solutions in order to work smoothly.
In this case, it makes sense to ask ourselves whether we want to have 100% automation of the process or what we have already done is enough to bring benefits to the company and switch the RPA team to another task? It is almost always possible to rearrange the process so that the robot does all the “dirty” preparatory work, transfers its results to a person to make a decision, and then the robot performs routine steps to complete the process. We can say that 80% of automation is more than enough for most tasks.
At the beginning of the path of robotization, when the team has not gained enough experience, it makes sense to choose easily achievable goals that will allow you to gain confidence in your own abilities, gain weight in the eyes of the company, and you should not be afraid of compromise solutions.
Use inappropriate implementation methodology
War is an area of chance: only in this stranger is such a wide scope given up, because nowhere does human activity come into contact with it with all its sides like in war.
Carl von Clausewitz, On War
An error that occurs when they do not distinguish between projects on, for example, SAP and RPA.
Robotization gives the maximum effect where we spend much less time and effort on it than on “full-fledged” automation. And this means that it is necessary by all means to strive to ensure that robotization is as fast as possible, and the labor costs for it are significantly and provably smaller than other solutions to the same problem.
Most often, in large enterprises, this problem is expressed in the fact that any IT decision has been made to run through a series of checks and approvals, and the entire project should be carried out using a “hard” development methodology, such as RUP.
This approach, which has proven itself in creating and supporting large solutions, crashes on projects where the entire cycle should last 2-3 months. If the process can be automated two to three times faster than making all the necessary approvals, you need to change the approach, provide robots with the opportunity to pass checks faster, accompany them with less documentation, etc.
Where the Agile approach is already being used, at least for some products, it makes sense to find out whether development of robots cannot be attributed to this category either.
Where everything is still “serious” you need to devote a lot of time to training and explaining what robots are, what they eat with and why they need special treatment.
Underestimate the competencies and resources necessary for the full implementation
If the army does not have a wagon train, it perishes; if there is no food, she perishes; if there are no stocks, it perishes.
Sun Tzu, The Art of War
The consequence of the easy-going pilot is creating “dizziness from success”, and it seems that you can go further from victory to victory without putting any serious effort into it.
To create a pilot, you can usually download the free version of the platform from the Internet (for example, UiPath Community Edition or RPA Express ) and start creating. Using a team of two or three people is quite realistic to make and start the first process in a couple of months. But for a large company this is not enough, dozens of processes are needed that robotic business processes in different areas, running on a wide variety of computers, servers, virtual machines.
The beginning of a full-fledged implementation is impossible without gathering the backbone of the team, training specialists, obtaining the necessary resources, etc. etc. So, all this needs to be thought out, prepared and agreed upon in advance, it is necessary to find those to whom the task will be really interesting.
Often the complexity of this task is underestimated at the initial stages of the project, which, in the future, leads to unpleasant disappointments.
Incorrectly calculate the effect of implementation
From time immemorial, only great victories have led to great results.
Carl von Clausewitz, On War
The error arises when the effect of implementing PRA is calculated based only on the obvious metric - “FTE savings”. The problem here is that in our realities, where the salary in the regions is comparable to the cost of a robot license, this metric fails, leaving most of the processes below the line when a positive ROI can be obtained in 9-12 months (in the USA or Western Europe this is usually around 6 months).
Here you need to understand that the effectiveness of RPA is measured in a more complex way than just saving man-hours. It is necessary to take into account the fact that the processes begin to work much faster, unloading the multi-week “waiting lists”, and that the percentage of errors that were previously introduced by the “human factor” and the inability to add additional checks to the long and complicated process is reduced.
There are even more difficult to measure indicators, such as an increase in employee satisfaction with their work (which means fewer layoffs, which means less HR workload), improved customer relationships (their requests are processed faster and without errors), better process control and many other factors.
In the short term, it is difficult to create a model for calculating the effectiveness of RPA that fully takes into account all these factors, but this does not mean that this is not necessary and that such a model, although incomplete or preliminary, should not exist from the first days of the existence of the robotic program.
By the way, when calculating the cost, it is taken into account that the robot works 24x7, does not get sick, does not occupy a place in the office, it does not have to pay taxes and deductions to the pension fund, etc. - it turns out that the cost of the robot is quite comparable with the cost of the employee. And this means that living people should bring real benefits, doing interesting work, and not transferring documents from one folder to another.
Do not care about involving key employees of the company
The military must obey politicians.
Carl von Clausewitz, On War
If decision makers do not understand what an RPA is, why it is needed and why the company is engaged in it, it will not work far along the path of robotics.
Very often, the need for an agreed-upon RPA implementation strategy is underestimated, involving all levels of the company, from top management to the main performers.
This is especially important at the initial stage, when the program has not yet proved itself, and it is necessary to engage in its popularization.
Support must also be obtained from above: for the company to publicly support the introduction of robots, this was discussed at general meetings, units set automation goals, etc. But support is also needed from below: employees must understand that robots do not take away their work, but take away boring routine tasks, do not interfere in solving problems, but simplify their solution. The IT team must understand that their participation is not only necessary, but also necessary, the business must understand that they have a decisive word in how their processes will be robotized, the Security Council must be sure that robots do not create a gaping hole in security and etc.
In general, explaining to important people of the company why they need an RPA and how it will help them is probably the most difficult, but also the most important thing that a team will have to do.
Forget to make a clear plan
The hardest part is to better prepare for the victory; this is an inconspicuous merit of the strategy, for which it rarely receives praise.
Carl von Clausewitz, On War
Moving forward, not quite understanding why, where and how we are going to do this, it is a frequent, but, unfortunately, no less important problem.
Strategic development involves a clearly defined goal that the entire RPA team must share and which must be agreed with decision makers.
Such development should have benchmarks that are tightly tied to the time “by 2020 to make 10 processes”, “until the end of Q2'19, robotize HR processes by 50%,” “create a library of at least 50 reused components this month”, “ transfer 20% of automated tests in development to the RPA platform. ”
There should be metrics: NPS, saving FTE, recycling robots and so on.
Roles in the team, criteria for selecting processes, criteria for measuring success, and much more should be defined (or planned to be determined).
All of this, in aggregate, will help not only to understand whether the implementation of RPA in a company is moving well or poorly, but also to convincingly explain this to the interested authorities or the management of related departments. It will be much easier for people to participate in the initiative if they can clearly and clearly explain what it does and how.
So, if desired, the second quote for this item can safely put unforgettable
It is better to lose a day, but then fly in five minutes.
G. Grif, “Wings, Legs, and Tails”
Finally
An RPA can be a powerful tool to help a company transform digitally, which means its robotics strategy should be part of its overall digitalization strategy.
But in order for robots to help the company move along the path to the digital future, it’s not enough to say the magic words “RPA”, “ML”, “OCR”, you also need to work a little bit to ensure that a friendly, motivated and purposeful team is behind these words having a clear action plan and support at all levels of the organization, from management to ordinary employees.
Of course, this is not easy, of course, in real life the abyss on the way sometimes seems insurmountable.
But, concluding the article with another quote from Karl Clausewitz:
Without courage, an outstanding commander is inconceivable ... We consider her the first condition for a military career.
Source Links
In preparing the article used materials
- CSO (Strategy Director) UiPath Vargha Moayed “From pilot to full scale RPA deployment”
- Carl Philipp Gottlieb von Clausewitz , On War
- Song Zi , The Art of War
- Pictures of robots from Mobile Fighter G Gundam