As every finance director knows, interrogating the data held in a company’s ERP system can be fraught with difficulty and delay. The good news: increasingly, a technology known as in-memory analytics is being seen as a way to sidestep that challenge.
Why? Some people will tell you that in-memory analytics offers a way to speed up the delivery of vital reports and business intelligence. By holding the database in memory, rather than querying data held on physical disks, large volumes of data can be processed in incredibly short timescales.
Which is true, but does rather miss the point. If in-memory analytics delivers a report in seconds, as opposed to hours, it’s certainly helpful. But is it a game-changer? No.
Because it’s not lengthy processing times that really holds up the flow of information and business intelligence for the average FD.
Instead, ask FDs where their data access problems really lie. The answer: it’s not in the time take to process existing reports and queries—it’s the time it takes to define, design, and deliver new reports and queries.
That’s because each time an FD wants a new report, someone has to sit down and code it. And in most businesses, those skills are scarce and expensive—and usually reside within the IT function.
Making the problem even worse is the fact that as businesses increasingly surround their core ERP systems with specialist third-party systems—think Salesforce.com for CRM, Concur for expense management, and Preactor for factory-floor scheduling—the more complex becomes the report-writing challenge.
Which is where in-memory analytics comes in.
How, exactly, can in-memory analytics help? To answer the question, let’s think for a moment about why exactly those scarce IT skills are needed in order to design and deliver a new report or query.
Simply put, that’s because queries and reports need careful design and coding in order to make sure that they are looking at, and reporting on, the correct data.
In the case of reports and queries run against a live production SQL Server or similar database that underpins an ERP system, the clever coding does two things.
First, it tries to avoid slowing down transaction processing too much, so that functions such as order entry can carry on uninterrupted. Second, production databases are ‘normalised’, meaning that information is spread across lots of tables, using a system of pointers.
Granted, in the case of reports and queries run against a data warehouse, there’s no need to worry about the impact on transaction processing. But again, it’s important to be able to define and access the correct data. A technology called ‘OLAP’—on-line analytical processing—helps in this, by building indexed data ‘cubes’.
No more OLAP skills
But OLAP isn’t for everyone. So while it’s certainly possible that someone in the finance function might have OLAP skills and a sufficient understanding of SQL, it’s unlikely. Which is why new reports and queries have to be written by the IT function, who do possess OLAP skills.
The good news? With in-memory analytics, the need for OLAP data indexing and hierarchies is largely eliminated.
That’s right: the entire database is loaded into memory, meaning that it’s no longer necessary to specify the links between individual records of interest.
As a result, new reports and queries don’t have to be written by people with OLAP skills. Any moderately skilfully spreadsheet jockey—with appropriate training—can simply use a ‘self-serve’ reporting tool.
Do it yourself
Which is what happens in the case of FDs using our Matillion cloud based, BI as a Service technology.
Each night, our servers extract data from our customers’ ERP systems, and build the data warehouse ‘data cube’ that customers’ reports, queries, visualisations, and dashboards are run against—in-memory, in the Cloud. Blisteringly fast.
And when there’s a need for new report or query, to address a specific information requirement? That’s where our ‘self-serve’ iReport report authoring tool comes in—again running in-memory, in the Cloud. Without the need to invoke complex OLAP referencing.
And the skills needed to define, design, and deliver such new reports and queries? In short, they’re well within reach of any competent spreadsheet jockey.
Which, let’s face it, most finance functions possess in abundance.