“Storms make trees take deeper roots” – Dolly Parton
The storm brings changes and changes aren’t easy, but it could be the first step to a better place. This approach is an abrupt and proactive action to a new reality.
In this article, I want to show the essay of a strategy that I have been designing, called RPA Storm.The main objective is to use the ‘quick wins’ and bring a quick economy to the business through RPA. This strategy will cause immediate impact and it should be seen as a strategy of short-term, aiming at the pursuit of a specific goal.
I had this sudden insight when verifying that in many situations we need to act fast and it is necessary to have quick wins, in order to gather sponsors support for a second wave, where it is possible to adopt a more robust strategy. Although it is not the RPA Storm purpose to be a long-life strategy, the implemented code could be refactored generating a more sustainable implementation. In other words, this strategy can be adopted in order to use the first wave savings to sponsor the second wave.
Inspirations
Pixar has plots are an undoubtedly successful and the construction of this plots are complex projects, Emma Coats has published 22 rules of storytelling and some of those rules fit with this strategy.
One of those struck me,
#8: Finish your story, let go even if it’s not perfect. In an ideal world you have both, but move on. Do better next time. (Emma Coats)
Using the RPA Storm strategy, we know that we will not create a perfect solution and this is not the goal, but this strategy can give us the opportunity to build something really sustainable after having won the sponsors or stabilized an environment. “We will do better next time”.
Pareto Principle
Although it is a well-known concept, I would like to remind of the Pareto principle, which was one of the concepts that inspired me in this idea and which corroborates with the strategy proposal.
The Pareto Principle is also referred to as the 80-20 rule, the law of the vital few, or the principle of factor sparsity[1, 4]. It states that for many events, roughly 80% of the effects come from 20% of the causes.
The main point of the Pareto principle is to recognize that most things in life are not distributed evenly. This strategy has much of its foundation based on this concept, mainly because we want to use the least possible effort to achieve the maximum result, understanding that the effort and gain are not evenly distributed.
RPA Storm’s definition
RPA Storm was designed aiming to provide a quickly saving through the massive use of RPA, by means of automating longest manual processes committing the least possible development effort.
Coefficient
Thus, I have created a simple coefficient that must be used to prioritize and define what should be done:
C = coefficient
DT = Development Time
MT = Manual Performing Time "Annual"
C = DT / MT
For the processing time, it is necessary to use a standard time of measurement. We will adopt into examples, yearly measurements.
Example
'Task [X]
---------------------------------------
DT = Development Time
MT = Manual Performing Time "Annual"
Coefficient = DT / MT
Coefficient = 7 / 240
Coefficient = 0.029167
'Task [Y]
---------------------------------------
DT = Development Time
MT = Manual Performing Time "Annual"
Coefficient = DT / MT
Coefficient = 10 / 400
Coefficient = 0.025
'Priority
--------------------------------------
1) 'Task Y - 0.025
2) 'Task X - 0.029167
Setting Targets
In order to start the process we need firstly set a target, for example, let’s supposed, you have an overstaff of 10 people who work 8 hours a day, in a month you have a deficit of 1600 hours. So my target could be 1600 hours, in other words, I need to automate 1600 hours. Certainly, you may have other reasons to define your target, however, in this example, I will use overstaff. You could, for example, use this strategy to reduce the overtime or even as a proof of concept. Undoubtedly, there is a huge range of reasons and goals to use this approach, but the crucial point is to set a target to orient your effort, even more, define the target should be the first action.
Establish the target is necessary to discover, map and gather the activities that may be automated. Notice that I used the word activity, instead of process, because we will not really focus on the process as usual. A typical RPA project aims to automate a full process, however, we want to automate 1600 hours and we do not care if they are in sequence or if they are isolated activities. What we want is to use the slightest effort in order to achieve the higher return. In overstaff, after we achieve the target we will need to rebalance the activities in order to release resources.
A frequent activity that comes up to me is people spending hours to create new reports through data consolidation. These are typical cases that we can automate effortlessly. Using RPA Storm idea you will notice that in many cases we will use automation as a tool to support human activities and not as a touchless automation that seeks extinguish the job human intervention in the process.
Let’s suppose, that a person spends 1 hour a day to consolidate this information, so in a month with 20 working days we will have 20 hours and in a year we will have 240 hours. It looks like an extremely small gain. Nevertheless, imagine that to automate this we will spend only 2 hours. Well, that is the ace in the hole of this strategy.
Mapping Activities
Now, it’s time to go to the operation to gather information about the activities. The idea at this point is to reveal activities from the operation, thus, it’s interesting to do it from the operation perspective, not only based on a point of view from leader or manager. I recommend you trying talk with all the team. Try to start, gathering the requirements, from the lowest grades, because there you will find more simple activities to act and you will understand all the activities from the bottom to up. That probably will facilitate the process to you, since the complexity will increase gradually together with your knowledge about the process.
As you will be immersed in the daily work activities you probably will notice that you can make savings even without RPA. So, don’t hesitate and let the client aware about the situation because in the RPA Storm we will enter in the client to cause an impact, we need to be agents of change not only RPA providers.
Grouping Activities
Many people can repeat activities, sometimes even call them by different names but they are essentially the same thing. For this reason, we have to group these activities and calculate the time grouped to understand our real saving. Therefore, we can reuse the implementation bringing the development time, for repeated situations, to zero.
Estimating development
Once all activities have been gathered, it will be necessary to estimate the effort to develop an automation. The scopes must be limited and should only focus on specific parts of the process, it is not intended to automate all possible process flows because this is not the goal of the strategy.
These automations will have a small life cycle and for this reason, it should be borne in mind that refactoring is inevitable. Estimates must be made quickly and for this reason, we may end up having imprecise estimates. It’s important to select an experienced team to use this strategy, of course, doing it the outcome will be more accurate.
I recommend using a divide-and-conquer strategy to split your activities into smaller actions until all development tasks are less than one workday. This will help you get a clearer picture and the mistakes will be less because you will have a deeper view of what needs to be done.
Another technique that I like is to use fixed values: 30 min, 2 hours, 5 hours and 8 hours. For example, an activity that supposedly will take 1 hour and 16 minutes in accordance with the analysis, must be estimated at 2 hours.
After all, why estimate using fixed values? Let’s pretend the following situation, you have a dog and a lion. Now think which one weighs the most? The interesting thing about this though is that even though you did not know the exact weight, you know one thing is heavier than the other.
Cost-benefit Matrix
At this point we already have the two data needed to generate the cost-benefit matrix, now it is simple, we must calculate the coefficients and select the activities from the lowest coefficient to the highest until achieving the target.
An agile methodology adheres very well to this kind of environment, mainly because it fit an extremely volatile environment. Another important point is that we can have continuous deliveries of value since we have a lot of small implementations.
There is no doubt that continuous delivery of value is something that must be done in order to have an impact since the beginning of the project.
Planning the Future
After the previous steps have been completed and the automations was already delivered, it is crucial to plan the future of these processes since these automations have a short life cycle, therefore two alternatives are possible to the future: refactoring or complete replacement.
Fact is, this is an impact strategy and it does not aim to be sustainable or have completeness. What we are looking for is quick saving. It is not a strategy indicated for all situations or environments.
Therefore, is better to start a project being honest with the stakeholders. Because if your client wants a quick saving and you cannot guarantee a scalable, robust and sustainable structure, still, you can provide a strategy to achieve the client expectation and preparing the environment to the next steps. Thus, RPA Storm allows you to deliver value and increase gradually your automation’s environment, assuming that we are creating something valuable, but temporary.
Source: Robson Fernando Veiga (linkedin) – RPA STORM – The Strategy
