Start with the process, not the model

The problem is not the model

Most AI projects that stall halfway share the same pattern: the use case was chosen starting from what the technology can do, rather than from which process is most expensive to run by hand.

The proof of concept works, the demo impresses, and then nobody uses it. Six months later the system is still there, but the team is doing exactly the work it was doing before.

This is not a technical failure. The model may well have been a good one. What went wrong was the order of the decisions.

Why the wrong order feels right

Choosing from the technology side feels sensible because it can be demonstrated. There is something to show management, something measurable as progress, and a vendor ready to help.

Process mapping, by contrast, produces nothing you can present in week two. It produces understanding — which is precisely what determines whether the rest of the budget is wasted.

A company that has already been burned by one AI project usually finds the second one far harder to launch, even when the second is the right use case. That cost is rarely counted.

Three questions before writing code

We score every candidate use case against the same three questions. Not because they are complete, but because they are enough to eliminate most candidates that sound appealing but carry no value.

How many times a day does this run, and how many people run it? Frequency determines whether a per-cycle saving ever compounds into a number that matters. A process that runs three times a month is almost never worth automating first, however good the demo.

How long is one cycle, and where does the queue build up? What matters is not total duration but the point at which work waits. Automating a step that is not the bottleneck changes nothing at the far end.

If the output is wrong, who carries it and how expensive is it? This determines how much safeguarding must be built, and therefore the real cost. A use case that is cheap to build but expensive to get wrong is not a cheap use case.

If none of the three can be answered with a number, the use case is not ready — and what is needed first is measurement, not development.

Automation that does not change the queue on the floor has only moved the work, not removed it.

What we do first

Before building anything, we map the process as it runs today — including the steps that appear in no SOP but get done anyway. That is usually where the weight sits.

This mapping is almost always done with the people who run the process day to day, not only with management. Not because management is wrong, but because the real flow contains shortcuts, exceptions, and habits that never make it into any document.

Some of the findings that come up most often:

One person acts as the bridge between two systems, and the whole process halts when they take leave
The same data is retyped in three places because the systems do not talk to each other
An approval step that is formally mandatory but in practice always approved unread
A report assembled by hand every week and read by two people

Not all of this needs AI. Some of it needs integration, and some of it just needs the step removed.

Only then, the technical decisions

Once the process is clear, the technology choice becomes far narrower and far easier: does this need an LLM, would a rule engine do, or is it really just an API integration between two systems that have been bridged by copy-paste all along.

This order also changes how the project is discussed internally. When the use case comes from a process that genuinely burdens the team, the team does not need to be convinced the problem is real — they live it every day.

That is what makes the system get used after go-live, and in the end that is the only measure of whether the project succeeded.