KI-Bestandsverwaltungsagenten mit OpenClaw

Der Lagerbestand steht an der Schnittstelle aller wichtigen Geschäftsfunktionen: Finanzen (im Lagerbestand gebundenes Betriebskapital), Betrieb (Abwicklungsgeschwindigkeit und -genauigkeit), Vertrieb (Verkaufsverfügbarkeit) und Beschaffung (Lieferantenbeziehungen und Durchlaufzeiten). Wenn Sie es in eine Richtung falsch verwalten, kommt es zu Fehlbeständen, die zu Umsatzeinbußen führen und die Kundenbeziehungen schädigen. Wenn Sie es im anderen Fall schlecht verwalten, haben Sie überschüssige Lagerbestände, die Bargeld binden, Lagerraum beanspruchen und möglicherweise ablaufen oder veraltet sind, bevor sie verkauft werden.

Die herkömmliche Bestandsverwaltung basiert auf statischen Parametern: festen Nachbestellpunkten, festen Sicherheitsbeständen und manuellen Überprüfungszyklen. Diese Parameter werden einmal festgelegt und selten erneut überprüft – bis ein Fehlbestand oder ein Überbestand die Aufmerksamkeit auf sich zieht. OpenClaw-KI-Agenten ersetzen statische Parameter durch dynamische, sich kontinuierlich anpassende Bestandsinformationen, die in Echtzeit auf sich ändernde Nachfragemuster, Änderungen der Lieferantenzuverlässigkeit und Marktsignale reagieren.

Wichtige Erkenntnisse

• OpenClaw Demand Forecasting Agents nutzen Zeitreihenmodelle für Ihre Verkaufshistorie, angereichert mit externen Signalen (Saisonalität, Werbeaktionen, Markttrends) für eine höhere Genauigkeit.
• Die Parameter für den Bestellpunkt und den Sicherheitsbestand werden automatisch neu berechnet, wenn sich die Nachfragemuster ändern – keine manuellen Parameteraktualisierungen mehr.
• Der Lieferantenkoordinationsagent automatisiert die RFQ-Verteilung, die Bestellungserstellung, die Lieferverfolgung und die Koordinierung der Qualitätsprüfung. – Der Bestandsausgleich an mehreren Standorten identifiziert sich langsam bewegende Bestände an einem Standort, die vor der Nachbestellung an Standorte mit höherer Nachfrage übertragen werden können.
• Das Ablauf- und Obsoleszenzmanagement identifiziert proaktiv gefährdete Bestände und löst Abschlags- oder Umverteilungsmaßnahmen aus.
• Die Agenten lassen sich über die OpenClaw-Toolschicht in Odoo, SAP, NetSuite, Fishbowl und benutzerdefinierte ERP/WMS-Systeme integrieren.
• Jede Agentenentscheidung umfasst ihre Argumentationskette – Parameter, Signale und Berechnungen sind vollständig transparent und überprüfbar.
• ECOSIRE entwickelt OpenClaw-Bestandsverwaltungssysteme für Hersteller, Händler und Einzelhändler mit mehreren Standorten.

---

Architektur der Bestandsverwaltung

Der OpenClaw-Inventarstapel verfügt über fünf spezialisierte Agenten:

[ Sales History + External Data ]
              ↓
[ Demand Forecasting Agent ]   — forecast per SKU per location per week
              ↓
[ Parameter Optimization Agent ] — calculate optimal reorder points and safety stock
              ↓
[ Replenishment Agent ]        — trigger POs, transfers, or production orders
              ↓
[ Supplier Coordination Agent ] — RFQ, PO, delivery tracking, receipt coordination
              ↓
[ Exception Agent ]            — stockout risk alerts, overstock alerts, expiry alerts

Alle Agenten teilen sich einen Echtzeit-Bestandsdatenspeicher, der über einen Webhook Aktualisierungen vom ERP/WMS erhält. Agentenentscheidungen werden als Empfehlungen (von Menschen überprüft) oder Aktionen (autonom ausgeführt, abhängig von Ihrer Richtlinienkonfiguration) an das ERP zurückgeschrieben.

---

Demand Forecasting Agent: Vorhersagen, was Sie benötigen

Eine genaue Bedarfsprognose ist die Grundlage für alles andere in der Bestandsverwaltung. Eine um 30 % falsche Prognose führt zu um 30 % falschen Nachbestellpunkten, um 30 % falschen Sicherheitsbestand und zu Bestellungen mit falschen Mengen.

