Stauplanoptimierung: KI für Container-Stabilität und Hafenreihenfolge

Das echte Ausmaß des Problems

Ein modernes Containerschiff der ULCV-Klasse (Ultra Large Container Vessel) fasst bis zu 24.000 TEU. Die Zahl valider Beladungskonfigurationen ist astronomisch, Milliarden möglicher Staupläne, von denen die meisten regulatorisch korrekt, aber logistisch suboptimal sind. Menschliche Planer können davon einen winzigen Bruchteil evaluieren, gestützt auf Erfahrung, Faustregeln und Bauchgefühl.

Eine Analyse von SolverMinds (2026) hat das konkretisiert: Drei erfahrene Stauverantwortliche erhielten identische Eingangsdaten und erstellten jeweils einen validen Plan. Die Ergebnisse wichen erheblich voneinander ab, Overstow-Raten zwischen 3,2 % und 5,1 %, benötigte Umstauungen zwischen 62 und 104 Einheiten, Stabilitätsmargen zwischen +8 % und +15 % über den Mindestwert. Alle Pläne erfüllten die SOLAS-Kriterien. Aber der schlechteste kostete rund 42 zusätzliche Krantakte, bei Krankosten von ca. 40–60 USD je Takt summiert sich das auf über 2.000 USD an Mehrkosten pro Hafenanruf.

Multipliziert auf eine Flotte: Ein Reederei-Stauplan-Mix, der systematisch 2 Prozent mehr Umstauungen als nötig erzeugt, kostet bei 200 Hafenanläufen pro Jahr und 800 USD Krankosten je Umstauung rund 320.000 USD, jährlich, ohne dass das Buchungssystem oder der Kapitän je davon erfahren würden.

Hinzu kommt der Liegezeit-Effekt. Jede Umstauung, die im Zwischenhafen hätte vermieden werden können, kostet nicht nur den Krantakt selbst, sie verlängert die Liegezeit des Schiffs. Die Betriebskosten eines großen Containerschiffes inklusive Kapitalkosten und Hafengebühren liegen bei $1.500 bis $2.000 pro Stunde. Eine um eine Stunde verlängerte Liegezeit in Rotterdam bedeutet $1.500 bis $2.000 direkten Mehraufwand, plus die Kaskadeneffekte auf den nächsten Hafen, wenn das Schiff Verspätung hat.

Das dritte, unsichtbare Problem ist die Kraftstoffdimension: Ein schlecht getrimmtes Schiff erhöht den Kraftstoffverbrauch durch ungünstige Gewichtsverteilung. Die Trimmoptimierung zeigt, wie eng Beladungsverteilung und Bunkerverbrauch verknüpft sind, ein Stauplan, der auch den Trimm berücksichtigt, spart 1–2 % Kraftstoff pro Voyage on top.

Mit vs. ohne KI, ein ehrlicher Vergleich

¹ Zahlen basieren auf Branchenberichten (SolverMinds 2026, Yangshan-Port-Studie MDPI 2022) und Herstellerangaben Navis StowMan. Individuelle Ergebnisse abhängig von Flottengröße, Routenstruktur und TOS-Integration.

Einschätzung auf einen Blick

Zeitersparnis, mittel (3/5) Planungszeit sinkt von 4–8 Stunden auf 30–60 Minuten je Voyage, das ist substanziell für Stauverantwortliche. Der Effekt bleibt aber begrenzt auf die Planungsabteilung und tritt nicht täglich auf, sondern pro Voyage. Verglichen mit Anwendungsfällen, die täglich Arbeitsstunden sparen (Wartungsplanung, technische Dokumentation), ist die Zeitersparnis real, aber auf eine spezifische Berufsgruppe konzentriert. Daher Mittelfeldposition.

Kosteneinsparung, sehr hoch (5/5) Dieser Anwendungsfall ist innerhalb der schiffbau-Kategorie der stärkste Kostenhebel. Jede gesparte Stunde Liegezeit eines großen Containerschiffes entspricht $1.500–2.000 an vermiedenen Kosten. Eine um 1–2 Stunden kürzere Liegezeit pro Hafenanruf, auf 40 Anrufe pro Jahr, ergibt $60.000–160.000 je Schiff jährlich, allein durch bessere Stauplanung. Hinzu kommen gesparte Krantakte (800–2.000 USD je Umstauung), verbesserte Kapazitätsauslastung und Kraftstoffersparnis durch optimierten Trimm. Dieser Wert ist vergleichbar mit Bunkerverbrauch-Trimmoptimierung und Ballastwasser-Management, maximal bewertet.

