AI Strategy for SMEs: One Concept Instead of Isolated Tools

Almost every SME I talk to is now doing something with AI. And almost every one has the same problem: it does not know whether what it is doing fits together.

The pattern is remarkably uniform. Marketing runs a tool for copy. In sales, somebody set up an assistant that prepares quotes. Accounting is testing document recognition. IT has heard about some of it. Nobody can say what it delivers in total, what it costs, where the data ends up, and what happens if the vendor doubles prices tomorrow.

That is not an AI strategy. That is a collection of experiments.

Why isolated tools appear

They do not appear out of stupidity, but as a reasonable reaction to pressure. The pressure is real: everybody is talking about it, the competition is supposedly already doing something, and the tools are cheap and set up in ten minutes. Waiting until a strategy is finished feels like missing out.

And the individual experiments mostly work, too. The copy gets faster, the quotes cleaner. The problem only shows up later, and it always shows up in the same three places.

The data. Every isolated tool needs access to something. Customer data, prices, contracts, internal documents. When that happens independently in five places, nobody has an overview of what information the company has handed where.

Operations. A tool used day to day is a system, even if nobody calls it that. It fails, it changes, it needs somebody responsible. With isolated tools, the responsible person is whoever set it up back then – until they leave the company.

The benefit. Five small efficiency gains in five departments rarely add up to an effect you can see in the income statement. The big lever almost always sits where a process crosses departmental boundaries – and that is exactly where no isolated tool reaches.

What an overall concept means

An overall concept is not a hundred-page paper. It is the answer to four questions you can work out in a few days.

First: where do we create value, and where do we lose time? Not "where could we use AI", but "where is effort in the worst relation to results". Those are rarely the places where the AI discussion normally starts. Often it is not marketing but order processing, quote preparation, or the data upkeep between two systems that were never properly connected.

Second: what data do we really have, and in what state? The most common reason an AI undertaking does not deliver is not the model but the state of the data. Without a clean customer history you will not get a meaningful analysis out of it.

Third: where do things run, and who owns them? That is the question most readily postponed and most expensive when postponed. For many Swiss SMEs the answer is a cloud environment with clear data handling; for others it is their own infrastructure. Both are legitimate. Having no answer is not.

Fourth: where do we start? An overall concept that begins with a twelve-month programme is dead before it starts. It needs a first use case small enough for one quarter and big enough that somebody notices the difference.

Strategy first, then code

I do it in this order not because it sounds good, but because the reverse order is expensive.

If you build first, you get software that implements a process nobody questioned beforehand. The result is a fast, digitised, bad process. That mistake used to be affordable, because building took long enough that thinking happened along the way anyway. Today building is so fast that the mistake goes through unchecked.

That is why many of our development projects grow out of a consulting mandate. Not because I enjoy consulting, but because otherwise the implementation starts in the wrong place.

The pragmatic way in

If I had to recommend an SME a starting point, it would be this: take half a day with the three or four people who really know the processes, and write down where in the company the most time goes into activities nobody enjoys and nobody would miss. That is not a technology question, and that is exactly why it works.

That list almost always yields a first case worth doing. And because implementation is no longer the bottleneck, the result is not there in a year, but in weeks.

In the next article I break down where the saving of roughly two thirds that I see in development projects comes from – and where it explicitly does not.