Impact

Dispo-Standardlauf im Regelbetrieb

Das Deployment Dispo führt im Unternehmen den operativen Standardlauf der Disposition: Lagerbestände prüfen, Daten zusammenführen, fällige Hersteller erkennen, Bestellungen vorbereiten und freigegebene Bestellungen auslösen. Der täglich gestartete Lauf prüft jeden Hersteller separat und dokumentiert jeden Abschlussstatus nachweisbar. Damit wird der Dispositionsprozess im freigegebenen Standardpfad aus manueller Abarbeitung in eine geführte operative Fallführung überführt.

-14,50 %

Bestandswert

-18,30 %

Transportkosten pro Palette

99,78 %

First-Time-Right-Bestellungen

Herausforderung

Manuelle Disposition

Ein E-Commerce-Unternehmen in DACH mit ca. 200 aktiven Herstellern musste Bestände, Herstellerfälligkeiten und unregelmäßige Bestellbedarfe täglich überwachen, um das interne Serviceziel zuverlässig zu erreichen. Der Prozess umfasste tägliche Nachdisposition sowie einen mehrstufigen Bestell- und Freigabeprozess.

In der manuellen Disposition wurden Bestellungen dafür häufig korrigiert, vergrößert oder als kleine Einzelbestellungen ausgelöst. Das sicherte kurzfristig Verfügbarkeit, erhöhte aber gebundenes Kapital, Lieferkosten und Lageraufwand.

Die zentrale Frage war nicht nur, ob Bestellungen automatisiert werden können. Die eigentliche Herausforderung lag darin, einen täglichen Dispositionsstandardlauf zu schaffen, der Lieferfähigkeit sichert, Bestände wirtschaftlich steuert, fällige Hersteller rechtzeitig erkennt und Bestellentscheidungen kontrolliert ausführt - ohne dass der Prozess dauerhaft von manueller Überwachung und individueller Nachsteuerung abhängt.

Lösung

Ergebnisgeführter Dispositionslauf

In Q1 2026 baute das Unternehmen mit Jadeys Agentenschwarm eine ergebnisgeführte In-House-Lösung für den täglichen Dispositionsstandardlauf auf. Die Lösung wurde im Unternehmen betrieben und führte fällige Hersteller, Datenprüfung, Bestellentscheidung, Freigabe und Bestellung in einem kontrollierten Ablauf zusammen.

Über einen Messzeitraum von acht Wochen zeigte sich im Vergleich zur vorherigen manuellen Disposition eine deutliche wirtschaftliche Verbesserung. Die Auswertung basiert auf 897 durchgeführten Bestelldurchgängen bei ca. 200 aktiven Herstellern. Das interne Serviceziel blieb dabei stabil.

First-Time-Right bedeutet in diesem Deployment: Ein Bestelldurchgang wurde nach Freigabe und PO-Anlage ohne nachträgliche manuelle Korrektur abgeschlossen. 895 von 897 Bestelldurchgängen erfüllten diese Definition.

Hinweis: Unternehmensname, absolute Bestellwerte und ERP-Details sind aus Vertraulichkeitsgründen anonymisiert. Prozessstruktur, Messlogik und Artefaktkette entsprechen dem eingesetzten Deployment.

KPIVor JadeyNach JadeyWirkungAussage
Durchschnittlicher BestandswertIndex 100,00Index 85,50-14,50 %Weniger Kapitalbindung im Bestand
Transportkosten pro PaletteIndex 100,00Index 81,70-18,30 %Effizientere Transporte durch bessere Bündelung
Ungeplante Einzelbestellungen9218-80,50 %Deutlich weniger reaktive Nachsteuerung
Gebündeltes Bestellvolumen65,00 %80,54 %+23,90 %Mehr Volumen läuft durch planbare Sammelbestellungen