Schnelle Umsetzung, niedrig (2/5) TOS-Integration ist das Nadelöhr. Ein produktiver Einsatz erfordert die Anbindung an das Terminal Operating System (typisch Navis SPARCS N4 oder OPUS), die Anbindung des Booking-Systems und die Übernahme von Containerdaten in Echtzeit. Realistische Einführungszeit: 8–18 Monate. Das ist kein Softwareproblem, sondern ein Integrationsproblem, und es schließt viele Reedereistrukturen aus, die ihre TOS-Landschaft nicht kurzfristig ändern können. Niedrig bewertet, weil vergleichbare maritime Anwendungsfälle wie Wetterrouting (kein TOS nötig, SaaS-Einstieg in Wochen) deutlich einfacher starten.

ROI-Sicherheit, mittel (3/5) Die Einsparungen sind messbar, Overstow-Rate, Krantakte und Liegezeit lassen sich vor und nach dem System direkt vergleichen. Die Kausalzuordnung ist handhabbar, weil dieselben Schiffe und Routen als Kontrollgruppe dienen. Herausforderung: Hafenzeiten hängen von vielen Faktoren ab (Terminal-Produktivität, Wetterbedingungen, Crew-Timing), sodass der Stauplan-Effekt im operativen Betrieb nicht immer sauber isolierbar ist. Mittelfeld.

Skalierbarkeit, hoch (4/5) Einmal integriert, skaliert das System proportional mit der Flotte, jedes neue Schiff, das ans TOS angebunden wird, profitiert ohne wesentlichen Mehraufwand. Nicht maximal bewertet, weil jede neue Route und Hafenkonfiguration eine Anpassung der Constraint-Parameter erfordert und der Pflegeaufwand mit Flottenvielfalt wächst.

Richtwerte, stark abhängig von Flottengröße, TOS-Infrastruktur und Routen-Komplexität.

Regulatorik als Constraint: SOLAS, IMDG-Code und Lashing-Kräfte

Das Besondere an der Stauplanoptimierung für Containerschiffe: Regulatorik ist nicht der Rahmen, in dem das System arbeitet, sie ist der wichtigste Optimierungsconstraint. Wer das übersieht, baut ein System, das elegante Lösungen findet, die keiner übernehmen darf.

SOLAS-Kapitel II-1 (Stabilität): Jedes Containerschiff muss bestimmte Stabilitätswerte einhalten, insbesondere die metazentrische Höhe (GM), den Leckstabilitätsnachweis und den Stabilitätsbereich in der GZ-Kurve. Ein Stauplan, der die Gewichte so verteilt, dass die Stabilitätswerte unterschritten werden, ist unzulässig, unabhängig davon, wie viele Krantakte er spart. KI-Systeme müssen diese Parameter als Hard Constraints modellieren, nicht als Soft-Parameter.

IMDG-Code (Gefahrgut-Segregation): Der International Maritime Dangerous Goods Code schreibt vor, welche Gefahrgutklassen nicht miteinander im selben Schiff gelagert werden dürfen und welche Mindestabstände gelten. Klasse 1 (Explosivstoffe) und Klasse 5.1 (Oxidationsmittel) dürfen nicht nebeneinander gestaut werden. Klasse 3 (entzündbare Flüssigkeiten) muss von bestimmten anderen Klassen durch mindestens eine Bucht getrennt sein. Der IMDG-Code wird alle zwei Jahre überarbeitet, ein KI-System, das mit veralteten Segregationstabellen arbeitet, ist nach einer Revision nicht mehr compliant.

