Work force automation framework

“I think we know where to apply the robots. We have spoken to our teams and here is a list of areas that cause a lot issues.” This is typically how the story of Work Force Automation (WFA) or robotics usually starts. If this narrative was provided to the technical team, they would most likely start building and implementing the robots (no offense to anyone out there implementing robotics). These teams rely on the business to make sure that the right parts of a process were selected for automation. And this is the point where typically things go wrong. So, yes, there is a formula or defined set of steps that needs to be followed in order to ensure success. By success, I mean measurable and quantifiable returns for your investment in a automation using robot. Here are steps that can help mitigate risks with Work Force Automation.

Step 1 – Finding Opportunities for Robotics

Generally, there are two options for finding ideal opportunities for implementation of robotics:

1. Identify processes or transactions that are either high volume, have substantial resources assigned to them (high cost), miss SLAs or result in complaints. You get the idea … start with a process that is either high in cost, or results in dissatisfaction.
2. The other option is to provide a platform for business leaders and SMEs to give you their list of pain points. At this stage they don’t really need to know that you can leverage robotics as an improvement tool, rather you are looking for improvement opportunities.

Step 2 – The “Fit” Test for Robotics

Not every poor performing process is a good candidate for robotics. As a matter of fact, automation through robotics should be the last strategy we leverage to deliver efficiency after we have exhausted all other options. I will explain my position a little later on. You can do a quick “fit” test to eliminate some of the opportunities you discovered in Step 1. If you answer YES to any of the questions below, then robotics is NOT a viable option for improving client experience or efficiency:

1. Can this process be automated using existing tools/applications? An example may be that the system supporting the process actually has the capability to automate certain steps, or eliminate tasks. Analyzing the process can provide you with the opportunity to explore enhancements to a system that were not considered in the past.
2. Is the process highly customized? Another way of thinking of this is to explore the lack of standardization in a process, i.e., does it change depending on the request type, region, employee, etc.? Robotics is successful in cases where there is a repeatable set of steps & rules.
3. Does the process rely on data that cannot be easily accessed from a viable source? Access to structured and available data is key to automation. If your data resides in image format, then the robot cannot access it in order to complete its required tasks.

If your opportunities pass these tests, then it is time to pick your top 2 – prioritize based on either the current cost associated with the process (volume x labor cost x amount of labor applied) or the risk of resulting in negative customer experience.

The final phase of Step 2 is to process map the life cycle of the transaction and collect operation data. A best practice is to map the entire process, from where it starts all the way to the step that deems the process complete. So, if you are documenting account opening, the process starts from the minute that a customer initiates the process online or in the branch, all the way to the time that all their services and products are delivered/activated. Think value stream. While documenting the process, also collect data that will help you baseline current performance. You will need this data to prove that post automation value has been delivered. Here are a few examples of data to collect:

1. Total cycle time of process – This is the total time it takes to start and finish the process. It will include all the waiting, reviewing, re-routing, approving and working on a request.
2. Total Touch Time – This is the total time employees actually spend working on a request. So it excludes all the wait time (waiting for additional info, approval, review…)
3. Percentage of time a step is reworked – If there are QA/QI steps, capture how often the work is considered incomplete or incorrect. Any time work is stopped so that it can be re-worked, re-submitted, rejected, re-contacted then we are adding cost to the process. We need to capture how often that happens.
4. Head count – How many people are involved in the process and what percent of their time?

You are now armed with unbiased data to make your decision for automation. What makes a process, or a step in a process a good fit for robotics?

1. The process or step is highly manual
2. The logic used to complete the task(s) are repeatable, i.e., we can replicate the logic with code

Step 3 – Should you automate the process as-is?

This step is most often overlooked, but it is here where the true value of automation can be realized. Redesign the process to ensure optimal flow before automating. Work force automation through robotics isn’t just about digitizing work as it is done today. Rather, it is about delivering efficiency through seamless flow. I have never, and I mean never, implemented robotics on a process as I found it. Once I am done with step 2, there have always been discoveries about how work can be done better to either improve client experience or to deliver cost reduction. Take the time to re-imagine how work can be done and then use robotics to take over the repetitive & highly manual steps.

Step 4 – Technical feasibility assessment

We now know where we want to apply the robots and what we want them to do but that doesn’t mean that it is possible. THIS is the point where the technical team really gets involved. By explaining how work gets done today, how we want to work in the future and what tasks are to be completed by the robot(s), the technical team can determine feasibility. By “technical team” I am referring to two separate groups – the application owners (the systems that will be impacted by the robot) and the people who actually know about robotics capabilities & coding. Once there is agreement that the robots can push and pull data from the target applications, then we are good to go.

Step 5 – Building requirements, coding & testing

Building a requirements document, is like developing the architectural blue prints of a new building. It should outline:

1. What data/input is needed and how it will flow
2. What tasks will be completed
3. The frequency at which “jobs” will be run
4. The logic, sequence and workflow of the robot

Once signed-off, the development and testing can begin. You may need one or multiple robots to automate sections of a process. That decision is left up to the technical team and is based on the complexity and frequency of the tasks in need of automation. By the time testing is taking place, there should be enough data to validate if our estimated savings will be realized.

Once the robot is in full production there are other critical factors to think through, such as change management, training and general governance of the robots – but let’s leave these for another article. There is a reason that over 50% of robotics initiatives fail. This is because we start with the technical solution in mind. Instead we should let the process mapping, data collection and analysis guide the discovery of where workforce should be automated. Just because we can automate something, it doesn’t mean that we should. Hopefully this framework will help with your future automation endeavors.