Prozessoptimierung

Vendor Managed Inventory: MRO-Bestände beim Kunden steuern

Vendor Managed Inventory steuert MRO-Nachschub aus Kundenbeständen. So klären IT-Leiter Daten, Regeln, Rechte, ERP-Anbindung und Pilotbetrieb.
Vendor Managed Inventory: MRO-Bestände beim Kunden steuern
Prozessoptimierung aus der Conveso Praxis
Fynn Governatori15. August 20269 Min.

Beispielszenario, kein Kundenfall: Ein Industriekunde möchte seine C-Teile nicht mehr einzeln bestellen. Der MRO-Großhandel soll die Bestände an mehreren Entnahmestellen überwachen und rechtzeitig nachfüllen. Im Kundensystem stehen jedoch andere Artikelnummern und Einheiten, eine Lieferung ist noch unterwegs und der letzte Verbrauch wurde verspätet gemeldet. Vendor Managed Inventory beginnt deshalb nicht mit einer automatischen Bestellung. Zuerst müssen beide Seiten dieselbe Sicht auf Bestand, Verbrauch und Verantwortung herstellen.

Vendor Managed Inventory, kurz VMI, ist ein gemeinsamer Nachschubprozess, bei dem der Lieferant die Bestände definierter Artikel beim Kunden plant. Der Kunde stellt vereinbarte Bestands- und Verbrauchsdaten bereit. Der MRO-Großhandel prüft daraus den Nachschub gegen Zielbestand, offene Lieferungen und Ausnahmen. Eigentum, Bestellung, Lieferung und Abrechnung sind davon getrennt zu regeln. Das ERP bleibt auf beiden Seiten das führende System.

Kurzantwort

Für Vendor Managed Inventory braucht der MRO-Großhandel eindeutige Kundenstandorte, Artikel und Einheiten, aktuelle Bestands- und Verbrauchsdaten, eine vereinbarte Nachschubregel sowie sichtbare offene Lieferungen. Ein Pilot sollte Vorschläge zunächst ohne automatische Ausführung berechnen. Erst wenn Datenabgleich, Freigabe, Lieferung und Bestandsfortschreibung belastbar funktionieren, kann der Standardweg weiter automatisiert werden.

Was ist Vendor Managed Inventory im MRO-Großhandel?

Bei Vendor Managed Inventory übernimmt der Lieferant die Planung des Nachschubs für einen vereinbarten Bestand beim Kunden. Der Kunde übermittelt dazu Bestände, Verbräuche und gegebenenfalls Bedarfsinformationen. Der Lieferant entscheidet innerhalb festgelegter Grenzen, wann und in welcher Menge nachgefüllt wird.

Die aktuelle SAP-Dokumentation zu Vendor Managed Inventory in SAP IBP, Version 2605 beschreibt VMI als gemeinsamen Nachschubprozess: Der Lieferant überwacht Bestände an Kundenstandorten, plant auf Basis bereitgestellter Bestands- und Prognosedaten und erzeugt daraus Nachschubvorschläge. Diese Produktdokumentation ist kein Pflichtenheft für jedes System. Sie zeigt aber die fachliche Rollenverteilung, die auch ohne SAP gelten muss.

Für einen MRO- und Werkzeuggroßhandel passt das Modell besonders zu wiederkehrend verbrauchten Normteilen, Befestigungsmitteln, Arbeitsschutzartikeln oder anderen klar identifizierbaren Betriebsmitteln. Es passt nicht automatisch zum gesamten Sortiment. Unregelmäßige Ersatzteile, projektbezogene Sonderbeschaffungen und Artikel mit ungeklärter Kritikalität brauchen meist einen anderen Prüfweg.

Was unterscheidet VMI von Kanban und Konsignationslager?

Die Begriffe werden häufig gemeinsam verwendet, bezeichnen aber unterschiedliche Entscheidungen.

| Konzept | Kernfrage | Was dadurch nicht automatisch geklärt ist | |---|---|---| | Vendor Managed Inventory | Wer plant den Nachschub beim Kunden? | Eigentum, Abrechnung und konkretes Auslösesignal | | Kanban-Regelkreis | Welches Verbrauchssignal löst welchen Nachschubvorgang aus? | Wer die Bestandsplanung verantwortet | | Konsignationslager | Wem gehört die Ware bis zur Entnahme, und wann wird sie berechnet? | Wer Mengen und Lieferzeitpunkt plant | | Mindest- und Höchstbestand | Innerhalb welcher Bestandsgrenzen wird aufgefüllt? | Datenweg, Rollen und Folgebelege |

