To quickly recap, they are:
- Collection: What data sources need to be joined?
- Assembly: What are the business rules defining how the data fits together?
- Delivery: Who should access information and how?
We have discussed the important aspects of data collection in a previous post. Now let’s talk about our second step: data assembly.
After you have determined what data is needed, where it is located, and what the parameters are to collect the data, it’s time to assemble it. The first step is to determine the business rules that govern your data. These are the rules that your organization uses to operate, as well as to measure and achieve its goals.
Business rules vary from industry to industry and from organization to organization. They can range from quite simple to very complex. However, no matter how “difficult” they are, it is important to figure them out to ensure that you are measuring the right data in the right way.
Here’s an example of a simple business rule:
Revenue is counted in a specific fiscal quarter based on the date of the transaction.
Here’s an example of how a simple business rule can actually be quite complex:
Revenue is counted in a specific fiscal quarter only if it is shipped (not just booked). The date range for each quarter is set by the finance department and sometimes it does not fall on the exact calendar dates defining the first and last day of the quarter because of holidays, weekends, and other factors. Dates are measured by the time zone where your corporate headquarters is located (not branch offices).
Let’s imagine your business wants to have all of its goaling (KPIs, quotas, etc.) in your SAP ERP system. In the past, your company stored performance goals in spreadsheets, and then measured progress against those goals by running reports from SAP. It was a manual process to pull the reports each time and enter data into the spreadsheets for comparison.
You may not have realized it, but when you ran reports out of SAP you were manually applying business rules (selecting the proper date range for the report, or running reports for deliveries rather than bookings, etc.). But if you made even a small mistake with your manual application of the business rules then it could cause big problems including FCC violations and incorrect employee compensation. This is one of the many problems with using spreadsheets as your BI solution.
Getting the data assembled appropriately according to all the business rules is critically important. Once you do that, you can look forward to accurate and insightful analysis (which we will cover more in the next blog post regarding delivery). You can easily and accurately compare performance over different time periods, different personnel, different customers, and different products, leading to smarter planning and more accurate forecasting. And along the way you will probably identify process inefficiencies that can be cleaned up. It’s important to have an idea of what you eventually want to compare while you are setting up your assembly routines because it will undoubtedly affect your collection and assembly strategy.
Typically, assembly is not performed once, but rather, it is a regular recurring activity. Once the hard work of business rule definition is finalized, the ongoing collection and assembly routines are automated. A final concern is to understand the frequency of change in your data. Do you want to look at data from yesterday? Or three years ago? Or one hour ago? This question will help you schedule the collection and assembly routines for optimal business usefulness balanced with resource planning for IT systems and networking infrastructure.
Dimensional Insight and Data Assembly
The Extraction, Transformation and Loading (ETL) tool within The Diver Solution (Diver)extracts data from any source system, aggregates and merges it, and applies business rules to create a highly indexed data structure. With our cross-indexing technology, Diver transforms your data stream into a multi-dimensional data Model that is optimized for query, analysis and reporting. Because our Models integrate data from multiple sources, you can compare, for example, data from transactional systems with information in your data warehouse, legacy system, spreadsheets or flat files.
The Diver Solution Technical Overview.