Bestandsreservierungen im ERP: wie du im KMU aufhörst, denselben Artikel zweimal zu verkaufen

40 Stück auf Lager. Vertriebler A verspricht 30 einem Kunden in Poznań. Eine Stunde später verspricht Vertriebler B 25 einem Kunden in Kraków. Beide haben in denselben Report geschaut, und beide hatten Recht — in dem Moment zeigte das System 40 Stück. Das Problem: Das ERP wusste beim zweiten Versprechen nichts vom ersten. Zwei Tage später bekommt einer der beiden Kunden einen Entschuldigungsanruf.

Dieser Beitrag geht darum, warum „Lagerbestand" im ERP nicht reicht, um zu verkaufen, was harte von weichen Reservierungen unterscheidet und wie ein zweiwöchiges Projekt Reservierungen so einführt, dass Vertriebler ihre Kunden nicht mehr in gutem Glauben belügen.

Warum reiner Bestand nicht reicht

Fast jedes ERP, das in polnischen KMU läuft — Comarch Optima, Comarch ERP XL, enova365, Subiekt GT/nexo, Streamsoft — hat im Artikelstamm ein Feld „Lagerbestand". Es zeigt, was physisch im Lager liegt. Das ist genau — bis etwas vom Regal geht oder eine Lieferung eintrifft.

Der Vertriebsprozess läuft nicht in dieser Zeitachse. Zwischen einem Versprechen an den Kunden und der Auslieferung liegen Stunden, Tage, manchmal Wochen. In diesem Fenster sehen alle Vertriebler, der Webshop, der Lagerleiter und der Einkauf denselben Bestand. Jeder trifft Entscheidungen, als wäre er der einzige, der ihn nutzt.

Das funktioniert, solange die Firma zwei Vertriebler und ein Lager hat. Es hört auf zu funktionieren, sobald Angebote, Telefonbestellungen, der Webshop, EDI-Feeds an B2B-Ketten und die Produktion (die dasselbe Material zieht) parallel laufen. Typische Symptome dafür, dass ein Unternehmen dem „eine Zahl für alle"-Modell entwachsen ist:

• „Du hast verkauft, was wir nicht haben" — regelmäßige Beschwerden, dass die für Dienstag versprochene Ware erst Freitag geht.
• Vertriebler rufen vor jedem Angebot im Lager an — weil der ERP-Report nicht ausreicht. Der Lagerleiter nimmt am Tag 15 solcher Anrufe entgegen.
• Der Webshop verkauft, was ausgegangen ist — erst beim Kommissionieren fällt auf, dass das verfügbare Stück längst mit einem B2B-Auftrag ausgeliefert wurde.
• Der Einkauf bestellt zu viel — weil er Bestand 0 sieht und die 20 Stück nicht sieht, die schon zu einem anderen Auftrag unterwegs sind.
• Die Produktion steht, weil „das Material verkauft wurde" — der Planer hat eine Charge auf Material geplant, das am Morgen weg war, weil es nachts auf einen Lieferschein ging.

Jedes Symptom kostet Geld. Pro Vorfall nicht dramatisch, aber jeden Tag — über ein Jahr ist das ein Geschäftsführerurlaub, aufgefressen von Beschwerden, die nicht hätten sein müssen.

Harte vs. weiche Reservierungen

Im praktischen ERP-Vokabular gibt es zwei Begriffe, die man trennen sollte, bevor man an die Konfiguration geht.

Eine harte Reservierung blockiert eine konkrete Menge in einem konkreten Lager für einen konkreten Auftrag. Wenn der Vertriebler einem Kunden X 30 Stück bestätigt, verschwinden diese 30 im ERP aus „verfügbar für Verkauf" für alle anderen. Keine Diskussion, kein „wir werden uns schon einigen". Der Bestand gehört dem Beleg.

Eine weiche Reservierung ist ein Signal, dass jemand die Ware nehmen will, aber noch nicht bestätigt hat. Typisch: ein verschicktes Angebot, das noch nicht angenommen wurde. Eine weiche Reservierung hat immer ein Ablaufdatum — nach 7 Tagen ohne Bestätigung fällt die Sperre, die Ware kehrt in den verkäuflichen Pool zurück.

Grundregel: jeder Beleg im Vertriebsprozess braucht einen eindeutig zugewiesenen Reservierungstyp. Angebot = weich, bestätigter Auftrag = hart, Warenausgang = physischer Bestandsabgang (keine Reservierung mehr).