Dieser Abschnitt ist eine fachliche Orientierung und ersetzt keine Rechtsberatung oder Zertifizierung durch eine Klassifikationsgesellschaft (DNV, Lloyd’s Register, ClassNK, Bureau Veritas o. a.). SOLAS-, IMDG- und Lashing-konforme Staupläne erfordern Freigabe durch den befugten Schiffsoffizier oder ein zugelassenes Planungsbüro; verbindliche Auslegung der jeweils aktuellen IMO-Regelwerke obliegt der zuständigen Flaggenstaatverwaltung und der Klassifikationsgesellschaft.

Lashing-Kräfte: Container müssen auf dem Deck gesichert werden. Die Sicherungsmittel (Twistlocks, Lashing-Stangen) haben Lasttragfähigkeiten, die in Abhängigkeit von der Position auf dem Schiff, der Höhe des Container-Stacks und den erwarteten Seegangsbedingungen eingehalten werden müssen. Ein schlecht durchdachter Stauplan kann zu Überschreitung der Lashing-Kapazitäten führen, mit potenziell fatalen Folgen auf See.

Reefer-Strom: Kühlcontainer müssen an Deck-Steckdosen angeschlossen sein. Die Zahl der Steckdosen pro Bay ist begrenzt. Ein Stauplan, der zu viele Reefer in dasselbe Bay stopft, erzwingt Umstauungen im nächsten Hafen. Diesen Constraint automatisch zu modellieren ist technisch lösbar, erfordert aber vollständige und aktuelle Schiffsprofile in der KI-Plattform.

Das bedeutet für die Praxis: Bevor ein KI-Stauplan in den Produktionsbetrieb geht, müssen alle regulatorischen Constraints formalisiert und testiert sein. Das ist Arbeit, ein bis zwei Monate für einen erfahrenen maritimen Compliance-Experten, bevor die erste automatische Planung freigegeben werden darf.

Was der KI-Stauplan konkret macht

Ein Machine-Learning-gestütztes Stauplan-System arbeitet in zwei Schichten:

Schicht 1, Constraint-Solver: Das System modelliert alle harten Anforderungen als mathematische Constraints: Schiffsstabilität (GM, GZ-Kurve), IMDG-Segregation, Reefer-Strom-Kapazität, maximale Stapelhöhen, Lashing-Kräfte. Dann sucht es den Stauplan, der innerhalb dieser Constraints die gewählte Zielfunktion optimiert, typisch eine Kombination aus minimalen Umstauungen in Zwischenhäfen, minimalen Krantakten und minimaler Liegezeit. Werkzeuge wie Google OR-Tools, Gurobi oder der Constraint-Solver von IBM CPLEX übernehmen diesen Teil. Für die Problemgröße echter ULCV-Schiffe sind Heuristiken (Simulated Annealing, Large Neighborhood Search) oft effizienter als exakte Solver.

Schicht 2, Predictive Analytics auf Cargo-Mix: Wer die Stauplanung für zukünftige Voyages vorbereiten will, bevor das vollständige Booking vorliegt, nutzt ML-Modelle, die auf historischen Ladungsdaten trainiert sind: Welche Containergattungen kommen typischerweise auf dieser Route? Wie hoch ist der Gefahrgut-Anteil in der Hochsaison? Diese Prognosen erlauben “Pre-Stowing”, vorläufige Stauplanung, die bei Eingang der endgültigen Booking-Daten präzisiert wird.

Last-Minute-Reaktion: Der wichtigste Praxisvorteil ist die Szenarien-Geschwindigkeit. Wenn ein Großkunde 30 Minuten vor Ladeschluss einen 40-Fuß-Tank-Container mit Class-3-Gefahrgut anmeldet, kann ein KI-System in Minuten durchrechnen, ob der Container noch in den Plan integrierbar ist, ohne IMDG-Segregationsvorgaben zu verletzen, und wenn nicht, auf welche Alternative-Bay er ohne Umstauungen in Rotterdam staubar wäre. Ein manueller Planer bräuchte für diese Evaluation eine Stunde.

Ein in der Praxis validierter Rahmen: Wissenschaftler der Yangshan-Port-Studie (MDPI, 2022) implementierten einen DQN-LNS-Algorithmus für reale Schiffsgrößen und erzielten eine Reduktion der Container-Umstauungen um 16,8 %, mit einer Planungszeit von ca. 10 Minuten für große Schiffe.

