Next Generation Reporting Architectures: Part Two
Why use cases take you in the wrong direction
Most corporate business intelligence (BI) endeavors begin one of two ways: Someone asks a data analyst a question, or IT decides to purchase a BI product. Let’s examine the probable outcome of both approaches.
Approach #1: The business asks a question
In this approach, business leaders ask a question that requires data analysis to answer. Every question gives rise to an independent analysis and can be considered a separate use case. Soon, there is a team of three to five people devoted to answering data questions. Data quality becomes an issue because all source systems have their quirks, and each analysis must deal with these quirks independently. This approach would benefit from an enterprise reporting model that could iron out the data inconsistencies and data quality issues ahead of time. However, one or two questions alone don’t warrant an enterprise BI project. It takes many recurring questions before an enterprise reporting model is viewed as a viable solution.
Approach #2: IT decides to purchase a BI product
This approach turns into a competition between vendors in which the winner demonstrates the most value in solving a use case defined by the business. Here, a use case is a specific BI capability. The shortcomings of this approach are that the focus is on a single use case and the use case is always sales by product. (More literally, the inaugural use case is sales by product by time and sometimes by geography, but we will refer to all this as “sales by product.”) The executives who paid for the BI tool get a sales-oriented dashboard and feel that the cost of the BI tool has been justified. Since the executives are happy, this is where the BI endeavor often ends. But this is hardly an enterprise reporting model — it’s a simple data extraction program.
What comes next?
Some organizations can’t imagine what lies beyond the first use case. The reality is that sales by product will keep you afloat (sic) in the short term, but the bulk of the enterprise’s business processes remain uncharted.
For organizations that evolve beyond sales by product, the evolution is usually tenuous. Each future use case often gives rise to a separate reporting model. A business analyst once told me, “All our reports are different. We don’t have a common reporting model.” Their perspective is that a top-10 product report is essentially different than a report that shows sales by month, not knowing that both are generated from the same data. Over the long haul, it becomes clear that creating many, many reporting models isn’t sustainable.
Use cases take you in the wrong direction
The root problem with approaches one and two is that the use case is not the right vehicle to drive an enterprise BI solution. For one, a use case is hyper focused and does not take the overall terrain into account. The analyst mentioned above is somewhat justified in the sense that a small wording change can make two use cases seem completely unrelated.
Additionally, a use case is functionally equivalent to a report. Back in the 1980s when relational databases were brand new, people thought of them as reporting tools. Thought leaders at the time said that the best way to design a relational database was to look at the reports it needs to produce and build the database structure around the reports. No one says that anymore. No one has said that for 40 years. Yet, this is precisely how use cases drive BI projects.
Finally, use cases are a tremendously inefficient way to build a complete solution. Imagine if you built a car one use case at time:
- First use case: I need a way to get groceries home from the store. The most cost-effective solution is to purchase a golf cart.
- Second use case: I need a way to get kids to their soccer game, so I now need a golf cart with more seats.
- Third use case: I need to visit my grandmother who lives in Duluth, MN. Now I need to get a real car.
- Fourth use case: It gets cold in Duluth, so I need to take the car apart and retrofit it with a bigger engine and cabin heating.
You may go through hundreds of use cases before you land on the type of vehicle you actually need. The real-life situation is that some BI organizations are currently trying to maintain thousands of separate use cases. Most organizations that take the use case approach to BI development never reach an enterprise solution.
The solution: Business Process Analysis (BPA)
So, now that we’ve denigrated the approach that 90% of all organizations use, what’s the solution? The answer is Business Process Analysis (BPA). BPA is a structured, multi-step method of examining the internal processes of a business. BPAs are often conducted with the intent of replacing the inefficient processes. Our intent is to understand each process well enough to identify the underlying data supporting the process. The following sections describe two specific ways that BPA can be used to support analytics.
Alternative #1: KPIs and drivers
The first alternative is to define key performance indicators (KPIs) and drivers. A KPI is a measure of a business that is critical to its success. A driver is something that contributes to a KPI that a specific person (that you must identify) can control.
I once worked with a company to identify financial KPIs and someone gave us an off-the-shelf finance book that identified several hundred financial measures. In practice, I’ve never seen an organization that used more than a handful of these measures — only the ones that are critical are considered KPIs. Each KPI must be linked to one or more drivers. A metaphor I’ve heard is that poor performance of a KPI means someone is going to be fired while poor performance of a driver means someone is going to get punched (No, I didn’t make this up.) In other words, a driver has to be something that a specific person can control directly, like a sale price.
Referencing our earlier discussion, sales by product may be a viable KPI, but what are the drivers that affect sales? While this same KPI is used by many companies, identifying the drivers requires an in-depth business analysis that varies from one company to the next. Also, database designers can select measures from a database to use as KPIs, but they have no way to define the drivers since these depend on the specific organization and people.
In summary, KPIs and drivers link an organization’s performance to the things that people in the organization have control over. IT can then be summoned to collect the data to support these KPIs and drivers.
Alternative #2: Process flows
The second alternative is to perform a detailed examination of an organization’s internal processes and document them using cross-functional flowcharts, swim lanes, or process flow diagrams. While BPA is often focused on process improvement, we’re more focused on touchpoints. We want to identify every instance where an employee, vendor, or customer interacts with a business.
Once the processes and touchpoints have been defined, database designers can comb through the available source systems or data staging areas to identify the database tables that support each touchpoint. Using our knowledge of the business process and tables, we can then define the major business objects (or “dimensions”) and the business transactions (or “fact tables”) that need to be captured in our reporting model. These dimensions and fact tables will form several star schemas, and we can choose which will be the most beneficial to build first.
BPA gives you a roadmap. The next step is to capture any standout use cases. While this may seem like a contradiction to what I stated earlier, it isn’t. Previously, use cases were used in place of an overall design. Now that we have an overall design, we just need to identify standout use cases to add more detail. For example, I supported a company that manages residential real estate properties. One of the major dimensions was “resident,” which contains attributes describing the people occupying a rental home.
Subsequent to the BPA, a use case surfaced where an analyst wanted to see if there was a relationship between the resident’s salary, length of employment, and their probability of subsequent eviction. We didn’t capture salary or length of employment in the original design because they weren’t stored in the specific database tables we were looking at. Those attributes were part of the application process, not the rental process. Having been made aware of this use case, it was easy to add a few attributes to the existing resident dimension.
You most likely won’t get these standout use cases from the people performing day-to-day jobs because these people are highly focused on the success of each job rather than the analytics associated with a set of jobs. However, the company will most likely be able to point you to their data analysts who have already started to wrestle with specific use cases.
Conclusion
I have one last observation related to the BI initiatives I’ve supported. I once built a complete enterprise reporting model for a major U.S. company in an IT-led effort based on analyzing the data maintained in source systems. Because the effort was led by IT, the business leaders never fully understood the value of the resulting reporting model. And since they didn’t ask for it and were busy with their own initiatives, they never used it.
In summary, better BI results from better BPA, and the business must be the one driving the effort — not IT.
Slalom is a global consulting firm that helps people and organizations dream bigger, move faster, and build better tomorrows for all. Learn more and reach out today.
