Please can we stop saying that the future of Finance is all about RPA and AI! It’s not!

By Andy Burrows

So much ink has been spilled about the impact of technology and automation in Finance – RPA and AI and the like - that it’s starting to get a bit tedious. From reading all this stuff, anyone would think that there’s a robot army lining up to make us all redundant! And it’s written as if it’s at the forefront of everyone’s minds in Finance.

On the ground, in the real world of Finance in real world business, it’s not like that!

And we all know deep down that it’s hype! Who sponsors the conferences and the accountancy publications and the webinars that are spouting this stuff? The software vendors!! There’s a vested interest in inflated claims and understated costs/risks.

And yet it feels like the whole Finance and Accounting industry looks down on you if you’ve never heard of RPA, haven’t got a cloud ERP project planned, or you’re not talking about analytics and predictive modelling.

What we need is a balanced analysis of the issues involved, in order to make an informed assessment of the real challenges facing the Finance function and accounting profession. Otherwise, people start to get numb to the hype, ignore what’s going on, and miss the concerning trends that are lurking beneath the headlines.

So, what I’m going to do in this article is to try and say what I think is true, and what is not, regarding technology in Finance. Based on that I’ll do another article outlining what real challenges are raised for Finance by technology.

What’s new about RPA?

I guess one of the things, first of all, that bugs me a bit is the implication that automation is somehow a new thing for Finance. As if Finance is still using quill pens and ledger books, and the robots are going to come and revolutionise everything.

Come on! Automation isn’t a new thing in Finance. You can do amazing automation with just Excel and Access! And Finance people have been doing just that, increasingly, for more than 20 years.

But, on the other hand, Robotic Process Automation is a step forward. The new aspect is that you can effectively write or record a macro that controls any keystroke and data entry and mouse click you do on your computer. It’s not limited to one application.

So, if you have a very repetitive job, you can easily automate it now with RPA. And it’s not that expensive to do. It can also help to integrate different systems where API or back end database integration is not possible or too expensive.

RPA isn’t a good fit for everything

The other thing about Robotic Process Automation is that it’s not the panacea for automation that it’s quite often made out to be.

The truth is that RPA is good for some things, and not so good for others.

The biggest full-on genuine RPA project I know of personally in Finance planned to address less than 10% of the headcount in the Finance function. And it didn’t get off the ground. That’s not what I call “an army of robots coming to take our jobs!”

The best processes to automate with RPA are a) stable, and b) very repetitive (ideally many times a day).

What this means is that, if you think about it, the best processes in Finance to use RPA with are transactional processes – raising invoices or processing expense claims, and that sort of thing... which are largely already integrated and automated without needing RPA.

When it comes to R2R (record-to-report) processes and FP&A (financial planning and analysis) processes, individual tasks are mainly only performed once a month. So, these processes are not really repetitive enough to get the benefit of a robot doing them quicker.

And there’s always a risk that a new account will be added, the menu options will change, or someone will insert a column on a spreadsheet. That means that from a desktop computing point of view at least, the processes are not always as stable enough, because the robot needs reprogramming almost every month.

All these things mean that R2R and FP&A processes, which now represent the majority of Finance manual tasks, are not going to benefit much from Robotic Process Automation.

Hence, in my humble opinion, the potential for RPA in Finance is nowhere near as great as is being hyped.

Confusing terminology

Another thing that makes me cynical is the deliberate confusion of terms by the tech companies.

RPA is not as new as everyone thinks in the first place, and on top of that some older automation software and solutions are now being called RPA to give them a new lease of life.

API and other types of system integration are more robust than RPA. But they’re not RPA.

Machine Learning is being “re-badged” as Artificial Intelligence – but it’s been around for years! For years now, we’ve been able to scan purchase invoices, read them with Optical Character Recognition, and then have the computer learn where the key details are on the page so that it can process it automatically in future.

(And by the way, don’t get me started on AI! There aren’t any current exciting – let alone viable - applications of artificial intelligence working in mainstream Finance functions – someone please prove me wrong... this is laying down the gauntlet!)

We haven’t made the best of what we’ve got already

The other thing we’ve got to realise about automation in Finance is that we almost definitely already have tools that can do much of the automation we want, without having to pay for a new robot.

RPA may be relatively cheap, but it’s not free. There are licence, maintenance, training and support costs, just like any other software.

And it’s not easy to implement RPA. Certainly not as easy as it’s made out to be.

The nature of RPA is that you have to know exactly – down to every individual mouse movement, menu option, key stroke and click – what the process to be automated involves. And if there are any variations, choices, exception processes, these have to be built in to the programming as well. The robot will do this the same way every time, so you have to get it exactly right.

Therefore, you need someone in the department, and within the business, who knows what’s going on when things fall over (which will happen from time to time).

So, RPA needs a business case just like any other technology change.

But surely you’ve already got Microsoft Office? You’ve got Visual Basic (VBA), you can record macros, you’ve got MS Access – you don’t have to pay anything extra for these. 

Nowadays, you can probably also get Power Query, Power Pivot and Power BI for no extra cost (or very little). These, in my view, are swinging the pendulum back towards Excel in many ways. 

What about your ERP system? There may be some built in functionality to record macros, or automate certain regular tasks. Some of them have some ready-made integrations with other software. SAP and Oracle certainly have configurable automations, macros and the like.

And are all our spreadsheets built in the most efficient way (for minimal updating)?