Konkrete Werkzeuge, was wann passt

Stauplanoptimierung ist kein SaaS-Produkt, das man für 99 EUR/Monat abonniert. Es ist ein Systemintegrationsprojekt, mit Spezialsoftware, die in die bestehende maritime IT-Landschaft eingebettet werden muss.

Navis StowMan, Der Branchenstandard für landseitige Stauplanung. Heute Teil der Kaleris-Gruppe (ehemals Interschalt AG, Schenefeld bei Hamburg). 50 % der globalen TOP-10-Linienreedereien setzen StowMan ein. Das System berechnet optimierte Staupläne in ca. 30 Sekunden, berücksichtigt simultane IMDG-Segregation, Stabilitätswerte, Krankapazität und Reefer-Anschlüsse. Einsatz als SaaS-Abonnement, Kosten als OPEX buchbar, kein Investitionskapital. ZIM (Israel) und UASC beschreiben Stauplanung nach mehreren Szenarien als “beeindruckend schnell”. Passt für: Linienreedereien mit 5+ Schiffen, bestehender TOS-Infrastruktur (Navis SPARCS N4), zentralisiertem Planungsbüro.

loadmaster.ai (StowAI), Neuerer Ansatz auf Basis von Reinforcement Learning. Im Gegensatz zu klassischen Constraint-Solvern, die immer neue Trainingsdata brauchen, arbeitet StowAI “cold-start ready”, der RL-Agent lernt ohne historische Stauplan-Datenbank und passt sich bei wechselndem Container-Mix selbst an. Das Tool benötigt keine Trainingsdaten aus Vergangenheitsplänen, was den Einstieg erleichtert. Das Unternehmen (Niederlande) hat keine öffentliche Kundenliste, positioniert sich als “next generation” gegenüber den etablierten Anbietern. Passt für: Terminals, die eine moderne KI-Methodik ohne Abhängigkeit von historischen Datenpools testen wollen. Vorsicht: Kein namentlicher Track Record vergleichbar mit StowMan.

Google OR-Tools / Gurobi (Eigenentwicklung), Wer eine Eigenentwicklung plant, kombiniert typisch einen Constraint-Solver mit einem Machine-Learning-Modul. Google OR-Tools ist Open Source und für mittlere Problemgrößen geeignet; Gurobi ist der kommerziell überlegene Solver für große Schiffe (Gurobi outperforms CPLEX auf ULCV-Skalen, laut mehrerer akademischer Vergleiche 2024). Passt für: Reedereien mit eigenem Tech-Team, die eine tiefe TOS-Integration und Custom-Constraints ohne Vendor-Lock-in bevorzugen. Entwicklungskosten: 6–18 Monate Entwicklerzeit.

Zusammenfassung: Wann welcher Ansatz

• Linienreederei, Navis-TOS, klarer Budget-Rahmen → Navis StowMan
• Terminal sucht KI-Modernisierung ohne historische Datenlast → loadmaster.ai (StowAI)
• Tech-Team vorhanden, Custom-Constraints dominant → Eigenentwicklung mit Gurobi

Datenschutz und Datenhaltung

Stauplanung verarbeitet Cargo-Manifeste, sensible kommerzielle Daten, die Ladungsart, Absender, Empfänger und im Fall von Gefahrgut genaue Klassifizierungen enthalten. Das ist keine personenbezogene Verarbeitung im Sinne der DSGVO, aber es handelt sich um Geschäftsgeheimnisse mit erheblichem Wettbewerbswert.

Für die gängigen Systeme gilt:

• Navis StowMan (Kaleris): US-amerikanisches Unternehmen, Cloud-Infrastruktur primär in den USA. EU-Hosting-Option vorhanden, aber explizit anfragen und vertraglich sichern. AVV für Unternehmen mit EU-Sitz möglich. Für sensible Cargo-Manifeste (z. B. Militärfracht, Dual-Use-Güter) sollte EU-Datenhaltung vertraglich fixiert sein.

• loadmaster.ai: Niederländisches Unternehmen, EU-Datenhaltung standardmäßig. Für EU-Reedereien datenschutzrechtlich unkomplizierter.

