Logistics engineering is systems engineering. Let us put systems engineering into perspective. We talk about systems, we talk about technology, we call certain pieces of technology “a system” — for instance, a computer — and sometimes we call certain systems “technology.” And we frequently deal with systems of systems. A factory, an automated warehouse, or an oil refinery — these are systems of systems, and they are also embedded in larger systems.
The point I want to make in this article is this: there is a big difference between technology engineering and systems engineering. We can also say that there is a big difference between engineering a subsystem and engineering the overarching system. The skills, knowledge, and experience needed to engineer the larger overall system are not the same as those needed to engineer the various subsystems.
Most companies in the automation space are focused on subsystems. They are not really systems engineering companies. They are mechanical engineering companies, electrical engineering companies, or sometimes robotics companies. Very few are IT companies, and even fewer are genuine systems engineering companies in the broader sense. In many cases, these companies are extremely good at what they originally grew up doing. They know how to build a robot, a stacker crane, a conveyor, a motor, a drive, a sensor, or some other technical component.
But being very good at building components is not the same thing as being very good at engineering a system. A system is more than a collection of technical parts. It is more than steel, motors, sensors, controls, and software modules connected in some technically plausible way. A system has to function as a whole. And designing that kind of total behavior is a different task from designing or supplying the individual parts.
That is why I think systems engineering, and in our context also logistics engineering, should be seen as a discipline in its own right. The logistics engineer, as I would define the profession, does not build a forklift truck, a clutch, a motor, or a robot. He does not optimize one technical component in isolation. He designs a material flow system. That means he has to think about the interaction of many elements, not just about the technical quality of each part on its own.
Historically, this distinction was less important than it is today. If you wanted to build an automated warehouse thirty years ago, it probably would have been a high-bay warehouse with a few stacker cranes and some conveyor technology, and it did not require a deep understanding of logistics or material flow. Strong mechanical and electrical engineering, solid project management, and reliable equipment delivery were sufficient. And many companies became very good at exactly that.
Today, many of the systems we deal with are far more complex. We are talking about systems with very high throughput, often thousands of flow units per hour, with many interacting processes, many control decisions, much more software logic, and much tighter coupling between physical and digital elements. A modern automated warehouse often resembles a factory much more than a traditional warehouse. And to make that work, you need to understand systems engineering. You still need people who know how to build a decent stacker crane; that is still necessary, but no longer sufficient. It requires a different way of thinking and a different skill set. It requires understanding not only the components, but also the interactions between them. It requires understanding material flow, process dependencies, queueing effects, variability, exception handling, software logic, sequencing, and the way local decisions influence total system performance. In other words, it requires systems thinking.
Many companies are still playing the old game. They are still approaching these projects mainly from the perspective of component engineering, not from the perspective of total system behavior. They still think primarily in terms of machines, equipment, and installation, even though the actual challenge now lies in the design, integration, and operation of a highly interdependent system. For some companies, that means they are very focused on their stacker cranes or single-level shuttles. The more modern variant is the AutoStore integrator who is very focused on the AutoStore installation but neither understands, nor seems to have much interest in, the overall material flow system. I see this in AutoStore projects I am involved in, and I also see it in finished AutoStore sites I visit that clearly indicate that the entire project seems to have been about the AutoStore installation, while the material flow interfacing with the AutoStore installation was not deliberately designed or redesigned. That is why it is fair to say that something like AutoStore is almost never “the solution,” but merely a component that is part of the solution. It is only slightly different from selling customers a stacker crane when what they really need is an optimized, coherent material flow system.
This is probably not unique to logistics automation. I suspect the same distinction applies in many other industries as well.
Someone who knows how to build a steering wheel, an engine, or a clutch is not automatically capable of building a good car as a system, let alone a good car company. Those are different tasks. The same is true in construction. Someone may be very good at painting walls, laying bricks, tiling floors, or installing HVAC systems. That still does not mean that he is automatically capable of building a house as a coherent system. A house has to be built in the right sequence, with the right interfaces, with the right coordination between trades, and with a view to how everything has to work together in the end. That is a different discipline from being good at one trade or even several individual trades.
The same logic applies here. Doing good work on individual components is not the same as engineering a good total system.
A tender I ran for a client last year involved some AutoStore integrators and Gridstore, a younger company offering an AutoStore look-alike. The thing about Gridstore is that almost everyone who works there is an experienced systems engineer, most of them former SSI Schäfer employees. Their planning was on a completely different level from what I saw from the AutoStore integrators. Their planning was not just better; they were playing an entirely different game. A good indicator that someone has a clue about logistics systems engineering is when they present you with a proper material flow diagram. In contrast, two of the AutoStore integrators asked me what I meant by “material flow diagram” when I mentioned it during a Teams call.
Technology matters, of course. Good components matter. Mechanical engineering matters. Electrical engineering matters. Robotics matters. But none of that should be confused with systems engineering. Systems engineering is about designing, integrating, and improving the whole so that it performs under real conditions. And that is a different discipline from building the parts.
