What is Analytics Maturity Framework?

Analytics maturity is a model commonly used to describe how companies, groups, or individuals advanced through stages of data analysis over time. This model progresses from the easy-to-implement types of analysis towards more difficult types of analysis, with the working assumption that the more complex types of analytics provide more value.

In this post, we will give an overview of the purpose of the ubiquitous analytics maturity model, but we will also talk about how it is commonly misinterpreted. By the end of this post, you will have a more nuanced understanding of applying the analytics maturity model within your organization.

Spoiler: Don’t over-invest in one category at the expense of another.

What is Analytics Maturity?

On the face of it, the analytics maturity curve is simply the progression of types of analysis an organization focuses its resources on. For example, a single descriptive analysis use case is not as valuable as a single predictive analysis use case. Knowing what has happened is helpful, but not quite as helpful as predicting the future. This is the progression of analytics maturity. Each level ties directly to the types of questions we are trying to answer.

Answering the question “What happened yesterday?” is a much easier question to address in an organization than the question “What will happen tomorrow?” 

This is a simple example of analytics maturity. In principle, the more effectively an organization invests in technology, process, and their people, the more complicated questions they will be able to answer. The underlying assumption is that these more complex questions have more valuable answers for an organization.

We label the type of questions with types of analytics.

Descriptive = What happened?

Diagnostic = Why did it happen?

Predictive = What is likely to happen?

Prescriptive = How can we make something happen?

We tie the maturity of an organization to the levels of analytics it can effectively address.

A graph titled, "Analytics Maturity" that shows a traditional Analytics Maturity model.

Understanding Analytics Maturity Models

If you work in data science, analytics, business intelligence, or even IT, you have likely seen a version of the chart above. It is ubiquitous, to the point that it is almost cliche. Companies, like Gartner, have made a business around creating nifty little visuals like these and you will see them everywhere online. It is an excellent way to describe the difference between the main types of analysis. It is a great chart for visually exemplifying the different types of analysis.

However, people and companies misinterpret this visualization. They assume this is a roadmap. Moving from one type of analysis to another. This shouldn’t be the takeaway. In fact, having that be your final interpretation can be damaging to your company.

This misinterpretation tends to lead to an over-investment in Predictive and Prescriptive analytics within enterprises, while under-investing in Descriptive and Diagnostic analysis. That’s not to say that Prescriptive analysis isn’t the “holy grail” of business intelligence, it still is and will likely continue to be, it is that focusing on Prescriptive analysis shouldn’t be at the expense of more foundational analysis.

Where Do People Go Wrong With Analytics Maturity?

The main reason people misunderstand this chart is they assume you are moving from one type of analysis to another, going from Descriptive to Diagnostic to Predictive to Prescriptive. This is actually not the case. You are not moving from one to another, you are adding additional analysis types within your organization.

Let’s take a basic sales use case as an example.

Descriptive: What were our sales in July 2021?

Diagnostic: Why were our sales higher/lower in July 2021 compared to July 2020?

Predictive: What are our estimated sales for July 2022?

Prescriptive: What do we need to do to make sure sales in July 2022 are higher than July 2021?

You need to start with the descriptive questions and you progress from there. Undoubtedly, the prescriptive question is a much more valuable question to be answered, but the descriptive question is foundational in order to get to that point.

Analysis: Some companies make the mistake of over-investing in Predictive/Prescriptive analytics (and the corresponding resources and tools) at the expense of Descriptive/Diagnostic analytics (and the corresponding resources and tools). Don’t fall into this trap. Descriptive use cases will always continue to exist and are the foundation of more valuable analysis, such as diagnostic, predictive, and prescriptive.

If It's Not a Progression, What is it?

If it’s not a progression, how can we define it? Well, it’s really about foundation building.

Descriptive analytics is the foundation of diagnostic analytics. Diagnostic is the foundation of predictive analytics, and so on. Just like on a house, you need a solid foundation to support all of the other elements.

It is important to remember three things:

  1. Just because a single descriptive use case is (generally) less valuable than a single prescriptive use case, it does not mean that a descriptive use case isn’t valuable overall. 
  2. You will always have more descriptive use cases than prescriptive. As you move up the curve, you will have less volume at each of the levels.
  3. Prescriptive use cases also require prerequisite use cases at the other levels: Predictive, Diagnostic, Descriptive. Your organization will never stop using these.

Recommendation: Avoid over-investing in Prescriptive and Predictive analytics until you have a solid foundation to support your Diagnostic and Descriptive needs.

A graphic that shows the 4 types of analytics prescriptive, predictive, diagnostic, and descriptive

Keep Creator Personas in Mind

Your company’s infrastructure must support multiple groups, and each of those groups may have differing personas. 

The type of analytics an individual (i.e. persona) focuses on depends on their role and department within an enterprise. Invest in the tools that support both of these personas.

A graphic that shows the type of analytics an individual focuses on depends on their role and department within a business.

Line-of-Business Analysts generally will focus on Descriptive and Diagnostic use cases. They will tend to work on a higher volume of use cases (i.e. questions to answer). Where each individual answer may not be as valuable to the company as a whole, the total sum of the value provided is very high due to the volume.

Citizen Data Scientists and Analytics Engineers tend to support prescriptive and predictive use cases. They generally have a much smaller volume of use cases, answering a smaller set of questions, but the value of each of these answers can be higher.

Because of the differing focuses of each of these personas, it is important to select the right tool for that persona within your organization.

A 4-tiered graphic showcasing which tools are right for each persona within an organization.

For example, a line-of-business analyst is likely best suited with Power BI and Tableau. Where a citizen data scientist, or analytics engineering, may be better suited with Alteryx or Dataiku.

Conclusion

Don’t fall into the common trap of only focusing on the shiny predictive and prescriptive use cases. They are super valuable and worthy of investment, but they shouldn’t be at the expense of resources that support the more foundational analysis. Remember that these “lower levels” of analysis are foundational prerequisites for more advanced projects.

Looking for more resources on your journey to analytics maturity? Be sure to check out our guide on 5 Steps to Analytics Modernization: Real Solutions for Modern Analytics

Accelerate and automate your data projects with the phData Toolkit

Data Coach is our premium analytics training program with one-on-one coaching from renowned experts.