Henri Knyphausen, Managing Partner at Singulier by OMMAX, explains how to conduct an AI opportunity assessment so it ends in a decision rather than a list

Most AI opportunity assessments end with a long list. Hundreds of use-cases, each with a colour and a paragraph, handed to a board that then does nothing with it. Twelve months later the same organisation commissions the same exercise again. 

What I remind my clients is this: The list is not the deliverable. The cut is.

We ran an assessment across nine functions of a European healthcare group earlier this year, working with the CEO and about thirty people below him. Nearly a hundred use cases came out. Eight were worth starting. How you get from the first number to the second is the whole job, and it is described below with the client removed. 

Why AI Opportunity assessments usually stall

Four things go wrong, and they go wrong together. 

1. Value is asserted rather than sized. Every case claims an efficiency gain. Almost none states how many euros, on what revenue or cost base, over what ramp. Without a sizing logic behind each number, the list cannot be ranked, so it gets ranked by who argued hardest in the workshop. 
2. Feasibility is judged by whoever wants to build it. Ask a software vendor whether their product is feasible in your environment. Feasibility has to be scored against the data and systems that exist today, including the ones nobody wants to talk about, rather than against the roadmap. 
3. Speed is left out of the score. A case that reaches a working version in six weeks and one that needs sixteen weeks and regulatory validation are not the same case, even at identical value. Speed belongs in the score, not in a footnote. 
4. Nobody checks for overlap. The same underlying engine turns up in five functions under five different names, gets five separate business cases and, if nobody checks, five separate budgets. 

There is a fifth problem, and it is the one that actually kills these programmes. Nothing ever comes off the list. Everything stays a priority, so nothing starts. 

Score three things, and be strict about value 

Three dimensions, three levels each, one total out of nine. Three levels rather than a ten-point scale, because a ten-point scale invites everyone to award a seven.

The financial value row is where the discipline lives. Group-material means someone can write a euro figure on it that a CFO would recognise, with the driver and the base stated. Functional-scale means it matters inside one department and would never reach a board pack. Sub-material means it saves somebody a few hours a week, which is a real benefit and a bad reason to start a programme. 

What the distribution looks like once you apply it 

Two thirds of the ideas were buildable on data the group already had. Only one in nine carried value at group materiality. The two distributions barely overlap, and that gap is the finding. Most AI ideas inside a large organisation are easy and small. The interesting ones sit where the two overlap, and there are never many of them. 

Deprioritise is the most useful box on that page. Thirty-five cases went into it with a written reason, which meant thirty-five conversations did not have to be reopened in the next planning cycle. If an assessment produces no deprioritise list, it has not done its work. 

The quick wins deserve a word too. Fifty-two of them, all cheap, all fast, none of them individually worth a board discussion. Run them, but run them inside the functions and in parallel. They are the easiest way to spend a year looking busy while the eight cases that carry the value sit untouched. 

Look for the same engine under different names 

This is the step almost everyone skips, and it is where the money is.

Once every case is profiled, sort them by what they need underneath, not by who asked for them. More than half the list will usually collapse into a handful of shared capabilities. This one did.

External monitoring is the classic example. Commercial asks for a competitor tracker. Procurement wants supplier risk alerts. Legal wants a feed of regulatory changes. Corporate development wants deal screening. That’s four sponsors, four business cases and four names. Underneath, it is one engine: pull in external sources, classify them and flag what matters to whom. Build it once and each function gets its own view of it.

The test is simple. If two cases need the same data, the same kind of model and end in the same type of workflow, they are one case with two users.

Once you cluster this way, the sequencing question changes. Most of the top priorities feed a few shared engines, so the debate stops being about which function gets funded first and becomes which foundation gets built first.

We backed the planning cluster first, because the value was concentrated there and the systems were already close enough to attach to. That was a judgement call made with the client in the room, not an output of the model.

Sequence it, and say what you would accept as failure 

A word on readiness 

One group we assessed had roughly 150 enterprise chat licences and about twenty people using them in any given week. That ratio told us more about readiness than any maturity model would have. It also shaped the recommendation. Where a business already runs a lean, largely offshore cost base, AI framed as headcount reduction has almost nothing to work with. The value sits in decision quality, in launches, tenders, deal screening and stock cover, and it shows up on the top line.

What you should be handed at the end 

• A workbook, not a deck. Every case profiled with its type, users, data sources, sizing logic and score, filterable and re-scorable by the client’s own team. 
• A named owner for every case in the top quadrant. A use case with no owner is an idea. 
• A written deprioritise list with reasons, so the same suggestions do not return next quarter. 
• A shortlist small enough to actually start, with a dated decision gate against it.

Five things to insist on

1. Make the sizing logic explicit. Force a euro figure and a stated driver on every case. Anything that cannot carry one is a quick win, and should be labelled as such. 
2. Score feasibility against today. Data, systems and regulatory constraints as they are, not as the roadmap promises. Someone from IT has to be in the room while it is scored. 
3. Put time to build in the score. Six weeks and sixteen weeks are different answers even at the same value. 
4. Cluster before you cost. Do the clustering before the business cases. Otherwise the same engine gets funded three times under three sponsors. 
5. Insist on a deprioritise list. An assessment that recommends everything has recommended nothing. 

The core message 

Let’s talk 

If you are trying to work out where AI genuinely creates value in your business, which cases to fund first, and how to avoid building the same capability four times, our Data & AI and strategy teams run this diagnostic in three to four weeks, with the scoring model handed over. Get in touch with our experts now.