Die stärkste operative Veränderung liegt in den ungeplanten Einzelbestellungen. Sie sinken von 92 auf 18. Das zeigt, dass der Prozess nach Einführung von Jadey deutlich weniger reaktiv arbeitet. Bedarfe werden früher erkannt, Herstellerläufe konsequenter geführt und Bestellungen seltener außerhalb des Standards nachgesteuert.

Gleichzeitig steigt das gebündelte Bestellvolumen von 65,00 % auf 80,54 %. Das erklärt die sinkenden Transportkosten pro Palette: mehr Volumen wird planbar zusammengeführt, statt kleinteilig und kurzfristig bewegt zu werden.

Der niedrigere durchschnittliche Bestandswert zeigt zusätzlich, dass die bessere Planung nicht durch mehr Sicherheitsbestand erkauft wurde. Der Prozess wird wirtschaftlicher, ohne bloß mehr Ware vorzuhalten.

Im definierten Standardlauf wurde die bisherige manuelle Disposition nicht mehr als laufende Bearbeitungseinheit benötigt. Jadey übernahm die tägliche Fallführung über Hersteller, Datenprüfung, Freigabe und Bestellung hinweg. Menschliche Eingriffe blieben auf klar abgegrenzte Ausnahme- und Pflegeaufgaben begrenzt, etwa die Anlage neuer Hersteller oder die Ergänzung fehlender Informationen.

Technische Tiefe

Vom Auslöser zur dokumentierten Bestellung

Die technische Architektur des Deployments basiert auf einer bewussten Trennung von Orchestrierung, fachlicher Fallführung, Datenprüfung, Planung, Review, Bestellung und Nachweis. Dadurch führt Jadey den Dispositionsstandardlauf nicht als unkontrollierte End-to-End-Automation, sondern als begrenzten, prüfbaren und dokumentierten Betriebsprozess. Die folgende Übersicht zeigt die beteiligten Agenten, Systeme und Abläufe in ihrer tatsächlichen Tiefe im eingesetzten Unternehmen.

Agenten und Rollen im Deployment

Am täglichen Herstellerlauf sind drei Agentenbereiche beteiligt. cron startet den Tageslauf, erkennt fällige Hersteller und übergibt jeden Hersteller als eigenen Fall an dispo. dispo übernimmt in der Rolle ops die Fallführung: Der Agent hält den Herstellerfall zusammen, steuert die Datenphase, Disposition, Prüfung, Freigabe und Bestellung und beauftragt dafür weitere spezialisierte dispo-Rollen wie demand, planner und review.

Bei Bedarf wird zusätzlich crawl eingebunden. crawl recherchiert öffentliche Hersteller- oder Produktinformationen, bereitet diese strukturiert auf und gibt sie als Datenartefakt in den Herstellerfall zurück. So bleibt der Tageslauf klar geführt: cron orchestriert den Start, dispo/ops trägt die Ergebnisverantwortung pro Herstellerfall und crawl ergänzt externe Daten, wenn die interne Datenlage nicht ausreicht.

Agent/RolleFunktion im DeploymentTätigkeit
cron/opsTageslauf-Orchestrierung
Startet den Tageslauf und sequenziert Herstellerläufe.

cron/ops verantwortet den technischen Tageslauf. Der Agent startet den Dispositionslauf werktags um 09:00 Uhr, prüft fällige Hersteller und sequenziert die einzelnen Herstellerläufe.

Pro Hersteller startet cron/ops einen wartenden Subtask an dispo/ops und wartet auf Ergebnis, Fehler, Timeout, Blocker oder Befund. Erst danach wird der nächste Herstellerlauf gestartet. Der Tageslauf, gestartete Subtasks, Ergebnisse und übersprungene Hersteller werden dokumentiert.

Begrenzung: cron/ops trifft keine fachlichen Bestellentscheidungen und darf keine Bestellung auslösen. Der Agent steuert den Tageslauf, aber nicht die Disposition selbst.

dispo/opsFachlicher Herstellerlauf
Führt den Herstellerfall von Datenprüfung bis Abschluss.

