Behälter-Management: Vom Lagerträger zum Datenanker — wie ein Pilot zur Blaupause wurde

In diesem Format beleuchten wir reale Lessons-Learned-Fälle aus unserem Projektfundus und dem Logistik- und SCM-Kosmos. Wir zeigen die Ausgangslage, den Umsetzungsansatz beziehungsweise die Lösung sowie die konkreten Maßnahmen.

In den letzten beiden Real-Cases-Editionen haben wir gezeigt, wie sich Frachtkosten-Strukturen analytisch aufstellen lassen und wie eine TMS-Einführung mehr ist als ein IT-Projekt. Diese Woche schließen wir den Transport-Block ab und schauen auf das, was zwischen Frachtraum und Lager steht: Behälter und Ladungsträger. Klingt operativ-banal — ist in Wahrheit eine der unterschätzten Datenquellen in der Mehrstufen-Fertigung.

Ausgangslage: Behälter als operativer Aufwand, nicht als Datenpunkt

Ein international aufgestellter Hersteller mit Mehrstufen-Fertigung (Ringe → Schrauben → verpackte Fertigteile) stand vor einer typischen Situation: Behälter und Ladungsträger waren über mehrere Standorte und Werke im Umlauf, ohne durchgängiges Tracking. Die Logistik wusste in groben Zügen, was wo war — aber nicht präzise genug, um Produktionssteuerung, Qualitätsmanagement und Versand zuverlässig zu synchronisieren.

Drei strukturelle Probleme:

• Fehlende durchgängige Steuerung. Lose und Behälter durchliefen mehrere Prozessstufen, mussten aber an jedem Übergangspunkt manuell erfasst werden. Die Übergaben zwischen Schichten oder zwischen Werken waren fragil. Was in einem Werk als „freigegeben“ galt, konnte am Empfangsstandort als „in Prüfung“ geführt werden — ohne dass jemand das Datenproblem sah.
• Keine Statusmatrix. Die Frage „Wo steht dieses Los gerade?“ hatte keine systematische Antwort. Es gab nicht den einen Datenanker, sondern fünf bis sieben verschiedene Status-Notierungen über die Systeme hinweg. Das ist kein Hightech-Problem — das ist ein typisches Wachstums-Artefakt vieler deutscher Mittelstands-Unternehmen.
• Shopfloor-Hardware nicht integriert. Waagen, Scanner, Drucker waren da, aber nicht zentral angebunden. Was hardwareseitig erfasst wurde, landete als Excel-Export im Best Fall — oder als Notiz auf dem Lieferschein im Normalfall.

Die Frage, die das Projekt entscheidend gemacht hat: Wie machen wir Behälter und Ladungsträger vom Aufwandsposten zum Datenanker — ohne dass die Werker:innen jeden Klick mehr machen müssen?

Umsetzungsansatz: Vier-Phasen-Modell mit klarer System-Architektur

Das Pilotprojekt wurde in einem nordamerikanischen Werk gestartet, mit dem expliziten Ziel, eine Blaupause für den weltweiten Rollout zu schaffen. Methode: klassisches Phasenmodell, aber mit einem mehrschichtigen System-Modell als Architektur-Grundlage.

• Phase 1 — Initialisierung: Projektrahmen, Stakeholder, Rollen. Projektsteckbrief und Kommunikationsplan als Abschlussartefakte. Was hier wichtig war: Die Trennung zwischen IT-Projektleitung und operativen Stakeholdern (Produktionssteuerung, Qualitätsmanagement, Schichtleitung, Werker:innen, Administrator:in) wurde von Anfang an strukturiert. Keine „der IT-Verantwortliche entscheidet“-Logik, sondern eine Rollenmatrix mit klaren Entscheidungsbefugnissen.
• Phase 2 — Blueprint: Sollprozesse modellieren und Systemarchitektur ableiten. IST-Aufnahme der bestehenden Prozesse, Sollprozess-Workshops mit den operativen Anwendern, Definition eines Schichtenmodells (ERP ↔ MES ↔ Shopfloor). Das Ergebnis: ein abgenommenes Pflichtenheft, das sowohl IT-seitig umsetzbar als auch operativ akzeptiert war.
• Phase 3 — Realisierung: Funktionen konfigurieren und entwickeln. Hier wurde eine wichtige Designentscheidung getroffen: Erweiterungen werden im eigenen Namensraum entwickelt, nicht in den Standard-Konfigurationen des ERP/MES. Das verhindert Konflikte bei späteren Standard-Updates und macht den Rollout an andere Standorte berechenbar.
• Phase 4 — Integrationstest: End-to-end-Prozesse verifizieren. Wareneingang bis Versand getestet, mit dokumentierten Testprotokollen. Die Stabilisierung dauerte länger als ursprünglich geplant — wie in fast allen Mehrstufen-Fertigungs-Projekten — aber die strukturierte Testphase verhinderte spätere Eskalations-Schleifen.