Ein VMI-Prozess kann einen Kanban-Scan als Verbrauchssignal nutzen. Er muss es aber nicht. Der bestehende Leitfaden zum Kanban-Regelkreis im MRO-Großhandel erklärt den Weg vom Leersignal bis zur bestätigten Auffüllung. VMI setzt eine Ebene darüber an und klärt, wie der Großhandel aus Kundenbestand, Verbrauch und offenen Lieferungen die Nachschubentscheidung vorbereitet.

Auch Konsignation ist keine Voraussetzung für VMI. Die Oracle-Dokumentation zu Vendor Managed Inventory unterscheidet ausdrücklich zwischen konsigniertem Bestand, der bis zum Verbrauch dem Lieferanten gehört, und nicht konsigniertem Bestand, der bei Empfang in das Eigentum des Kunden übergeht. Eigentumsübergang, Umsatzrealisierung, Steuer und Vertragswirkung müssen deshalb separat mit kaufmännischer und rechtlicher Verantwortung geklärt werden.

Für welche MRO-Artikel und Kunden eignet sich Vendor Managed Inventory?

VMI ist prüfenswert, wenn der Nachschub regelmäßig wiederkehrt und beide Seiten die benötigten Daten verlässlich bereitstellen können. Die SAP-Grundlagendokumentation zu VMI nennt unter anderem wichtige Kundenbeziehungen, standardisierte wiederkehrende Produkte, ausreichend stabile Bedarfsmuster und hohen Transaktionsaufwand als geeignete Ausgangslage.

Für einen MRO-Pilot sollten IT und Fachbereich jeden Artikel gegen konkrete Fragen prüfen:

  • Ist Artikel, Ausführung und Einheit an beiden Standorten eindeutig zugeordnet?
  • Entsteht ein wiederkehrender, beobachtbarer Verbrauch statt eines einmaligen Projektbedarfs?
  • Sind tatsächlicher Bestand, offene Lieferung und Ware in Klärung getrennt sichtbar?
  • Reicht die vereinbarte Wiederbeschaffungszeit für den benötigten Servicegrad?
  • Ist klar, wer bei Bedarfssprung, Fehlbestand oder Artikelwechsel entscheidet?
  • Lassen sich Lieferung, Verbrauch und gegebenenfalls Abrechnung über gemeinsame Referenzen verbinden?

Ein niedriger Stückpreis allein macht einen Artikel nicht geeignet. Ein C-Teil kann beim Industriekunden produktionskritisch sein. Umgekehrt kann ein höherwertiges Werkzeug einen stabilen, gut planbaren Verbrauch haben. Die Auswahl braucht deshalb Artikelmerkmale, Verbrauchsverlauf, Wiederbeschaffungszeit und eine gemeinsam festgelegte Risikoklasse.

Welche Daten braucht Vendor Managed Inventory?

Der zentrale Engpass ist selten die Formel für den Zielbestand. Kritisch ist, ob beide Partner dieselben Objekte und Zeitstände meinen. Für jeden VMI-Bestand sollten mindestens diese Angaben definiert sein:

| Datenbereich | Benötigte Angaben | Typischer Fehlerfall | |---|---|---| | Partner und Standort | Kunde, Werk, Entnahmestelle, Lieferadresse | Bestand wird dem falschen Werk zugeordnet | | Artikelidentität | Kundenartikel, Großhandelsartikel, Herstellerreferenz | Nachfolgeartikel läuft unter alter Nummer weiter | | Menge und Einheit | verfügbar, gesperrt, reserviert, Stück, Pack, Gebinde | Kundensystem meldet Pack, ERP plant Stück | | Verbrauch | Menge, Zeitpunkt, Ort, Korrekturstatus | dieselbe Entnahme wird zweimal übertragen | | Nachschubregel | Mindestbestand, Höchstbestand, Zielmenge, Prüfrhythmus | Grenzwerte sind ohne gültige Version hinterlegt | | Offene Versorgung | Auftrag, Lieferung, Transitmenge, erwarteter Termin | bereits versandte Ware wird erneut geplant | | Kaufmännischer Bezug | Vertrag, Kondition, Eigentum, Abrechnungsereignis | Nachschub entsteht ohne gültige Vereinbarung | | Datenstand | Erzeugungszeit, Empfang, Quelle, Qualitätsstatus | eine alte Meldung überschreibt den neueren Bestand |

