Die Theater-Eröffnung ist die logistikintensivste Phase jedes größeren Streitkräfteeinsatzes. Bevor die erste Kampfeinheit in Operationen eingesetzt werden kann, müssen enorme Mengen an Personal, Ausrüstung, Treibstoff, Munition und Nachschubbeständen durch eine begrenzte Anzahl strategischer Eintrittspunkte — Seehäfen und Flugplätze — in ein Theater fließen, das möglicherweise über begrenzte Infrastruktur, umkämpften Luftraum und einen Gegner verfügt, der aktiv versucht, den Aufbau zu stören. Die Software, die diesen Fluss verwaltet, entscheidet darüber, ob eine Streitmacht kampfbereit ankommt oder fragmentiert, unterversorgt und operativ anfällig.

Theater-Nachschubmanagementsoftware ist kein kommerzielles ERP-System im Tarnanzug. Sie muss die Ladungsmanifestierung und den Durchsatz in Entladehäfen verwalten, wo täglich Hunderte von Containern ankommen, ein Verteilungsnetz planen, das zu Beginn der Operationen noch nicht existiert, zwischen Push- und Pull-Logistikmodellen arbitrieren, während sich die operative Lage entwickelt, und Sichtbarkeit über alle Ebenen eines Theaters bieten, das sich über Hunderte von Kilometern erstrecken kann. Dieser Artikel beschreibt die Architektur von Softwaresystemen, die in der Lage sind, jede Phase dieser Herausforderung zu bewältigen.

Theater-Eröffnungslogistik: vom Schiff zum Schützengraben

Die Theater-Eröffnung umfasst den Empfang, die Bereitstellung, die Weiterbewegung und die Integration (RSOI) von Streitkräften und ihren Nachschublieferungen in ein operatives Theater. Jede Phase stellt unterschiedliche Anforderungen an das Nachschub-Informationssystem.

Empfang findet im Hafen der Entladung (POD) statt — dem Seehafen (SPOD) oder Flugplatz (APOD), an dem strategische Transportmittel die Streitmacht abliefern. In einem Seehafen entladen Roll-on/Roll-off-Schiffe (RO/RO) Rad- und Kettenfahrzeuge direkt auf den Pier; Containerschiffe entladen ISO-Boxen durch Kräne in Sammelpunkte. Auf einem Flugplatz parken C-17-, C-130- oder alliierte Transportflugzeuge auf Rollfeldern zur schnellen Entladung, bevor die nächste Welle von Flugzeugen den Platz benötigt. Der Empfang wird durch die Anzahl der Liegeplätze, Krankapazität, Rollfeld-Parkfläche und Zollabfertigungsraten begrenzt — alles Parameter, die die Nachschubsoftware als Kapazitätswerte modellieren muss.

Bereitstellung ist das Sammeln entladener Ladung im Hafenbereitstellungsbereich bis zur Weiterbewegung. Fahrzeuge, die ohne Besatzungen ankommen, Container, die vor ihrer übergeordneten Einheit ankommen, und Ausrüstung, die auf Zollinspektion wartet, häufen sich in der Bereitstellung an. Schlechtes Bereitstellungsmanagement — unzureichende Fläche, unklare Verantwortlichkeit, unzureichende Verfolgung — verursacht Hafenstaus, die Theater-Eröffnungen historisch um Tage oder Wochen verzögert haben. Software, die jede Ladeeinheit durch den Bereitstellungsbereich mit RFID- oder Barcode-Scanning verfolgt und Verweilzeitverstöße markiert, ist das primäre Werkzeug zur Verhinderung von Bereitstellungsstaus.

Weiterbewegung ist der Konvoi-, Schienen- oder Lufttransport von bereitgestellter Ladung vom POD zum taktischen Sammelgebiet (TAA), wo Einheiten sich vor dem Einsatz in Operationen konsolidieren. Die Weiterbewegung wird gegen die TPFDD-Sequenz (Time-Phased Force and Deployment Data) geplant — Einheiten mit früheren operativen Verpflichtungen haben Vorrang für die Weiterbewegung, unabhängig davon, wann ihre Ladung zufällig am Hafen ankommt.

