Cdo

In this article, we are going to review the elements of a good analytics planning framework and how analytics planning is part of data product ownership in the data mesh.

What Is Analytics Planning?

As part of any CDO or CDAO role, there is both data and analytics governance and a process for ensuring that analytics and insights are generated from the right data to solve a variety of business problems.

To make sure that data products (i.e., dashboards, insights, commercialized analyses, etc.) in the data mesh are fit for purpose, the business and analytics problem framing must occur to have workable high-impact solutions.

Analytics planning and next-generation analytics are helpful to a variety of stakeholders—chief data analytics officers, chief data scientists, heads of marketing analytics, and heads of digital analytics.

Many times, data analytics is a center of excellence, and therefore is vital for the professionals in the COE to have a seat at the table whether that is with a data product owner, a tribe lead, or a business person. This linkage and relationship are vital, not only from a relationship management standpoint but to enable the right data mesh design by helping to identify the right analytics and data products. The goal is to get the data needed to improve business decision-making and monetization.

What Type Of Meeting Or Committee Does Analytics Planning Require?

Analytics liaisons and data stewards from the COE should meet with data product owners and business people in what I call data analytics governance meetings where the types of analytics and data products are discussed. This is a “seat at the table” meeting among business partners to discuss the appropriate types of proactive analytics that would drive problem solutions and business impact.

Data analytics topics to be discussed include:

• Data requirements
• Descriptive analytics
• Predictive and prescriptive analytics
• Data products and monetization tactics

These leadership meetings should occur at least quarterly. Monthly (or more frequent) reviews should occur at the project team level. Typically, data analytics functions can have hundreds or thousands of projects depending on the number of business partners.

What Is The Business Purpose Of These Planning Meetings?

For analytics or data products to be fit for purpose, you will want to review the partner's business strategy as well as any P&L drivers where analytics might have an impact:

1. Frame the business problems and opportunities.
2. Determine if the data mesh/data fabric can support these efforts.
3. Then decide what the deliverables/solutions are and the path to deploy. Don’t lead with models, analyses, or research outputs. Ensure that if you build a solution there is a commitment from the client to deploy it with an understanding of the potential business benefit.

Data analytics governance creates a prioritization process.

The prioritization process could include business ROIs, GCOs (good customer outcomes), or other metrics to determine what gets worked on first. Are these projects high priority, medium, low, strategic, or even non-negotiable? (Non-negotiable might mean compliance projects which means the data analytics team must carve out bandwidth to create new data pilots/new analytics pilots. Pilots could include identification of new segments or new scoring systems based on transaction data and more.)

Data Analytics Planning — It All Goes Back To Business Problem Framing.

What is the number one reason analytics fail? We hopefully all know this, but it is worth mentioning again: the number one reason analytics fail is due to a failure to frame the business problem correctly.

What type of problems may clients mention to the data analytics team during the quarterly check-ins?

1. How are we improving against customer expectations?
2. Are we connecting with prospective customers?
3. How do we qualify sales leads for better cross-sell/upsell?

Analytics Problem Framing: Choosing The Type Of Analytics Method To Solve The Problem.

Let’s review the categories of analytics that may be part of the discussion during the analytics planning meeting with the business and product owners.

• Metrics and measurement. How does the business person or product owner run their business line? That which is measured is actioned.
• Setting KPIs becomes a focal point for understanding key drivers of any problem and provides the jump-off point for additional analytics.
• KPIs and metrics are considered more of a BAU type of analytics and answer questions such as:
  • How many customers do we have in which segments?
  • How many and what channels are they using?
• Describing and profiling: often helps define customer behaviors.
• Which customers are profitable? Helps understand the 80/20 rule.
• What prospects are similar to our customers? Look-alike profiles, etc.
• What is the financial situation of our customers—are they wealthy, what life stage are they in, etc.?
• Knowledge discovery: surface unknown patterns which customers have. For example, if you're in a bank, are certain checking customers diminishing their balances which may mean they're taking their money out and potentially putting it elsewhere? Intervention strategies can be designed from this type of knowledge discovery.
• Segmentation and clustering: grouping customers by homogenous groups, for example, based on their value, life stage, potential, etc.
• Algorithms and prediction. Many data science and statistical methods can help to predict the customer's responsiveness, next best action, right channel to engage, risk level, and more.

So that's a little bit about how to match the business problem to the type of analytics. The next step would be for the analytics leader or analytics liaison to work with the data product owner or business lead to provide an endorsed quarterly data analytics plan which would also identify data needs in order to perform the agreed-upon analytics.

What are the elements of the analytics plan?

1. A list of prioritized BAU initiatives that have been agreed upon from the meeting with the product owners along with business goals and projected returns generated from insights.
2. Agreement on the type of analytics deliverables and the path to deploy. For example, will this model be scored on an ongoing basis to provide targeted leads to salespeople? If the business person or the product owner declines to leverage learnings, then these analytics should be prioritized as low or even canceled.
3. Agreement to proactively serve up new analytics. Some level of innovative pilots should be part of any analytics planning framework. This approach takes the data analytics team out of defensive mode and puts them in an offensive, proactive, and prescriptive position.
4. Analytics planning includes an agreement to do an ongoing blueprint and roadmap for analytics which includes an assessment of the maturity level of the firm’s data analytics. Unfortunately, many of the maturity models that exist only focus on data governance and don’t connect the dots between data maturity and data analytics maturity. A data analytics maturity assessment and blueprint must include looking at the level of next-generation analytics that the firm is developing and testing including RPA, generative AI, machine learning, and more. One view in the plan should assess the level of defensive data analytics the team is involved in versus offensive analytics. (Get in contact with me if you need more information about this maturity model.)

Given the data mesh puts a higher degree of quantitative skills on business partners, it is imperative for all stakeholders to have a better understanding of data, analytic methodologies, and execution. Training and knowledge maturity is critical.

I hope this post helps fill in some of the planning gaps in the data mesh concept and shows how analytics planning can inform what the data product owners can work on and how an ongoing engagement and governance model can be established to benefit both the analytics team as well as the business as a whole.

What has your experience been with data analytics planning in the data mesh? We look forward to hearing your thoughts.