As a finance professional, when you are asked about data structure, what is the first thing that comes to mind?
In my experience, when faced with the question, the vast majority of respondents tend to first of all think about what the reports should look like. A smaller percentage start to think about the ways they interact with the data, and therefore expand on the answer a bit further, by including some of the metrics or calculations that are key for them to have available.
The topic typically comes up during the information and requirements gathering process, whether at the point of architecting the data structures, or when looking to understand reporting requirements. At this stage, the data architect or business analyst would typically ensure that they probe further into the level of granularity, the timing, the refresh rate, the upstream and downstream sources and consumers of the information, any lateral / concurrent use of the same data, systems involved, business rules, and so on, all typical activities that drive the design. However, there is a critical component that is often missed, and which relates to master data: predefined hierarchies and groups of master data.
These are the structures that enable consistent, reliable reporting, while providing a clear path down to the lowest level data members that roll up into aggregates. Ask yourself or anyone in your finance team about being able to trace data down to the lowest level of granularity (think not just transaction, but transaction with full set of objects such as customer or vendor data, supporting documents, product information, plant or inventory location data, and so on). The answer is inevitably that this is not just highly desirable, but critical.
Without these hierarchical structures, reports can still be built of course, and groups of data can be defined at the reporting level. However, the main issue with this approach is that the group definitions are often specific to that one copy or version of the report. Of made available for others to use as building block for reports, everyone else needs to be aware of its existence, as well as ensure that updates are copied or propagated across all instances where used. Furthermore, with most BI tools, an end user will lose the ability to see the elements that make up a group. This in turn leads to inevitable reconciliation exercises so as to ensure that the data behind the aggregates is understood, is correct, and it makes sense.
Designing the structures at the master data level produces a common platform that any data user can leverage “as a given”, knowing that the groupings are governed at the source.
It is key for the data architect / business analyst / data engineer / whoever ends up designing the solution to understand what constitutes the lowest level of data granularity required for efficient and effective analysis, while providing the necessary building blocks that will aggregate to the higher level data consumed by top management.
So, going back to title of this article: “Data Structure vs Reports” – the reporting needs may be a high level, with a given grouping of data. This is merely one use case, and should be treated as such, rather than being used as the definition for data structures. Locking yourself down into a particular report structure that is relevant at that point in time highly reduces the ability to be flexible and to accommodate the inevitable future changes in requirements, while also impeding the transparency and ease of access to analytical details.
Leverage the master data and related structures following best practice for maximum flexibility and scalability of your reporting & analytics!