Der Prognoseagent von OpenClaw verwendet eine Hierarchie von Modellen. Das für jede SKU gewählte Modell hängt von der Länge und Stabilität der Nachfragehistorie ab:

Exponentielle Glättung (ETS): Für SKUs mit einer Historie von mindestens 12 Monaten und relativ stabiler Nachfrage. Das Modell erfasst Niveau-, Trend- und Saisonalitätskomponenten.

SARIMA: Für SKUs mit starken saisonalen Mustern und ausreichender Historie (2+ Jahre). Bewältigt komplexe saisonale Zyklen besser als ETS.

Machine Learning (Gradient Boosting): Für SKUs, die von externen Signalen (Werbeaktionen, Wetter, Wirtschaftsindikatoren) beeinflusst werden. Übernimmt Feature-Eingaben, die über die Zeitreihe selbst hinausgehen.

Gleitender Durchschnitt: Für neue SKUs mit einer Historie von weniger als 3 Monaten. Einfache Basislinie mit geringer Vorspannung, bis genügend Verlauf für anspruchsvollere Modelle vorhanden ist.

export const ForecastDemand = defineSkill({
  name: "forecast-demand",
  tools: ["erp", "analytics", "external-data"],
  async run({ input, tools }) {
    const salesHistory = await tools.erp.getSalesHistory({
      productId: input.productId,
      locationId: input.locationId,
      weeks: 104, // 2 years of weekly data
    });

    const externalSignals = await tools.externalData.getSignals({
      productCategory: input.category,
      signals: ["seasonality-index", "market-trend", "promotion-calendar"],
    });

    // Model selection
    const model = selectForecastModel(salesHistory.length, externalSignals.hasPromoCalendar);

    const forecast = await analytics.forecast({
      model,
      history: salesHistory,
      signals: externalSignals,
      horizonWeeks: 13,
      confidenceIntervals: [0.80, 0.95],
    });

    return {
      productId: input.productId,
      locationId: input.locationId,
      forecastWeeks: forecast.weeks,
      // Returns point estimate + confidence intervals per week
    };
  },
});

Überwachung von Prognosefehlern: Der Agent verfolgt wöchentlich den tatsächlichen Wert im Vergleich zur Prognose für jede SKU und berechnet den MAPE (mittlerer absoluter prozentualer Fehler). SKUs, bei denen das Modell dauerhaft eine unterdurchschnittliche Leistung erbringt (MAPE > 25 %), werden zur manuellen Überprüfung oder zur Neuschulung des Modells mit aktualisierten Funktionen markiert.

---

Parameteroptimierungsagent: Dynamischer Sicherheitsbestand und Nachbestellpunkte

Mit genauen Prognosen berechnet der Parameter Optimization Agent den statistisch optimalen Sicherheitsbestand und Nachbestellpunkt für jede SKU an jedem Standort.

Formel für den Sicherheitsbestand: Der Agent verwendet die Formel für den statistischen Sicherheitsbestand, die auf Ihren angestrebten Servicelevel abgestimmt ist:

Safety Stock = z × σ_LT × √(L + R)

Wo:

• z = Z-Score für Ziel-Service-Level (z. B. 1,65 für 95 %, 2,33 für 99 %)
• σ_LT = Standardabweichung der Nachfrage während der Durchlaufzeit
• L = Lieferantenvorlaufzeit in Wochen
• R = Überprüfungszeitraum in Wochen

Das Service-Level-Ziel ist pro Produktkategorie konfigurierbar. Langsam verkaufte Produkte mit geringer Marge könnten 90 % ausmachen; Bei schnelllebigen, margenstarken Produkten oder Artikeln mit langen Vorlaufzeiten könnten 99 % der Kosten anfallen.