Nicht jedes Feld muss in einer neuen Anwendung gepflegt werden. Kunden, Artikel, Konditionen, Auftrag und Lieferung bleiben in den führenden Systemen. Eine Integrationsschicht kann Daten zusammenführen, Regeln ausführen und Abweichungen an die zuständige Person geben. Die ERP-Integration sollte dabei festhalten, welches System jedes Feld führt und wie Korrekturen zurückgespielt werden.

Wie läuft ein VMI-Prozess vom Kundenbestand bis zur Auffüllung?

Ein belastbarer Ablauf verbindet Planung und physische Versorgung in acht Schritten:

  1. VMI-Umfang festlegen: Kunde, Standorte, Artikel, Einheiten, Zielbestände, Zeitfenster und Verantwortliche werden versioniert vereinbart.
  2. Bestand und Verbrauch melden: Das Kundensystem überträgt den vereinbarten Datenstand mit Zeitstempel und eindeutigen Referenzen.
  3. Nachricht prüfen: Partner, Standort, Artikel, Einheit, Vollständigkeit und Reihenfolge werden technisch und fachlich validiert.
  4. Versorgungsstand bilden: Bestand, gemeldeter Verbrauch, offene Aufträge, Transitmengen und gesperrte Ware werden zusammengeführt.
  5. Nachschub vorschlagen: Die vereinbarte Regel berechnet Menge und Termin. Auffällige Fälle erhalten einen Fehlergrund statt eines verdeckten Standardwerts.
  6. Fachlich freigeben: Der zuständige Mitarbeiter prüft insbesondere Bedarfssprung, Fehlbestand, Ersatzartikel und Vertragsabweichung.
  7. Liefern und bestätigen: Auftrag, Kommissionierung, Versand, Empfang und gegebenenfalls Einräumen bleiben über eine gemeinsame Referenz verbunden.
  8. Bestand abgleichen: Beide Seiten gleichen bestätigte Lieferung, neuen Bestand und offene Differenzen ab, bevor der nächste Planungslauf startet.

Die SAP-Business-Network-Dokumentation zu Supplier Managed Inventory beschreibt einen vergleichbaren Ablauf mit freigegebenen Materialien, Bedarfs- und Bestandsinformationen, Mindest- und Höchstwerten, geplanten Sendungen und Lieferavisen. Für den mittelständischen MRO-Großhandel ist daraus vor allem eines wichtig: Ein Rechenvorschlag ist noch keine bestätigte Lieferung. Jeder Übergang braucht einen sichtbaren Status.

Wie dockt VMI an ERP, EDI und API an?

Vendor Managed Inventory schreibt kein bestimmtes Übertragungsformat vor. Je nach Kunde können eine dokumentierte API, EDI-Nachrichten, ein Portal oder eine vereinbarte Dateiübergabe passen. Entscheidend sind Dateninhalt, Version, Aktualität, Fehlerbehandlung und Zuständigkeit.

GS1 Germany beschreibt im EANCOM-Überblick unter anderem den Lagerbestandsbericht INVRPT und den Verkaufsdatenbericht SLSRPT. INVRPT kann aktuelle, geplante sowie minimale oder maximale Bestandsmengen enthalten. SLSRPT kann Verkaufsdaten je Produkt, Zeitraum und Ort übertragen. Diese Nachrichten sind mögliche Bausteine, aber kein Selbstzweck. Partner- und Produktcodes müssen vorher abgestimmt sein, und ein Bericht ersetzt nicht automatisch Bestellung oder Lieferabruf.

