Impact

Dispo ohne Dispoabteilung

Das Deployment Dispo übernimmt im Unternehmen den operativen Standardlauf einer Dispositionsabteilung: 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 weitgehend aus manueller Abarbeitung in eine geführte operative Fallführung überführt.

-30,70 %

Ungeplante Nachfrageeinheiten

-10,70 %

Durchschnittlicher Bestandswert bei stabilem Serviceziel

-12,70 %

Transportkosten pro Palette

Herausforderung

Manuelle Disposition

Ein E-Commerce-Unternehmen mit rund 200 beliefernden Herstellern musste Bestände, Herstellerfälligkeiten und unregelmäßige Bestellbedarfe täglich überwachen, um das interne Serviceziel zuverlässig zu erreichen.

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 zwei Monaten zeigte sich im Vergleich zur vorherigen manuellen Disposition eine wirtschaftliche Verbesserung: Lagerbestände konnten bei gleichbleibendem Serviceziel reduziert, Bestellungen besser gebündelt und Transportkosten pro Bestellung gesenkt werden.

-30,70 % ungeplante Nachfrageeinheiten
-10,70 % durchschnittlicher Bestandswert bei stabilem Serviceziel
-12,70 % Transportkosten pro Palette

Im definierten Standardlauf wurde die bisherige Dispositionsabteilung nicht mehr als operative 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

Agent / Rolle	Funktion im Deployment	Tätigkeit
`cron/ops`	Tageslauf-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/ops`	Fachlicher 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/demand`	Datenphase	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/planner`	Disposition / 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/review`	Vier-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/scrape`	Recherche 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.

Systeme im Deployment

System	Nutzung im Deployment	Website-taugliche Beschreibung
ERP-/Bestellsystem	Bestellanlage und PO-Prüfung	Angebundenes Unternehmenssystem für operative Bestellungen. Erst nach geprüfter Datenlage, Dispositionsbewertung und Freigabe wird die Bestellung dort angelegt und der PO-Status geprüft.
`GitHub`	Abschlussnachweis	Dokumentiert den technischen Abschluss des Herstellerfalls mit Referenz auf erzeugte Artefakte und Bestellnachweise.
`Excel`	Bestellartefakt	Wird als erzeugtes Abschlussartefakt für die Bestellung verwendet und im Nachweisprozess referenziert.
`Browserless`	Öffentliche Recherche	Unterstützt öffentliche Crawl- und Scrape-Läufe, wenn bei Erstbestellungen zusätzliche Hersteller- oder Produktinformationen benötigt werden.

Artefakte im Deployment

Artefakt	Owner	Bedeutung
`Laufnotiz`	`cron/ops`	Dokumentiert Tageslauf, fällige Hersteller, gestartete Subtasks, Ergebnisse und übersprungene Hersteller.
`lauf.json`	`dispo/ops`	Hält den Herstellerfall, Laufkontext und Abschlussstatus zusammen.
`datenquellen.json`	`dispo/demand`	Beschreibt geprüfte Datenquellen, Datenlinks und Quellartefakte für den Herstellerlauf.
`disposition.json`	`dispo/planner`	Enthält Dispositionsbewertung, Mengenlogik und vorbereitete Bestellentscheidung.
`review.json` / `freigabe.json`	`dispo/review`	Belegt Prüfung, Befund und Freigabe vor einer operativen Bestellung.
`bestellung.json`	`dispo/ops`	Dokumentiert die ausgelöste Bestellung und den zurückgeführten Bestellstatus.
`Excel-Datei`	`dispo/ops`	Dient als erzeugtes Bestellartefakt und wird im Abschlussnachweis referenziert.
`crawl_recherche`	`crawl/scrape`	Liefert öffentliche Hersteller- oder Produktinformationen bei Erstbestellungen.

Der tägliche Dispositionslauf als geführter Wertstrom

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

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

  subgraph crawl_lane["crawl/scrape 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 Auftrag Tageslauf"]
    c1[Job faellig]
    c2[Precondition Bestelltag passt]
    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 Auftrag Herstellerlauf"]
    d1[Herstellerlauf starten]
    d2[demand Subauftrag]
    d3[Auf Daten warten]
    d4[planner Subauftrag]
    d5[Auf Disposition warten]
    d6[review Subauftrag]
    d7[Auf Freigabe warten]
    d8[PO Excel GitHub abschliessen]
    d1 --> d2 --> d3 --> d4 --> d5 --> d6 --> d7 --> d8
  end

  c4 --> d1
  d8 --> c5
  d2 -. Erstbestellung .-> cr1
  cr3 -. crawl_recherche .-> d3
  cr2 -. Stoerung .-> co1
  co2 -. Rueckgabe .-> cr2
  d7 -. bei Klaerbedarf .-> h1
  h2 -. Rueckgabe .-> d7

Service-Hierarchy

flowchart TB
  deployment[[Dispo Stufe 2 Bestelltag]]
  cron_ops[cron/ops Owner Tageslauf]
  dispo_ops[dispo/ops Owner Herstellerlauf]
  demand[dispo/demand Owner Datenphase]
  planner[dispo/planner Owner Disposition]
  review[dispo/review Owner Freigabe]
  cvi[(ERP-/Bestellsystem)]
  github[(GitHub)]
  crawl_scrape[crawl/scrape Owner crawl_recherche]
  crawl_ops[crawl/ops Troubleshooting]
  crawl_maintain[crawl/maintain CLI Runbook Config]
  human[Human-Service Stammdatenklaerung]

  deployment --> cron_ops
  cron_ops --> dispo_ops
  dispo_ops --> demand
  dispo_ops --> planner
  dispo_ops --> review
  dispo_ops --> cvi
  dispo_ops --> github
  demand --> crawl_scrape
  crawl_scrape -. Stoerung .-> crawl_ops
  crawl_scrape -. wiederkehrende Automatisierung .-> crawl_maintain
  crawl_ops -. Feature Wunsch .-> crawl_maintain
  dispo_ops -. unklarer Owner .-> human

Der Lauf bleibt nur deshalb steuerbar, weil Gesamtverantwortung und Subaufträge getrennt bleiben. cron/ops entscheidet nicht fachlich und bestellt nicht. dispo/ops hält den Herstellerlauf zusammen, bestellt aber erst nach Datenlage, Disposition, Review und Freigabe. Subservices liefern Nachweise zurück, statt die Gesamtverantwortung im Staffellauf weiterzureichen.

Die ausgewiesenen Effekte beziehen sich auf den definierten Prozessumfang im produktiven Regelbetrieb. Sonderfälle, Ausnahmen und notwendige Freigaben werden nicht verdeckt automatisiert, sondern separat geprüft, gesteuert und nachvollziehbar gemacht.

Das Deployment-Muster passt dort, wo Lieferantenversorgung nicht nur aus einzelnen Bestellaktionen besteht, sondern aus wiederkehrenden Bedarfen, Bestands- und Zulaufsignalen, Priorisierung, Prüfung und betriebswirksamem Abschluss geführt werden muss. Nicht gemeint ist ein isolierter Einkaufsklick ohne laufende Versorgungssteuerung.

Jadey zeigt hier keine allgemeine Einkaufsautomation und keine pauschale Lieferantengarantie. Gezeigt wird der beschriebene Wertstrom vom Beschaffungsbedarf bis zur belastbar ausgeführten Bestellung, mit sichtbarer Priorisierung, Prüfung, Rückführung und betrieblichem Abschluss.