Lösung: Was sich konkret verändert hat

• Ein Los-Objekt als zentraler Datenanker. Statt fünf bis sieben parallel laufender Status-Notierungen gibt es nun ein einziges Datenmodell. Jedes Los hat genau einen Identifikator und einen aktuellen Status. Wenn an Standort B etwas erfasst wird, weiß Standort A das in Echtzeit — über das ERP-Backbone.
• Statusmatrix mit klaren Übergängen. Lose durchlaufen jetzt einen definierten Lebenszyklus: frei → angemeldet → verladesicher → verbraucht. Jeder Statuswechsel ist regelbasiert; manuelle Override-Möglichkeiten existieren, sind aber dokumentiert. Das macht die Daten audit-fähig.
• Hohe Konfigurierbarkeit für den Rollout. Was im Pilotwerk parametrisiert wurde — Gewichtstoleranzen, Statuscodes, Arbeitsplatztypen, Lagerzonen — lässt sich für andere Standorte standortbezogen pflegen. Das ist der eigentliche Hebel: nicht die Lösung als solche, sondern ihre Rollout-Fähigkeit.
• Shopfloor-Hardware integriert. Waagen und Scanner sind nun zentral angebunden. Die Werker:innen haben einfache Dialogoberflächen, die ihre Tätigkeit eher beschleunigen als verlangsamen. Ein Argument, das in der Konzeptionsphase oft unterschätzt wird: Wenn das System schneller ist als die manuelle Methode, wird es genutzt. Wenn nicht, wird es umgangen.

Maßnahmen: Best Practices für Ihr Behälter-Management

• Ein Los-Objekt als zentraler Datenanker definieren. Bevor Systeme angebunden werden, muss das Datenmodell stehen. Ein Los — eine ID — ein aktueller Status. Alle anderen Sichten (Werk, Lagerzone, Materialfluss) sind Ableitungen aus diesem zentralen Datenpunkt.
• Statusmatrix vor Workflow-Implementierung. Welche Stati gibt es? Welche Übergänge sind erlaubt, welche nicht? Welche manuellen Overrides sind möglich, und wer darf sie auslösen? Diese Regeln gehören vor die Workflow-Implementierung — nicht danach.
• Shopfloor-Hardware früh einbinden. Waagen, Scanner, Drucker, Mobile Devices sollten ab Blueprint-Phase Teil der Architektur sein. Nachträgliche Integration ist teurer und fehleranfälliger. Wer schon investiertes Equipment hat, sollte den Plan daran ausrichten — nicht umgekehrt.
• Erweiterungen im eigenen Namensraum. Standard-Konfigurationen des ERP/MES nicht überschreiben. Erweiterungen in einem klar abgegrenzten Namensraum implementieren. Das ist auf den ersten Blick zusätzlicher Aufwand — auf den zweiten Blick Rollout-Versicherung.
• Rollenmatrix vor Funktionsmatrix. Wer entscheidet was? Wer darf Override-Stati setzen? Wer hat Lese-, wer hat Schreibrechte auf welche Datenfelder? Die Antworten gehören ins Pflichtenheft, nicht in die operative Praxis nach Go-Live.
• Pilot vor weltweitem Rollout. Ein Werk mit klarer Rollout-Perspektive ist effizienter als drei parallele Implementierungen. Die Lessons Learned aus dem Pilotwerk sind die operative Grundlage für die zweite Welle. Wer überall gleichzeitig startet, lernt überall gleichzeitig falsch.

Was bedeutet das für Ihr Unternehmen?

• Können Sie für jeden Behälter und jeden Ladungsträger in Ihrem Materialfluss in Echtzeit sagen, wo er steht und in welchem Status er ist? Falls „in groben Zügen“ die Antwort ist, haben Sie die gleiche Datenanker-Lücke wie das Pilotwerk vor Projektstart.
• Welche Hardware (Waagen, Scanner, Mobile Devices) ist in Ihrem Werk verfügbar — und welche davon ist nicht systemisch angebunden? Jedes Stück nicht-angebundene Hardware ist eine manuelle Excel-Übersetzung im Tagesgeschäft.
• Wenn Sie heute einen neuen Standort öffnen würden, könnten Sie die bestehende Behälter-Management-Logik standortbezogen konfigurieren und ausrollen? Falls „nein“ oder „nur mit großem Aufwand“, fehlt die Rollout-Architektur.

Den Anschluss bildet eine zweiteilige Storyline zur Bestandsoptimierung: wie ein global aufgestellter Hersteller seine „Nulldreher“-Bestände in internationalen Lagern (China, USA) strukturell angegangen ist — und welche zwei Datenpunkte die Diskussion entscheidend verändert haben.

Anonymisierter Projektfall aus dem SCM-Projektfundus.