• Eigenentwicklung mit On-Premise-Betrieb: Maximale Kontrolle. Cargo-Daten verlassen nie die eigene Infrastruktur. Für Reedereien, die Militär- oder Dual-Use-Cargo regelmäßig transportieren, oft die einzige akzeptable Option.

IMDG-Daten (welche Gefahrgutkombinationen auf welchem Schiff) sind aus Sicherheitssicht hochsensibel, sie geben Aufschluss darüber, wo ein Schiff besonders verwundbar ist. Diese Daten sollten weder in US-Cloud-Diensten landen noch an Dritte weitergegeben werden, ohne dass die regulatorischen Konsequenzen geprüft wurden.

Was es kostet, realistisch gerechnet

Einmalige Einrichtungskosten (TOS-Integration und Setup)

• Navis StowMan: Implementierungsprojekt 150.000–400.000 EUR (typisch, abhängig von Flottenstruktur, Anzahl der integrierten TOS-Systeme und Customizing-Umfang)
• Eigenentwicklung mit Gurobi: 250.000–600.000 EUR in Entwickler- und Lizenzkosten, 12–18 Monate Laufzeit
• Begleitende IT-Beratung und maritime Compliance-Expertise: 20.000–60.000 EUR zusätzlich

Laufende Kosten (monatlich/jährlich)

• Navis StowMan: Enterprise-SaaS, Preise auf Anfrage; Marktberichte nennen typisch 80.000–200.000 USD/Jahr für mittelgroße Flotten (5–20 Schiffe), nicht verifizierbar ohne direktes Angebot
• Gurobi Solver-Lizenz: ab ca. 7.500 USD/Jahr (Solver-Lizenz ohne Application-Entgelt)
• Interne Wartung und IMDG-Update-Pflege: 0,5–1 FTE maritime IT

Was du dagegenrechnen kannst Ein konservatives Szenario: Eine Reederei mit 8 Schiffen auf Europa-Routen, durchschnittlich 4 Hafenrufe pro Schiff pro Monat. Aktuelle durchschnittliche Mehrliegezeit durch suboptimale Stauplanung: 45 Minuten pro Hafenruf (konservativ). Reduktion durch KI: 50 % der Mehrliegezeit (22 Minuten gespart). Bei $1.500/Stunde entspricht das: 22 Minuten × 8 Schiffe × 4 Hafenrufe × 12 Monate = 1.408 Stunden × $1.500 = $2,1 Mio. jährlich. Selbst wenn nur 20 % des theoretischen Wertes realisierbar sind: $420.000 jährlich. Bei Implementierungskosten von 300.000 EUR: Amortisation in unter einem Jahr.

Diese Rechnung ist optimistisch und setzt voraus, dass Liegezeiten tatsächlich der Stauplanung zuzuschreiben sind (nicht dem Terminal oder Wetter). Realistische Projektion: 30–50 % der theoretischen Einsparung in den ersten 18 Monaten.

Integrations-Realität: Wenn KI auf das Terminal Operating System trifft

Hier steckt die eigentliche Arbeit. Die KI-Algorithmen sind lösbar, die Integration in die bestehende maritime IT-Landschaft ist das Projekt.

Schritt 1: TOS-Anbindung klären. Das Terminal Operating System (typisch Navis SPARCS N4 oder OPUS) ist die Datenquelle für alles: Containerattribute, Gewichte, Gefahrgutklassen, Reefer-Bedarf, Destination. Ohne vollständige und fehlerfreie Daten aus dem TOS arbeitet der Optimizer gegen Phantome. Die API-Anbindung an SPARCS N4 ist technisch gut dokumentiert, aber sie erfordert maritime IT-Expertise, nicht nur Software-Engineering.

Schritt 2: Booking-System-Schnittstelle. Staupläne müssen erstellt werden, bevor das vollständige Cargo-Manifest vorliegt, Pre-Stowing auf Basis des Booking-Stands. Das bedeutet Anbindung an das Booking-System der Reederei, mit automatischer Aktualisierung des Stauplan-Vorschlags bei neuen Buchungen.