Im KMU-ERP ist das meist eine Checkbox im Beleg-Kopf plus ein Datumsfeld für die Reservierungsgültigkeit. Der Rest ist Konfiguration: welcher Belegtyp welche Reservierung per Default erzeugt, wer was ändern darf, wann die Sperre automatisch fällt.

Verfügbarer Bestand ist nicht Lagerbestand

Sobald man Reservierungen aktiviert, wird aus einer Zahl im Artikelstamm vier — und das ganze Team muss lernen, sie zu lesen:

• Lagerbestand — was physisch da liegt (ändert sich nur durch Wareneingänge, Warenausgänge, Umlagerungen).
• Reserviert — wie viel ist auf bestätigte Aufträge gesperrt (harte Reservierungen).
• In Bestellung — wie viel ist beim Lieferanten bestellt, aber noch nicht angekommen (Bestellungen ohne Wareneingang).
• Verfügbar für Verkauf = Lagerbestand − Reserviert + In Bestellung (optional gefiltert nach Liefertermin).

Ein Vertriebler schaut nie auf „Lagerbestand". Er schaut auf „Verfügbar für Verkauf". Der Webshop zieht „Verfügbar" per API, nicht „Lagerbestand". Der Lagerleiter schaut auf „Lagerbestand" und „Reserviert", denn seine Sorge ist, ob physisch da liegt, was da liegen soll.

Diese eine Änderung — dem Team beizubringen, dass es aus „Verfügbar" verkauft, nicht aus „Lagerbestand" — löst 80% des Doppelverkaufsproblems. Der Rest ist Konfiguration der Belegtypen und die Disziplin, weiche Reservierungen ablaufen zu lassen.

Konfiguration in einem typischen KMU-ERP

Beispielhaft an Comarch Optima und Comarch ERP XL, weil das in polnischen 15-50-Personen-Firmen am häufigsten ist. In enova365, Subiekt und Streamsoft ist der Mechanismus sehr ähnlich, nur die Feldnamen unterscheiden sich.

Schritt 1 — Reservierungen für ausgewählte Lager aktivieren. In den Lagereinstellungen „Reservierungen ignorieren" abwählen. In einer Einlager-Firma ist das eine Änderung. In einer Firma mit Haupt- und Detailhandelslager lohnt es sich meist, Reservierungen nur auf dem Hauptlager zu haben.

Schritt 2 — Default-Reservierungstypen für Belege setzen. Bestätigter Verkaufsauftrag = harte Reservierung. Angebot = weiche Reservierung, 7 Tage. Proforma-Rechnung = harte Reservierung bis Zahlung oder bis zum Gültigkeitsdatum (typisch 3 Tage).

Schritt 3 — festlegen, wer Reservierungen manuell aufheben darf. Vertriebler — nur seine eigenen. Vertriebsleiter — alle. Das muss in den Berechtigungen sitzen, sonst hebt jeder jedem etwas auf und es wird chaotisch.

Schritt 4 — zyklisches Ablaufen weicher Reservierungen. Ein täglicher Hintergrundjob oder ein Eintrag im ERP-Scheduler: „alle Angebote älter als 7 Tage ohne Auftrag → Reservierung aufheben, dem Vertriebler mailen".

Schritt 5 — Sichtbarkeit im Artikelstamm. Auf dem Artikelstamm eine Liste aller Reservierungen anzeigen mit Belegnummer, Kunde, Menge und Ablaufdatum. Wenn der Vertriebler sieht „30 Stück reserviert auf VA/2026/1234 für Kunde X bis 15.09", weiß er, ob er Kunde X anrufen und einen kürzeren Termin verhandeln oder sich Ware woanders suchen soll.

Schritt 6 — Integration mit Webshop und EDI. Wenn der Webshop den Bestand per API zieht, auf „Verfügbar" umschalten. Wenn ihr Katalog-Updates per EDI an Handelsketten schickt, sicherstellen, dass in den INVRPT-Dateien „Verfügbar", nicht „Lagerbestand" steht. Sonst bestellt die Kette, was ihr schon für jemand anderen gesperrt habt.

Ein konkretes Beispiel

