My personal obsession: 5 Steps to Build an Enterprise Data Strategy, Straight From an Expert

Data can be a scary word.

It shouldn't be, but it is. Mostly because people struggle with how to manage it.

Many companies have reached the point where they have so much data, they don't know where to go next. Others believe they are so small, there's no need to invest in an enterprise data strategy.

The truth is, regardless of the size of your company and the current state of your data, you will benefit from implementing a data strategy.

To help you get started, we've enlisted the expertise of Zosia Kossowski, the group product manager for the business intelligence team at HubSpot (i.e. our in-house data strategy expert.)

By the time you finish reading this article, you'll have a better idea of your company's current data maturity level, what factors to consider before you build your strategy, and some steps to help along the way.

Despite popular belief, an enterprise data strategy isn't solely for big companies with large volumes of data. In fact, small businesses can benefit from investing in a data strategy early on and set the foundation that will help them scale.

Benefits of an Enterprise Data Strategy

The common pitfall many organizations face is that while they are collecting a lot of data, every team is interpreting it in their own way. There's no standard reporting method and each team might be reporting a different value for the same metric.

This means that everyone ends up with different data with no clear understanding of what's accurate. When there's no single source of truth, it becomes incredibly difficult to trust your data and pull valuable insights.

"Data doesn't just exist in a silo," said Kossowski. "The marketing team is not just going to use marketing-specific data that no other team has any influence over. They're going to want to pull information from different areas as well."

She continues, "And so, an element of governance and standardization and a common language is really important in making sure that those teams can communicate with one another."

So, by implementing an EDS, you prevent information silos, allow for trust in the data, and enable decision making.

What To Consider When Building an Enterprise Data Strategy

1. Your Current Data Maturity Level

The first thing Kossowski recommends doing before building out your strategy is a self-assessment.

Ask yourself: Where does your company fall in the data maturity stage?

Dell has a widely used "Data Maturity Model" that helps companies determine how data-driven their company actually is. There are four stages:

Data aware – Your company has not standardized its reporting system and there's no integration between your systems, data sources, and databases. Plus, there's a lack of trust in the data itself.
Data proficient – There's still a lack of trust in the data, specifically its quality. You may have invested in a data warehouse but there are still some pieces missing.
Data savvy – Your company is empowered to make business decisions from your data. However, there are still some kinks to work out between business leaders and IT, as IT works to provide reliable data on demand.
Data driven – IT and business are working closely together and are on the same page. Now, the focus is on scaling the data strategy because the foundation work (particularly integrating data sources) has already been successfully implemented.

What's most important here is being realistic about where your company falls.

"I think the biggest pitfall that I see is not being really honest with yourself about where your company is in the data maturity stage," said Kossowski.

She adds that it's not enough to look at the feelings you have about how data driven you think your company is. Look at the facts.

Start by identifying the data problems your company currently faces, as that is a great indicator of where you stand.

2. Your Industry and Company Size

The industry you're in and the size of your company will determine whether you take a centralized or distributed approach to your data strategy.

But before we break down those approaches, let's talk about two data strategy frameworks: offense and defense.

During my conversation with Kossowski, she brought up how this framework (explained in detail here) has helped HubSpot develop its own strategy.

Data defense prioritizes things like data security, access, governance, and accuracy while data offense focuses on gaining insights that will enable decision making.

Every company needs a balance of offense and defense. However, some lean more on one end of the spectrum based on their industry.

A healthcare organization or financial institution, for instance, likely deals with highly sensitive data, where data privacy and security is paramount.

Getting real-time data and quick insights is likely not a top priority whereas providing guardrails for who can access data probably is. As such, they will lean more toward a defense framework.

On the flip side, you have tech companies, an industry that tends to move quickly and relies more heavily on a quick turnaround of data insights.

So, they lean more on offense. With that said, there are certainly departments within tech companies (and other fast-moving industries) that will focus more on defense, such as finance.

Now back to centralized and distributed strategies.

The framework you use will inform which strategy serves your company best.

In a centralized structure, you have a centralized reporting or business intelligence (BI) team that manages and prepares the data as well as the reports.

"That [structure] can work a lot better at a smaller organization, and especially in an organization that's prioritizing defense because you're going to move slower," said Kossowski. "You're going to be the bottleneck but you also have tight control over every piece of it."

A distributed model, on the other hand, works better for larger teams who take the offensive approach. This way, each team can move quickly and is empowered to do work in a way that works for them.

In this model, BI simply is responsible for the platforms and setting the guardrails while the teams do the development work, Kossowski explains.

"If you think about an organization, as the company gets larger, with a more centralized team, it becomes more and more difficult to scale," she said. "You end up having to just hire more and more people to be able to achieve that."

"So I think at a certain size of the company, you're going to end up moving more and more toward [a] decentralized [strategy] anyways."

So, once you understand which framework works best for your industry and size, you can implement the appropriate strategy.

3. Your Data Management Team

Data science is the hot topic right now in data management, according to Kossowski. And she's not wrong.

In 2012, Harvard Business Review named it the sexiest job of the 21st century. Nearly 10 years later, Glassdoor has named it the second best job in America.

But if you're debating what role to add to your data management team, a data scientist shouldn't be your first option.

Kossowski highlights that your data science is only going to be as good as the data that's powering it. And if that data isn't trustworthy, you're not going to get valuable insights.

