How do you make data-driven decisions?

Few organizations lack the ambition to work data-driven. Data is everywhere, and whoever doesn't use that data to steer their business will sooner or later be left behind. At least, that's the prevailing opinion in the business world, and of course we wholeheartedly agree. So we want to work data-driven. But how do you do that? And what does it actually mean, making data-driven decisions? In this blog, Data Strategy Leader Louis de Roo explains it to you.

What data-driven decision-making is not

Let's start by naming what data-driven decision-making is not, because not all use of data actually contributes to data-driven decision-making:

• Data-driven decision-making is not: looking at a list of results, and then deciding based on your experience or intuition.
• Data-driven decision-making is also not: conjuring up all available data on a screen and expecting everyone to understand what needs to happen.
• Data-driven decision-making is certainly not: making your decision based on gut feeling and then finding the data that supports your decision.

The examples above may seem obvious, but in daily practice they occur all too often: after all, what's the alternative? Blindly trusting your data and the underlying logic? Is the quality of the data actually good enough? Is the logic even correct?

Which decision do you want to make?

The key lies in figuring out which decision you would actually want to make with your data. Years of output-driven business operations have taught us to look at the outcomes, and then examine the preceding process to see where we can optimize without negatively affecting that output. But a data-driven decision works differently. With a data-driven decision, you try to make an optimal choice as early as possible in the process, after which your process delivers the desired result as smoothly as possible. Analyzing the end results can help further optimize the process, but comes too late to make fundamental decisions within the process. On top of that, at the output side of your process you're much more dependent on all kinds of exceptions that can occur throughout the entire process, which will in any case require special attention — after all, every process exception means the regular steps could not be followed.

For example, measuring your delivery time to customers definitely holds valuable insights, but for improving your process, that information comes too late. A good data-driven decision would be to increase or decrease your stock position based on your sales forecast, so that you always have enough in stock to deliver without delays. Looking at the realized delivery time then allows you to see whether you achieved your goal, and to flag any exceptions, but that evaluation needs to be fed back to the stock reorder point before you can make a truly data-driven decision here.

Mapping out your process

So it's essential to realize that some decisions don't become better by making them data-driven, and that it's important to properly map out your process before pulling all kinds of random data off the shelf to steer your process. As if that bit of self-reflection weren't enough, there's then the honest task of thinking carefully about the logic you need to apply in your data-driven decision: at what threshold value should you take action? What are the signal points? Which metrics do you respond to, and which don't you?

Scalable decisions

Setting up a data-driven decision mechanism is complex, and requires time and insight. This is also the reason why, for many organizations, the reflex is to just go back to the familiar way of doing things. After all, that's less 'work'. For a single decision, that's also true. Building decision logic to solve a one-off issue is, for that reason, also a waste of money and resources. We therefore look for those decisions that can contribute to better results in a scalable way.

Data-driven decision-making is therefore, first and foremost, about figuring out which decisions will actually get better through the use of data. And then letting those decisions improve your process. Then there's nothing wrong with looking back at the data afterward and being satisfied with your results.

Written by Louis de Roo
Data Strategy Leader