SeriesFrom decision to deploymentPart 6 of 7
  1. AI Won't Fix a Chaotic Process. First Check You Have Something to Automate
  2. Don't Automate Your Most Important Process First. Pick One the Company Can Learn On
  3. Does Automation Pay Off? How to Build the Business Case Before You Invest in AI
  4. Do You Really Need an LLM? Picking the Right Technology for Process Automation
  5. From Excel to AI. Six Ways Companies Work With Data
  6. You Have Data and Reports. Why Don't They Lead to Better Decisions?
  7. The AI System "Works". But How Often Is It Right?

You Have Data and Reports. Why Don't They Lead to Better Decisions?

The sales and cost reports are ready. And yet the company can't approve a discount for a big customer without a fight.

The salesperson prices the deal on product margin. Finance adds transport and order-handling costs. Both calculations are correct. They just answer different questions. Until the company decides which one counts when a discount is approved, each side will defend its own number, and the customer will keep waiting.

You could produce another report, but a new table isn't what's missing. What's missing is a shared rule for pricing the deal.

That's one of several reasons why a company's information doesn't turn into decisions. Sometimes the data arrives too late. Sometimes preparing it depends on one person. Sometimes the report is finished and nobody uses it.

Don't grade the whole company. Pick one decision

"Are we good at using data?" is too broad a question to answer with a single verdict. Approving discounts, planning shifts and handling complaints can each look completely different.

Pick one decision that comes back regularly and that someone in the company knows from the inside. Ideally one where the team already feels the friction: delays, arguments, numbers that need double-checking.

Then take the last three to five comparable cases. For each one, reconstruct what information was needed, when it arrived, who prepared it, what rules were used to read it and what was finally decided. This isn't an audit. A simple table and a conversation with the people who were in the room will do.

That exercise separates four problems that, from the boardroom, all look like the same thing: "the decision is stuck again".

Four places where data stops helping

Four places where data stops helping: access, preparation, shared meaning and use. Check them in order, but the first problem you find isn't necessarily the most important one

1. Access: did the information arrive in time?

In the discount case, the missing piece might be as simple as current transport costs or the extra delivery conditions. The team knows exactly what it wants to calculate. It just has to wait for someone to hand over the missing number.

What to check: for each recent deal, was the full set of data available before the price was approved? If not, what was missing, and who could have supplied it?

First move: agree where that information comes from, who owns it and by when it's needed. For costs that can't be known precisely yet, agree on an estimate instead of waiting for the final invoice.

2. Preparation: how much work does an answer take?

The data may all be there, but each time the same person has to gather it, check it and run the numbers. When that person is out, the decision waits. Or the calculation is produced regularly, just too late to help.

What to check: how long did the calculation take for the recent deals, which steps were repeated every time, and could anyone else have done it?

First move: write down how the calculation is actually produced and remove the most tedious repeated step. If the work is fast, reliable and doesn't delay anything, leave it alone. Automation for its own sake isn't the goal.

3. Shared meaning: is everyone counting the same thing?

Back to the two margins. If sales and finance include different costs, they get different, equally correct numbers. The trouble begins when both sides present theirs as the answer to the same question.

What to check: ask both sides to recalculate the same handful of deals independently. Then compare which costs and assumptions each one includes. Are the differences deliberate, or did nobody ever agree on a definition?

First move: set one basis for the calculation for this type of discount decision. Write down which costs are in, where the data comes from and how exceptions are handled. That doesn't mean one margin definition has to serve every purpose across the company. It also won't fix errors in the source data by itself.

4. Use: did the numbers actually shape the decision?

A team can have a complete, current, agreed calculation and still not use it. Maybe the report doesn't answer the question the decision-maker is actually asking. Maybe nobody has said when a result needs a second approval. Or maybe the numbers are just one factor among several, along with customer size and the state of the relationship.

What to check: did the person approving the discount see the calculation before deciding, and what difference did it make? If they skipped it, why?

First move: decide what role the calculation is supposed to play for this kind of deal. Don't jump straight to a hard threshold. First find out whether the numbers genuinely help or are just an attachment nobody opens.

Check these four in order, because a gap in access or preparation will undermine everything downstream. But treat it as an order of investigation, not an automatic diagnosis. The first problem you hit isn't necessarily the most expensive or the most important one. And when you don't know, ask the person doing the work rather than guessing.

One problem, one change, one small experiment

Suppose the review of recent deals confirms the margin problem: two definitions, two numbers. What can you do without launching an IT project?

Start by measuring where you are. Take three to five comparable deals and count how many times sales and finance had to argue over how margin was calculated. Record how long it took to approve the price once the data was available. Don't cherry-pick the worst cases.

Then agree on one small change. Sales and finance settle which margin applies to this type of discount, which costs go into it and who rules on exceptions. One page of agreed rules. Not a new system.

Test it in practice. For the next two to four weeks, or one full representative cycle if the decision is rarer than that, work by the agreed rules. Keep tracking the same two things: the number of arguments about the calculation and the time it takes to reach a decision. Compare like with like, because an unusual order will take longer no matter how good the data is.

Watch for side effects too. Are approved deals being corrected more often? Do the discounts still meet the profitability criteria you agreed, and are any exceptions approved deliberately? Faster isn't a win if the decisions get worse.

Then decide. If the arguments disappear, approvals move faster and profitability holds, keep the change. If the arguments were rare to begin with, or nothing got faster, don't build it out any further. The real obstacle may be a multi-step approval chain, a vague discount policy or something the first pass simply didn't reveal.

That way the company does more than tidy up a margin calculation. It finds out whether this problem was really what slowed the decision down. A hypothesis that doesn't survive the test is a useful result too. It keeps you from investing in the wrong fix.

A small experiment instead of an IT project: measure the starting point on a few deals, agree one change, test it for a few weeks with the same two measures, then decide whether to keep it

Do you also need to predict what happens next?

Not every decision needs a forecast or an early warning. Those only earn their place when they let you do something differently. For discount approvals, a simple flag that a deal needs a second look may be all that's required. In other processes a forecast can be genuinely useful, but only if someone has the time and the authority to act on it.

An alert firing doesn't mean a better decision got made. What matters is who gets it, when, and what they do next. Not every signal like this needs AI.

The report is not the end of the process

A good report makes a situation easier to understand. It doesn't replace agreeing on what the key numbers mean, who makes the call and what they do with the information once they have it.

So before you order the next dashboard, pick one decision that keeps coming back and trace the last few times it was made. You may find that all it takes is agreeing on one definition, setting a deadline for one data set or changing how an existing report is read. And if it all works well enough already, there's nothing to fix.

And when part of the process is handled by AI, one more question comes up: how often does the system actually get it right?