--- lang: de template: deployment-detail --- # Dispo ohne **Dispoabteilung** > Impact 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 % {#less-unplanned-demand} Ungeplante Nachfrageeinheiten ### -10,70 % {#lower-inventory-value} Durchschnittlicher Bestandswert bei stabilem Serviceziel ### -12,70 % {#lower-transport-cost} Transportkosten pro Palette ## Manuelle Disposition {#challenge} > Herausforderung 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. ## Ergebnisgeführter Dispositionslauf {#solution} > Lösung 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. ## Vom Auslöser zur dokumentierten Bestellung {#technical-depth} > Technische Tiefe 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 #### `cron/ops` Funktion: Tageslauf-Orchestrierung Tätigkeit: 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` Funktion: Fachlicher Herstellerlauf Tätigkeit: 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` Funktion: Datenphase Tätigkeit: 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` Funktion: Disposition / Planung Tätigkeit: 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` Funktion: Vier-Augen-Prüfung / Freigabe Tätigkeit: 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` Funktion: Recherche bei Erstbestellungen Tätigkeit: 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 #### ERP-/Bestellsystem Nutzung: Bestellanlage und PO-Prüfung Beschreibung: 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` Nutzung: Abschlussnachweis Beschreibung: Dokumentiert den technischen Abschluss des Herstellerfalls mit Referenz auf erzeugte Artefakte und Bestellnachweise. #### `Excel` Nutzung: Bestellartefakt Beschreibung: Wird als erzeugtes Abschlussartefakt für die Bestellung verwendet und im Nachweisprozess referenziert. #### `Browserless` Nutzung: Öffentliche Recherche Beschreibung: Unterstützt öffentliche Crawl- und Scrape-Läufe, wenn bei Erstbestellungen zusätzliche Hersteller- oder Produktinformationen benötigt werden. ### Artefakte im Deployment #### `Laufnotiz` Owner: `cron/ops` Bedeutung: Dokumentiert Tageslauf, fällige Hersteller, gestartete Subtasks, Ergebnisse und übersprungene Hersteller. #### `lauf.json` Owner: `dispo/ops` Bedeutung: Hält den Herstellerfall, Laufkontext und Abschlussstatus zusammen. #### `datenquellen.json` Owner: `dispo/demand` Bedeutung: Beschreibt geprüfte Datenquellen, Datenlinks und Quellartefakte für den Herstellerlauf. #### `disposition.json` Owner: `dispo/planner` Bedeutung: Enthält Dispositionsbewertung, Mengenlogik und vorbereitete Bestellentscheidung. #### `review.json` / `freigabe.json` Owner: `dispo/review` Bedeutung: Belegt Prüfung, Befund und Freigabe vor einer operativen Bestellung. #### `bestellung.json` Owner: `dispo/ops` Bedeutung: Dokumentiert die ausgelöste Bestellung und den zurückgeführten Bestellstatus. #### `Excel-Datei` Owner: `dispo/ops` Bedeutung: Dient als erzeugtes Bestellartefakt und wird im Abschlussnachweis referenziert. #### `crawl_recherche` Owner: `crawl/scrape` Bedeutung: Liefert öffentliche Hersteller- oder Produktinformationen bei Erstbestellungen. ### Der tägliche Dispositionslauf als geführter Wertstrom ```mermaid 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 ```mermaid 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.