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 and automation in Finance. Based on that I’ll do another article outlining what I think the real challenges are that technology raises for Finance.
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 significant step forward. The new aspect is that you can effectively write or record a macro that controls every keystroke and data entry and mouse click you do on your computer.
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 RPA project I know of 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:
- 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.
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.
AI is an idea, not an innovation, in Finance
And when it comes to Artificial Intelligence, there are currently no serious production-strength applications of AI in Finance (that I know of).
Machine Learning doesn’t count – that’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.
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 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 (like Xero) have some ready-made integrations with other software.
Are all our spreadsheets built in the most efficient way (for minimal updating)?
We can no longer let “key person dependency” put us off
One of the biggest problems 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 Acecss 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.
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!
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? What is the best way of doing analysis or modelling? And how do you do it?
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 my next article, I want to look at what this all means for Finance and the accountancy profession in general. Because 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.
I’ll be speaking on “The DNA of the future CFO” at the AICPA-CIMA Finance Transformation conference in London on 3-4 September. Find out more here: https://aicpa-cima.knect365.com/finance-transformation-london/
This article is part of a loosely connected series aimed at framing that talk.
Other articles include: