← All posts

AI strategy for the Mittelstand: the first ninety days

Most AI strategies are documents nobody implements. A concrete sequence for the first three months: which process to take first, how to judge it, and how to tell when to stop.

July 26, 2026aimittelstandstrategy6 min read

Most documents called an AI strategy are read once and never opened again. They contain a market overview, a five-stage maturity model, an eighteen-month roadmap, and a list of focus areas. What they do not contain is an answer to the only question that matters in the Mittelstand: which process do we touch on Monday?

This is a sequence for the first ninety days. It is deliberately small. At the end there is no transformation programme, just a system running in production and a defensible basis for deciding whether a second one follows.

Why strategy-first does not work in the Mittelstand

The approach of developing a company-wide strategy first and implementing afterwards comes from organizations with their own delivery teams. It makes sense there: if you have to coordinate thirty engineers, you need a direction first.

In the Mittelstand the ratio inverts. You do not have thirty engineers, you have two people in IT and an external partner. The scarce resource is not direction, it is delivery capacity. A strategy that names twelve focus areas while you can implement one per year is not a plan, it is a wish list.

There is a timing problem on top. An AI strategy written in spring and implemented in autumn plans around assumptions about models and prices that are obsolete by then. The market moves faster than the planning cycle.

So the workable order is reversed: one process, one production system, then the question of strategy. After the first system you know things about your own company that no consulting document could contain. For instance, how clean your data actually is.

Day 1 to 30: choose the first process

The goal of the first month is a decision, not a concept. You are looking for exactly one process.

Collect candidates where the work actually happens, not in the management meeting. The most useful input comes from employees who can answer one question: which task do you do every week that feels like a machine could take it over? Ten to fifteen candidates is enough.

Judge each candidate against four criteria:

Criterion Good sign Bad sign
Frequency daily or weekly a few times a year
Inputs unstructured but already digital on paper or in people's heads
Cost of error a mistake is annoying, not expensive a mistake costs you a customer
Owner a named person wants it nobody feels responsible

The fourth row decides success more often than the first three. A technically perfect candidate without an internal owner will not be used after rollout. Whether a candidate also carries itself commercially is what the formula in automating business processes is for.

Two patterns that regularly turn out to be good entry points in the Mittelstand: extracting data from recurring documents, such as supplier invoices or orders that arrive in twenty different layouts. And drafting responses to recurring inquiries, where a human reviews and approves the draft instead of writing it.

At the end of the first month you have one sentence on one page: we are automating this process, this employee owns it, this number should measurably change.

Day 31 to 60: build a system that runs

The second month is for building. The most important principle concerns the role of the human in the loop.

Build the first system so that it proposes and a human confirms. Not because the technology could not do better, but because at this stage you need data about quality. Every confirmation and every correction is a measurement. After four weeks you know in what percentage of cases the system was right, and that number is what every further decision rests on.

Three things often overlooked in this month:

  • The failure case belongs in the first version. What happens when the model does not respond or returns nonsense? If the answer is that the process stops, the system is not production-ready.
  • Measurement belongs in the first version. If you only start counting after rollout, you have no baseline.
  • The storage location is decided now, not later. Whether your data goes to a provider in the US, to a data center in the EU, or onto your own hardware is an architecture decision. Changing it afterwards means rebuilding the system.

Day 61 to 90: operate and decide

The third month is the one most projects skip, and the only one that proves whether something works.

The system runs in daily use with real users. You watch three numbers: the hit rate from the confirmations, the time saved per case, and the number of cases where somebody works around the system. The third is the most honest. If employees find a way past it, that is a verdict on the solution, not on the employees.

At the end of ninety days you reach one of three decisions:

Expand. The hit rate is high enough, the time saving is real, people are using it. Now you can take the human out of some cases, for instance where the system is especially confident, and concentrate review on the uncertain ones.

Adjust. The benefit is there but the hit rate is not sufficient. Usually this is down to the input data, not the model. Another month spent on data quality does more here than a larger model.

Stop. This happens, and it is not a failure but a result after three months instead of two years. You now know this process does not suit, and you know why.

What comes next

After the first system you have something no strategy document can deliver: a measured figure for effort and benefit inside your own company. That lets you judge the second candidate seriously, and the third one too.

From roughly the third or fourth system onwards, cross-cutting questions become relevant. Where does the data live that several systems need? Who decides which model gets used? What rules apply to review and approval? That is the point where an AI strategy becomes worthwhile, and by then it describes conditions you actually know.

If you look for outside help at that stage, ask for AI strategy consulting that thinks from operations, not from a maturity model. The difference shows quickly: a consultant who asks first about your data sources and your ownership has operated systems before. One who opens with an industry overview has built presentations. Five questions that settle this in a first call are in our buyer's guide to choosing a vendor. How we offer this ourselves is on the AI consulting for the Mittelstand page.

The honest objection

There are cases where strategy first is right. If AI becomes part of your product rather than just your internal processes, you are deciding on architecture, liability, and pricing model at the same time. A pilot then saves effort at the wrong end.

For anything concerning internal processes, and in the Mittelstand that is the large majority, the reverse order applies. Ninety days, one process, one measured number. That is less impressive than an eighteen-month roadmap, but at the end something is running.

If you have a specific candidate in mind and want to know whether it fits: thirty minutes with an engineer is enough for a first assessment.

All posts

Thirty minutes with an engineer.

No sales, no slide decks. We reply within one business day.

Email

info@liermann.engineering

Phone

shown via JavaScript

Haan, Germany

Book a slot

30 minutes, video call, English or German.