Bestellt wurden zehn, geliefert werden 240: Mengeneinheiten in der Auftragsautomatisierung

Zehn bestellt, 240 geliefert

Ein Großhändler für Praxis- und Klinikbedarf nimmt Bestellungen über drei Wege an: ein Kundenportal, per E-Mail als PDF und bei zwei großen Kunden über eine Schnittstelle. Ein Workflow liest die Positionen aus, gleicht die Artikelnummer ab und legt den Auftrag im ERP an. Übernommen werden Artikelnummer und Menge. Die Mengeneinheit wird nicht übernommen, weil sie in der Bestellung nirgends als eigenes Feld steht.

Eine Pflegeeinrichtung bestellt zehn Packungen Einmalhandschuhe. Im Artikelstamm ist die Basiseinheit Stück, die Verkaufseinheit ein Umkarton mit 24 Packungen. Der Workflow schreibt die Zehn in das Mengenfeld, das ERP rechnet gegen die hinterlegte Verkaufseinheit, und die Kommissionierung bekommt zehn Umkartons auf den Beleg. 240 Packungen verlassen das Lager.

Angenommen wurde die Lieferung trotzdem. An der Rampe kennt niemand die Bestellung. Aufgefallen ist es in der Rechnungsprüfung, drei Wochen später.

Eine Zahl ohne Einheit ist keine Menge

In jedem ERP hat ein Artikel mindestens zwei Einheiten: die Basiseinheit, in der der Bestand geführt wird, und eine Verkaufseinheit mit einem Umrechnungsfaktor darauf. Meistens kommen weitere dazu, eine Lagereinheit für die Palette und eine Preiseinheit, weil pro 100 Stück kalkuliert, aber pro Karton verkauft wird.

Diese Felder sind in aller Regel sauber gepflegt. Das Problem sitzt eine Ebene davor. In der Bestellung steht eine Zahl, und die Einheit dazu steht gar nicht da, oder sie steht als Wort in einem Freitextfeld, oder sie steckt in der Artikelbezeichnung.

"10 Handschuhe Gr. M" ist keine auswertbare Angabe. Wer die Bestellung früher erfasst hat, hat daraus zehn Packungen gemacht, weil er den Kunden kennt und weiß, dass eine Einrichtung mit vierzig Betten keine 240 Packungen ordert. Diese Prüfung hätte niemand als Kontrolle bezeichnet, sie stand in keiner Verfahrensanweisung. Beim Umstieg auf den Workflow ist sie ersatzlos entfallen.

Der Fehler läuft in beide Richtungen, und die zweite Richtung ist die teurere. Zu viel geliefert kostet eine Gutschrift, eine Retoure und einen verärgerten Anruf. Zu wenig geliefert fällt oft erst auf, wenn die Station am Freitagnachmittag nach Material fragt. Was diese Lücke kostet, steht in keiner Auswertung, weil sie mit einer Sonderfahrt geschlossen wird und niemand die Sonderfahrt auf die Bestellung zurückführt.

Der Umrechnungsfaktor ändert sich

Wer den Fehler einmal gesehen hat, hinterlegt den Faktor im Workflow. Das ist die Lösung, die wir am häufigsten vorfinden, und sie hält ungefähr ein Jahr.

Verpackungseinheiten sind keine Eigenschaft des Artikels, sondern eine Entscheidung des Herstellers. Aus 24 Packungen im Umkarton werden 20, weil die Palettierung umgestellt wurde. Die Artikelnummer bleibt, der Bestand stimmt weiter, und einzig die Tabelle im Workflow zeigt auf einen Wert, den es nicht mehr gibt.

Beim Lieferantenwechsel passiert dasselbe: gleicher Artikel, andere Bezugsquelle, andere Gebindegröße. Im ERP hängt diese Angabe an der Lieferantenbeziehung. Im Workflow hängt sie in einer Spalte, die vor achtzehn Monaten jemand ausgefüllt hat.

Dazu kommt, dass Kunden in unterschiedlichen Einheiten bestellen dürfen. Die Klinik nimmt den Umkarton, die kleine Praxis die Einzelpackung, beide über dasselbe Portal, beide mit derselben Artikelnummer. Ein Faktor pro Artikel bildet das nicht ab.

In Kliniken wird viermal umgerechnet

Der Bedarf entsteht auf Station und wird in Stück gedacht: 200 Kanülen für den Monat. Die Materialwirtschaft bestellt in Verpackungseinheiten. Geliefert wird auf Palette, vereinnahmt wird im Zentrallager, und ausgegeben und auf die Kostenstelle der Station gebucht wird wieder in Stück.

An jedem dieser Übergänge wird umgerechnet. Solange an einer Stelle ein Mensch sitzt, fällt eine unsinnige Zahl auf. Wenn Bestellung, Wareneingang und Verbrauchsbuchung automatisch ineinandergreifen, wandert ein Faktor 24 unbemerkt bis in die Verbrauchsauswertung. Dort sucht ihn niemand, weil dort niemand nach Fehlern sucht.

Was tatsächlich hilft

Die Einheit gehört als eigenes Feld in die Bestellposition. Drei Angaben statt zwei: Artikel, Menge, Einheit. Im Portal ist das eine Auswahlliste neben dem Mengenfeld. In EDI- und API-Formaten existiert das Feld längst und wird nur nicht befüllt. Damit ist der größte Teil des Problems erledigt.

Umgerechnet wird im ERP. Der Faktor steht dort bereits und wird von denselben Leuten gepflegt, die den Artikelstamm pflegen. Jede Kopie davon an anderer Stelle ist eine zweite Wahrheit, die irgendwann von der ersten abweicht.

Für PDF- und E-Mail-Bestellungen braucht es eine Obergrenze. Wenn eine Position mehr als das Fünffache dessen ergibt, was dieser Kunde in den letzten zwölf Monaten von diesem Artikel bezogen hat, geht sie in eine Freigabe. Der Baustein ist klein und fängt vertippte Mengen gleich mit ab.

In die Auftragsbestätigung gehört die Rechnung sichtbar hinein: zehn Umkartons zu 24 Packungen, insgesamt 240 Packungen. Kunden korrigieren das am selben Tag. Eine Rechnung drei Wochen später korrigieren sie nicht, die reklamieren sie.

Ein Blick in Ihren eigenen Workflow

Öffnen Sie den Schritt, der die Position ins ERP schreibt, und sehen Sie nach, was im Einheitenfeld steht. Ein fest eingetragener Wert oder ein leeres Feld bedeutet, dass die Vorbelegung aus dem Artikelstamm über Ihre Liefermengen entscheidet.

Ziehen Sie danach die Gutschriften der letzten sechs Monate und suchen Sie nach Mengen, die ein glattes Vielfaches der bestellten Menge sind. 12, 20, 24 und 100 tauchen dabei häufiger auf, als der Zufall erklären würde.

Bei den Anbindungen, die wir uns ansehen, ist das selten ein Umbau. Es fehlt ein Feld, das an drei Stellen mitlaufen müsste, und eine Grenze, ab der jemand hinschaut.