Manual processes are slowly killing your business

We generate endless volumes of data each day in our dispatch and accounting systems.  Even more is found in unstructured formats, such as emails, PODs, load tenders and invoices.  Many paid hours are spent taking information from one format and rekeying it into one or more other disparate systems. This duplicated effort is not only expensive, but it opens the (large) possibility of errors through typing mistakes or missed documentation.

The reality is, many of the tasks handled by our operations, accounting and customer service teams are repetitive and prime candidates for automation. In general, any repetitive, rule-based task is a prime candidate for automation. So why haven’t they already been automated? Until recently such automation required a lot of expensive programming that resulted in systems that were not very flexible.  Simple upgrades of your dispatch system could cause the automation to fail simply by having a table renamed. When this happens, your team must revert to the old manual processes until the programmer has the updates in place. The other reason is human nature.

The growing list of portals and manual updates downloaded to today’s trucking companies is like compound interest. It started with a work-around to make one customer happy and has grown exponentially to the elephant in the room that no one wants to talk about.

Electronic data interchange has been used to try and automate the transfer of information. However, it has rarely been able to fully transform a manual task and create efficiencies. EDI protocols can be very rigid as it uses standardized and outdated formats. It is also expensive, meaning that most carriers or logistics companies are not able to invest what is necessary to use EDI to its full capabilities. The other challenge is that it is not necessarily in real time. Things like check calls are not readily handled and a POD request is likely still going to require a phone call or email. The result is many carriers can only justify the expense of EDI setup and maintenance for their largest customers, typically representing less than 30% of loads.

Web portals have become more common for 3PLs and some larger customers to attempt to get around the limitations of EDI. Early on, you undoubtedly saw these portals as a huge plus. However, they’ve quickly become a plague.  Documents such as PODs can be easily uploaded. Documentation supporting detention can be transmitted, and many can log comments when further explanation is required. However, they can introduce other inefficiencies. A human is still needed to transfer or transpose the information into the portal. Errors are still possible and very likely, despite best efforts. Depending on the internet speed where that employee is located, a lot of time could be wasted if your team member must wait for the information to get uploaded to the site and then wait again for the next screen to load.

The Institute for Robotic Process Automation defines RPA as “the application of technology that allows employees in a company to configure computer software or a ‘robot’ to capture and interpret existing applications for processing a transaction, manipulating data, triggering responses and communicating with other digital systems.”  In more practical terms, it’s software that you can “teach” to move information from multiple inputs to multiple systems without the help of a human. RPA is designed to be deployed in days or weeks, not months. It also does not care where the information comes from or where it goes. One of it’s strengths is that it does not rely on things like EDI or API’s to bridge into other systems or require complex programming to work.

Let’s look at a simple example that happens many times a day in your company. A customer emails a shipment request to your CSR team. The CSR is constantly monitoring their email for these requests. When they see one, they are likely saving, sometimes printing, the email to get the request on file. The CSR then creates the order and enters the shipment details. Once it is in your dispatch system, the CSR then logs into that shipper’s portal and enters the pickup date and time. Finally, the CSR replies to the original email to confirm that the order has been entered and received. Depending on how busy it is, each CSR may be doing hundreds of these transactions every day. Each of these steps could be automated by RPA. The robot can monitor the email queues more efficiently than a human can. It will parse each e-mail and pull out the new shipment information. That data is then moved into your TMS where it checks availability and schedules the pickup date, time and location. Because RPA is rules based, if there is missing information or any other exception, it will flag the appropriate CSR to handle it. Once there are no exceptions, the system will log into the portal and update it with the pick-up information.  Finally, it will generate and send the customer email confirmation. In this one scenario you can see that the CSR will now have time to work on higher value-added tasks, likely making their work much more interesting. The process will be handled more efficiently, and the possibility of errors is greatly reduced. The best part is you can implement entirely on your own, no need to get in the long queue with your TMS provider to complete on your behalf.

So, what should you pay attention to when considering an RPA implementation?  A recent CIO.com article gave 8 keys to having a successful RPA implementation.

1.   Do the Research – Frank Casale, founder of the Institute for Robotic Process Automation & Artificial Intelligence, recommends that you invest the time to build a business case for RPA and learn about the products available. There are three key boxes to get success and only having two out of three will not work. The boxes include:

a.       Choosing the right technology solution to meet your organization’s needs;

b.       Creating a solid business case for RPA, including developing ROI metrics;

c.       Assessing current processes and organizational issues to avoid political problems.

Keep in mind that RPA is a disrupting technology. People will fear that the technology will affect their jobs, possibly eliminating them. The human resources that will be affected are not going to be eager to train the robots that might replace them. A vision and roadmap for the future needs to be communicated and it should include new opportunities for displaced workers. Managers also need to go in with open eyes, a cautiously optimistic mindset. Management of expectations is critical.