Integration ist die abschließende Phase, in der Ausrüstung, Munition, Treibstoff und Verpflegung, die separat ankamen, im TAA mit ihren übergeordneten Einheiten zusammengeführt werden, sodass die Einheit Bereitschaftsinspektionen durchführen und sich für Operationen als verfügbar erklären kann.

Die kritische Softwareanforderung, die alle vier Phasen überspannt, ist ein einziger Datensatz für jeden TCN (Transportation Control Number) — die DoD-Kennung für eine Ladeeinheit — der seinen Zustand durch die RSOI-Pipeline verfolgt. Ohne dies kann das Theater Sustainment Command die grundlegendste Frage nicht beantworten: Wo befindet sich Ladung X, und wann wird sie Einheit Y erreichen?

Verwaltungssoftware für den Entladehafen (POD)

Die Verwaltungssoftware für den Entladehafen übernimmt die Empfangsphase am Eintrittspunkt. Ihre Kernfunktionen sind Ladungsmanifestierung, Durchsatzverfolgung, RFID-Tracking sowie Zoll- und Gefahrgutverwaltung.

Ladungsmanifestierung nimmt das Schiffsfrachtmanifest oder das Luftfrachtmanifest auf, vergleicht es mit dem TPFDD und erstellt für jede Ladeeinheit einen TCN-Datensatz. Die Manifestintegration muss mit der Realität umgehen, dass Manifeste in mehreren Formaten ankommen: RFID-getaggte Ladungen erzeugen automatisierte TCN-Listen über das In-Transit Visibility (ITV)-System; ältere Ladung kann mit Papierfrachtbriefen ankommen, die manuelle Dateneingabe erfordern. Die Software muss beides ohne doppelte TCN-Datensätze verarbeiten.

Ein typischer TCN-Datensatz im POD-Verwaltungssystem enthält:

{
  "tcn":          "T2AABC1234567",
  "unit_id":      "1-68AR",
  "nsn":          "2350-01-523-5947",
  "description":  "TANK, COMBAT, FULL TRACKED: M1A2 SEPv3",
  "quantity":     1,
  "unit_of_issue":"EA",
  "gross_weight_kg": 62000,
  "hazmat_class": null,
  "tpfdd_arrival": "2026-06-24T06:00:00Z",
  "actual_arrival": "2026-06-24T08:14:00Z",
  "rsoi_state":   "STAGING",
  "staging_area": "YARD-BRAVO",
  "staging_since": "2026-06-24T10:30:00Z",
  "priority":     1,
  "onward_destination": "TAA-NORTH"
}

Durchsatzverfolgung misst die tatsächliche Verarbeitungsrate des Hafens gegenüber der geplanten Rate aus dem TPFDD. Wenn der Plan erfordert, dass täglich 5.000 Short Tons durch den SPOD fließen, um den Zeithorizont für den Streitkräfteabschluss einzuhalten, und der tatsächliche Durchsatz bei 3.800 Tonnen pro Tag liegt, muss die Software diese Abweichung aufzeigen und die daraus resultierende Verzögerung beim Streitkräfteabschluss prognostizieren, damit das Theater Sustainment Command Korrekturmaßnahmen ergreifen kann — zusätzliche Kranschichten, mehr LKW-Kapazitäten oder angepasste Einheitsprioritätssequenzen.

RFID-Tracking am POD verwendet passive UHF-RFID-Interrogatorportale (ISO 18000-6C, EPC Gen 2), die an den wichtigsten Engpässen des Hafens installiert sind. Jede getaggte Ladeeinheit — Container, Palette oder Fahrzeug — wird automatisch gelesen, wenn sie durch Kran-Entladebereiche, Bereitstellungsbereichstore und Hafenausgangstore fährt. Das Portal-Leseereignis erzeugt ein zeitgestempeltes Ereignis, das den RSOI-Zustand des TCN in der Datenbank ohne manuelle Dateneingabe aktualisiert. Verbleibende ungelesene TCNs (jene, deren Tags beschädigt waren oder durch einen Portalfehler nicht gelesen wurden) werden am Ende jeder Schicht durch Handlesegeräte erfasst.