dispo/ops ist der führende fachliche Agent pro Hersteller. Er hält den Herstellerfall über Datenphase, Disposition, Review, Freigabe, Bestellung und Abschluss hinweg zusammen.

Dafür ruft dispo/ops spezialisierte Rollen wie dispo/demand, dispo/planner und dispo/review auf, führt deren Ergebnisse zusammen und steuert den Fall bis zum Abschlussstatus. Nach Freigabe kann dispo/ops die Bestellung über das ERP-/Bestellsystem auslösen und die Abschlussartefakte erzeugen.

Begrenzung: dispo/ops ersetzt nicht die einzelnen Fachrollen. Der Agent führt den Herstellerfall, bleibt aber auf Datenlage, Planung, Review und Freigabe angewiesen.

dispo/demandDatenphase
Liefert die geprüfte Datenbasis für den Herstellerlauf.

dispo/demand liefert die geprüfte Datenbasis für den Herstellerlauf. Der Agent sammelt relevante Datenquellen, erzeugt Quellartefakte, erstellt datenquellen.json und stellt die erforderlichen Datenlinks bereit.

Die geprüfte Datenlage wird an dispo/ops zurückgegeben und bildet die Grundlage für die weitere Disposition. Bei Erstbestellungen kann dispo/demand zusätzliche öffentliche Recherche über crawl/scrape einbinden.

Begrenzung: dispo/demand liefert Daten und Nachweise, trifft aber keine Bestellentscheidung und darf keine Bestellung auslösen.

dispo/plannerDisposition / Planung
Erstellt Dispositionsbewertung und Bestelllogik.

dispo/planner erstellt auf Basis von datenquellen.json die fachliche Dispositionsbewertung. Der Agent bewertet Mengen, Bestellbedarf, relevante Kommentarpositionen und erzeugt daraus disposition.json.

Das Ergebnis kann eine konkrete Bestellentscheidung vorbereiten, etwa bestellen_heute. Damit liefert dispo/planner die fachliche Grundlage für Review und Freigabe.

Begrenzung: dispo/planner kann eine Bestellentscheidung vorbereiten, aber nicht operativ bestellen. Die Ausführung bleibt an Review, Freigabe und Systemaktion gebunden.

dispo/reviewVier-Augen-Prüfung / Freigabe
Prüft die Dispositionsentscheidung vor Ausführung.

dispo/review prüft die Dispositionsentscheidung vor der operativen Ausführung. Der Agent kontrolliert Datenlinks, Dispositionsartefakt und fachliche Plausibilität.

Bei positivem Ergebnis erzeugt dispo/review review.json und freigabe.json. Bei Problemen gibt der Agent Befund, Rückfrage oder Ablehnung zurück.

Begrenzung: Ohne explizite Freigabe durch dispo/review darf keine Bestellung ausgelöst werden. Der Review-Agent prüft und gibt frei, bestellt aber nicht selbst.

crawl/scrapeRecherche bei Erstbestellungen
Recherchiert öffentliche Hersteller- und Produktdaten.

crawl/scrape wird nur bei Bedarf eingebunden, insbesondere wenn für Erstbestellungen zusätzliche öffentliche Hersteller- oder Produktinformationen benötigt werden.

Der Agent recherchiert öffentliche Quellen, extrahiert strukturierte Hersteller-, Produkt- und Quelleninformationen, dedupliziert Ergebnisse und stellt ein JSON- oder CSV-Artefakt bereit. Der Rückgabestatus enthält unter anderem Quellenabdeckung, Row-Count und Artefaktpfad.

Begrenzung: crawl/scrape ist kein generischer Recherche-Agent für beliebige Datenbeschaffung. Der Agent wird nur innerhalb der Datenphase genutzt und arbeitet auf öffentlichen, regelkonform nutzbaren Quellen.

Service-Hierarchy