export const OptimizeParameters = defineSkill({
  name: "optimize-inventory-parameters",
  tools: ["erp", "analytics"],
  async run({ input, tools }) {
    const [forecast, supplierData, currentParams] = await Promise.all([
      tools.analytics.getForecast({ productId: input.productId, locationId: input.locationId }),
      tools.erp.getSupplierLeadTime(input.productId),
      tools.erp.getCurrentInventoryParams(input.productId, input.locationId),
    ]);

    const serviceLevel = getServiceLevelTarget(input.productCategory);
    const z = getZScore(serviceLevel);

    // Calculate demand variability during lead time
    const demandDuringLeadTime = forecast.weeks.slice(0, supplierData.leadTimeWeeks);
    const meanDemand = mean(demandDuringLeadTime.map(w => w.pointEstimate));
    const stdDevDemand = stdDev(demandDuringLeadTime.map(w => w.pointEstimate));

    const safetyStock = Math.ceil(z * stdDevDemand * Math.sqrt(supplierData.leadTimeWeeks + 1));
    const avgWeeklyDemand = mean(forecast.weeks.map(w => w.pointEstimate));
    const reorderPoint = Math.ceil(avgWeeklyDemand * supplierData.leadTimeWeeks + safetyStock);
    const economicOrderQty = calculateEOQ(avgWeeklyDemand, input.orderingCost, input.holdingCostRate, input.unitCost);

    const recommendation = {
      safetyStock,
      reorderPoint,
      economicOrderQty,
      currentSafetyStock: currentParams.safetyStock,
      currentReorderPoint: currentParams.reorderPoint,
      changeSignificant: Math.abs(reorderPoint - currentParams.reorderPoint) / currentParams.reorderPoint > 0.15,
    };

    if (recommendation.changeSignificant) {
      // Significant change — flag for human review before applying
      await flagForReview(recommendation, input);
    } else {
      // Minor adjustment — apply automatically
      await tools.erp.updateInventoryParams(input.productId, input.locationId, { safetyStock, reorderPoint });
    }

    return recommendation;
  },
});

Parameteränderungsrichtlinie: Große Parameteränderungen (mehr als 15 % Anpassung an den Nachbestellpunkt oder Sicherheitsbestand) werden zur menschlichen Überprüfung gekennzeichnet und nicht automatisch angewendet. Kleinere Anpassungen werden ohne Unterbrechung vorgenommen. Dadurch wird verhindert, dass das System dramatische Änderungen aufgrund kurzfristiger Nachfragespitzen vornimmt, die das Prognosemodell noch nicht filtern kann.

---

Replenishment Agent: Die richtige Aktion zur richtigen Zeit auslösen

Wenn der Lagerbestand auf oder unter den Nachbestellpunkt fällt, bestimmt der Nachschubagent die entsprechende Aktion – es handelt sich nicht immer um eine Bestellung.

Entscheidungsbaum für Nachschub:

1. Sind Lagerbestände an einem anderen eigenen Standort verfügbar? Wenn ja und die Transferkosten niedriger sind als die Bestellkosten, veranlassen Sie einen Transfer zwischen Standorten.
2. Gibt es eine bestehende offene Bestellung für dieses Produkt? Wenn ja und der erwartete Beleg den Bedarf deckt, aktualisieren Sie bei Bedarf die Bestellmenge, anstatt ein Duplikat zu erstellen.
3. Ist eine Bestellung angemessen? Erstellen Sie eine Bestellung mit der wirtschaftlichen Bestellmenge, angepasst an etwaige Mindestbestellanforderungen.
4. Handelt es sich um ein auf Lager gefertigtes Produkt? Erstellen Sie einen Produktionsauftrag statt einer Bestellung.

export const TriggerReplenishment = defineSkill({
  name: "trigger-replenishment",
  tools: ["erp", "warehouse"],
  async run({ input, tools }) {
    const neededQty = input.reorderPoint + input.economicOrderQty - input.currentStock;

    // Check inter-location transfers
    const otherLocations = await tools.erp.getStockByLocation(input.productId, {
      excludeLocation: input.locationId,
      minAvailable: neededQty,
    });

    if (otherLocations.length > 0) {
      const source = otherLocations.sort((a, b) => b.available - a.available)[0];
      const transferCost = await estimateTransferCost(source.locationId, input.locationId, neededQty);
      const orderCost = await estimateOrderCost(input.productId, neededQty);

      if (transferCost < orderCost * 0.7) {
        await tools.erp.createInternalTransfer({
          productId: input.productId,
          fromLocationId: source.locationId,
          toLocationId: input.locationId,
          qty: neededQty,
        });
        return { action: "TRANSFER_CREATED", sourceLocation: source.locationId };
      }
    }

    // Create purchase order
    const bestVendor = await selectBestVendor(tools.erp, input.productId, neededQty);
    const po = await tools.erp.createPurchaseOrder({
      productId: input.productId,
      vendorId: bestVendor.id,
      qty: Math.max(neededQty, bestVendor.minimumOrderQty),
      price: bestVendor.price,
      expectedDelivery: addDays(new Date(), bestVendor.leadTimeDays),
    });

    return { action: "PO_CREATED", poId: po.id, qty: neededQty, vendor: bestVendor.name };
  },
});

---

Bestandsausgleich an mehreren Standorten