Ein 18-Personen-Distributor für Installationsmaterial bei Łódź. Comarch ERP XL, vor 6 Jahren gekauft, Lagermodul auf Default konfiguriert — Reservierungen wurden beim Rollout nie eingeschaltet, weil „das kompliziert ist". Vertrieb über 5 Mitarbeiter im Büro, einen B2B-Webshop und EDI-Feeds an zwei Großhandelsketten. 2.400 Artikel im Lager, tägliche Bewegung von 300-400 Belegpositionen.

Warum sie angerufen haben: Der Vertriebsleiter hat Beschwerden für das erste Halbjahr gezählt — 84 Fälle „versprochen, nicht geliefert", darunter 11 verlorene Kunden, die zur Konkurrenz gegangen sind. Der Eigentümer hat die verlorene Marge gerechnet: rund 340.000 PLN im Jahr, plus die Belastung von Buchhaltung und Logistik durch Korrekturrechnungen.

Was wir in 3 Wochen gemacht haben:

1. Audit des Vertriebsprozesses — 2 Tage mit dem Vertriebsleiter, einem Vertriebler und dem Lagerleiter. Wir haben 6 Vertriebskanäle gemappt (Telefon, Mail, B2B-Webshop, EDI, Außendienst, Verkauf ab Detailhandelslager). Schlüsselerkenntnis: Der Außendienst „reservierte" Ware per SMS ans Büro, das Büro notierte es in Outlook — im ERP war davon nichts.
2. Reservierungen auf dem Hauptlager aktivieren — eine Config-Änderung in Comarch ERP XL, aber wir mussten 32 offene Aufträge der letzten 6 Wochen durchgehen und nachträglich Reservierungen erzeugen, damit der Verfügbarkeitsbestand nicht kippt.
3. Reservierungstypen für Belege konfigurieren — Angebot = weich 5 Tage, bestätigter Auftrag = hart, Proforma = hart 3 Tage. Ein Tages-Job um 6 Uhr morgens lässt überfällige weiche Reservierungen ablaufen und mailt dem Vertriebler die Liste „das ist dir gestern abgelaufen".
4. Report-Änderung im B2B-Webshop — der Shop zeigte den Kunden bisher den Lagerbestand. Wir haben die API-Abfrage auf „Verfügbar" umgestellt (Lagerbestand − harte Reservierungen + Bestellungen mit Liefertermin in den nächsten 7 Tagen). Ein paar Kunden haben die Änderung bemerkt und gefragt, warum „plötzlich weniger". Antwort: „Weil wir jetzt nicht mehr verkaufen, was wir nicht haben".
5. EDI-Datei-Änderung — die INVRPT-Datei für die zwei Ketten bekam eine andere Sicht auf denselben Artikel: liefernde Verfügbarkeit, nicht Lagerbestand. Die Ketten haben die Formatänderung nicht bemerkt, aber sie haben aufgehört, Ware zu bestellen, die schon reserviert war.
6. Mobile Ansicht für den Außendienst — ein kleines Add-on, Zugriff auf den B2B-Webshop vom Handy. Statt SMS ans Büro erzeugt der Vertriebler beim Kundentermin ein Angebot, das sofort eine weiche Reservierung im ERP anlegt.
7. Neues Dashboard für Vertriebler — „meine aktiven Reservierungen" mit Ablaufterminen, damit jeder Vertriebler seine eigenen vor Ablauf managt, nicht danach.

Ergebnis nach 3 Monaten: „versprochen, nicht geliefert"-Beschwerden fielen von 14-16 pro Monat auf 2-3. Diese 2-3 sind hauptsächlich Lieferverzögerungen bei Lieferanten, nicht Doppelverkäufe. Vertriebler hörten auf, vor Angeboten im Lager anzurufen — der Lagerleiter schätzte die Ersparnis auf rund 40 Stunden seiner Zeit pro Monat. Zwei verlorene Ketten kamen im Quartal zurück, weil ein Vertriebler mit einem konkreten Argument angerufen hat: „wir haben jetzt einen zuverlässigen Verfügbarkeitsbestand im EDI, eure Bestellung wird nicht verschenkt".

Projektkosten: rund 18.000 PLN — 3 Tage Audit, 4 Tage Konfiguration Comarch ERP XL, 2 Tage Arbeit an der API-Integration des Shops und der EDI-Datei, 1 Tag Schulung der Vertriebler und des Lagerleiters, mobile Ansicht für den Außendienst basierend auf dem bestehenden B2B-Portal (keine neue Anwendung — nur eine mobile Ansicht). Amortisation: zwei Monate, gerechnet über zurückgewonnene Kunden und die freigesetzte Zeit des Lagerleiters.

