Fährbetriebs-Software: dynamische Disposition, Yield und Störungsbewältigung

Von allen Segmenten unter dem Dach des kommerziellen Maritimbetriebs liegt der Fährverkehr am weitesten vom Lehrbuch entfernt. Ein Containerschiff fährt wochenlang; sein kommerzieller Zyklus bemisst sich in Quartalsverträgen und FFA-Hedges. Ein Tanker verbringt Tage in Lade- und Löschhäfen; sein Rhythmus wird von Laytime-Klauseln bestimmt. Eine Passagierfähre dagegen kann einen vollen kommerziellen Zyklus vier- bis zwölfmal am Tag abschließen, mit Liegezeiten von dreißig Minuten, Passagiererwartungen auf Retail-Niveau, verderblichem Inventar in Form leerer Sitze und unverkaufter Lademeter sowie Wetterrisiko, das auf enge saisonale Fenster konzentriert ist. Die operative Physik ist anders, und die Software, die sie trägt, muss es ebenfalls sein.

Dieser Artikel betrachtet, was Fährbetriebs-Software tatsächlich leisten muss — Disposition, Yield, regulatorische Ladeplanung, Störungsbewältigung — und warum generische Plattformen, aus dem Container- oder Tankerumfeld portiert, an einem echten Fährtag scheitern.

Anatomie eines Fährtags

Ein typischer Tag auf einer Küsten- oder Short-Sea-Route kann um 04:30 Uhr beginnen, mit der Übergabe an die Crew, der Bunkerabsprache mit der Hafenbarge, der Vorbereitung des Fahrzeugdecks und der finalen Kontrolle der Lärm- und Emissionsprotokolle der Vornacht. Um 06:15 Uhr stehen die ersten Fußpassagiere an; um 06:45 Uhr lädt das Fahrzeugdeck nach einem Stauplan, der bereits Trailergewichte, Gefahrgutsegregation und die kommerziellen Prioritäten des Betreibers berücksichtigt — Stammkunden, Vertragsspediteure, Last-Minute-Drive-ups. Das Schiff legt um 07:00 ab. Es kommt um 09:30 zurück. Es muss um 10:00 erneut auslaufen. Eine Liegezeit von dreißig Minuten, fünf- bis zehnmal am Tag wiederholt.

In dieser Fenster muss das Operationsteam abstimmen:

• Aussteigen und Räumen des Fahrzeugdecks gegen Linkspan-Verfügbarkeit;
• Einsteigen von Fußpassagieren, Passagieren mit Mobilitätsbedarf und Fahrzeugen, oft über getrennte Zugänge;
• Crew-Rotationen unter den Ruhezeitregeln des MLC 2006;
• Bunker und Abfallannahme nach MARPOL Anlage I, IV, V und VI;
• Hafen-Slot-Abstimmung, da die meisten Short-Sea-Häfen Liegefenster zuteilen, die ohne Kaskadeneffekt nicht verschiebbar sind;
• Echtzeit-Passagierkommunikation: Gate-Wechsel, Verspätungen, verpasste Anschlüsse zu Bahn oder Bus;
• Sicherheitsbriefings, Manifest-Schluss und finale SOLAS-Stabilitätsprüfungen vor der Abfahrtsfreigabe.

Keine dieser Tätigkeiten ist für sich exotisch. Die Schwierigkeit liegt darin, dass sie alle ineinandergreifen, alle auf der 30-Minuten-Uhr laufen und an jedem Hafen jeder Rotation, jeden Tag, parallel passieren.

Kapazität und Yield: zwei Inventare auf einem Rumpf

Eine Passagierfähre verkauft auf derselben Abfahrt zwei grundsätzlich verschiedene Produkte. Das Passagierdeck ist Retail: Sitze, Kabinen, Lounges, manchmal Restaurants und Shops. Das Fahrzeugdeck ist Logistik: Lademeter für Pkw, Motorräder, Vans, Reisebusse und — zunehmend wichtig — Frachttrailer. Beide haben unterschiedliche Erlöse pro Kubikmeter, unterschiedliche Preiselastizitäten, unterschiedliche Buchungskurven und unterschiedliches No-Show-Verhalten. Fahrzeugbuchungen festigen sich früher und sind selten No-Show; Passagierbuchungen, vor allem im Freizeitsegment, können sich in den letzten 72 Stunden stark bewegen.