I once ran an automation workshop in a large company, and identified more than fifteen software applications they already had and could use to increase automation with minimal additional cost. And they already had people with skills to use them. Why buy RPA and spend many thousands of euros when they could achieve almost as much for a fraction?... simply by better use of what they already had.

We can no longer let “key person dependency” put us off

One of the biggest problems I’ve come across with technology solutions in Finance – even ERP systems – is that even in larger businesses they cause “key person dependency”.

“Key person dependency” is the way of describing a particular kind of risk. It’s the business risk caused where a critical business activity or process is only known to one person. If that person leaves the business, there’s a struggle to be able to continue doing that activity, and there may be adverse business impact.

This is one of the things that has stunted the progress of automation in Finance.

I well remember my first role outside of public practice, when I came into a big company which had an Oracle GL in 1996. What they did progressively with MS Excel and MS Access blew my mind, stepping in from an accountancy practice that still used paper files, and had one PC and two laptops in the audit department to serve 20 people!

Spreadsheets were linked, so that when data was imported from the ERP it was only done once. And database links and macros were developed to do that automatically to make sure that the right places were updated (yes, in 1996!).

VBA was used extensively, alongside MS Access, both for monthly reporting and budgeting and forecasting. It automated data extracts, calculations, data gathering and reporting (again, yes, in 1996!)

The problem was that this was only possible because we happened to have one person who was “techie”, plus 1 or 2 others who could get by.

After a year or two we were getting very worried that this one “techie” might leave… and he was an agency temp, with one week contractual notice, who didn’t want to go permanent! If he left, and then one of the macros didn’t work, we’d be stuck. And in some cases we didn’t have any process to fall back on.

That has become a familiar conversation over 22 years since then, and it’s one of the reasons why in some places they’ve banned Finance from using MS Access, VBA and macros.

But if you think about it, RPA is no different, it’s just a different tool.

Whoever programs the robot (and the vendors keep telling us that they’re designed to be set up by users, not specialist programmers) is then the only one who really knows what it’s supposed to be doing if things go wrong. And the programming may be intuitive, but it’s not a skill widely available in the market, and (as with VBA) different programmers do things different ways. 

And that’s just the techie piece – what each bit of code does. What about the underlying process? – what it’s doing, why it’s doing it, what qualifies as doing it right and properly, how you can tell when it’s gone wrong. You can’t just program the robot, make the guy redundant who did the job, and then just assume that the robot will carry on working, even if you have well-written procedure documentation.

RPA could still lead to “key person dependency”.

And that’s because RPA is front end automation, user programmable, just like VBA, SQL and MS Access. This is, by nature, not as robust as back end database or API integration, or application-coded automation. But it’s cheap to implement and flexible.

So, I guess what I’m suggesting is that perhaps we shouldn’t run a mile from automation opportunities just because they appear to create “key person dependency”. This has always been true, but is increasingly so because of the increase in number and variety of solutions available. Spread the knowledge and skill instead!

Conversely, 22 years on, VBA doesn’t actually create as much key person dependency as we think. In the automation workshop I referred to earlier, we discovered that we had more than 15 people with VBA skills in a Finance department of 250 people. Tech skills outside of the IT function are becoming much more widespread, especially in Finance, but in other operational and support functions too.

I suppose my argument is that if we’re going to get all excited about RPA – front end user defined automation – why aren’t we revisiting our attitude to VBA, MS Access and SQL? It’s very similar in essence.

There are better ways of doing things

The other thing that has hampered progress (and this is true in some areas, but not others) is the assumption that most software applications are intuitive, or that the only training you need is at the ‘how to’ functional level.

So, you may get training in the ERP system – how to post a journal, run a report, do a ledger query, etc.

Or if you get Excel training, it’s how to do a VLOOKUP or a pivot table, and so on.

What you don’t tend to get is what I would call “best practice”. Think about it logically. There are always ways of doing things better – better techniques. From swinging a golf club, to driving a car, to building a spreadsheet. Very few organisations I know of actually do this piece of training or coaching. What is an efficient spreadsheet? A good spreadsheet? What is the best way of doing analysis or modelling?

It leads to an attitude that once you’ve done your training, been on your course, away you go! We think that simply having the tools will make the difference. And that leads to very variable quality in processes.

What does it all mean?

Well, I hope I’ve caused enough of a stir to get you thinking about what’s real and what’s not in the world of digital transformation, and whether “key person dependency” is a good enough reason to shy away from certain automation tools. 

In a future article, I want to look at what this all means for Finance and the accountancy profession in general. I believe that being mesmerised by the hype around the shiny new things – RPA, AI, cognitive-this, predictive-that – is distracting from some key issues that are more important. Those are the issues of skills needed in Finance, and how we get them.

Related articles 

The future CFO – Four ingredients for CFO success in the modern age

Free downloadable resources

I think that the future of Finance is bigger than just automation and efficiency within our own function. It's about driving business performance. Find out how I think Finance can drive business performance in this free downloadable white paper. Just click the link below:

https://www.superchargedfinance.com/pl/44847

I think that before we go spending loads of money on RPA and new technology, we should make sure we're properly using what we've already got and already paid for. So, I developed a "Finance Automation Arsenal Template" which gathers information on all the tools you've got, their strengths and weaknesses. I used it in a Finance Transformation Programme to assess the best plan of action. I hope you find it useful too!

Finance Automation Arsenal Template