The Case Against Excel

Microsoft ubiquitous spreadsheet application, Excel, is always an easy target for RPA robots. The data held in the spreadsheets is usually well-structured and the files are easily accessible – no special permissions, beyond maybe a password, are usually required to open them. And spreadsheets are usually doing the job that the robots were built to target – those where an enterprise system doesn’t quite do everything it should do, so someone creates a spreadsheet that uses exported data to do some calculations that are then imported back into the original application or a different one. Prime ‘shooting-apples-in-a-barrel’ candidate processes for automation using RPA.

But, surprisingly, we still find Excel being used in organizations like it is the best thing ever. Excel’s dominance in the business world was demonstrated recently when scientists had to rename human genes because the software was misreading them as dates (for example, the abbreviation for the ‘Membrane Associated Ring-CH-Type Finger 1’ gene is MARCH1, which Excel automatically converts to the ‘1st of March’). Of course, sometimes a quick spreadsheet is the best answer to some bespoke, and probably one-off, calculation exercises. But the level of dependency on Excel for business-critical processes in organizations can be very worrying indeed.

This concern was recently brought home when the UK Government’s ‘Public Health England’ (who are responsible for front line health management, including collating Covid-19 statistics) admitted that they had accidentally under-reported the number of Coronavirus cases by 15,841 over a particular week. As you may have guessed, the error, which could have serious life-or-death consequences, was caused by the incorrect use of Excel.

For those of you that are interested (this is a tech blog after all) the error came about because PHE messed up the import of ‘CSV files’ (essentially these are simpler versions of a spreadsheet) received from commercial firms that were contracted to analyze swab tests to detect who has the virus. PHE was using a version of Excel from 2007 which meant that each import was limited to about 65,000 rows of data (the latest version of Excel can handle around 1 million rows). Each test result covered a number of rows of data, so a maximum of 1,400 results were imported at any one time – any more than that simply dropped off the end and were lost. And each lost test result meant that many more people who should have been traced were not.

Of course, it could have been quite easy to automate that process using RPA and get exactly the same result. But a good RPA developer would have built-in automatic checks to ensure all the data had been imported every time. But an even better outcome would have been to use RPA to export the data directly out of the contractors’ systems and straight into PHE’s system without it having to touch a spreadsheet at all. That way there would have been no limitations on data volumes, plenty of checks that could have been built in, and no room at all for human error.

So, the lesson for all of this is that wherever you see a spreadsheet used in a business process, there is likely to be a use case for RPA. Good RPA developers will ensure that the robots will do the work quicker and more accurately, avoiding any huge mistakes like the one that PHE experienced.

However, there is always an exception that proves the rule, and the above should not be used as a blanket directive. We thought we would leave you with one example of where a spreadsheet can do some quite surprising things – in this case being used as a drum machine. Dylan Tallchief used the similarities between the structure of a spreadsheet and a MIDI sequencer to create his beat maker. You can watch a video of it action here, and actually, download a copy of the spreadsheet here.

But in the meantime, enjoy your spreadsheet hunting…

Tags: Process Automation, RPA