Part two – The answer revealed
Have you ever completed a word search puzzle by first attempting to find all of the words, and then comparing your list of found words with the one that was provided? Of course you haven’t.
The same simple approach applies to solving data problems. You have to truly know what the issues are before you go about fixing them. (Hint: Building a data warehouse is not always the right solution.) Do your homework. Understand your problems before looking for the answers. This is what defi CEO Stephanie Alsbrooks challenged you with in part one of this article in the January/February 2017 Non-Prime Times issue.
We often hear about how a technology solution is doing wonders to fix someone else’s problems. However, their problems may not be your problems. Even if they are, you should ask yourself, “What’s the ROI? Is the existing cost of my problem greater than the implementation, maintenance, and operational overhead costs of the solution I’m considering?” If not, then you may be solving for the wrong problem or attempting to solve the problem with the wrong solution.
Hopefully, you took Stephanie’s advice and did your homework. What should you do next? Well, it involves prioritizing the problems you identified, evaluating potential solutions, and determining which solutions, if any, to implement.
I recommend you start by changing the way you see your problems. When you’re looking for technology solutions to fix business problems, it’s really helpful to think of your problems as the absence of a capability.
Let’s say one of the problems you’ve identified is fragmented, siloed and disparate data being utilized by different groups across your organization. Marketing’s reporting tool may have Metric X coming from Database A, while Customer Care’s reporting tool may be pulling the same metric from Database B. This can cause a clear problem when various business units are operating from business metrics with potentially different values. These data discrepancies are typically caused by differences in load or transformation logic between the two databases or reporting tools. To fix the problem, you may, for example, simply force Marketing to use the same reporting tool as Customer Care. Fixed, right? Sure, unless Finance begins using that same metric in a third and different way next week. But what if they do?
In this example, you ultimately want to address your lack of a single source of truth, a practice of defining a single, trusted, universally agreed upon version of all key data points that are driving business insights. By viewing the problem as a potential capability absence or gap, you focus on defining single sources of truth for each key data point across your enterprise, not why Marketing’s metric X is different from Customer Service’s metric X.
Now, let’s go back to the task of prioritizing your problems, or what we’re now calling capabilities. We’ll use something called a Capability Maturity Matrix. Sounds complicated, but it’s simply a way to visualize capability gaps relative to one another. A Capability Maturity Matrix will help you:
1) Visualize the current state of your capabilities, relative to one another.
2) Visualize the desired state of your capabilities, relative to one another.
3) Visualize the largest gaps between current and desired state.
In the matrix shown above (Graph 2), the biggest pain point is the single source of truth capability. Why? Because the capability doesn’t exist today and it has the farthest to go to reach the desired “Tomorrow” state. In this example, scalability is also a capability that doesn’t exist today.
However, since there might be a relatively shallow volume trajectory, there’s not an immediate need for this capability to be fully mature.
Once your capabilities have been prioritized, solutions come into play. Solutions can be simple, complex, or everything in between. This is where a knowledgeable and trusted technology vendor might be of help. And with any technology solution, the decision to implement almost always boils down to Impact and Benefit versus Initiative and Effort — Cost versus Benefit or ROI.
How does a solution like a data warehouse address the Capability Maturity Matrix we examined? Does having a data warehouse address a single capability, several or none? Of the capabilities the solution addresses, what will the matrix look like after we’ve implemented it? Evaluating where the solution falls on the scale of Impact and Benefit versus Initiative and Effort becomes easier when you consider potential solutions this way. (Graph 3)
Whether you’re bolstering your operational reports in Excel or building out an enterprise data warehouse, understanding how to view your data problems, the root capabilities behind your problems and how the proposed solution is expected to mature that capability is paramount to success. You need to accurately quantify the benefit of maturing a given capability as well as the costs of implementing and maintaining the solution that furthers that capability.
A data warehouse might be the right solution for you. It might not be.
But what’s important is that you know how to measure and evaluate problems, capabilities, and solutions relative to one another, and ultimately quantify implementation success, instead of searching for a problem to the solution you already have.
In other words, you need to check the word list before you begin the word search.
Brandon Burns is the director of data and analysis for defi ANALYTICS, the new flexible analytics and reporting platform from defi SOLUTIONS. Founded by Stephanie Alsbrooks, the defi platform now includes defi ANALYTICS, defi SERVICING, defi DIGITAL, and, of course, the popular defi LOS. Email Stephanie at firstname.lastname@example.org or Brandon at email@example.com.