Bei Unternehmen mit mehreren Lagern oder Einzelhandelsstandorten kommt es häufig zu Bestandsungleichgewichten: An Standort A verstauben 200 Einheiten von Produkt X, während Standort B nicht vorrätig ist und eine Bestellung aufgibt. Der Ausgleichsagent identifiziert diese Möglichkeiten wöchentlich.

Der Ausgleichsalgorithmus:

1. Berechnen Sie die prognostizierte Lieferwoche an jedem Standort basierend auf der lokalen Nachfrageprognose.
2. Identifizieren Sie Standorte mit einem Vorrat von mehr als 8 Wochen (überbesetzt für ihre Nachfrage).
3. Identifizieren Sie Standorte mit einem Vorrat von weniger als 3 Wochen (unterbesetzt).
4. Berechnen Sie Transfermengen, die alle Standorte in die Zielwochen bringen.
5. Prüfen Sie, ob die Transferkosten geringer sind als die Kosten für die Platzierung einer neuen Bestellung für den Empfangsstandort.
6. Erstellen Sie Überweisungsaufträge für wirtschaftlich gerechtfertigte Überweisungen.

---

Ablauf- und Obsoleszenzmanagement

Verderbliche Produkte und Elektronik mit kurzen Produktlebenszyklen erfordern ein aktives Ablaufmanagement. Der Expiry Agent überwacht gefährdete Bestände und löst rechtzeitige Interventionen aus.

Für verderbliche Produkte:

• 60 Tage vor Ablauf: Markierung für priorisierte Kommissionierung (FEFO – First Expiry, First Out).
• 30 Tage vor Ablauf: Benachrichtigen Sie das Vertriebsteam über den verfügbaren Lagerbestand für Aktionspreise.
• 14 Tage vor Ablauf: Abschlagspreisempfehlung bzw. Schenkungs-/Entsorgungsermächtigung erstellen.

Für langsamdrehende Produkte:

• Berechnen Sie die Lagergeschwindigkeit (verkaufte Einheiten pro Monat) und die aktuellen Liefermonate.
• Produkte mit einem Vorrat von mehr als 12 Monaten und einem rückläufigen Geschwindigkeitstrend werden als Überschuss gekennzeichnet.
• Der Agent erstellt eine Liste überschüssiger SKUs mit empfohlenen Maßnahmen: Preisnachlass, Rückgabe an den Lieferanten (sofern eine Rückgabevereinbarung besteht) oder Liquidation.

---

Überwachung der Lieferantenleistung

Der Lieferantenkoordinationsagent verfolgt die Lieferantenleistung in drei Dimensionen: pünktliche Lieferrate, Mengengenauigkeit (gelieferte Menge im Vergleich zur bestellten Menge) und Qualitätsabnahmerate. Diese Kennzahlen fließen in Entscheidungen zur Lieferantenauswahl ein, wenn neue Bestellungen erstellt werden.

export const UpdateSupplierPerformance = defineSkill({
  name: "update-supplier-performance",
  tools: ["erp"],
  async run({ input, tools }) {
    const receipt = await tools.erp.getPurchaseReceipt(input.receiptId);
    const po = await tools.erp.getPurchaseOrder(receipt.poId);

    const onTime = receipt.receivedDate <= po.expectedDelivery;
    const qtyAccuracy = receipt.receivedQty / po.orderedQty;
    const qualityAcceptanceRate = receipt.acceptedQty / receipt.receivedQty;

    await tools.erp.updateSupplierScore(po.vendorId, {
      deliveryId: receipt.id,
      onTime,
      qtyAccuracy,
      qualityAcceptanceRate,
      leadTimeActual: daysBetween(po.createdDate, receipt.receivedDate),
    });

    return { vendorId: po.vendorId, onTime, qtyAccuracy, qualityAcceptanceRate };
  },
});

Die Lieferantenbewertungen werden bei jeder Lieferung aktualisiert und beeinflussen die Lieferantenauswahl im Replenishment Agent. Ein Anbieter mit durchweg schlechter pünktlicher Lieferung wird im Auswahlalgorithmus herabgestuft, wodurch künftige Bestellungen auf zuverlässigere Alternativen verwiesen werden.

---

Häufig gestellte Fragen

Wie lange dauert es, bis das Nachfrageprognosemodell für neue SKUs korrekt ist?

