en
da
What does your BI department have in common with your accounts department? Very little in most companies. And this is a pity. If your BI department is primarily made up of developers and database experts, who is to ensure that your data are valid and that all the files from your sales systems and ERP system have been included correctly?
When companies stop using Excel and start using a BI solution such as Power BI, Tableau, or the like, they often have a vision to make fancy dashboards and dynamic models that are easy to update and automaticlally share with the management and the business.
And admittedly - it's not difficult to build data models that collect and present the results in a new and smart way.
The question is, though, whether the model can stand up to an auditor's zeal, a bookkeeper's reconciliation methodology, or an IT specialist's infrastructure review?
Four typical BI errors that a bookkeeper can remedy
- Inaccuracies - errors in the data read
- Incompleteness (or double data)
- Errors in data limits
- Non-governance - access to data that one shouldn't have access to
It takes only a few errors in the reports for the management to be suspicious of the quality of the figures presented. And if a not overly enthusiastic atmosphere spreads, your BI investments will soon become an costly mistake for your business.
Misleading data result in misled decisions
Errors in your reports will typically have negative consequences. At best, the company will have a wide number of expensively developed reports, KPIs, and dashboards that aren't used since nobody trusts the figures. At worst, the reports, analyses, and sales figures are used with incorrect figures, so that the decision-makers are provided with a wrong basis for their conclusions and strategic recommendations.
You've probably guessed what may happen - it may have fatal consequences to your business.
But what does this have to do with a bookkeeper?
Well, you see ...
… A bookkeeper has many tasks and is to be in control of the accounts - especially through the company's income and expenditure. A bookkeeper also prepares VAT settlements and tax calculations, and that all documentation is in accordance with a strict system substantiating all business activities.
So if a bookkeeper was involved in all BI projects to check the figures, many of the above BI challenges would be nipped in the bud.
... if a bookkeeper was involved in all BI projects to check the figures, many of the above BI challenges would be nipped in the bud.
Much ado about nothing?
Do the above scenarios sound like science fiction? Then, wait a minute ...
We have a couple of examples of BI projects that we believe can convince you that they may not be that far from reality as you may think.
What both BI projects have in common is the fact that the basis on which the reporting is built hasn't had a fundamental reconciliation methodology before and after having been put into production. And don't worry - we'll also touch upon possible ways in which to get rid of the problem.
Example 1: The HR report shows double wages
A mere six months after the implementation of a protracted BI project, the HR director chose to no longer use the HR report that had been developed to provide insight into the company's wage trends and HR's general performance, because confidence in the report evaporated when it suddenly became clear that the figures in the HR report weren't in accordance with the those in the P&L report from Finance. And what was even worse: This hadn't happened just once, but every month since the implementation of the report.
The implementing BI house was called in, and the relevant data were fully reloaded.
A few months later, irregularities figured again. This time, they were detected by the CFO who chose to insert a simple reconciliation of the main figures between the payroll system and the final report directly in the report.
When the error occurred as expected, it was quickly ascertained that the BI database had been set to retrieve data from the payroll system for new recorded voucher numbers ('incremental loads'). It was also found that the payroll accountants could delete already recorded voucher numbers in the payroll system without creating credit entries. This means that every time the payroll accountants made corrections to the payrooll system, only the corrected payroll entries were sent directly to the BI database - and thus not the deleted entries. Therefore, the report presented double wages for the corrected employees.
To avoid making changes to the payroll system, the solution was to change from 'incremental loads' to 'full loads', thereby transferring the data 1:1 between the payroll system and the BI database. And more reconciliations were built into the HR report.
Example 2: Non-governance of master data resulted in management reporting gaps
A retail chain with a rather large BI landscape didn't have any sales data in the management reports from their ships around the world.
After quite a few reconciliation exercises, the customer found out that master data were managed at a decentralised level, i.e. the sub-departments were responsible for adding new departmental and product codes in the local BI systems, just as they were responsible for the transfer of the same information to headquarters.
Unfortunately, they failed to perform the last step quite a few times, which resulted in data disappearing if the new departments and products didn't exist in the HQ mapping tables.
The solution was, first and foremost, to scrutinize all SQL codes and data transfer packages (SSIS) to make the BI system indicate (rather than delete data) whether there were any new departments, products, etc.
Subsequently, the responsibility for master data governance was transferred to headquarters, from where the new master data were automatically rolled out to the local BI systems.
In our experience, most large BI projects should include reconciliations by a bookkeeper or similar profile before being put into operation.
How to proceed from here?
The examples above point to an important learning: that the data basis is alpha and omega to get value from your output - or as usually said: Crap In = > Crap Out.
Do you happen to know, by the way, when your BI or IT department most recently checked whether your P&L, cashflow statement, or sales report are still in accordance with your data sources?
In our experience, most large BI projects should include reconciliations by a bookkeeper or similar profile before being put into operation. Thus, the company ensures that the data are correct, timely, and complete before the decision-makers - or eventually the investors - make use of the conclusions.
Consequently, it would be tempting to ask: ... Is your BI report correct?
Do you need sparring?
Basico's BI developers have experience from finance, controlling, auditing, or a plan old-fashioned accounts department. Thus, our focus is not only on fancy reports with colourful graphs, but just as much on fundamental data sources and how they end up in the reports.
Does this sound interesting? Then, don't hesitate to contact Director Thomas Malmros for a non-binding talk about what we can do for your company's BI report.