Schritt 3: Stabilitäts-Approbation. Der KI-generierte Stauplan muss vom Ladecomputer des Schiffs auf Stabilitätswerte validiert werden, entweder direkt durch Integration mit dem Stabilitätsprogramm (z. B. MACS3, ein weiteres Produkt aus der Interschalt/Kaleris-Familie) oder durch Export und manuelle Prüfung durch den verantwortlichen Offizier.

Schritt 4: Schnittstelle zum Terminal-Representative. Der finale Stauplan muss an den Terminal Representative übertragen werden, in einem Format, das das Terminal direkt in seine Kransteuerung einlesen kann. Inkompatible Formate hier erzeugen manuelle Nacharbeit, die einen erheblichen Teil der Zeitersparnis wieder auffrisst.

In der Praxis berichten IT-Teams in Reedereien von 12–18 Monaten für eine vollständige End-to-End-Integration, selbst wenn alle Beteiligten wohlwollend kooperieren. Das liegt nicht am System, sondern an der fragmentierten IT-Landschaft im maritimen Bereich: TOS-Anbieter, Booking-Systeme, Schiffs-IT und Terminal-IT sind oft aus verschiedenen Jahrzehnten und sprechen selten dieselbe Sprache.

Typische Einstiegsfehler

1. Den Stauplan-Algorithmus ohne Constraint-Vollständigkeit in Produktion nehmen. Das häufigste Muster: Das System läuft im Pilotbetrieb, Planer nutzen es als Basis und passen manuell nach. In dieser Phase fehlen oft Constraints, fehlende Reefer-Kapazitätsdaten, veraltete Lashing-Tabellen, fehlende Sonderfälle für Übermaßcontainer. Solange der Plan manuell nachkorrigiert wird, bleibt das unsichtbar. Sobald Vertrauen wächst und manuelle Überprüfung nachlässt, landen regulatorisch invalide Pläne in Produktion. Lösung: Vollständige Constraint-Testmatrix vor Produktionsstart, iteriert durch maritime Compliance-Experten.

2. IMDG-Code-Revision ignorieren. Der IMDG-Code wird alle zwei Jahre revidiert. Software, die mit einer alten Segregationstabelle arbeitet, erzeugt nach einer Revision Pläne, die formal non-compliant sind, ohne Fehlermeldung, ohne Warnung. Die Cargo Incident Notification System (CINS)-Daten zeigen, dass falsch deklarierte und falsch gestaute Gefahrgutkombinationen weiterhin eine der Hauptursachen von Schiffsbränden sind. Lösung: IMDG-Revisionskalender in den Software-Wartungsvertrag aufnehmen; Compliance-Update innerhalb von 90 Tagen nach Revision als vertragliche Pflicht.

3. Die Planer-Akzeptanz unterschätzen. Ein KI-Stauplan, der nominell besser ist als der manuelle Plan, wird von erfahrenen Stauverantwortlichen oft trotzdem abgelehnt, weil er Entscheidungen trifft, die sie nicht erklären können oder die ihrer Erfahrung widersprechen. “Das System hat Container X in Bay 14, Reihe 6 gestaut, warum? Das ist bei Regen schwer erreichbar.” Wenn das System die Begründung nicht liefert, entsteht kein Vertrauen. Lösung: Explainability einbauen, jeder Stauplan-Vorschlag muss anzeigen, welche Constraints die Entscheidung dominiert haben.

Was mit der Einführung wirklich passiert, und was nicht

Die Technologie ist das kleinste Problem. Das größere Problem ist die Entscheidungshierarchie.

Ein KI-Stauplan ist eine Empfehlung. Die Freigabe obliegt dem verantwortlichen Kapitän oder dem zugelassenen Planungsbüro, das schreibt SOLAS vor, und daran ändert kein KI-System etwas. Was sich ändert: die Qualität der Ausgangsbasis, über die der verantwortliche Offizier entscheidet. Das System macht den Planer besser, nicht überflüssig.

Widerstandsmuster, die regelmäßig auftreten:

• “Das funktioniert für unsere Spezialladungen nicht.” Jede Reederei hat Sonderfälle, Projektladungen, militärische Güter, Überseecontainer. In der Einführungsphase werden diese Ausnahmen als Argument gegen das System verwendet. Die Lösung: Sonderfälle explizit als Constraint modellieren, nicht manuell umgehen. Das dauert, ist aber die einzige nachhaltige Lösung.

