Analytics creates value for an SME only when it changes a decision

A reporting or analytics project can have a budget, a delivery date and a named technical owner while still lacking the one thing that justifies it: a clearly named business decision.

That is a common approval failure. A dashboard is delivered, but nobody changes what they do. A forecasting model is accurate enough, but purchasing continues to rely on the previous routine. A data platform improves access to information, yet the operational problem that prompted the investment remains unresolved.

Delivering a tool is not evidence that a decision improved.

For SC-Analytics, the approval test should begin somewhere more concrete: which decision should change, who will act on it, and what evidence would justify continuing the work? Only then should the company decide whether it needs reporting, forecasting, optimisation, automation or a more advanced analytical method.

Why this matters for SMEs

The OECD has documented barriers that affect SMEs seeking to adopt and benefit from data-based technologies. These include gaps in resources, skills and organisational capabilities relative to larger businesses. This does not mean that every SME has the same problem, or that analytics is unsuitable for smaller companies. It means that a technically possible initiative may still fail if the business lacks the time, ownership, data or process needed to use it.

The practical implication is straightforward. Resources are limited, so a company should not judge a proposal only by whether the technology is available or the demonstration is convincing. It should ask whether the initiative can change an important decision under the real conditions in which that decision is made.

For example, a company may say that it needs “better forecasting.” That is a capability, not yet a project definition. The useful question is more specific:

> Which purchasing, production or stock-allocation decision should use a better forecast, and what should change as a result?

This distinction matters because different underlying problems lead to different solutions. A weak forecast may be the issue. But so might inconsistent product definitions, late sales inputs, unclear authority to change replenishment quantities, or a planning meeting that does not use the available information. Building a more complex model before identifying the decision can produce a good technical asset attached to the wrong operational problem.

The SC-Analytics approval test

Before approving an analytics initiative, document six points. They are not a substitute for judgement. They are a way to expose what is known, what is uncertain and what needs to be true for the work to be worthwhile.

| Question | What needs to be specified | Why it matters |

|---|---|---|

| 1. What decision should improve? | A concrete decision, not a technology label | It defines the actual problem to solve |

| 2. Who will act? | The person or role with authority in the process | Analysis has no effect unless someone can use it |

| 3. What measure matters? | An operational or economic indicator | It provides a basis for judging the result |

| 4. What are the constraints? | Data, timing, business rules, skills and maintenance needs | It prevents a design that cannot work in practice |

| 5. What will change in the process? | The new action, routine or workflow | It connects output to behaviour |

| 6. What is the pilot decision? | Criteria to continue, adjust or stop | It limits avoidable commitment under uncertainty |

The first three questions are the core of the test: decision, actor and measure. If a proposal cannot state them plainly, it is not ready for a technology choice.

The remaining questions matter because a decision does not happen in a vacuum. It happens at a particular time, with incomplete information, operating constraints and people who may need to override or validate a recommendation.

An illustrative purchasing example

Consider an illustrative SME distributor that wants to invest in demand forecasting. The original request is simple: “We need a machine learning forecast.”

That request should be reframed before any model is selected.

**1. Define the decision.** The decision is the weekly replenishment quantity for a defined group of products. The objective is not forecasting in the abstract. It is to give the planning team a demand estimate they can use when placing purchase orders.

**2. Name the actor.** The supply planner prepares the proposed order, while the purchasing manager approves exceptions above an agreed threshold. This matters because a model cannot alter stock levels by itself. The people involved need to know when to use it and who has the authority to depart from it.

**3. Define the measure.** The company might monitor stock availability, excess inventory and the time required to prepare the weekly order. These measures connect the initiative to service, working capital and process effort. They also make clear that forecast accuracy is not the only relevant result. A more accurate forecast has limited value if it does not improve the order decision.

**4. Identify constraints.** Historical sales may be available, but promotions may not be consistently recorded. Supplier lead times may change. Product substitutions may sit outside the ERP data. The planner may only have a short window each week to review recommendations. These are not technical details to leave until implementation; they shape what a usable first version can be.