2.   Educate Staffers About RPA – It’s important to clarify what the technology will and will not do with regards to employees’ job roles. Many organizations use RPA strategically by helping staff do routine tasks quickly and efficiently so that they can spend time addressing higher priority needs.  Determine how your company will use the technology and then honestly communicate what that vision is so that you get people onside with you before rolling the technology out.

3.   Determine Where the Technology Will Work Best – You will want to identify processes where you are most likely to see a positive business impact. Keep in mind that it will not always be easy.  However, as the organization becomes more experienced with RPA, other processes will more easily be uncovered. Many successful implementations are very selective as to what processes to automate—look for something that it repetitive and frequent. Once you have achieved some initial success, fight the urge to try and automate everything. If a task can not be done without a very limited amount of human interaction, preferably none, then it really is not a suitable candidate. When picking your first process, remember that while cost reductions are important, improving customer experience is even more valuable. The client experience is what will be your competitive advantage.

4.   Keep It Simple and Modular – RPA works best when it is not complex. As much as possible, keep your bots as generic, common and reusable objects. Mona Kahn of Fannie Mae recommends that you externalize all variables and logic to minimize failure points. This makes it much easier to update when something changes and makes it much faster and easier to test before putting the changes into production.

5.   Don’t Neglect Data Security – Make certain that processes can not be manipulated. Start with any processes that are business or mission critical. These must be secured before any implementation is attempted. Regardless of how critical a specific task is, keep in mind that RPA will process much faster than a human can, so ensuring that a bot is secure must happen during the testing phase and this should be a show stopper if it is not secure.

6.   Test Implementations Regularly – Notwithstanding what we just discussed, testers can only try to test so many points of attack. Weaknesses are going to appear once the robot has gone live.  Keep in mind that individual testers may not be as experienced with a process and may only be looking for positive results. If possible, include the staff that actually do the task in the testing phase. Additionally, test the automation on desktops running legacy systems to ensure that the desktop will be capable of handling the infrastructure requirements. It is critical that you understand how different bots work together so that processes do not break.

7.   Develop a Cross-Functional Center of Excellence – By this, I mean put together a team that will share experiences and best practices to other parts of the organization. The idea is to leverage previous efforts to ensure that the wheel does not get reinvented repeatedly. Make sure that both failures and successes are documented to make certain that the knowledge of those experiences is not lost.

8.   Prepare for Future Advances and Challenges – RPA is going to advance, and each company must keep up with the changes. Eventually, each organization will struggle with the management of the automation. End users will find ways to automate desktop processes for their own use, so understanding how the introduction, elimination or upgrading of enterprise applications will affect these deployed bots will become increasingly critical. Like any other asset, bots need to be tracked and managed so that they can properly be maintained. Consider what would happen if a password policy was changed for one of the applications the bot uses and how would you know if data is not being properly passed though?

So, what’s driving the implementation of RPA? The obvious one is cost reductions. Forrester Research estimates that about 16% of US jobs could be replaced by RPA by 2025, while creating new jobs that are equivalent to 9%, meaning a net loss of 7% of jobs. This is because bots are generally low cost and relatively easy to implement.

In the financial services sector, there is a major shift away from manual, clerical-type jobs and a move towards more analyst or advisory jobs. The shift is being fueled by the vast amounts of data that RPA is creating, resulting in customers needing more human advice to help them process it.  In some cases, bots are assisting the human advisors by identifying patterns and offering options that the advisor can then present and explain to their clients.

There are several companies that have experience in working with our industry.  These include:

• Kofax with it’s products that include Kapow, TotalAgility and Information Capture
• Pega with it’s Pega Infinity digital transformation suite
• Jacada with it’s Jacada Agent Desktop Automation
• Automation Anywhere has it’s Automation Anywhere Enterprise Suite
• UIPath – the UIPath Enterprise RPA Platform
• Nintex Platform – utilizing Promapp, DocGen, Xtensions Framework and Hawkeye application
• IBM – Robotic Process Automation with Automation Anywhere

For those with an in-house development team (even a small one), building your own RPA toolkit and ‘army of bots’ is possible. There is even an open-source development framework to get you started. This Python-based framework, Selenium, is used thousands of companies all over the world. Worth examining if RPA is on your to-do list for 2019.