• “Wir haben das immer so gemacht.” Erfahrene Planungsverantwortliche haben über Jahre eine Intuition für ihre Schiffe entwickelt. KI-Pläne, die von dieser Intuition abweichen, werden misstrauisch aufgenommen, auch wenn sie nachweislich besser sind. Abhilfe: Pilotphase mit explizitem Vergleich dokumentieren, Kennzahlen transparent machen, keine Top-Down-Einführung.

• “Das Terminal nimmt meinen Plan so nicht.” Formatkonflikte zwischen dem KI-Stauplan-Export und dem Terminal-System sind real. Wenn der Plan nicht direkt übertragen werden kann, sind Planer gezwungen, manuell umzutippen, was die Zeitersparnis auffrisst und die Fehlerwahrscheinlichkeit erhöht. Erst Format-Integration lösen, dann ausrollen.

Realistischer Zeitplan mit Risikohinweisen

Wichtig: In keiner Phase wird das System vollständig ohne menschliche Prüfung laufen. SOLAS verlangt die Freigabe durch einen befugten Offizier, das ist kein Fehler im System, sondern die richtige Sicherheitsarchitektur.

Häufige Einwände, und was dahintersteckt

„Unsere Planer kennen die Schiffe in- und auswendig, was soll KI da besser wissen?” Die SolverMinds-Analyse (2026) zeigt: Drei erfahrene Planer mit identischen Eingangsdaten erzeugen Pläne, die sich um bis zu 40 Umstauungen unterscheiden, alle drei regulatorisch valide, aber mit sehr unterschiedlichen Kosten. Das ist kein Versagen der Planer, es ist die strukturelle Grenze menschlicher Optimierung bei Milliarden möglicher Konfigurationen. KI ersetzt nicht das Schiffswissen, sie durchsucht den Lösungsraum systematischer.

„Wenn das KI-System falsch liegt, haben wir ein Sicherheitsproblem.” Das ist der richtige Einwand, und der Grund, warum Constraint-Modellierung und Freigabesystematik so wichtig sind. Ein KI-Stauplan ohne vollständige Constraint-Abbildung (SOLAS, IMDG, Lashing) ist gefährlich. Ein KI-Stauplan mit vollständigen Constraints und obligatorischer Offizier-Freigabe ist sicherer als ein manueller Plan, weil er jeden Constraint automatisch prüft, auch die, die der Planer nach einer 10-Stunden-Schicht vergessen könnte.

„Wir sind zu klein für so ein Projekt.” Für Reedereien mit weniger als 5–8 Schiffen ist die TOS-Integrations-Investition wirtschaftlich schwer zu rechtfertigen. Es gibt alternative Abstufungen: Standalone-Stauplan-Software ohne vollständige TOS-Integration ist für kleinere Carrier ein sinnvoller Mittelweg, Navis StowMan wurde historisch auch als Desktop-Lösung eingesetzt, bevor die SaaS-Version dominierte.

Woran du merkst, dass das zu dir passt

Signale, dass es passen könnte:

• Deine Stauverantwortlichen verbringen 4+ Stunden pro Voyage mit Stauplanung und haben trotzdem regelmäßig Umstauungen im Zwischenhafen
• Du hast mehr als 5 Schiffe im Liniendienst mit fester Rotation
• Du verwendest Navis SPARCS N4, OPUS oder ein anderes TOS mit dokumentierter API
• Gefahrgut ist regelmäßiger Teil deines Cargo-Mix, manuelle IMDG-Prüfung ist fehleranfällig
• Du verlierst in Spitzenzeiten (Feiertage, Saisonmaxima) Buchungen, weil Kapazitätsauslastung bei manueller Planung nicht optimal ist
• Last-Minute-Container-Umplanungen (30+ Minuten vor Ladeschluss) führen regelmäßig zu suboptimalen Stauplänen

Drei harte Ausschlusskriterien, wer es (noch) nicht tun sollte:

