Will Robotics (RPA) Replace ACL?

In my last post, I described Why Internal Auditors Should Care about Robotic Process Automation.

In this post, I’ll explore whether RPA can replace analytic packages like ACL, IDEA, R, and Power BI.

That might seem like a strange question, but a few managers and a VP have asked me just that recently. Here’s how I’ve answered it.

Please note that in this post, unlike my previous post, I’m only addressing robotics use in internal audit as it applies to analytics, not as it applies to the typical business operation (even though some of the same points would apply when comparing robotics to python scripting, Power BI, etc., to accomplish business operations).

Also, when I refer to ACL, I am including IDEA, Power BI, R, and any other analytics software used for analytics. I’m just saying ‘ACL’ as a shortcut, and because that’s what most auditors use.

Will RPA Make ACL DOA?

Here’s my answer:

No!, not in most cases, because:

• Robots require a well-defined process that is rule-based. How many of your analytic projects meet that criteria? Not many of mine, either.
  Also, many analytic projects are one-time projects. Few are well-defined, at least not from the start. Once you have it scripted in ACL and it is well-defined, maybe robotics would work. But if you already have it scripted in ACL, why bother with robots?
• Due to the rule-based requirement, you can’t give a robot something that requires human judgment. Robots are not good with exceptions and nuance. If a transaction requires that, the robot just flags it and passes it to a human.
• With robotics, you still have to code the analysis (again, this assumes you’re replacing an analysis package like ACL), whether its in Excel, SQL, or whatever language. Doesn’t it make sense to code data analysis in a package like ACL that is custom-built for that purpose? Why code the analysis in another software while in the process also code the robot? Do twice the work for what reason?
• One of the first exercises in a data analytics process is to profile the data and explore it. While profiling data can be codified in a rule base, often the exploration piece depends on the data; the more different types and sources of data, the more creative opportunities. Do you really want to try to code all the possibilities into software?
  Also, data analysis isn’t just a science, it’s a art. Robots don’t have hunches, can’t follow their gut, and don’t get tips and gossip over lunch that sometimes leads you down a profitable rabbit hole.
• The key selling point of a robot is that it uses the same software as users–it can log in like a user and access, add, or update data. But if the screen name, file menu option, field name, or button name changes, the robot scratches its virtual head and spits on the floor. Do you want to update your robotic process every time your IT group updates MS Office, Oracle,  or a home-grown application, etc.? I don’t.
• When problems occur, a human could look for the missing screen, file menu option, field, or button, and have a good chance to figure out what changed, adapt, and keep working. A robot can’t.
• If your company already one, two, or a handful of auditors who can write ACL scripts and use other analytic tools, why spend additional training dollars and climb another learning curve? Again, I don’t see the ROI in this.
• Robotics will require additional licenses and maintenance fees, and the robot(s) have to live somewhere (server, infrastructure). Again, where’s the ROI?
• As this IIA article noted, we can’t codify everything (requires IIA membership & login). Although the point of that article is that good auditors do more than follow standards, guidance, and a code of ethics, or get certifications, the same holds true for analytics. Creativity, adaptability, and years of experience are extremely valuable, and can’t be programmed into a robot perfectly.

Shortly after this post appeared, ACL posted this about data robots. I’m guessing they are jumping on the recent hype about robots and automation to sell more software and services. While their points are well-taken and needed to be heeded by all auditors, I think they did a bait-and-switch on the robot/automation topic.

Why do I think that? Even if you master ACL and use it to script and automate most of your risk assessment, testing, etc., I do not believe that’s enough to meet the data revolution that’s already starting; I do not believe any one analytics program can save the audit profession and keep internal audit relevant to the business. I’ll lay out those thoughts in a future post.

Conclusion: Stick with ACL, IDEA, Power BI

So in summary, show Mr. Roboto to the analytic door.

The biggest reasons for NOT doing analytics via robotics:

1) Most things that would cause an automated ACL project to fail (e.g., a new/changed column/field on a data source file) would also cause a robotic process to fail.

However, a robotic process has more failure points, especially when the process navigates an application user interface (most analytics use file paths or back-end processes to obtain data). A complicated process could depend on multiple applications or websites, each with their own interfaces, and if any of them changed substantially, the robot would fail.

Therefore, you would not typically choose robotics over ACL (and the like) unless you simply couldn’t do it any other way–that’s when you DO want to use robotics.

2) Data analysis is part science and part art. You might be able to get a robot to ‘think’ and ‘learn’ the science, but the art is another matter. That’s where creativity, adaptability, and judgment come in. Spock is dead.

3) You better have some good ROI numbers before trying robotics. Aside from the training and licensing costs, the real issue has been whether you can really save money in the long run by roboticizing your process (yes, that’s a new technical term).

What About ROI with ACL?

Now you might say the ROI isn’t too good with ACL. If so, why are you using it?

In my experience, bad ROI with ACL and similar tools is due to the following:

• Management doesn’t support analytics, or says they do, but don’t really (I wrote an entire post about this here).
• Analytics is not part of the audit process. Therefore, analytics is only done periodically and it’s hard to retain something you only use occasionally.
• Obtaining key data (e.g, HR, user ID, payroll, general ledger, IT infrastructure and devices) is not automated, formatted, and made available to auditors for use on multiple audits.
• Scripting and automation are not a goal. Starting from scratch for each audit takes too much time and doesn’t eliminate work.
• No one is dedicated to lead the analytics program.
• Too many auditors are not analytical thinkers and are not technical enough to learn analytics and the skills required to make automation happen.

Think Automation

As I mentioned in my previous post (and ranted about immediately above), auditors need to step up…

If automation is the future, don’t you think you should learn more about it? One way to get started is to do analytics, and then automate those analytics.

This will require you to increase your technical acumen as you connect to databases and websites, format and transform data, analyze data, write scripts, schedule and maintain analytics, and finally, trouble-shoot all the scheduling, connectivity, user ID, database, and network/firewall problems you’ll encounter along the way.

ACL, IDEA, R, or Power BI would be a good place to start. Or Python.

Just get started.

If you have already started, that’s great. Now take it to the next level.

Comments?

Are any of your companies using robotics or thinking about it?

Related Posts

• Why Internal Auditors Should Care about Robotic Process Automation
• Robotics to Replace ACL, Part 2
• Auditors, Do Data Analytics or Die
• #1 Reason for NOT Doing Data Analytics
• Excel: Basic Data Analytics

Advertisement