Yield-Management aus der Luftfahrt oder Hotellerie behandelt Inventar als homogenen Pool. Fähr-Yield kann das nicht. Eine moderne Engine modelliert Passagier- und Fahrzeugdeckinventare zunächst getrennt und dann gemeinsam, weil sie sich gegenseitig beeinflussen: Eine schwere Frachtladung reduziert die verbleibenden Lademeter für Pkw, was den Preis der nächsten Pkw-Buchung begrenzt, was wiederum in die Angebotsoberfläche für den Freizeitkanal zurückfließt. Manche Betreiber führen Kabineninventar als dritte Achse auf Nachtüberfahrten ein — und Kabinen verhalten sich, anders als Sitze, eher wie Hotelzimmer als wie Flugzeugsitze, mit einem festen Same-Day-Floor.

Als Branchenkontext genannte Betreiber — DFDS, Stena Line, Brittany Ferries, Grimaldi, GNV, Moby, Trasmediterránea, Baleària — haben jahrelang ihre Yield-Logik auf ihre Routenmischungen kalibriert. Das gemeinsame Muster ist ein geschichtetes Modell: eine strategische Price-Ladder pro Route und Saison, ein taktisches Overlay, das auf den Buchungstakt reagiert, und ein Echtzeit-Floor, der die Kannibalisierung von Vertrags-Fracht verhindert.

Dynamische Disposition und Fahrplanwiederherstellung

Der veröffentlichte Fahrplan ist in der Praxis ein Anspruch. Ein COO weiß, dass an jedem beliebigen Tag ein Anteil der Abfahrten von etwas berührt wird — einer Acht-Bft-Vorhersage, einem Ruderalarm, einer Hafensperrung wegen eines Kreuzfahrtanlaufs, einer medizinischen Ausschiffung. Die Frage ist nicht, ob die Störung passiert; sie ist, wie schnell der Betrieb stabilisiert werden kann.

Software für dynamische Disposition muss drei Horizonte abdecken:

1. Strategischer Fahrplanentwurf, in dem Jahres- oder Saisonfahrpläne gegen Nachfrageprognosen, Hafen-Slots, Crew-Pläne und Wartungsfenster gebaut werden;
2. Taktische Umplanung, im Fenster 24 bis 72 Stunden vor Abfahrt, in dem Windprognosen, technische Mängel oder kommerzielle Buchungen das Streichen, Zusammenlegen oder Aufwerten von Abfahrten rechtfertigen können;
3. Echtzeit-Recovery, wenn eine Abfahrt bereits gestört ist und der Betreiber Passagiere umbuchen, Fracht umrouten, Crews umsetzen und den Fahrplan am selben oder nächsten Tag wieder einfangen muss.

Am schwierigsten ist die Echtzeit-Recovery. Sie verlangt, dass die Plattform ein lebendes Bild der gesamten Flotte hält — Bunker, Ballast, Crewstunden, Hafenfreigaben, Passagier- und Fahrzeugmanifeste — und in Minuten, nicht in Stunden, durchführbare Wiederherstellungspläne erzeugt. Software, die aus dem Containerschiff-Umfeld portiert wurde, in dem ein verspätetes Schiff einfach gegen das nächste Hafenfenster gepuffert wird, hat dafür kein natives Konzept; dort wird Recovery in Tagen gemessen, nicht in Minuten.

Auslastungsoptimierung ohne Stabilitätsbruch

Jeder kommerzielle Betreiber will Resttragfähigkeit füllen. Auf einer Fähre gibt der Engpass, der zuletzt nachgibt, nicht aus kommerziellen, sondern aus regulatorischen Gründen nach. SOLAS Kapitel II-1 regelt die Leckstabilität von Passagierschiffen, und sein probabilistisches Rahmenwerk nach 2009 — gemeinsam mit dem Stockholm Agreement für nordwesteuropäische RoRo-Passagierfähren — setzt harte Grenzen, wie Fahrzeugdecks gegenüber Passagierabteilungen und wasserdichter Unterteilung beladen werden dürfen. Eine kommerziell attraktive Trimmlage kann betrieblich illegal sein.

