Operations is the work between your people, your systems and your machines. What AI does and does not do there, what an operations engineer spends the week on, and the six places it breaks down.
The word is on almost every job posting, every org chart and every vendor website, and nowhere does it mean the same thing: operations.
To one company it is the warehouse. To another it is the servers. To a third it is everything that is not sales or marketing.
We use it in a narrower, more concrete way. Operations is the work between your people, your systems and your machines. The handover, in other words. The moment something that happens on the floor has to end up in a system in the office, or the other way around.
An incoming order is not an operation. The fourteen steps after it are: checking stock, picking, packing, labelling, shipping, invoicing, and the four exceptions nobody ever wrote down. That is where the manual work sits, that is where the errors sit, and that is almost always where the first gain is.
Operations is not a department. It is the layer that ties your departments together. Wherever that handover is manual, it is slow and error-prone. Not because your people are careless, but because retyping carries a failure rate and costs attention that is needed further down the line.
Scanning, weighing, measuring, signing off, photographing. What happens on the floor has to reappear in the system the business is run from.
Webshop, ERP, WMS, CRM, accounting, planning. Six systems that each hold part of the truth, and rarely agree with one another.
Counters, sensors, temperatures, downtime. A machine has known what is happening all along; it is the route to the planner's screen that is missing.
Who picks this up, who approves it, who hears about it when it goes wrong. The handover that most often lives in someone's head and nowhere else.
Search for operations engineer and you get roughly two professions back. The first is the IT one: someone who keeps software running. Servers, deploys, monitoring, incidents. In most companies that role is now called DevOps or SRE, and it is about the layer underneath your systems.
The second is the one most companies are actually looking for, and the one we mean: someone who builds the process itself. Not the layer underneath, but the operation on top. We call that person a forward-deployed engineer. Not an advisor writing a report from a distance, but a builder who comes and sits inside your business. Here is what the week looks like.
Next to the people who do the work, writing down what actually happens instead of what the manual says.
Where does which data live, who owns it, and what is the source of truth when two screens disagree.
Those decide whether an automation still works three weeks in. Not the happy path, which always works.
Bounded, with a value that can be measured. Everything next to it is the second module, not the first.
Connect it to the systems already in place, ship it, and check whether what we assumed holds up.
AI for operations is a different thing from AI for marketing or AI for support. It is not about producing text, it is about a step in your process that genuinely gets executed, with the same controls and logging as any other system you put into production. Not a chatbot glued to your website. Four things make the difference.
A PDF purchase order, an email with a change halfway through, a handwritten docket, a photo of a pallet. Language models have become genuinely good at that, and it is exactly where processes stall: not at the arithmetic, but at making sense of messy input.
By your rules, and it hands over what it is unsure about. A good automation does not pretend it can do everything. It settles what is clear and puts the rest in front of a human, and you set that line yourself.
A line in your ERP, a status in your WMS, a draft invoice, a message to the customer. An answer on a screen is not an automation yet.
Every step logged, every exception visible, every decision reversible. Without that it gets switched off at the first mistake, and rightly so.
Always the same question: where is the handover, and who is doing it manually right now?
Orders arrive through the webshop, by email, through a large customer's portal and over the phone. Every channel has its own format and the same ending: someone retypes it. If there is a change, it happens again. Automatable: reading the order regardless of where it came from, checking it against stock and agreed pricing, creating it in the system, and only escalating the doubtful cases.
Paper pick lists. Stock differences between the warehouse, the ERP and the sales channels. A check at packing that mostly consists of looking again. Automatable: scanning at intake and location assignment, guided picking with validation at the pack station, stock that stays in sync across one chain, and returns processing that pulls itself through the steps.
Batch numbers, weights and quality measurements on paper or in loose files. Weighing, labelling and software systems that do not connect. Automatable: recording at the place where the action happens, connected weighing and labelling stations, count and status signals from sensors or a PLC, and a traceability file that builds itself. Often with one small, smart link in between: a scanner, a sensor or a gateway.
Job sheets retyped at the end of the week, so the invoice waits with them. Purchase invoices coded by hand. Automatable: capturing on site including materials, hours and sign-off, an approved job sheet waiting as a draft invoice, and purchase invoices matched against the order before anyone looks at them.
Meter readings someone has to walk around and collect, reports arriving by email, maintenance tracked in a spreadsheet that only stands out once something breaks. Automatable: readings that report themselves, a report that lands straight with the right party along with the details of the asset, and maintenance planned on usage instead of on the calendar.
Camera and sensor feeds on a screen somebody has to watch, which therefore only works while somebody is watching. Automatable: detection that raises the alarm itself, with image and location in the message, and a log that shows afterwards what was seen and when. The human decides, the system keeps watch.
Then the pattern is probably there, and the words are different.
The same pattern shows up in agrofood and processing, where the traceability file is still assembled by hand. In technical field service, where the job sheet and the invoice sit a week apart. In infrastructure management, where an inspection only counts once someone retypes it. And in sustainability data, where the supply chain report is pulled together from ten sources.
Where it does not work. As a replacement for a process nobody can explain. As an answer to the question "what can we do with AI". And as a side experiment next to the systems the work actually lives in. If you want to know where the gain is before anything gets built, that is Recon; if you want it built, that is Operations.
You do not need to know what AI means for your company before you do anything. You need to be able to point at one process that annoys you.
A conversation about that one process. Within 48 hours you have a written scope: the approach, the number of modules and a fixed price. No hourly meter.
If you want to know where the biggest gain sits first, an engineer spends a week alongside you and maps the operation from the inside before anything gets built.
Modules of 40 hours, €8,000 per module. Every ten hours you see a working version, so you steer on something real instead of on a plan.
Roll it out, measure it and adjust to what actually happens rather than to what we assumed up front.
An automation you do not measure is an opinion. Agree up front on what you will look at, and record the baseline before anything changes.
Pick the process your team complains about most. That is almost never the most exciting process, and almost always the one with the most repetition. It is where the gain shows fastest and the risk is smallest.
