It is not about replacing systems, it is about moving architecture.
When companies first hear about Logistics as a Service, the same question almost always appears: Do we need to replace all our systems?
The answer is no.
By: Per Imer, CEO, Homerunner
Contains: 950 words
Becoming ready for LaaS is not about starting over. It is about understanding what you already have and using it correctly. In many organizations, the real problem is not that the systems are poor. The problem is that they are being used for something they were never designed to do. That is where transformation begins.
Most transformation initiatives begin internally. Conversations revolve around ERP, TMS, WMS, integrations, roadmaps, and release plans. But LaaS begins somewhere else, as it begins with the customer.
- What are you promising?
- Which decisions are made throughout the customer journey?
- Where does friction occur?
- Where do you become reactive instead of proactive?
When you start from the outside and move inward toward your systems, it becomes clear where decisions break, where data stops flowing. And where people compensate manually. That is where the architecture must move, not necessarily the systems themselves, but the way they work together.
The first step is not implementation, it is clarity. Creating a real understanding of your existing architecture typically takes one to two months.
During that period, systems, integrations, decision points, and manual workarounds are mapped. Hidden complexity becomes visible, and the goal is not to identify mistakes. The goal is to understand reality.
Without architectural clarity, you cannot design a future structure. Without visibility, you risk accelerating what is already unclear.
There is a fundamental realization many organizations reach late: core systems are not meant to be intelligent, they are meant to be stable.
ERP is designed for transactions and WMS is designed for warehouse flows. TMS is designed for transport handling, so they are not built to contain your entire cross-organizational decision logic.
Yet we repeatedly see companies forcing complex business logic deep into their core systems. They ask them to solve problems they were never built to handle. The outcome is always the same: fragility, technical debt, and lack of flexibility.
When decision logic is embedded inside core systems, every change becomes heavy. Every improvement becomes a project. Every adjustment requires specialist intervention. This is where architecture must be lifted.
Middleware, or an orchestration layer, is not another system to add to the stack. It is a principle, and is the place where decisions are gathered.
This is where data is connected across systems, rules are defined, automation is controlled - and complexity is organized. When decision logic is moved out of core systems and into a shared decision layer, something important happens. Systems can run more standard. Upgrades become simpler. Flexibility increases.
LaaS does not add complexity. It creates coherence.
Once clarity is established and the future decision architecture is designed, implementation typically takes between one and five months, depending on your readiness.
Readiness is rarely about technology alone. It is about clarity in decision logic, data quality, leadership direction, and the willingness to change workflows. Today, integration is rarely the slow part. Uncertainty is.
When direction is clear, transformation moves faster than most expect.
Once the decision layer is established, the real shift begins. Data starts flowing freely. Decisions become transparent. Rules can be adjusted quickly. Repetition becomes automation. The organization moves from reactive firefighting to proactive control. From manual compensations to structured orchestration.
Tools and technology can accelerate this significantly. But only if thinking is clear.
And real thinking is rare.
To think is to hold two perspectives at once and conduct an internal dialogue before acting. Many organizations have been used to executing within predefined system constraints. Now they must define the structure themselves. AI can build what you describe. It cannot define direction. When software is no longer scarce, technology is not the limiting factor. The quality of your thinking is.
This is not an academic model, it is craft.
Craft is about understanding the material. In our world, the material is data, decisions, flows, and system constraints.
A strong architecture cannot be copied from a template. It must be shaped within its specific context. Who makes decisions? Where does authority sit? Where does complexity live? What should be automated, and what should remain human?
Science seeks universal answers. Craft seeks the right solution in a specific reality.
Becoming ready for Logistics as a Service is not about replacing systems. It is about starting from the customer, creating architectural clarity, stopping the misuse of core systems, and gathering decision logic in one place.
It begins with one to two months of architectural work. It is implemented over one to five months. Then the movement from reactivity to proactivity begins.
It is not a system shift. It is a structural shift.
And when done correctly, LaaS does not become a project.
It becomes the way you work.