As a real-life example, Kofax has publicized a successful implementation with Crete Carrier (see the full case study here). Specifically, Crete automated their appointment scheduling process because they previously only had CSRs available Monday thru Friday even though their business is 24/7.  If a shipment tender came in on the weekend, it would sit there until someone came in on Monday morning. Meaning that some of the shipments would have been missed, and the shipper might have ended up using a different carrier.  This is likely a scenario that you have all have faced at one time or another. Crete created Kapow robots that handle a range of information about the shipment. The bot then uses those parameters when it receives a tender and uses them to pick an appropriate pickup or delivery slot.  In most cases the bot can schedule an appointment on the first pass. If it is unable to find one, it then passes all the information that it has received to a human operator who can establish a new set of criteria and have Kapow take a second pass at it, with additional human help if needed.

Crete also uses RPA to enhance visibility of its freight as it moves across the country. It uses a near real time tracking of trucks, trailers and what freight is on each trailer. Previously they would need to send an employee to inspect a trailer to see if it was available, even if it was reported on a yard check because of the difficulty in going through numerous e-mails or reports. Kapow can go through all the reports and emails and give the operations staff the location and status of equipment as they need it.

A third use is allowing Crete’s customers to have improved freight tracking. Dedicated web portals are used to keep certain clients informed as to where their freight is. Staff would have to manually update the portal information, a time-consuming task that resulted in information-delivery delays. On off-hours and weekends, the customers knew that the portals were not always up-to-date, resulting in more calls to the customer service team for load tracking. The introduction of bots to this process have resulted in updates happening instantly, resulting in happier clients who now have faith in the portal information. On the back end, it eliminated some very tedious tasks, freeing up the customer service team to spend time on other tasks with a more strategic focus.

The use of RPA has allowed Crete to book freight further in advance, allowing them to have greater access to delivery slots that work for them and maximizes their meeting delivery targets as well as maximizing their effective use of rolling assets. Additionally, they have found that staff were able to be dedicated to more customer-facing services instead of only having the time to handle routine tasks. A better customer experience and a more efficient way for Crete to run the business are two major results.

Any of the companies or open-source packages that offer RPA tools, can allow your company to achieve similar or even greater success. The key is to know what it is that you want to accomplish without a defined project scope there is a significantly reduced likelihood of goal achievement. In fact, without spelling out what will constitute success and how to measure it you are probably dooming the project to failure right at the start. It also means that you are more likely to use someone or something other than the optimal solution provider. Similarly, the management of expectations is another critical component. In the example above, Crete has been using RPA for over four years. Your people need to understand that it will take some time to optimize and implement these bots. If someone is offering to come in and “have you up and running in a week”, be very skeptical and ask some very pointed questions as to how that will happen. It is possible that they have extensive industry specific experience and have semi-customizable templates that can get you implemented quickly. If they tell you that “customer service is customer service” then they probably are not going to work. A quick example is from the scheduling process used by Crete. If an RPA provider does not understand how HOS can impact appointment times, then they may program a solution that ignores the mandatory break after being on duty for 8 hours. A lack of industry experience does not have to be a deal breaker, but it will mean that your project team will have to spend more time and be more explicit in their requirements and specifications document.

So, in summary, some quick takeaways on RPA are:

• Robotic Process Automation is a potential game changer for our industry, possibly causing a revolution in how we handle routine customer service tasks.
• People are going to be afraid of losing their jobs when they hear the terms “robot” or “automation”. Expect that reaction and have education and communication resources prepared to help people get over those fears.
• The potential for head count reduction is there, but it should not necessarily be the driving force behind this initiative. It is more likely that you will be able to handle more productivity out of the same number of people.
• The ability to cover off-hours without having to add to your head count is a very real possibility. If things like location requests, driver direction requests or load tenders are why you are considering adding or maintaining off hours staff then this may be a lower cost solution for you.
• Do not treat automation as an ad hoc process. Have some form of control over where bots are implemented and try to use common programming as much as possible.  This will allow you to know what needs to be updated when other systems are upgraded. Additionally, it will greatly reduce the time needed to develop fixes when problems arise.
• Start with processes that occur regularly so that you have a few highly visible wins to the start of the project.
• Expect there will be setbacks. Many of these processes have dependencies and it only takes one to cause a failure.  Involve the people who currently do the job in the testing phase. They will have seen the process breakdown before and can offer insights as to where to challenges may come from. This in turn will allow for more robust testing pre-implementation.  It will also increase the acceptance of RPA as they will have some say in how it is implemented.
• RPA is not a magic bullet. Managing expectations is critical.  Exceptions are going to happen. Crete considers having 40 to 50% of appointments scheduled by the bot a success.  Other processes may achieve closer to 95%. Some processes may require human interactions. Your team needs to be prepared for these to happen.  At the same time, let them know what that 40% means in terms of freeing up time to handle their other tasks that might be getting pushed off to the side.