**5. Specify the process change.** Instead of building a parallel report, the pilot could produce a recommended replenishment quantity for one product category before the existing weekly ordering routine. The planner reviews the recommendation, records material overrides and notes the reason for them.

**6. Set the pilot decision.** After a defined number of planning cycles, the company reviews whether the planner used the output, whether the recommendation was practical within purchasing constraints, and whether the agreed measures moved in the expected direction. The outcome is not automatically “scale.” It can be continue, adjust the data or process, narrow the use case, or stop.

This is only an illustrative example. Its purpose is to show that the project becomes easier to assess once it is tied to an actual workflow rather than to a preferred method.

Use pilots to test use, not only technical performance

The public summary of an academic chapter on analytics value creation proposes assessing initiatives through enabling capabilities, risks, beneficiary functions and business impact. It also recommends bounded pilots and a scoring system to help prioritise initiatives before substantial resources are committed.

That approach is particularly useful when a company has several possible projects: automating a reporting task, improving demand planning, scheduling capacity, reviewing margin, or building a new data foundation. A simple scoring method can compare expected value with effort, data readiness, operational risk and the availability of the people required to use the result.

However, the score should not create false precision. A project with a high estimated benefit may depend on unreliable source data or a process that changes every month. Another may offer a more modest benefit but be easier to put into regular use. The point is to make those differences explicit before the company commits significant time and money.

A bounded pilot should test two separate questions:

1. Can the analysis produce an output that is useful enough for the decision?

2. Does the responsible person actually use that output in the workflow?

Both questions are necessary. A technically sound model can fail the second test. Equally, a simple rule-based workflow may be enough to improve a decision without requiring a sophisticated model.

Choose the simplest solution that can improve the decision

Starting with the decision does not mean avoiding advanced analytics. Forecasting, mathematical optimisation, machine learning and automation can be justified when they improve an important decision enough to warrant their cost, complexity and maintenance.

But they should be proportionate to the problem. Sometimes the right first step is a clearer reporting definition, an agreed planning routine, a structured exception process or a rules-based recommendation. These options may be less impressive than a complex architecture, but they can be easier to understand, maintain and adopt.

This is a judgement call, not a rule against technology. The relevant question is whether added complexity produces a meaningful improvement in the decision, given the data available and the company’s ability to operate the solution after it goes live.

A practical stopping rule

Before selecting a platform, dashboard or model, ask six questions: What decision will improve? Who will act? Which measure matters? What constraints apply? What will change in the process? What would make us continue, adjust or stop the pilot?

If the decision, actor, measure and pilot criterion cannot be specified, the project should be redefined before technology is chosen.

That may lead to a smaller pilot, preliminary work on data or process definitions, a simpler solution, or a decision not to build anything yet. None of those outcomes is a failure. They are often the most disciplined way to protect scarce resources.

Process flow for evaluating an analytics investment

**Business problem and decision** → **Name the responsible actor and current process** → **Set the relevant measure and expected improvement** → **Review data, capabilities and risks** → **Run a bounded pilot** → **Measure adoption and impact** → **Continue, adjust or stop**

The value of analytics is not established when a tool is delivered. It is established when a relevant decision changes, the surrounding process supports that change, and the result can be assessed with reasonable discipline.

Sources

• OECD, *Data Analytics in SMEs* (2019): https://www.oecd.org/content/dam/oecd/en/publications/reports/2019/06/data-analytics-in-smes_1535d46b/1de6c6a7-en.pdf
• OECD, *The Digitalisation of SMEs* (2021): https://www.oecd.org/content/dam/oecd/en/publications/reports/2021/08/smes-going-digital_3b1e76c1/c91088a4-en.pdf
• Springer chapter public summary on evaluating analytics value creation and prioritising initiatives: https://link.springer.com/chapter/10.1007/978-3-032-08480-4_20

Only the public summary of the Springer chapter was reviewed for this article; its claims are therefore limited to the information presented there.