AI transformation for SMEs: ten steps that actually work

We have sat in a lot of rooms where the AI conversation opens with somebody's laptop already turned around, showing a demo. The mood is usually a mixture of curiosity and quiet dread — curiosity because the demo looked impressive, dread because everyone present is already running at capacity and now there is a new thing to be behind on.

If that is roughly where you are, we want to say something that will not sound like it came from a vendor: you are not late, and you do not need a transformation programme. Most of the companies we work with are 50 to 500 people, have no data team, and are carrying a list of operational problems much older than AI. The ones that get somewhere are almost never the ones who started biggest. They are the ones who picked something small and unglamorous, finished it, and then did it again.

What follows is ten steps, in the order we have found they actually need to happen. We have made most of these mistakes ourselves — the fifth one twice — so where something went wrong we have said so rather than tidying it up.

Step 1 — Start from a frustration, not a technology

The opening question is never "what could AI do for us?" It is "what in this business makes people sigh?" Those are different questions and they lead to completely different projects.

When we run the first session with a new client, we ask four or five people in different roles one thing: what did you do last week that you resented doing? Not what was hard — hard work is usually the interesting part of someone's job. What was repetitive, mechanical, and needed them without deserving them. The answers are rarely what the management team predicted, and they are almost never what the demo was about.

Then turn the answer into a number you can check in ninety days. "Quotes take too long" becomes "a quote currently takes eleven days from enquiry to sent, and we want seven." Without that, you will have no way to tell whether anything improved, and the conversation at the end of the quarter becomes a matter of opinion.

Step 2 — Map the work before you automate any of it

Draw the process. On paper is fine. Every handoff, every place where something waits, every step that exists because a person who left in 2019 preferred it that way.

Two things fall out of this exercise almost every time. The first is that the delay is not where management thought it was — the work itself takes forty minutes and then sits in somebody's inbox for three days. The second is that a chunk of the process can simply be deleted, with no technology involved at all.

Step 3 — Find out what your data will actually let you do

This is the step everyone wants to skip and nobody can. Not because your data needs to be clean — it will not be, nobody's is — but because you need to know what exists, where it lives, who owns it, and what is not allowed to leave the building.

That last point matters more in manufacturing than almost anywhere else. If you are a subcontractor, the drawings and specifications on your server belong to your customers and you are holding them under contract. A great many of those contracts prohibit disclosure to a third party without written consent, and uploading a file to a cloud vendor is disclosure. We have watched a genuinely promising pilot stopped by a legal review in week nine, after the effort had been spent. Have that conversation in week one instead. It takes an afternoon and it changes your shortlist.

• A one-page inventory: which system, who owns it, how sensitive, how reliable.
• Your red lines, written down — what may never go into a tool you do not control.
• An honest note about quality, so nobody is surprised when the first results are mixed.

Step 4 — Choose tools for fit, not for capability

The most capable tool is frequently the wrong one. What matters for a company of your size is whether it fits the way your people already work: does it read from where the work already arrives, does it write into the systems you already have, can one person administer it without a specialist on retainer.

Ask every vendor the same three questions, and notice which ones answer directly. Does it solve a problem we named in step one? Does it respect the red lines we wrote in step three? Can our team adopt it without a project of its own? And then run the test that separates the serious vendors from the rest — send them your five worst files, not their demo set. The scan with the coffee ring on it, the one somebody annotated by hand, the fax. Ask for the raw output.

Step 5 — Pick one use case and actually finish it

We have made this mistake twice, so we will be blunt about it. Running three pilots at once feels like momentum and is the opposite. Pilots are cheap to begin and awkward to finish, because the last twenty per cent is unglamorous integration work that nobody enjoys. Start three and you will have three things sitting at eighty per cent and a team that has quietly concluded AI does not work here.

One use case, carried all the way to people using it for real work, teaches you more than five pilots ever will — about your data, your approval process, your appetite for change, and what your team actually needs from a tool.

Step 6 — Teach in small loops, not in workshops

We run AI courses, so we have a professional interest in telling you that training is the answer. It is — but not in the format most companies buy. A full day of AI training produces a room of people who enjoyed the day and cannot reproduce any of it on Thursday.

What works is twenty minutes of learning attached to twenty minutes of doing, on something live, every week. One skill, applied immediately to a real task, with somebody to ask when it goes wrong. It is slower to describe and far faster in effect.

And be careful who you train. The constraint in year one is not model capability — it is the number of people who can look at an output and tell whether it is right or merely plausible. Five people who can do that are worth more than fifty who have seen a demo.

The question is never whether your team is willing. It is whether the training format respects how little uninterrupted time they have.

Step 7 — Design the human check in from day one

AI can be useful and wrong in the same sentence, and the wrongness is often fluent. That is what makes it different from the software your team is used to: when a spreadsheet breaks, it looks broken.

So decide in advance where review is mandatory — anything leaving the company, anything touching money, anything entering a controlled document. Under AS9100 or IATF 16949 this is not a preference. "The system decided" is not a record, and an auditor will tell you so.

There is a second reason, and it is the one that decides adoption. People do not abandon a tool because it is occasionally wrong. They abandon it when they cannot tell which outputs to trust, because then checking costs as much as doing the work themselves. Confidence scores, a visible source for every claim, and a one-click way to reject something are not polish. They are the difference between a tool used in month six and a licence nobody opens.

Step 8 — Write the rules on one page

Governance in a company your size does not mean a framework. It means one page that a new starter can read in four minutes: which tools are approved, what each may be used for, what data is forbidden, where outputs are stored, and who to ask.

We have seen more initiatives stall from rules that were too complicated than from rules that were too loose. If the policy needs a meeting to explain, people will quietly route around it, and you will end up with customer drawings in a free chatbot because somebody was busy and the official path was tiresome.

Step 9 — Stop collecting tools, start building a system

Somewhere around the third or fourth successful use case, the nature of the problem changes. You are no longer evaluating tools; you are accumulating an operating model, and if nobody is tending it you are also accumulating risk.

The classic failure is a brilliant colleague whose prompts live in a personal notes file. When they take a fortnight off, the capability takes a fortnight off with them. Centralise the prompts, the approved templates, the places outputs are stored. It is unexciting work and it is what turns a collection of clever individual habits into something the company owns.

Step 10 — Make it a rhythm, not a project

Projects end, and a transformation that ends was a purchase. What we look for after the first year is not a finished state but a cadence: a monthly review of what is working, a quarterly decision about what to scale and what to stop, and a roadmap that covers two or three quarters rather than three years.

And talk to your organisation honestly while this is happening. Silence gets filled, and what it gets filled with is the assumption that this is about headcount — which will cost you exactly the cooperation of the experienced people whose knowledge the system needs most. Say what is changing, say what is not, and say how you will measure it.

If you want a thirty-day start

You do not need all ten steps before you begin. Here is the smallest version that still teaches you something real.

At the end of it you will not have transformed anything, and that is the point. You will know whether this helps, which is worth considerably more than a strategy deck that assumes it does.