In the previous 3 parts of this series on How to analyze a problem with data, I had provided a general guideline for each stage of the process. For Analysis, there is no one-size-fit-all framework. Different problems call for different way of thinking and alteration. Therefore, I have decided to break this Part 4 - Analysis down into two (or maybe more?) separate articles:
The first article aims to give you a fixed goal in mind, which hold true for any kind of analysis you are likely going to do, so you can navigate through the twists and turns in the process. In the second article, I will present a framework for analyzing E-commerce, which I believe is a familiar topic to us all, and show you how a professional would use it to diagnosing problems in the business.
The goal
The goal of any analysis can be summarized in one sentence:
To (1) deconstruct a problem into MECE parts that (2) facilitate the execution of potential next steps.
As clearly annotated, there are 2 main parts in the goal that we need to understand:
(1) deconstruct a problem into MECE parts
What is MECE?
MECE is short for Mutually Exclusive & Collectively Exhausted - a term popularized by Management Consultants. By "mutually exclusive", what it means is we want to break down a problem into a set of separated components. These components represent all the possible sources of the problem's root causes. The problem must be collectively and wholly caused by one or more or all components in the set and not by another outside of that set.
If this sounds confusing, check out my analogy below:
Why should I want MECE?
Generally, any good analysts would have followed the same approach though they may or may not used the same jargon or at all. The reason we want to deconstruct a problem this way is because "collectively exhausted" quality ensures we do not miss out any forces at play, and "mutually exclusive" allows you to assign responsibilities to specific areas or functions, where you can then take corrective actions.
In the food poisoning case above, we can be pretty certain that the fried rice dish has caused your food poisoning. However, knowing that does not help you prevent it from happening again to you and potentially to others. If you break the problem down into the set of 7 sources of root causes, then it is clearer what you can do. If it is an external problem - the ingredients was bad, you can take the identified items to the supermarket and ask them to check if the batch of products is having issues so they can halt it from being sold to more people and you can hopefully get a refund. If it is an internal problem - i.e., you prepared the dish the wrong way or your kitchen needs some serious cleaning, then you can take actions to avoid getting yourself sick again.
How do I know if I have achieved MECE in my analysis?
The answer is you don't always know. Sometimes you can tell if you are there yet by experience, or by adopting well-established frameworks that have been validated to work for your kind of problem. Try your best to come up with a comprehensive and appropriate structure, but if along the way, you find yourself missing a thing or two, simply go back and revise it.
In fact, it is not always possible to make a problem MECE, but MECE is what we strive for. In cases where the best set of components you could gather is relatively broad and/or it is difficult to draw a hard line between the components, it may be helpful to dissect the problem from multiple angles - i.e., create more than one set of components that can add layers to your insights.
(2) facilitates the execution of potential next steps
A well-deconstructed problem will give you clarity on what happened and many analysts think their job stops right there. However, the really shrewd ones - they would go over and beyond to shed light on the next steps that their stakeholders should take with actionable insights.
How do I anticipate the potential next steps and their execution if I am not sure about the problem yet?
The good news is you don't have to know the potential solutions well or even the problem well to anticipate the execution. You just need to know your organization: its structure, departments and activities because it is through these administrative units and processes that things get done. So, when you are not sure which way to dissect your problem, choose the one that built around those functions. As a result, once the company's stakeholders read the findings of your analysis, it will be clearer to them if and which impact they made and obviate the question "so what?" from their minds.
Example of an non-actionable vs. actionable insights
Comentários