flowchart TB
  cron_ops[cron/ops]
  dispo_ops[dispo/ops]
  demand[dispo/demand]
  planner[dispo/planner]
  review[dispo/review]
  crawl_scrape[crawl/scrape]
  erp[(ERP-/Bestellsystem)]
  github[(GitHub)]
  excel[(Excel)]
  browserless[(Browserless)]

  cron_ops --> dispo_ops
  dispo_ops --> demand
  dispo_ops --> planner
  dispo_ops --> review
  dispo_ops --> erp
  dispo_ops --> github
  dispo_ops --> excel
  demand --> crawl_scrape
  crawl_scrape --> browserless

Systeme im Deployment

Jadey schließt sich im Deployment an die bestehende Systemlandschaft des Unternehmens an. Interne Quellen liefern Herstellerdaten, das ERP- bzw. Bestellsystem führt freigegebene Bestellungen aus, Excel stellt operative Abschlussnachweise bereit, GitHub dokumentiert technische Ergebnisse und Browserless unterstützt bei Bedarf öffentliche Recherche.

SystemNutzung im DeploymentBeschreibung
ERP-/BestellsystemBestellanlage und PO-PrüfungAngebundenes Unternehmenssystem für operative Bestellungen. Erst nach geprüfter Datenlage, Dispositionsbewertung und Freigabe wird die Bestellung dort angelegt und der PO-Status geprüft.
GitHubAbschlussnachweisWird nicht als operatives Führungssystem genutzt, sondern als technische Referenz- und Run-Dokumentation für erzeugte Artefakte, Statusmeldungen und Abschlussnachweise.
ExcelBestellartefaktEntspricht dem bestehenden Abschlussformat des Unternehmens und wird bewusst als erzeugtes Bestellartefakt in die vorhandene Arbeitsweise integriert.
BrowserlessÖffentliche RechercheUnterstützt öffentliche Crawl- und Scrape-Läufe, wenn bei Erstbestellungen zusätzliche Hersteller- oder Produktinformationen benötigt werden.

Artefakte im Deployment

Die Artefakte im Deployment bilden die Nachweiskette des Herstellerlaufs. Jeder relevante Schritt erzeugt einen prüfbaren Nachweis: Datenbasis, Dispositionsbewertung, Review, Freigabe, Bestellung und Abschluss. Damit wird der Agentenlauf nicht zur Blackbox, sondern zu einem auditierbaren Betriebsprozess.

Für Enterprise-Umgebungen ist diese Artefaktkette zentral. Sie macht sichtbar, welche Daten verwendet wurden, welche Rolle welchen Schritt verantwortet hat, wann eine Entscheidung freigegeben wurde und wie das Ergebnis in der Systemlandschaft dokumentiert wurde. Jadey übernimmt damit nicht nur operative Arbeit, sondern erzeugt gleichzeitig die Nachweise, die für Kontrolle, Governance und kontinuierliche Verbesserung benötigt werden.

ArtefaktOwnerBedeutung
Laufnotizcron/opsDokumentiert Tageslauf, fällige Hersteller, gestartete Subtasks, Ergebnisse und übersprungene Hersteller.
lauf.jsondispo/opsHält den Herstellerfall, Laufkontext und Abschlussstatus zusammen.
datenquellen.jsondispo/demandBeschreibt geprüfte Datenquellen, Datenlinks und Quellartefakte für den Herstellerlauf.
disposition.jsondispo/plannerEnthält Dispositionsbewertung, Mengenlogik und vorbereitete Bestellentscheidung.
review.jsondispo/reviewBelegt Prüfung, Befund und Freigabe vor einer operativen Bestellung.
bestellung.jsondispo/opsDokumentiert die ausgelöste Bestellung und den zurückgeführten Bestellstatus.
Excel-Dateidispo/opsDient als erzeugtes Bestellartefakt im bestehenden Abschlussformat des Unternehmens und wird im Abschlussnachweis referenziert.
crawl_recherchecrawl/scrapeLiefert öffentliche Hersteller- oder Produktinformationen bei Erstbestellungen.

Vom Tagesstart bis zum Bestellnachweis

