When implementing centralized reporting systems, you need to make sure you are prepared to go “all the way” – after the implementation is done. We’ve recently finished the first phase of a project to centralize and consolidate financial reporting in a single tool / platform; pretty common stuff, and this story is relevant to any data warehouse / consolidated reporting platform.
A week or so ago, we had an internal IT meeting to review report requests. One of the business units, running on system X for the past umpteen years, was requesting a report from their financial module, to mimic a new report being generated by the new platform. They had a pretty good reason to make the request – looking to validate that the central system was seeing the same numbers that they were.
At first, it sounded ok, but something didn’t seem right – and then we realized that we were missing one of the key benefits of the centralized system; to eliminate redundant reporting in all the subsidiary systems. We wanted this new architecture to generate less reporting requests, not more.
The expectation should be that the central system is responsible for creating audit / validation / “proof of quality” reports that match the output of the system feeding the data. The burden of proof should be on the central system – If I am getting everything I should, I should be able to replicate your report. There should also be basic hash-total reports, that prove 100% of the dollars / units / # of records that were sent are received and posted.
A typical success measure for projects like this – the elimination of the backlog of reporting requests (not an increase!)
This Post Has 0 Comments