Gute Fähr-Ladeplanungssoftware optimiert Stauplan nicht nur nach Schwerpunkt und Trimm. Sie kodiert die tatsächliche Leckstabilitätsdokumentation des Schiffs, behandelt den Loading Computer als Single Source of Truth und weigert sich, Staupläne freizugeben, die die genehmigte Hülle verletzen. Darüber legt sie kommerzielle Logik: Gefahrgutsegregation nach IMDG, riskante Ladung auf Wetterdecks, Lebendvieh auf belüfteten Decks, Planung von Reefer-Steckplätzen und Spurzuweisung, die Shunting beim Aussteigen minimiert.

Für LNG-betriebene Fähren ergänzt der IGF Code eine weitere Schicht: Bunkerkompatibilitätsprüfungen, Gasdetektionszonen rund um den Bunker-Manifold und betriebliche Grenzen für gleichzeitiges Bunkern und Passagiereinstieg. Nichts davon ist in Software enthalten, die für Boxstauung auf einem 12.000-TEU-Containerschiff gedacht ist.

MARPOL, EEXI und CII: Druck speziell auf Fähren

Fähren sind anders umweltexponiert als Hochseeflotten. Ihre Hafen-zu-Hafen-Intensität führt dazu, dass ein hoher Anteil des Gesamtkraftstoffverbrauchs in Manöver, Festmachen und Cold-Ironing-Übergängen anfällt. Die Häufigkeit ihrer Anläufe erzeugt überproportionale Belastung lokaler Luftqualitätsregulierung in Hafenstädten — Genua, Barcelona, Marseille, Dover, Helsinki —, wo der kommunale Druck auf Emissionen schärfer ist als die Hochseeregulierung.

EEXI gilt einmalig. CII gilt jährlich, und seine Ratingbänder sind streng für Short-Sea-Betreiber, deren entfernungsbasierter Nenner klein ist. Betreiber reagieren mit Cold Ironing, Batteriehybridisierung, Slow Steaming auf flexiblen Etappen und betrieblichen Effizienzgewinnen, die von detaillierten Fahrtdaten abhängen: Seegang, Drift, ETA-Genauigkeit, Hafenwartezeiten. Die Software muss diese Daten pro Etappe erfassen, korrekt zuordnen und sowohl in das regulatorische Reporting (EU MRV, IMO DCS) als auch in die kommerzielle Disposition einspeisen — denn ein CII-Banddowngrade kann den Business Case einer ganzen Route verändern.

Störungsbewältigung und Passagierkommunikation

Der Fährpassagier von 2026 erwartet, was er von Bahn und Kurzstreckenflug bekommt: Echtzeit-Störungsinformation, automatische Umbuchungsangebote, Erstattung ohne Telefonate und barrierefreie Umroutung. Die ATOC-Standards in Großbritannien und die EU-Verordnung 1177/2010 zu Rechten der Schiffspassagiere setzen den gesetzlichen Boden; die kommerzielle Reputation setzt einen höheren.

Das Problem ist, dass Fährstörungen selten sauber sind. Ein gestrichener Zug fährt einfach nicht; eine gestrichene Fährabfahrt lässt Trailer am Kai zurück, Fußpassagiere ohne Anschluss und Fahrzeuge, deren Fahrer am Ziel bereits ein Hotel bezahlt haben. Recovery verlangt von der Plattform:

• Passagiere über die betroffenen Abfahrten umzubuchen, unter Wahrung von Kabinenzuteilung und Barrierefreiheit;
• Fahrzeuge und Frachttrailer umzusetzen, mit expliziter Behandlung von Gefahrgut und Reefern;
• Mit Hafenbehörden, Linkspan-Betreibern und weiterführenden Verkehrsanbietern zu koordinieren;
• Die Entschädigungsdossiers nach Verordnung 1177 automatisch zu erzeugen, nicht als manuelle Backoffice-Aufgabe drei Wochen später;
• Proaktiv zu kommunizieren, in Sprache und Kanal des Passagiers, mit substantiellem Inhalt — nicht generischen Entschuldigungstemplates.