Fallen, auf die man achten sollte

Ein paar Dinge, die ein Reservierungsprojekt kippen können:

• Eine Reservierung ohne Ablaufdatum ist eine Zeitbombe — nach einem halben Jahr sind 30% des Bestands auf Angebote reserviert, an die sich niemand erinnert. Ablaufdatum verpflichtend für jede weiche Reservierung.
• Harte Reservierung auf unbezahlter Proforma — wenn der Kunde die Proforma nicht in 3 Tagen zahlt, fällt die Reservierung. Sonst „reservieren" Kunden Ware und holen sie nie ab.
• Reservierungen außerhalb des ERPs — SMS, Mail, eine Outlook-Notiz, ein Zettel unter der Tastatur. Was nicht im ERP steht, existiert nicht. Regel: wer reserviert, tippt es ins ERP.
• „In Bestellung" bei Verfügbarkeit ignorieren — wenn im Artikelstamm 100 morgen ankommende Stück nicht auftauchen, verliert der Vertriebler den Verkauf, obwohl die Ware praktisch „um die Ecke" ist. Bestellungen müssen in die Verfügbarkeitsrechnung einfließen (gefiltert nach Liefertermin).
• Reservierungen zwischen Produktions- und Verkaufslager — wenn die Produktion Material zieht, das für einen Verkaufsauftrag reserviert war, gibt's Streit. Getrennte logische Lager und getrennte Bedarfslisten lösen das ein für alle Mal.
• Zu lockere Berechtigungen zum Aufheben — wenn Vertriebler A die Reservierung von Vertriebler B aufhebt, um seine eigene zu buchen, herrscht in einer Woche Vertriebskrieg. Fremdreservierungen aufheben — nur der Vertriebsleiter.
• Keine Kommunikation zum Kunden — wenn der Kunde bisher „wir haben 40 Stück" gehört hat und jetzt „12 verfügbar, 28 reserviert" hört, lohnt sich eine Erklärung in drei Sätzen per Mail. Sonst denkt der Kunde, du weist ihn ab.

Wann es sich nicht lohnt

Reservierungen zahlen sich erst ab einer gewissen Größe aus. Wenn die Firma zwei Vertriebler hat, ein Lager, von Tag zu Tag verkauft und praktisch keine offenen Aufträge in die Zukunft — sind Reservierungen Overengineering. Ein gemeinsames Excel mit „diese Woche versprochen" plus ein täglicher 5-Minuten-Vertriebs-Standup reichen.

Reservierungen lohnen sich, wenn:

• Mehr als 20-30 Aufträge gleichzeitig offen sind.
• Der Vertrieb über 3+ Kanäle parallel läuft (Telefon, Mail, Webshop, EDI, Außendienst).
• Der Zyklus vom Angebot zur Auslieferung länger als 24 Stunden dauert.
• „Versprochen, nicht geliefert"-Beschwerden häufiger als 2-3 pro Monat auftreten.

Unterhalb dieser Schwellen sind Reservierungen Verwaltungsaufwand ohne klaren Nutzen. Oberhalb kostet das Fehlen mehr als die Einführung.

Wie geht es weiter

Reservierungen im ERP sehen technisch aus, sind aber vor allem eine Änderung darin, wie ein Unternehmen über den Lagerbestand denkt. „Wie viel habe ich" reicht nicht mehr — das Team muss lernen, „wie viel ist für einen neuen Verkauf verfügbar" zu fragen. Diese Frage beantwortet ein korrekt konfiguriertes ERP in einer Sekunde und ein handgeführtes Lager nie.

Wenn bei euch Vertriebler vor Angeboten im Lager anrufen oder „versprochen, nicht geliefert"-Beschwerden jede Woche zurückkommen — eine halbe Stunde Gespräch reicht meist, um einzuschätzen, ob Reservierungen das sind, was eurer Firma fehlt.

Ein Vertriebler, der vor jedem Angebot im Lager anruft, tut das nicht aus Höflichkeit. Er tut es, weil der ERP-Report ihn belügt — und der belügt ihn, weil niemand Reservierungen aktiviert hat.

← Zurück zum Blog