"Data science is not a magic wand that magically turns bad data into insights. Regardless, you're still going to need that data foundation," she adds. "So, jumping into doing something because it's the next big thing, I think that's a big concern."

If you're in the earlier stages of the data maturity model, Kossowski has a suggestion on where to focus your efforts.

"A data warehouse architect or even a data analyst who is experienced in writing SQL and building out SQL tables," she says. "If you're only going to hire one person and you don't have that much data, that can be a really powerful hire because there's a lot that one person can do when you're at a smaller scale. They can wear many different hats and learn different things."

When it comes to the more technical tasks, like ingesting data into the warehouse, there are third-party tools you can use to do that for you.

At this stage, what you really need is someone to help you with structuring your data.

1. Outline your data architecture.

The first thing you want to do is understand your data at a granular level.

Ask yourself these questions:

Where will the data live?
What type of data will you be collecting and from what sources?
How will the data be organized?

The goal here is to understand the structure of your data.

If there's no understanding of the structure, you can't build a comprehensive plan on how to manage your data.

2. Define the relationship between BI and your teams.

When it comes to data strategy, one of the most important steps is defining the teams involved in the process and setting expectations for BI.

In a large organization that hasn't thought about data strategy before, you'll often find that every team follows a different model and has a different relationship with BI, making it hard for BI to operate in a streamlined and standard fashion.

It also blurs the lines between the roles of the data analyst and BI.

The data analyst should know the business logic that is specific to their team and the structure of the data being collected. BI, on the other hand, shouldn't need to have specific knowledge on the operational area it is supporting, and should instead be focusing on the data source and managing the platform to support the analyst.

When BI is regularly adjusting its process to match the team's specific business logic, it slows everything down and creates a constant need for relearning.

Kossowki's suggestion? Strip the business logic out of the BI layer and work on things that are relevant to as many teams as possible.

In addition, come up with a standard analyst profile and a model for the relationship between BI and teams.

"There are still going to be some places where we're working on data sets and not the whole platform," said Kossowski, "but as much as we can, it's cleaning up the base data, making it easy to join, but not actually doing those joins and the logic for them."

3. Assign ownership.

After establishing the relationship between your teams and BI, the next step is defining who will own what.

It's typical to have a different owner for each part of the data. For example, one person or team may own the operational data while another owns the reporting data.

You may also need to assign owners at different stages in the pipeline. The BI team may own the data at a particular stage then pass it on to the analysts.

Kossowski believes ownership starts with the teams who are producing the data.

"They need to feel some level of ownership over the data and have some level of accountability if something's wrong," she said. "Because if it's wrong at the source, there's very little that BI can do."

She continues, "And if you try to put in patch patches at that level, you're just going to run into more problems down the line, so that relationship is important as well."

4. Establish data governance.

Data governance is a set of policies and regulations that inform how data will be collected and stored to ensure accuracy and quality.

In simple terms, data governance is saying "Hey, you want to use and be a part of this source of truth data we've created? Then you've got to meet this criteria."

This can include meeting coding standards, having a certain number of reviewers, and following a specific documentation process.

"When we think about governance and adoption, it's really about the mechanisms you can put into place toward adherence," said Kossowski.

There are two pieces that you have to consider when it comes to governance: the cultural piece and the technological aspect.

From a cultural perspective, how do you get your teams to adopt these standards? And from a technical perspective, which processes can you automate so that everything does not require behavior modification?

As you think of these two pieces, you have to consider both the analyst side and the engineer (or source team) side.

Kossowski explains that for engineering teams, it can be hard to think about what data looks like when it comes into the warehouse because it's not a core part of their product or responsibility.

They may not see the tangible benefits of the data unless it's a data-driven organization that works tightly with its analysts. In this case, the analysts can relay that the data is powering X decision, so until the data means Y requirements, decisions can't be made.

For analysts, it's easier to see the benefits because they're closer to the business and can see the direct impact. They can realize that following data governance standards means less reliance on BI, which makes things move more quickly.

"The insights from the data have to be powering decisions being made about the product because that's the only way you're going to get the product and engineering teams

bought into the value of data and thinking about their data as it is exported," said Kossowski.

5. Reassess regularly.

Wherever you fall on the data maturity model, your data strategy will always need some tweaking.

"[At HubSpot], we have a three-year plan and all these ideas of what happens in each of those years," said Kossowski. But I fully expect that a year from now, when we look at it, there are things we're going to want to tweak based on how things have changed."

For instance, say you introduce a new feature in your product or service and now are collecting more sensitive customer data. This may require taking a more defensive approach. If your company grows exponentially, you may need to shift toward a distributed strategy instead of a centralized one.

Even if there are no changes in how your company operates, you may still need to reassess. Here are two major indicators it's time to review your data strategy:

There is frustration with how long things are taking.
There's a lack of trust in the data.

Kossowski says finding the balance between those two is key.

"You don't want BI doing everything because then it's just going to take a long time," she said, "but you also don't want to have so much freedom in the analyst population that you can't really rely on any data."

A good rule of thumb is to review your strategy every six months to a year. Speak with business leaders, IT, and your teams to understand how everyone feels about your progress and determine what changes need to be made.

The process for building an EDS will vary from one company to the next, as your data maturity level, industry, and company size all play a role in the steps you take.

By taking stock of where your company currently stands, you can develop a strategy that meets the specific needs of your business.

from Marketing https://blog.hubspot.com/marketing/enterprise-data-strategy