Der tägliche Dispositionslauf verbindet Tagesstart, Herstellerprüfung, Datenphase, Dispositionsbewertung, Review, Freigabe, Bestellung und Abschlussnachweis zu einem geführten Betriebsprozess. cron startet den Lauf und übergibt fällige Hersteller als einzelne Fälle. dispo/ops hält jeden Herstellerfall zusammen und führt ihn über spezialisierte Rollen, Systeme und Artefakte bis zum Ergebnis.

Der Standardpfad endet bei einer dokumentierten Bestellung oder einem nachvollziehbaren Abschluss. Nebenpfade greifen nur bei definierten Bedingungen: wenn öffentliche Herstellerinformationen recherchiert werden müssen, technische Crawl-Störungen auftreten oder Stammdaten und Vendor-Zuordnungen nicht ausreichend geklärt sind. Dadurch bleibt der Lauf steuerbar, auch wenn einzelne Fälle blockieren oder zusätzliche Klärung benötigen.

flowchart TB
  subgraph human["Human-Service<br/>Klaerung"]
    h1[Stammdaten oder Vendor klaeren]
    h2[Rueckgabe offen]
    h1 --> h2
  end

  subgraph crawl_ops["crawl/ops<br/>bedingtes Troubleshooting"]
    co1[Proxy Consent<br/>Challenge Timing pruefen]
    co2[Fix Issue oder HiTL zurueckgeben]
    co1 --> co2
  end

  subgraph crawl_lane["crawl/scrape<br/>Auftrag bei Erstbestellung"]
    cr1[crawl_recherche starten]
    cr2[Oeffentliche Quellen crawlen]
    cr3[Artefakt und Review liefern]
    cr1 --> cr2 --> cr3
  end

  subgraph cron_ops["cron/ops<br/>Auftrag Tageslauf"]
    c1[cron/ops trigger]
    c2[Bestelltag prüfung]
    c3[Herstellerliste sequenzieren]
    c4[dispo/ops Subauftrag starten]
    c5[Auf Ergebnis warten]
    c6[Run dokumentieren]
    c1 --> c2 --> c3 --> c4 --> c5 --> c6
  end

  subgraph dispo_ops["dispo/ops<br/>Auftrag Herstellerlauf"]
    d1[Herstellerlauf starten]
    d2[demand Subauftrag]
    d3[Auf Daten warten]
    d4[planner Subauftrag]
    d6[review Subauftrag]
    d7[Auf Freigabe warten]
    d8[PO Excel GitHub abschliessen]
    d1 --> d2 --> d3 --> d4 --> d6 --> d7 --> d8
  end

  c4 --> d1
  d8 --> c5
  d2 -. Erstbestellung .-> cr1
  cr3 -. crawl_recherche .-> d3
  cr2 -. Stoerung .-> co1
  co2 -. Rueckgabe .-> cr2
  %% Layout-Hilfe: haelt crawl/ops oberhalb der Crawl-Lane, damit Cluster nicht kollidieren.
  co2 ~~~ cr1
  d7 -. bei Klaerbedarf .-> h1
  h2 -. Rueckgabe .-> d7

Implementierung

Dieses Deployment kann zur Blaupause für Ihr Unternehmen werden

Das Dispo-Deployment zeigt, wie Jadey einen geschäftskritischen Ablauf im operativen Betrieb führt: von der Datenprüfung über die Bedarfsbewertung bis zur Freigabe, Bestellung und Nachvollziehbarkeit des Ergebnisses.

Was hier für die Disposition umgesetzt wurde, lässt sich auf vergleichbare Abläufe in Ihrem Unternehmen übertragen: mit bestehender Systemlandschaft, Ihren Freigabewegen und den Regeln, die Ihren Betrieb steuern.

In einem ersten Gespräch ordnen wir ein, ob dieses Deployment als Ausgangspunkt für Ihr Unternehmen geeignet ist und wo Jadey kurzfristig operative Wirkung erzeugen kann.