Gut gemacht, verwandelt das ein Force-Majeure-Ereignis in eine vertretbare kommerzielle Geschichte. Schlecht gemacht, erzeugt es die Social-Media-Vorfälle, die Betreiber heute mehr fürchten als den Regulator.

Was gute Fähr-Software leistet, was Container-adaptierte Software nicht kann

Das Muster ist inzwischen sichtbar. Software, die ursprünglich für Container- oder Tankerflotten gebaut und dann mit angeschraubtem Passagiermodul an Fährbetreiber verkauft wird, scheitert an fünf wiederkehrenden Stellen:

• Zeithorizont: sie unterstellt kommerzielle Zyklen in Tagen oder Wochen, nicht in 30-Minuten-Liegezeiten;
• Inventarmodell: sie behandelt Kapazität als homogen, nicht als gemeinsame Yield-Oberfläche aus Passagier-, Fahrzeug- und Kabineninventar;
• Stabilität und Sicherheit: sie hat kein natives Modell für SOLAS-Leckstabilität, IGF-Gaszonen oder RoRo-Spurzuweisung unter IMDG-Segregation;
• Störungen: ihr fehlen die Echtzeit-Fahrplan-Recovery-Primitive, die ein Fähr-COO um 06:00 an einem Acht-Bft-Morgen braucht;
• Passagiererfahrung: sie hat kein natives Konzept für Barrierefreiheit, Verordnung-1177-Entschädigung oder mehrsprachige Kommunikation.

Purpose-built Fähr-Software geht von der entgegengesetzten Annahme aus: Der Fährtag ist die atomare Einheit, Passagier und Trailer teilen einen Rumpf, aber nicht dieselbe kommerzielle Logik, und Störungsbewältigung ist kein Ausnahmepfad, sondern eine Kernfähigkeit.

Vom Werkzeugkasten zum Betriebssystem

Die stärksten Fährbetreiber, die wir in Europa und im Mittelmeer beobachten, lassen die Ära separater Disposition-, Yield- und Störungswerkzeuge, zusammengehalten durch Tabellen und geteilte Kalender, hinter sich. Sie konsolidieren auf ein einziges operatives System of Record, in dem COO, Route Manager, Port Operations Manager, Revenue und Customer Service gemeinsam arbeiten. Der Vorteil ist nicht ein einziges Dashboard. Es ist, dass dieselben Daten — Manifest, Stauplan, Crewstunden, Bunker, Wetter, Slots — jede Entscheidung steuern, sodass eine taktische Umroutung um 11:00 und eine Yield-Anpassung um 14:00 sich nicht um 17:00 widersprechen.

Diesen Punkt zu erreichen, ist ein mehrjähriges Programm, kein Software-Kauf. Aber der Ertrag ist messbar: höhere Auslastungen bei gleichem Yield-Risiko, schnellere Recovery, geringere regulatorische Exposition und eine Passagiererfahrung, die unter Druck hält.

Das Ferry-Modul von SupaMaritime ist speziell für dieses Segment gebaut — Passagier- und RoRo-Betreiber auf Küsten-, Short-Sea- und Mittelmeerrouten — und integriert sich in die breiteren SupaMaritime-Module für Agency- und Merchant-Flottenbetrieb. Lokalisierte Einstiegspunkte stehen zudem unter /ferry, /it/ferry, /es/ferry und /fr/ferry bereit. Für Betreiber, die abwägen, wo sie anfangen sollen, ist der praktische erste Schritt selten ein vollständiger Plattformwechsel; er ist ein fokussierter Review, an welchen Stellen die aktuelle Toolchain an einem echten gestörten Tag versagt, und eine Roadmap, die zuerst die teuersten Failure-Modi behebt.