Where does your SAP actually stop?

There is no shortage of vendors telling you which platform your frontline needs. There is a shortage of honest answers to what you already own and never switched on.

The question is never about the tool

Ask where SAP stops inside your own organisation and the answer is usually uncomfortable. It stops at the last desk. Past that point there is paper, a radio call, a photograph of a serial number, and somebody re-typing all of it at the end of a shift.

When a maintenance technician cannot close a work order where the asset is, that is not a mobility problem. It is a process that was designed around a screen in an office and then asked to work two hundred kilometres offshore. When a warehouse runs on printed picking lists, the technology was rarely the obstacle. Somebody simply never decided which steps belong on the floor and which belong in the system of record.

So we start by understanding the problem rather than by bringing a solution. Most vendors and most consultancies arrive with the new tool, the new AI capability, the new stack. We go in, assess, and work with the customer to understand the nature of the problem and what actually needs to change, based on where that customer is today and where they are heading. Only then does the question of technology come up.

That order matters commercially as well as technically. We are not a reseller. We earn on deployment and outcome, not on which product gets selected. It means we can recommend a different product, or no new product at all, and still be in the same commercial position. Customers can feel that in the advice they get.

Four layers, in order

When we do get to technology, we work through four layers, and we work through them in this order.

Standard SAP, first and always. More often than people expect, the capability is already paid for. We have taken more than fifteen separate transactions and collapsed them into a single role-based screen built on standard SAP, with the customer’s existing roles and authorisations intact. We have put embedded warehouse management next to automated storage so the two stopped being separate worlds. We have replaced day-old reports with near real-time analytics inside the system people already use. No new platform, no new licence, no new vendor relationship to manage.

Our own practice, where standard runs out. Standard SAP was not designed for every screen a frontline worker needs. We have built store applications used across more than a thousand grocery outlets, warehouse mobility that changed how picking and put-away are done, and app portfolios running on well over a thousand handheld devices at a time. This is a practice, not a product line, and it exists because real operations have edges a standard catalogue does not reach.

Certified solutions, where somebody has already solved it properly. Some problems are genuinely standard and genuinely hard. Fully offline work orders on an offshore installation is one of them. When a certified solution does that job better than anything we would write ourselves, we deploy it and say so. Choosing to buy rather than build is the easiest decision in the world to get right when nothing in your revenue depends on the answer.

AI and the last mile. This is where the interesting work is now. We have put AI agents into finance processes and cut invoice handling time by more than half. We have delivered voice-controlled, hands-free applications on headsets for field engineers who need both hands for the job, in a timeframe others had called impossible. The principle is the same as everywhere else: the assistance comes to the work, not the other way round.

What we take out before we put anything in

In everything we have done, the single most important thing in an SAP project is to take out as much technology risk as possible. The solution we arrive at together with the customer has to be built on technologies that are mature, that are compliant, that are future-proof, and that sit on the roadmap that specific customer has already set for themselves.

That is why we do not lead with an accelerator, and why we are sceptical of anyone who does.

An accelerator is a good answer to a question somebody has already asked properly.

Three rules that outlived four technology generations

Across stores, offshore platforms, warehouses, plants and public logistics, three things decided whether frontline SAP stuck.

Standardise the process before you mobilise it. Mobile access to a broken process gives you a faster broken process, and a larger audience for it.

Put the people doing the work into the design, not just into the acceptance test. Our lowest change-request counts have always come from projects with a real design process and the end users inside it.

Keep the system of record as the system of record. Everything at the edge should write back into SAP, not beside it. The moment a second source of truth appears on the floor, you have bought yourself a reconciliation problem that will outlive the project.

The tools changed four times in ten years. Those three rules did not move once.

If this is on your 2027 roadmap

Most Nordic companies now have an ERP decision in front of them and a frontline question sitting underneath it, usually unanswered. Whether that decision sits inside a wider S/4HANA transformation or stands on its own, the frontline part rarely answers itself.

The honest version of this conversation takes about thirty minutes: what you already own, what is genuinely missing, and what we would do first. No deck, and no product in the first meeting.

Frequently asked questions