Die Seite zu EDI und E-Procurement ordnet Transport, Partnerprofile und Fehlerbearbeitung ein. Für die IT-Leitung kommen im VMI-Pilot zusätzliche Leitplanken hinzu:

  • Bestandsdaten zunächst nur lesen, wenn keine schreibende Aktion erforderlich ist
  • Kunden und Standorte technisch voneinander trennen
  • Nachrichten gegen Dubletten, verspätete Reihenfolge und unvollständige Felder schützen
  • Regelversion, Vorschlag, Freigabe und Übergabe protokollieren
  • Wiederholung und Warteschlange für nicht erreichbare Systeme festlegen
  • unnötige personenbezogene Daten aus Bestand und Protokollen heraushalten
  • manuellen Rückfallweg für unterbrochene Übertragung dokumentieren

Eine KI ist dafür nicht erforderlich. Sie kann später Auffälligkeiten priorisieren oder unstrukturierte Zusatzinformationen aufbereiten. Die fachliche Basis bleibt ein nachvollziehbarer Daten- und Belegweg.

Welche Ausnahmen müssen bei VMI sichtbar bleiben?

Ein VMI-System darf eine fehlende Information nicht durch einen scheinbar plausiblen Bestand ersetzen. Mindestens diese Fälle brauchen einen klaren Prüfweg:

  • Bestandsmeldung fehlt, ist veraltet oder kommt in falscher Reihenfolge
  • Artikel, Standort oder Einheit lässt sich nicht eindeutig zuordnen
  • gemeldeter Verbrauch ist doppelt, negativ oder ungewöhnlich hoch
  • Ware ist unterwegs, aber im Kundenbestand noch nicht berücksichtigt
  • Empfang wurde bestätigt, die Menge weicht jedoch von der Lieferung ab
  • Mindest- oder Höchstbestand wurde ohne freigegebene Version geändert
  • Ersatzartikel, Charge oder Verfallsdatum erfordert eine fachliche Entscheidung
  • Kunde meldet Stillstand, Sonderbedarf oder einen geplanten Verbrauchssprung
  • Vertragsstatus, Kondition, Eigentum oder Abrechnungsweg ist ungeklärt

Jede Ausnahme braucht Ursache, zuständige Rolle und erlaubten nächsten Schritt. Die IT stellt die technische Sichtbarkeit her. Einkauf, Vertrieb, Logistik oder kaufmännische Leitung treffen die jeweilige fachliche Entscheidung.

Woran messen Sie einen VMI-Pilot?

Die Zahl automatisch erzeugter Vorschläge reicht als Erfolgsnachweis nicht. Ein Pilot muss zeigen, ob Versorgung, Datenqualität und Betriebsaufwand gemeinsam tragfähig sind. Geeignete Messgrößen sind:

  • Anteil pünktlich und vollständig eingegangener Bestandsmeldungen
  • Bestandsabweichungen zwischen Kundenmeldung, Lieferung und Abgleich
  • Vorschläge mit eindeutiger Artikel-, Standort- und Einheitenzuordnung
  • manuelle Korrekturen nach Ursache und Bearbeitungszeit
  • Fehlbestände, Eillieferungen und nicht erfüllte Zielbestände
  • Zeit vom erkannten Bedarf bis zur bestätigten Auffüllung
  • technische Abbrüche, Wiederholungen und Supportaufwand
  • offene Vorgänge nach Status und Alter

Beginnen Sie mit einem Kundenstandort, einer klar abgegrenzten Artikelgruppe und einem lesenden Datenweg. Lassen Sie die Nachschubvorschläge zunächst parallel zum heutigen Ablauf berechnen. Prüfen Sie anschließend Datenstand, Ausnahmen, Freigabe und tatsächliche Lieferung. Erst wenn der Abgleich über mehrere vollständige Versorgungszyklen trägt, ist eine automatische Übergabe für eindeutig definierte Standardfälle prüfenswert.

Der nächste Schritt für die IT-Leitung ist eine gemeinsame Datenprobe mit Fachbereich und Kunde: ein Bestandsbericht, ein Verbrauchszeitraum, offene Lieferungen und die zugehörigen Artikelreferenzen. Wenn Sie daraus Systemgrenzen, Prüfregeln und Pilotumfang ableiten möchten, kann ein sachliches Gespräch über Ihren VMI-Datenweg die offenen Punkte strukturieren.

Fynn Governatori
Fynn Governatori

Geschäftsführer und Berater für den technischen Fachgroßhandel

Welcher Ablauf beschäftigt Ihr Team gerade?

In einem ersten Gespräch ordnen wir den Engpass gemeinsam ein und klären, ob Automatisierung dort wirklich weiterhilft.