Die HAZMAT- und Zollabfertigungsverarbeitung fügt einen parallelen Workflow hinzu: Container mit Ladung der Klasse 1 (Explosivstoffe), Klasse 3 (brennbare Flüssigkeiten) oder Klasse 9 (sonstiges Gefahrgut) erfordern abgetrennte Bereitstellungsbereiche und besondere Handhabungsgenehmigungen. Die Software setzt Bereitstellungsbereichszuweisungen basierend auf der Gefahrgutkategorie durch und erstellt die erforderliche Gefahrgutdokumentation für die Zollbehörden des Gastlandes.

Planung des Verteilungsnetzes

Sobald die Ladung den Hafenbereitstellungsbereich verlässt, muss sie durch ein Verteilungsnetz bewegt werden, das das Theater Sustainment Command parallel zum Eintreffen der operativen Streitkräfte aufbaut. Das Verteilungsnetz verbindet den POD mit vorwärtigen Versorgungspunkten über eine Reihe von zwischengeschalteten Logistikknoten, von denen jeder seinem Echelon entsprechende Bestände vorhält.

Die standardmäßige Theater-Verteilungsarchitektur verwendet drei Echelon-Knoten:

Knoten Echelon Typische Kapazität Primäre Versorgungsklassen
Theater Distribution Base (TDB) Theater 30–90 Tage I, II, III, IV, V, VIII, IX
Combat Sustainment Support Bn (CSSB) Division 7–15 Tage I, III, V, IX hochnachgefragte Artikel
Brigade Support Bn (BSB) Brigade 3–5 Tage I, III, V vorgeschriebene Ladungen

Linienfernfahrt vs. lokale Fahrt ist die grundlegende Verteilungsplanungsentscheidung an jeder Echelon-Grenze. Die Linienfernfahrt ist der Massentransport vom Theater-Depot zum Divisionsversorgungsbereich unter Verwendung dedizierter Fernfahrzeugkapazitäten (PLS Flat-Rack, HET für schwere Ausrüstung). Die lokale Fahrt ist die abschließende Lieferung vom Divisionsversorgungsbereich nach vorne zu Brigadeversorgungspunkten unter Verwendung organischen Einheitentransports. Fernfahrzeugkapazitäten sind knapp und müssen so geplant werden, dass Tonnenkilometer pro Fahrzeug pro Tag maximiert werden; die lokale Fahrt wird durch die organische LKW-Dichte der unterstützten Einheiten und durch taktische Routensicherheitsüberlegungen begrenzt.

Die Planungssoftware für Verteilungsnetze modelliert die Transportrouten zwischen Knoten als gerichteten Graphen mit Kapazitäts- und Fahrzeitattributen. Das Netzwerkmodell ermöglicht es der Software, Folgendes zu berechnen:

# Distribution capacity check (pseudo-code)
def check_route_capacity(route_id, planned_tons_per_day):
    route = network.get_route(route_id)
    constraints = [
        route.bridge_classification,    # MLC for crossing
        route.surface_type,             # MSR, ASR, dirt
        route.current_status,           # OPEN / RESTRICTED / CLOSED
        route.max_tons_per_day          # traffic control capacity
    ]
    available_capacity = min(
        c.effective_capacity() for c in constraints
    )
    utilization = planned_tons_per_day / available_capacity
    if utilization > 0.85:
        raise CapacityWarning(
            f"Route {route_id}: {utilization:.0%} of capacity."
            " Alternate routing required."
        )
    return utilization

