THE ROBOTS ARE COMING!
Here’s how you can be ready for them
Christopher Hill,
Director-Automation
Windstream Communications
IN CASE YOU haven’t heard, robots are back, and back in a big way. Actually, they never left us, but they’ve definitely surged in popularity and features over the last few years. Today’s robots could give R2-D2 a run for his money.
It’s important to note, however, that I’m not talking about mechanical or physical robots, like the kind that serve you drinks in a galaxy far, far away, or even the kind that build cars on assembly lines here in our own galaxy. I’m talking about software robots that operate computer screens. For those of us in the software development business, the official term is “Robotic Process Automation,” or RPA. I have 20 years of experience in software development, and today I work with a team of RPA software developers at Windstream Communications. We build robots that automate processes.
What is RPA? At its root, it’s simply a macro-style program, or software that emulates a user interacting with a computer screen. A basic macro program records your computer screen as you carry out some operation, such as entering data into a spreadsheet. The macro tool converts the recording into a computer program that can automatically repeat that action in the future, with little or no human involvement. RPA is an evolved version of that.
The RPA of 20 years ago used the position of objects on a computer screen to pilot the automation from one step to the next, like using a road atlas to get from Jonesboro to Conway. Today’s RPA communicates directly with the code of the application to navigate through its user interface, which is more like using a live navigation app. I-40 is a parking lot between Little Rock and Conway? No problem, let me find a better route. In other words, modern RPA comes with a full suite of built-in application integration tools. Beyond keystroke emulation, RPA can communicate directly with other systems using the same technologies modern apps use to communicate with one another, like dblinks and RESTful APIs.
So whether you’re an employer interested in streamlining operations, or an employee considering a new career, let’s talk about what kinds of jobs robots are perfect for. Employers first: Are there people in your office manually typing orders/tickets/requests into systems in medium to high volumes? Are they swiveling between multiple systems and data sources to get this done? Do you have integration or consolidation work in your company’s IT pipeline that will ultimately reduce the need for repetitive data entry (assuming someone actually gets around to it)?
If you answered yes to any of these scenarios, chances are your company could benefit from RPA. Any process that is manual, well defined, and repetitive is a great candidate for RPA. But even if a particular process isn’t well defined or highly repetitive, it may still be a good candidate for robotics. Beyond the simple automation of a task or process, RPA can also serve as an opportunity to define and standardize a process that may be out of control. And we’ve all got some of those, don’t we?
You may believe that traditional integration of your applications is the more long-term and strategic approach to solving your data entry and process problems, and you’re not necessarily wrong. But don’t rule out robots just yet. The key to RPA’s success is that it’s non-invasive—you don’t have to change and test the application code of target systems to implement RPA automation and integration on and between them. Think of RPA as arthroscopy and traditional integration as open surgery. With RPA, nobody has to open the target system and operate on it for you to build the automation. That means the application development team (for the target app) can continue working on their high priority projects while you automate around them without impacting their timelines. The payback period for many RPA projects is months, not years, so if your traditional integration is on your roadmap, but not in the near term, go ahead and build the RPA as a short-term measure and replace it when the time is right. Bonus number one: The RPA automation will standardize, document, and bring consistency to your process. Bonus number two: Any integration code built to enable your RPA, like SQL queries or API calls, can be reused later to the benefit of your future integration project.
RPA is not industry specific; determining fit relies on analysis of the process—if it’s manual, repetitive, has low variance, and handles a medium to large volume of data, it’s a good fit. If it’s programmable and will save somebody time so they can focus on creative work or critical thinking tasks, it’s a good fit.
If you’re an employer, you’re no doubt wondering how much RPA costs. Most of the enterprise-strength RPA platforms come with licensing fees and obligations. Open-source options are available, but these will require more technical bench strength on your team. In any case, when done right, RPA projects pay for themselves quickly. A good RPA project can be delivered in weeks or months, not years. Why? Because RPA is perfectly suited for agile and incremental development. Your process might have 90 steps, but that doesn’t mean you have to automate all 90 of them before you can deliver value. Find the five most expensive steps and start there. Build, deliver, and measure—are you saving time and money? Find the next five most expensive steps and go. Learn by doing.
So how do you estimate ROI for RPA? Start simple, find a high-volume process, and figure the average amount of time it takes to complete it. Estimate the percentage of the process you believe can be automated. Find out how many of these transactions you process each day/week/month. Use the average wage of the team currently executing the process to determine the gross value created. Run this value out over some number of months or years and offset it with the cost to develop the automation, plus any licensing and other costs. (Your process will still have some fallout and you’ll need a small group of people to work the fallout, and other people to support the automation platform if it falters or if your underlying process changes. You also may need infrastructure if you deploy your platform internally.)
Now you need to measure. Make sure you’re processing the number of transactions you projected and that your fallout rate is at or below expectations. This measurement and reporting should be much easier now because you have the data resident in your automation platform (another bonus!). If all is good, keep going. If not, make adjustments to get it right, but don’t be afraid to write off your sunk costs if necessary. If you misjudged the automatability of your process, learn from your mistakes and find a more suitable process; redeploy your licenses so they can be leveraged for productivity. Such is the nature of agile development, and thankfully you only attempted to automate the first five steps of your process instead of all 90 before you learned this, right?
*
NOW, IF YOU’RE an employee instead of an employer, you’ve probably been reading this article with some trepidation. In the old days, when we thought about robots it was all in the fun of science fiction. Today, the subject can be fraught for a lot of people, who increasingly worry about being put out of work by them. It’s true that robots can do some jobs faster and less expensively than human workers. At the same time, they can provide a more stimulating, better-paying life for people trained to work with them. That’s what the Arkansas Center for Data Sciences means when they talk about “Life empowered by data science.”
Being proactive is key here. To be a good robot programmer you need some background in coding. You don’t need a degree in computer science, but you do need to master some fundamentals in order to get going. Assuming you don’t already have a coding background, you might start by recording a few simple macros of your own using Excel. Then open the code generated by Excel and see if it makes sense. Tweak the code to make the program do something slightly different. Modify it further to accept different values into a variable. You’re doing all this to see if you have an aptitude for programming, and to find out if you enjoy it.
If you do, take it a step further and download an open source tool like AutoHotKey to expand your skills. (Quick word of advice—check with your employer before you download and begin using AutoHotKey at work!) Focus on automating some of your own daily tasks, like starting up applications on your desktop. While the robot starts your apps, you can spend that time reviewing your calendar and getting organized, or maybe doing something more fun.
If you have success with that, take it a step further: Talk to your supervisor about the potential for automation within the team. Get some training in computer programming. Open an account at https://www.codecademy.com, or look for classes at a nearby university that are designed to provide non-traditional students with hands-on training.
But if coding isn’t your thing, that’s okay; it’s not for everybody. In this case, your focus should be on process, as in process documentation, processes stabilization, and process improvement. Do you have valuable and unique knowledge about processes within your company? Chances are you do. So start thinking about how your processes might be automated, which tasks within the process are good candidates for automation, and which tasks need to remain with humans. Document your processes with flow charts, and write down detailed instructions for each step along the way. You’ll probably have to interview and shadow others in the company to put together the whole picture. Quantify and measure the output of the process; if it yields inconsistent or poor results, it may be out of control.
You’ll probably find that different people have different ways to execute the same process, but if you can become proficient at documenting and standardizing processes, you’ll have an important role in robotic automation. And if you can become effective at stabilizing and improving processes, your role in robotic automation will be critical. So consider getting training in Six Sigma, and read up on Continuous Improvement. Become the de-facto end-to-end expert for as many processes as possible at your company. Become the employee who can identify and imagine the best process targets for Robotic Automation, and who can supervise and ensure the effective transition of a process from manual to automated, and you can lock in your role as a critical player among both the robots and the experts who deploy them.
*
REMEMBER, THE P in RPA stands for “Process,” and Robotic Process Automation yields the best results for processes that are stable, well documented, and optimized. Ironically, the practice of implementing RPA can in turn yield processes that are more stable, better documented, and optimized—but only if your RPA team includes disciplined process experts. This is critical for employers and employees alike. If you simply throw a bunch of coders at a bad process and ask them to automate it, they will do it, with energy and enthusiasm, because coders love to code. But then you’ll have an RPA implementation that churns out bad results much faster and in much larger volume than were ever possible before. So, word to the wise, lead your RPA initiative with process expertise.
If you do that, you’ll enjoy all the benefits that RPA can bring to an operation. Robots can run 24/7 if your systems allow it. They don’t need breaks, and they don’t get tired or confused. They also tend to complete tasks faster than humans. After you automate your process with RPA, the output and results will become much more consistent, and if you’ve done a good job, your data will be whole, clean, and accurate. And for you employees, RPA can give you time to focus on more rewarding strategic and knowledge-centric work.
Is RPA better than R2-D2? No, for those of us who grew up in the ‘70s and ‘80s, R2-D2 is still better. But RPA is a proven and growing technology that can drive great outcomes for both employer and employee.
Comments