Have you sat through any planning application demos recently? Well, you will probably find that most vendors are spinning a “single version of the truth” message.
This seems like a compelling prospect if you are currently using spreadsheets to manage your critical business processes. The vendor will probably tell a story of two managers sitting in the same meeting with two manually compiled spreadsheets. Each spreadsheet shows a different number for the same metric! Nice story. But is the vendor that you are considering really able to deliver a single version of the truth? If you take the time to look under the covers, then maybe not.
Do multiple views demand multiple data cubes?
Some applications do not support multiple views of data within the same dimension. This is often referred to as “alternative hierarchies” in this space. A good example of an alternative hierarchy would be within the cost-center dimension. For instance, I may need to roll up my cost centers by Function or Responsibility. As another example, in the account dimension I may have multiple views of my income statement — say, a management reporting view and a legal view.
The impact of this limitation is that the user needs to have multiple cubes holding the same data, with each cube providing a different view or rollup of that data. So, I may be forced to have my management reporting view in one cube and my legal view in another cube. This means that I have to move the data between cubes and maintain the same dimension in multiple places and then reconcile each of the cubes to make sure that they all agree.
The fact that my data is now split across multiple cubes means that my analysis in limited. What if I want to analyze something in one cube by something in another? The end result is that I’m forced to export the data and stitch it back together in a spreadsheet — just the type of activity that we were trying to avoid in the first place.
Some data reassembly required
You may have seen my previous post which details the challenges some applications face in supporting enterprise-scale data volumes. That data volume limitation is what forces you to split the data into multiple cubes. This implies a lot of data movement, followed by reconciliation steps to make sure that all of the data ties together.
Some vendors also require third-party applications to provide reporting and visualization. This means that you need to move the data yet again, from the planning application into the reporting or visualization tool. This requires even more data movement, duplicate security maintenance, and reconciliation steps. And of course those steps aren’t happening in real time. In an environment like that, how would a reporting user know if their numbers were correct or not? What if someone made one of those all-too-common last-minute adjustments but forgot to run the routine to move the data over? Where’s the “single version of the truth” then?
A multiple-cube architecture is actually a necessity for a robust planning application. But it should not force you to put the same data into multiple cubes just because the system has limitations. I recommend that you do your homework to make sure that any planning application you consider is genuinely capable of delivering the vision of a “single version of the truth.”
And if you’d like to see a demo of a planning application that makes multidimensional analysis — with a single version of the truth — faster and more flexible, watch this on-demand webinar from my colleague Dave Corbett.