BSA-, CSA- und ASA-Positionierungsentscheidungen — wo Logistikknoten platziert werden, wenn sich die taktische Lage entwickelt — werden durch die Sensitivitätsanalyse des Netzwerkmodells unterstützt. Die Verschiebung einer BSA um 20 km nach vorne kann die lokalen Fahrzeiten verkürzen, erhöht jedoch ihre Verwundbarkeit und erfordert ein neues Linienfernfahrtsegment. Die Software sollte es Planern ermöglichen, alternative Knotenpositionen durch Aktualisierung der Knotenkoordinaten und Neuberechnung des Netzwerk-Kostenmodells zu bewerten und dabei Kompromisse bei Lieferzeit, Routendistanz und Fahrzeugauslastung aufzuzeigen, bevor Positionen festgelegt werden.

Push- vs. Pull-Nachschubmodelle

Die Wahl zwischen Push- und Pull-Logistik ist nicht binär — es handelt sich um eine dynamische Richtlinie, die sich nach Versorgungsklasse, Operationsphase und Reife des Verteilungsnetzes verschiebt. Theater-Nachschubsoftware muss beide Modelle implementieren und den Übergang zwischen ihnen unterstützen.

Push-Logistik sendet vorkonfigurierte Versorgungspakete auf geplanter Basis an Einheiten, ohne dass Einheiten Bestellungen einreichen müssen. Während der Theater-Eröffnung ist Push der Standard für Klasse I (Rationen), III(B) (Massenpetroleum) und Wasser, da das Einheiten-Versorgungssystem möglicherweise noch nicht operativ ist, Funkkommunikation begrenzt sein kann und Standardverbrauchsraten vorhersehbar genug sind, um vorgeplante Bestände zu planen. Eine vorgeschriebene Bestandsliste (PLL) für ein mechanisiertes Bataillon gibt Standardmengen an Klasse-IX-Ersatzteilen an; ein Push-Paket für ein neu eintreffendes Bataillon wird aus dieser PLL erstellt und versendet, sobald die Einheit in ihrem TAA ankommt.

Pull-Logistik ist nachfragegesteuert: Einheiten stellen Bestellungen für bestimmte Artikel ein, und das Versorgungssystem füllt und versendet gegen diese Bestellungen. Pull ist genauer als Push — es reagiert auf tatsächlichen Verbrauch statt auf geschätzten Verbrauch — erfordert jedoch funktionierende Kommunikationssysteme und eine Versorgungsverwaltungsstruktur auf Einheitsebene. Pull wird zum dominanten Modell, sobald die Streitkräfte etabliert sind und das Verteilungssystem den Normalbetrieb erreicht hat.

Die Software für die Verteidigungslieferkette muss Push und Pull als getrennte, aber integrierte Workflows implementieren. Push-Pakete werden auf Ebene des Nachschubkommandos geplant und ohne Einheitenaktion versandt; Pull-Bestellungen entstehen auf Einheitsebene und fließen durch das Versorgungssystem nach oben. Ein hybrider Ansatz — tägliches Klasse-I-Paket automatisch pushen, aber Pull-Bestellungen für Klasse-IX-Ersatzteile erfordern — ist die Standardpraxis in den meisten Theater-Operationsplänen.

Das kritische Softwaremerkmal für das Management des Push-to-Pull-Übergangs ist ein Verbrauchsverfolgungsmechanismus, der erkennt, wenn der tatsächliche Klasse-IX-Verbrauch von den Push-Paket-Annahmen abweicht. Wenn Einheiten Ersatzteile mit dem Doppelten der geplanten Rate entnehmen, reicht die Push-Paket-Menge nicht aus, und die Lücke muss durch reaktive Pull-Bestellungen gedeckt werden. Die Software sollte diese Abweichung automatisch aufzeigen und nicht auf manuelle Analyse des Versorgungsoffiziers angewiesen sein.

Nachschubflusssteuerung: das Theater-Logistik-Lagebild