1. Weniger als 3 Schiffsanläufe pro Woche je Planerin oder Planer, der Automatisierungsgewinn ist zu klein, um die TOS-Integrationskosten zu amortisieren. Bevor du ein KI-System aufbaust, investiere in bessere Stauplan-Vorlagen und IMDG-Compliance-Checklisten.

2. Kein standardisierter IMDG-konformer Planungsprozess vorhanden, wenn das Team heute nicht nach einem dokumentierten Constraint-Katalog arbeitet, wird KI diese Lücke nicht schließen. Zuerst Prozess standardisieren, dann automatisieren. Ein KI-System auf Basis eines unklar definierten Prozesses erzeugt falsch-positive Compliance-Signale, gefährlicher als manuelles Arbeiten mit klarem Vier-Augen-Prinzip.

3. Kein Terminal Operating System (TOS) im Einsatz oder TOS ohne offene API, ohne Echtzeit-Datenfluss aus dem TOS fehlen dem Optimizer die Rohdaten, die er für valide Entscheidungen braucht. Eine manuelle Dateneingabe-Schnittstelle als Übergangslösung ist akzeptabel für einen Piloten, aber nicht für den Produktionsbetrieb.

Das kannst du heute noch tun

Auch ohne KI-System gibt es einen Sofort-Schritt, der die Qualität deiner Stauplanung verbessert: Starte mit einer strukturierten Constraint-Übersicht.

Fordere von deinen Stauverantwortlichen eine Liste der Top-10-Konflikte der letzten 12 Monate, Situationen, in denen ein Container im Zwischenhafen umgestaut werden musste, weil der Stauplan suboptimal war. Kategorisiere die Ursachen: War es IMDG-Segregation? Reefer-Kapazität? Zielhafen-Reihenfolge? Stabilitätsmarge? Das Ergebnis zeigt dir, welche Constraints in eurer Stauplanung systematisch zu kurz kommen, und damit, wo ein KI-System den größten Hebel hätte.

Nutze dazu folgenden Prompt:

Quellen & Methodik

• SolverMinds (2026): “The Hidden Risk of Manual Stowage Planning in a Modern Fleet.” Analyse von drei erfahrenen Planern mit identischen Inputs, Overstow-Rate 3,2–5,1 %, benötigte Umstauungen 62–104. solverminds.com

• Yangshan Port / MDPI (2022): “Advancing multi-port container stowage efficiency: A novel DQN-LNS algorithmic solution.” Implementierung eines RL-basierten Optimierers; 16,8 % Reduktion der Container-Umstauungen. Planungszeit ca. 10 Minuten für große Schiffe. sciencedirect.com

• ZIM und UASC, Navis StowMan: Kundenzitate zur Schnelligkeit und Effektivität der Mehrfachszenarien-Planung; 600 Schiffe global im Einsatz; 50 % der TOP-10-Linienreedereien. mehrcontainerfuerdeutschland.de und marinelink.com

• Schiffskosten $1.500–2.000/Stunde: ShipFinex, “Ship Operating Costs in 2026: Complete Cost Breakdown.” shipfinex.com

• IMDG Code: IMO International Maritime Dangerous Goods Code, aktuelle Revision 42-24 (in Kraft ab 2025). Zweijährliche Revisionszyklen. imo.org

• Solver-Vergleich CPLEX vs. Gurobi: ScienceDirect (2024), “Large containership stowage planning for maritime logistics: A novel meta-heuristic algorithm.” Gurobi outperforms CPLEX bei großen Instanzen. sciencedirect.com

• CINS (Cargo Incident Notification System): Coalitionsbericht zur Gefahrgut-Segregation und falsch deklarierten Gefahrgutkombinationen als Hauptursache von Schiffsbränden. Branchenkonsens der großen Linienreedereien.

• Preisangaben Navis StowMan: Kaleris-Vertrieb und Marktberichte (Stand Mai 2026); keine verifizierbaren öffentlichen Listenpreise, Angaben sind Orientierungswerte.

Du willst wissen, welche Constraint-Lücken in eurem aktuellen Stauplan-Prozess das größte wirtschaftliche Risiko darstellen, und wie ein realistischer Einführungspfad für eure Flottengröße aussieht? Meld dich für ein konkretes Erstgespräch.