In a previous article I spoke about the building blocks that can be used to describe your organization. The more complete the picture, the more useful the associated data will be. Because each one of those building blocks is a foundational element for the design of your systems.
Let’s use a very simple and common item: PRODUCT
Whether your organization produces a physical product, a software, or a service, you will inevitably look to gather information about activities both “inbound” as well as “outbound” as they relate to your product.
In the most basic form, a business user would look to understand:
- Which specific product
- What transaction took place
- When did the transaction take place
- Where did the transaction take place
- Who are the involved parties
The natural progression on such line of inquiry is providing a key insight into how the data should be structured in order to support answers to such questions. Specifically, based on what questions one needs to answer about the business, the data structure and the granularity of data that has to be captured is revealed.
This line of inquiry is also helping to develop use cases that outline the ways in which answers may need to be narrowed down. This process is supported technically by “slicing and dicing” the data based on parameters provided by the business user.
In the current example, using a query on product, a business user may look specifically for:
- Product ABC
- Returned
- In January 2018
- In the US
- By Customer XYZ
This highlights the point of intersection that we are looking to isolate, and the dimensions that it impacts:
- Product – filtered for “ABC”
- Transaction type – filtered for “Returns”
- Time – filtered for “January, 2018”
- Geographic location – filtered for “US”
- Customer – filtered on specific customer “XYZ”
Consider THE lowest level of granularity at which your building blocks should capture the data. Using the example above – does it matter what US state, city, or even zip code the transaction took place in? Can you envision a situation where it will? Contemplate your company’s future and determine the data requirements from a strategic standpoint.
Data storage is cheap these days, and processing speeds have significantly improved, making the usage of massive amounts of data relatively simple. This often results in the “if available, capture it, and just throw it in storage, may be useful one day”.
The key fallacy here being that without a strong backbone that supports the data management in a methodical, governed way, aligned with the organization’s strategic goals, the data can quickly become a burden, while providing no additional value whatsoever, and possibly turning into that dreaded “data cleansing” project that’s often thrown on the back burner.
The organized and thought out design of your data is absolutely critical, it is THE backbone that will support both financial as well as all non-financial metrics and information about your business and its health. Do not rush though the process, it is always better to think through all the implications and future requirements based on the long term vision of the organization. Measure twice, cut once.