Financial Project Management Insights | CFO Insights

Is Financial Data Structure Holding Back Your Business?

Written by Kelly Patchett | September, 19, 2017

Think, for a minute, about how you collect your data. Does it exist in a well-organized framework; one that enables you to leverage multi-dimensional data points to make valuable conclusions about your business? Or, does your data feel a bit more … chaotic? 

If you’re like many, the components of a well-designed data structure are somewhat of a grey area. And business leaders may not grasp the full impact of a poor data structure until they face its limitations first-hand: they have a critical data need that will reveal valuable insights about a specific product’s revenue in a specific region, for example—and frustratingly enough, those insights are simply unobtainable or require significant manual workarounds. 

So, what exactly, is your data structure—and what can you do to make sure it’s optimized to support your business needs? To answer these questions, we sat down with Alex Chang. With over a decade of experience in financial analytics, including serving as a Senior Finance Manager at The Walt Disney Company, Alex has helped numerous companies break down, rebuild and optimize their data structures to dramatically improve data-driven decisions. Here are Alex’s key takeaways.    

 

What is financial data structure – and why is it important?

Simply put, your data structure is the framework for raw data. A good data structure allows businesses to access and manipulate data according to their specific needs. Now, within that data structure are your data points, which are attributes of an entire record. Identifying those data points is critical—for example, any data that can be considered a “unique identifier” should be isolated. Those data points essentially become your building blocks for making multi-dimensional analyses – and that’s where decision-makers find enormous value.

 

Where do most companies go wrong with data structure?

In many cases, businesses will have data points that have not been correctly identified, isolated and organized. When data points are not separated into different fields as they should, they cannot be analyzed or aggregated as intended. Other common problems include poorly defined data hierarchies and work breakdown structures, or problems with standardization at the input level.

 

 
Data hierarchies need consideration as well. Learn more about master product hierarchies.
 
 

You mentioned separating data points into different fields. What do you mean?

I’ll use a simple scenario to demonstrate. Let’s say you have a chain of clothing stores across several locations. A single data set may include basic data points such as type of clothing sold, color, size, retail location and so on. However, a common mistake that the retailer might make would be concatenating the “location” attribute in the same field with other data points when those two fields should be separated.

When data points are concatenated in such a way, your data becomes “unique”— and that means a separate formula will have to be written each time, for each data set. In other words, you lose the ability to run automated processes/rules across large amounts of data. In contrast, when your data fields are separated correctly, your developers can write your rules once and apply them universally; thereby affording you those valuable “dimensions” I mentioned earlier.

Keep in mind, this scenario was basic. When you apply it to a large global corporation, or one with hundreds of legal entities, the impact of concatenated data is far worse.

 

What are some other ways to create a meaningful financial data structure?

A good data structure should also be configured based to data relationships. A couple of basic things you should be doing to ensure this is happening:

  • Establish proper data hierarchies when setting up your data, often done by creating parent-child relationships. For example, a business with locations across North America would create hierarchies based on location, where North America = Level 1; United States & Canada = Level 2; California & Massachusetts = Level 3, and so on.
  • Identify consolidation levels. This type of hierarchy would apply to companies with multiple subsidiaries, where lower levels (the child) roll up into higher levels (the parent), and are ultimately reported as consolidated financials. Without properly defining these relationships, the process around consolidated financials can quickly become convoluted.

You referred to work breakdown structure. Can you explain that?

Work breakdown structure essentially means breaking down a project or product into smaller components. Take your car or bicycle: you’ve probably seen those long numeric codes separated by periods, such as 1000.01.04.07.001. 

Each segment of that code is associated with a product component. When structured this way, those sequences can be pulled out and analyzed, ultimately helping decision-makers identify things like patterns in buying behavior. The same methodology can be applied to marketing initiatives, allowing marketing executives to get incredibly granular with specific components that may be driving revenue. In this case, cross-functional financial planning and analysis becomes incredibly streamlined, also helping you “connect” your data between multiple systems.

 

Can you touch on the issue of data standardization?

Building on the point above, a good data structure not only makes it easier to aggregate and connect data but also enforces standardization. Failing to standardize data can wreak havoc on your processes! Even slight variations in nomenclature (i.e., the same job title captured in multiple ways: Senior Manager, Sr. Manager, Senior Mgr., etc) can diminish your reporting effectiveness – and the more time that goes by, the more difficult it becomes to unwind. Standardized data also plays a key role in creating automated batch reports that require less customization.

 

Any final takeaways you can leave us with?

Well, based on first-hand experience, I really can’t emphasize enough the need for an organized data structure. So many companies fail to implement a correct structure from the start or they simply don’t have the resources needed to correct problems when they start to surface. (Keep in mind, that’s where a consulting organization like 8020 Consulting comes in.) And for companies focused on growth and scalability, addressing your data structure is especially important. Future growth is that much more difficult when your data is built with a shaky foundation.