Warehouse automation projects rarely fail because of SAP. They fail in between – between SAP, PLCs and physics. That is exactly where I work: from concept phase to go-live.
SAP EWM/MFS specialist for warehouse automation. I combine technical depth – down to telegram and PLC level – with a view of the whole system, and work on root causes, not symptoms.
Founded by René Fröhling. Automated warehouses don't work because every discipline works on its own – they work because someone understands the interplay: systems, processes, and the people in between.
The hardest bugs are not in any log. They live between the disciplines – and often in a side remark from someone who works on the line every day. That is why I combine systems thinking with listening: calm, structured, and understandable for everyone involved, from developers to warehouse managers.
Project analysis, solution architecture and process design – ideally from the concept phase.
The earlier the overall architecture is right, the fewer surprises during commissioning. I analyse requirements, design the solution across all disciplines and coordinate the technical decisions.
Architecture, customising and development – down to the telegram level.
Deep understanding of EWM architecture and MFS telegram communication. Customising, extensions, root-cause analysis and integration all the way down to the PLC – from concept to live operation.
FAT, SAT, mass testing, ramp-up, hypercare – the critical phase, handled calmly.
When it gets serious, prioritisation and calm are what count: test coordination, defect triage, escalation management and hypercare. So a finding never turns into a delay.
The link between SAP, PLCs, mechanics, operations and project management.
Most problems arise at the boundaries. I speak both languages – developers' and warehouse managers' –, moderate technical decisions and make sure nothing gets lost between responsibilities.
No glossy references – real situations from real projects. Anonymised, but exactly as they happened.
Automotive supplier · Automated tote warehouse · Mass test before go-live
For weeks, the mass tests ran stable. Then, from one day to the next: almost every tote gets rejected at the checkpoint. SAP unchanged. PLC unchanged. Mechanics unchanged. Classic troubleshooting inside the systems – nothing.
The decisive clue didn't come from a log, but from a side remark: "The new printer is somehow a bit odd." New printer? Show me the labels. The print quality was marginally weaker than before – barely visible to the human eye, decisive for the scanners on the conveyor line.
Old printers back at the workstations. Read rate back at 99%. Go-live risk off the table – without changing a single line of code.
The defect sat between the disciplines – exactly where nobody is responsible. You only find these when you understand the whole system and listen to the people on the floor.
Commissioning · AS/RS crane · PLC supplier only available remotely
The crane picks up one tote. Then the next. Then – silence. Nothing moves. In the cockpit, a height-measurement fault: light barrier. Nothing to do with SAP, and the PLC supplier was many kilometres away.
The easy answer would have been: "Not my discipline – call the supplier." Instead: out to the machine, checked the light barrier's mirror and realigned it. The line was running again.
Then handed a clean report to the PLC supplier – and trained the on-site staff so they can recognise and solve exactly this case themselves next time.
"Not my responsibility" is the easiest answer on a construction site – and the most expensive one. Commissioning works when someone looks beyond the system boundary instead of pointing at it.
SAP EWM/MFS · Testing & emulation · Telegram communication
In MFS projects you test against an emulation of the equipment. Normally. But it is often delivered late – and until then, every test means laborious manual work straight out of SAP.
You can document the problem, escalate and wait. Or you design the solution yourself: a telegram simulator that realistically emulates the equipment towards SAP EWM/MFS – making tests independent of the emulation's delivery schedule.
The project tool became a product: TeleForge. The customer uses it in the project today.
If you truly understand the telegram level between SAP and PLC, you can rebuild it. That depth is why my assessments hold up in concept phase and testing.
Clean architectures, stable codebases, reliable delivery. From prototype to production.
PLC-level diagnostics, MFS telegrams, stable EWM integration. Proven in real projects.
Automotive, retail, pharma. Standards-aligned, sustainable, reliable.
MFS Consulting · Telegram Design
Implementation and optimisation of MFS processes for efficient production logistics.
EWM Integration · Wave Management
Consulting and integration of SAP EWM for the orchestration of complex material flows.
Pharma WMS · GxP Validation
Automation and standardisation of warehouse processes in an international environment.
An MFS knows status: occupied, free, blocked, empty. The operator knows something else: context. He knows that lane 3 always acts up when the late shift starts. Anyone who ignores this knowledge because it is not in the system loses exactly the information that matters in the next two minutes.
When an MFS goes live, most people think first about technical issues: SAP acting up, machines not running as expected, never mind connection problems. But what if a large part of the issues begin much earlier, when no technology was involved yet, only people?
When people talk about SAP MFS, they think first of hard technology: telegrams, material flow, interfaces, conveyor systems. Sounds sober, almost cold. But the deeper I dive into projects, the more clearly I notice: in the end it is never just about machines or software, it is about people.
Two PDFs to forward straight away, for you and your customers.
Tell me about your project. I'll get back to you.