Das Theater-Logistik-Lagebild (LCOP) ist die integrierte Anzeige, die dem Theater Sustainment Command Sichtbarkeit des gesamten Nachschubflusses gibt — von Ladung, die noch an Bord von Schiffen auf See ist, über den POD, durch das Verteilungsnetz bis hin zu Tages-Versorgungsmengen auf Einheitsebene. Es ist das primäre Werkzeug zur Flusssteuerung: Identifizierung, wo die Nachschubpipeline verstopft ist, und Umleitung von Kapazitäten zur Beseitigung der Verstopfung.

Die Militär-Logistik-Sichtbarkeitsplattform, die dem LCOP zugrunde liegt, integriert Daten aus mehreren Quellen:

  • ITV (In-Transit Visibility)-System — RFID- und GPS-Verfolgungsdaten für alle getaggten Kapazitäten in der Verteilungspipeline
  • POD-Durchsatzsystem — täglicher Hafendurchsatz, Belegungsgrad des Bereitstellungsbereichs, Verweilzeiten
  • Einheits-Versorgungsstatusberichte — Tages-Versorgungsmengen nach Klasse, täglich von Einheits-S4-Sektionen eingereicht
  • Verteilungskapazitätsstatus — LKW-Verfügbarkeit, PLS- und HET-Auslastungsraten
  • Routenstatus — Route offen/eingeschränkt/geschlossen, aktualisiert aus Lagebild und Routenräumungsberichten

Das LCOP präsentiert diese Daten auf einer geospatial Anzeige mit logistikspezifischer Symbolik (MIL-STD-2525 Logistiksymbole für Versorgungspunkte, Wartungsbereiche, medizinische Behandlungseinrichtungen) und einem Satz von Versorgungsstatusüberlagerungen, die Einheitsstandorte nach Tages-Versorgungsmengen farbkodieren — grün für ausreichende Bestände, gelb für marginal, rot für kritischen Mangel. Das J4-Personal kann auf einen Blick sehen, welche Einheiten einem Versorgungsausfall gefährdet sind und welche Verteilungsrouten zur Verfügung stehen, um sie zu erreichen.

Flusssteuerungsmaßnahmen, die über das LCOP ergriffen werden, umfassen: Neuprioritisierung von LKW-Fahrten zur Unterstützung von Einheiten mit kritischen Engpässen, Umleitung von Ladung in Transit von einer überlasteten Route zu einer alternativen Route, Auftrag für Luftnachschub (CH-47 oder UH-60 Schleppladung), um Einheiten zu erreichen, die von der Bodenverteilung abgeschnitten sind, und Anpassung des Push-Paket-Zeitplans, um die tägliche Durchsatzkapazität des Verteilungssystems nicht zu überschreiten.

Integration mit strategischen Mobilitätssystemen

Theater-Nachschubsoftware arbeitet nicht isoliert — sie empfängt den Einsatzplan von strategischen Systemen und gibt Ausführungsdaten an diese zurück. Die wichtigsten Integrationspunkte sind JOPES, TCAIMS-II und LOGFAS für Koalitionspartner.

JOPES (Joint Operation Planning and Execution System) ist die maßgebliche Quelle für den TPFDD — die Einsatzsequenz, die angibt, welche Einheiten wann mit welcher Ausrüstung auf welchem strategischen Transportmittel bewegt werden. Theater-Nachschubsoftware nimmt den TPFDD auf, um den erwarteten POD-Ankunftsplan zu erstellen. Wenn tatsächliche Ankünfte vom TPFDD abweichen (Schiffe durch Wetter verzögert, Flugzeuge umgeleitet), berechnet das System die Auswirkung auf das operative Verfügbarkeitsdatum der Einheit und markiert es für die J4-Bewertung.