Neue SKUs ohne Verkaufshistorie beginnen mit einem gleitenden Durchschnittsmodell, das Daten von mindestens 4 Wochen erfordert. Nach 12 Wochen schaltet das Mittel auf exponentielle Glättung um. Nach 52 Wochen können saisonale Muster integriert werden. Während der ersten 12 Wochen wird der Sicherheitsbestand konservativ festgelegt (unter Verwendung der branchendurchschnittlichen Variabilität für die Produktkategorie als Stellvertreter), um während der Modellkalibrierung vor Fehlbeständen zu schützen. Die Prognosegenauigkeit erreicht typischerweise innerhalb von 16–24 Wochen den Zielbereich (MAPE unter 15 % für stabile Produkte).

Wie geht das System mit Produkten mit unregelmäßiger Nachfrage (zeitweise, unregelmäßige Verkäufe) um?

Eine uneinheitliche Nachfrage (häufig bei Ersatzteilen, B2B-Produkten und saisonalen Spezialartikeln) passt nicht zu Standard-Zeitreihenprognosen. Bei SKUs, bei denen eine unregelmäßige Nachfrage festgestellt wurde (Inter-Demand-Intervall größer als 1,3 nach der Croston-Methode), wechselt der Agent zur Croston-Methode oder zur Syntetos-Boylan-Näherung, die für intermittierende Nachfrage ausgelegt sind. Bei der Berechnung des Sicherheitsbestands für Produkte mit begrenzter Nachfrage werden breitere Konfidenzintervalle verwendet, um der höheren Variabilität Rechnung zu tragen.

Kann das System in das WMS eines 3PL integriert werden?

Ja. Die Lieferantenkoordinations- und Nachschubagenten kommunizieren mit 3PLs über ihre veröffentlichten APIs (die meisten großen 3PLs bieten REST-APIs an) oder über EDI, wenn der 3PL nicht über eine moderne API verfügt. Für 3PLs ohne API-Zugriff kann der Agent per E-Mail gesendete ASN (Advance Shipping Notice) und Bestandsberichtsdateien mithilfe der Dokumentenverarbeitungspipeline automatisch verarbeiten.

Wie geht das System mit Produkten um, bei denen die Nachfrage durch Werbeaktionen oder einmalige Ereignisse gesteuert wird?

Werbeveranstaltungen werden in der Datenquelle für externe Signale registriert. Vor einer bekannten Promotion passt der Agent die Prognose nach oben an, indem er das historische Lift-Verhältnis für ähnliche Promotions (falls verfügbar) oder einen konfigurierbaren Lift-Multiplikator verwendet. Nach der Werbeaktion erkennt der Agent den Nachfragerückgang nach der Werbeaktion und passt den Nachschub entsprechend an, um eine Überlastung der Nachfrage nach der Werbeaktion zu vermeiden. Bei einmaligen Ereignissen ohne historische Daten markiert der Agent die relevanten SKUs für die manuelle Prognoseanpassung während des Ereignisplanungszeitraums.

Was passiert, wenn das ERP offline ist, wenn eine Nachschubaktion durchgeführt werden muss?

Der Replenishment Agent stellt Nachschubaufgaben in einer dauerhaften Nachrichtenwarteschlange in die Warteschlange. Wenn die ERP-Verbindung wiederhergestellt ist, verarbeitet der Agent die in der Warteschlange befindlichen Aufgaben der Reihe nach. Bei zeitkritischem Nachschub (ein Produkt mit Nullbestand und einer ausstehenden Kundenbestellung mit hoher Priorität) sendet der Agent außerdem eine Benachrichtigung an das Beschaffungsteam, damit eine manuelle Bestellung aufgegeben werden kann, während die Systemverbindung wiederhergestellt wird.

---

Nächste Schritte

Durch die statische Bestandsverwaltung bleibt in jeder Hinsicht Geld auf dem Tisch – überschüssiger Sicherheitsbestand für leicht vorhersehbare Produkte, unzureichende Deckung für volatile Produkte. OpenClaw-Inventuragenten passen sich kontinuierlich der Realität an und reduzieren so gleichzeitig das Risiko von Lagerbeständen und die Lagerhaltungskosten.

Die OpenClaw-Implementierungsdienste von ECOSIRE umfassen die vollständige Automatisierung des Bestandsmanagements – Kalibrierung der Bedarfsprognose, Einrichtung der Parameteroptimierung, Konfiguration der Nachschubrichtlinie und ERP-Integration. Unser Betriebsteam kombiniert umfassendes Supply-Chain-Wissen mit OpenClaw-Engineering, um Systeme zu entwickeln, die eine messbare Verbesserung des Betriebskapitals ermöglichen.

Kontaktieren Sie ECOSIRE, um Ihre Herausforderungen bei der Bestandsverwaltung zu besprechen und einen maßgeschneiderten Automatisierungsvorschlag zu erhalten.