Part 2: Can Robotic Process Automation (RPA) save IT?

This is the second part of two-part blog topic. If you have not already read part 1, you can find it here.

As the divide between digitally transformed companies and all others continues to widen, the gap between IT and business within those companies is often a strong corollary. Business analysts, account managers and other advocates are often the only linkages between these groups on the operational level. Technologists often do not work directly with the end users or customers for the systems they are building. Business people do not know about the tools available to help them with their job, or how to use them. Silos and/or a throw it over the wall mentality often result when there is only this slim level of integration. Shadow IT efforts can form and the IT department often gets a bad reputation for being out of touch with the business.

Even if you agree with what I am saying you are probably wondering by now, what does any of this have to do with Robotic Process Automation (RPA)? RPA works directly on the systems that you are already using so it does not require anything from IT and it does require a good knowledge of how the business works. This means that RPA can be a great tool for use by technically astute business resources. Most IT departments are starting to recognize that their business teams can bring in RPA completely on their own and get it up and running in production with little to no support from the IT team. The good IT departments are seeing this as an opportunity rather than as a threat.

Small, cross-functional teams comprised of technologists from the IT department as well as tech savvy individuals on the business side that understand business processes and operations can combine to form the ultimate team for implementing RPA tools. The teams can be as small as two people but should really be no larger than 4 or 5. This combination allows a paradigm shift to provide focused thought on solving targeted business problems rather than how to adapt existing technologies to meet poorly understood needs.

The highly visual and easy to understand development interface provides a way for teams to easily work together and track and understand the overall progress being made. Business users can be on equal footing with those from IT because their lack of development skills and experience is no handicap in this case and they already understand the business process.

The approach that we have seen work very well is to “lock” the team and other stakeholders in a room before determining which business process to start with for improvement and automation. It is important to have the right decision maker in the room to allow that final decision to be made in that initial meeting. This combats the very common problem of not knowing where to start and starts the ball rolling. After that initial meeting, the team should be allowed to work independently. We find that most projects approached in this way can be ready for production within 6 weeks.

The common showstopper for a project like this is that any time integration with existing systems is required, you must go back to IT so that they can handle the integration work. Integrations with old legacy systems are often time consuming, dangerous, and sometimes impossible. There are often limited resources available with the right experience to tackle these problems which complicates things even further. Using RPA skirts around the issue because integration can be done through the existing user interface. This is a quick, low cost method to access data and business rules trapped in old systems, can allow for quick pilots and POCs at a greatly accelerated timeline and a much lower cost than has ever before been possible.

Another huge benefit is that it is typically very easy to show a documented ROI for these projects. Normally, the fact that companies often do not know the true cost of an activity in the first place makes it impossible to show conclusively how much money has been saved through automation. For RPA projects it is usually quite easy to contrast the cost for automation against the employee costs associated with performing the tasks in a manual way. This can be more difficult for “ad hoc” processes that are not well understood or tracked but using RPA as a monitoring process can be especially useful in this case. Business processes that are not fully documented or understood can be “instrumented” using RPA in order to provide some baseline data to measure the value returned through process automation. Of course, this step is not necessary in cases where the baseline is already well documented.

There is certainly much more to be said on this topic but I hope this encourages you to take a look at using RPA tools with small teams as a way to move forward your digital transformation agenda.

Do not forget to watch our on-demand webinar on how to orchestrate work between humans and bots.