TCAIMS-II (Transportation Coordinator's Automated Information for Movements System II) verwaltet die Bewegungssteuerungsfunktion: Zuweisung strategischer Transportmittel an Einheiten, Verwaltung von Konvoigenehmigungen und Verfolgung von Bewegungsanfragen bis zur Ausführung. Theater-Nachschubsoftware schnittstellt mit TCAIMS-II, um genehmigte Konvoigenehmigungen zu empfangen und tatsächliche Konvoiabschlüsse zu melden, was den Bewegungssteuerungskreislauf schließt.

LOGFAS (Logistics Functional Area Services) ist das Koalitionsäquivalent für europäische Verbündete. Die NATO-Logistik-Berichtsstandards, die LOGFAS implementiert, verwenden andere Datenmodelle als US-DLMS-Transaktionen — NATO-Lagernummern gegenüber NSNs, unterschiedliche Einheitsmengen-Konventionen und unterschiedliche Nachrichtenformate. Ein koalitionäres Theater-Nachschubsystem muss eine Übersetzungsschicht implementieren, die zwischen US-Logistiktransaktionsformaten (DLMS 856 Vorabanlieferungsmitteilung, DLMS 832 Preis-/Verkaufskatalog) und LOGFAS-Äquivalenten konvertiert. Die Übersetzungsschicht muss semantische Äquivalenz wahren — nicht nur Feldzuordnung, sondern korrekte Interpretation von Mengen-, Einheitsmengen- und Klassifikationskonventionen zwischen Bündnispartnern.

# TPFDD arrival vs actual comparison
SELECT
    t.tcn,
    t.unit_id,
    t.tpfdd_arrival::date          AS planned_arrival,
    t.actual_arrival::date         AS actual_arrival,
    (t.actual_arrival - t.tpfdd_arrival)
        / INTERVAL '1 day'        AS variance_days,
    t.priority,
    t.onward_destination
FROM tcn_records t
WHERE t.rsoi_state IN ('POD_ARRIVED','STAGING')
  AND t.actual_arrival IS NOT NULL
ORDER BY ABS(
    EXTRACT(EPOCH FROM (t.actual_arrival - t.tpfdd_arrival))
) DESC
LIMIT 50;

Nachschubmetriken und Bereitschaftsberichterstattung

Das Theater Sustainment Command berichtet täglich an das Joint Logistics (J4)-Personal über den Nachschubstatus des Theaters. Diese Berichte sind der primäre Mechanismus, mit dem der Operationskommandeur beurteilt, ob die Nachschubbasis geplante Operationen unterstützen kann. Die manuelle Erstellung dieser Berichte aus disparaten Datenquellen — Hafendurchsatzprotokollen, Einheits-Versorgungsstatusmeldungen, Konvoiabschlussberichten — ist zeitaufwendig und fehleranfällig. Theater-Nachschubsoftware automatisiert diese Berichterstellung aus kontinuierlich aktualisierten Daten.

Die kritischen Nachschubmetriken sind:

Hafendurchsatzrate — Short Tons, die täglich vom POD abgefertigt werden, gemessen gegen die geplante Rate, die erforderlich ist, um den Streitkräfteabschluss zu erreichen. Abweichungen unterhalb des Plans summieren sich: Ein Hafen, der fünf Tage lang bei 80 % des geplanten Durchsatzes läuft, häuft ein Defizit an, das dem gesamten Ladungsinhalt eines Schiffes entspricht, was den Streitkräfteabschluss um einen ganzen Entladezyklus eines Schiffes verzögert.

Versorgungsantwortzeit (SRT) — verstrichene Zeit von der Einreichung einer Einheitsbestellung bis zur Verfügbarkeit des Artikels am Einheits-Versorgungspunkt. Die SRT-Aufschlüsselung — Trennung von Bestellverarbeitungszeit, Ausgabezeit, Transportzeit und Empfangszeit — identifiziert, welche Komponente der Lieferkette der Engpass ist. Eine lange Transportzeit kann auf unzureichende LKW-Kapazitäten hinweisen; eine lange Ausgabezeit kann auf einen Versorgungspunkt hinweisen, der ohne automatisiertes Lagerbestandsmanagement arbeitet.

Pipeline-Befüllung nach Versorgungsklasse — die Gesamtmenge jeder Versorgungsklasse, die sich derzeit in der Verteilungspipeline befindet (im Transit, aber noch nicht bei einer Einheit). Die Pipeline-Befüllung bestimmt, wie viel Puffer zwischen der aktuellen Bestandsposition und einem Mangel besteht. Eine Pipeline-Befüllung von weniger als fünf Tagen für Klasse III(P) (verpacktes Petroleum) auf BSA-Ebene zeigt Risiko bei hochintensiven Operationen an, die Lieferzyklen überschreiten könnten.

Tages-Versorgungsmengen (DOS) vorhanden — die am weitesten verbreitete Nachschubmetrik, berechnet pro Einheit und pro Versorgungsklasse aus dem täglichen Einheits-Versorgungsstatusbericht. Das Nachschubkommando verlangt von jeder Einheit, eine Mindest-DOS-Schwelle aufrechtzuerhalten (typischerweise 3 DOS für Klasse I und III auf Kompagnieebene, 5 DOS auf Bataillonsebene) — Einheiten unterhalb der Schwelle erzeugen automatische Nachschubaktionen.

Der automatisierte Nachschubschätzbericht aggregiert diese Metriken mit Trendlinien und erstellt einen strukturierten täglichen Brief:

THEATER SUSTAINMENT ESTIMATE — 24 JUN 2026 / 0600L
─────────────────────────────────────────────────────
POD STATUS (SPOD ALPHA)
  Throughput (last 24h):  4,840 ST   [Plan: 5,200 ST  ▼ −7%]
  Staging area fill:       68% / 100% capacity
  Cargo dwell > 24h:       142 TCNs   ← ACTION REQUIRED
  Ships in port:           3 (USNS Gilliland, ARC Endurance, MV Resolve)
  Ships at anchor:         1 (ETA berth 25 JUN 0200L)

DISTRIBUTION PIPELINE
  Class I (Rations):      4.2 DOS average across BCTs   [Green]
  Class III(B) (Bulk):    5.1 DOS at TDB; 3.8 DOS BSB   [Amber]
  Class V (Ammo):         Pipeline fill 8.5K ST          [Green]
  Class IX (Parts):       SRT avg 38h   [Plan: 24h  ▼ +58%]

DISTRIBUTION ROUTES
  MSR IOWA:      OPEN (confirmed 0400L)
  ASR COLUMBIA:  RESTRICTED (bridge repair, MLC 50 max)
  ASR DECKER:    OPEN

UNITS AT RISK (< 3 DOS on any Class):
  2-7 CAV (Class III): 2.1 DOS — emergency resupply dispatched
─────────────────────────────────────────────────────

Der Ladungs-Verweilzeitalarm im obigen Beispiel — 142 TCNs im Bereitstellungsbereich seit mehr als 24 Stunden — wäre in einem manuellen System unsichtbar, bis eine physische Inventur die gestaute Ladung entdeckte. Im softwaregesteuerten POD-Betrieb erscheint der Alarm innerhalb von Minuten nach Überschreitung der Verweilzeitschwelle, was dem Hafen-OIC ermöglicht, den Engpass zu untersuchen und zu beseitigen, bevor er sich zu einem allgemeinen Bereitstellungsbereichsstau ausweitet.

Designprinzip: Theater-Nachschubsoftware sollte die Ausnahme sichtbar machen, nicht das Normale. Das J4-Personal sollte keine Zeit damit verbringen, Routineberichte zu lesen, um festzustellen, dass der Durchsatz im Plan liegt und die DOS ausreichend ist — das System sollte nur die Abweichungen vom Plan, die gefährdeten Einheiten und die spezifischen erforderlichen Maßnahmen präsentieren. Ein gut gestaltetes Nachschub-Dashboard ist größtenteils grün, mit gelben und roten Elementen, die sofortige Maßnahmen erfordern. Das Ziel ist die Verkürzung der Entscheidungszykluszeit auf Nachschubkommandoebene, nicht die Erstellung umfassender Berichte um ihrer selbst willen.