Der Rückruf kommt freitags um vier: Ihre Automatisierung kennt den Artikel, nicht die Charge
Chargen und Verfallsdaten entstehen im Lager und bleiben dort. Auftrag, ERP und Kundenkommunikation arbeiten mit der Artikelnummer, und deshalb lässt sich die einfachste Frage nicht beantworten: Wer hat diese Charge bekommen?
Freitag, 16:20 Uhr, zwei Chargen im Rückruf
Ein Großhändler für Praxis- und Klinikbedarf bekam an einem Freitagnachmittag die Rückrufmeldung eines Herstellers. Betroffen waren zwei Chargen eines Einmalprodukts, Losnummern 24-118 und 24-119. Frist für die Information der Kunden: 48 Stunden.
Im ERP stand, wer den Artikel gekauft hatte, 412 Kunden in vierzehn Monaten. Wer die beiden Chargen bekommen hatte, stand nirgendwo. Genauer: an keiner Stelle, die eine Abfrage erreicht. Die Chargennummer war beim Kommissionieren gescannt worden, sie stand im Lagersystem am Buchungssatz und auf dem gedruckten Lieferschein. In der Auftragsposition, die die Schnittstelle ins ERP geschrieben hatte, stand sie nicht.
Das Wochenende ging für 412 Anrufe drauf, von denen die allermeisten unnötig waren. Zwei Kunden haben danach den Lieferanten gewechselt. Ein Rückruf, der pauschal alle trifft, sieht nach fehlender Kontrolle aus, und in diesem Fall war er es auch.
Der Artikel sagt, was verkauft wurde, die Charge sagt, was geliefert wurde
Die Artikelnummer beschreibt ein Produkt. Die Charge beschreibt die Ware, die tatsächlich im Karton lag: eine Produktionsreihe mit eigenem Verfallsdatum und eigener Prüfdokumentation. Bei Medizinprodukten hängt die Seriennummer oder die UDI daran, bei Geräten die Garantie.
Automatisierungen bilden fast immer nur die erste Ebene ab, und dafür gibt es einen nachvollziehbaren Grund. Beim Bestellen ist die Charge noch unbekannt. Der Auftrag nennt Artikel und Menge, mehr kann er nicht nennen. Die Charge entsteht später, im Lager, beim Griff ins Regal.
Genau dort endet in den meisten Setups die Kette. Das Lagersystem weiß Bescheid. Das ERP kennt eine Auftragszeile, das CRM kennt einen Kunden, und die Automatisierung, die daraus Auftragsbestätigung, Rechnung und Versandmail baut, arbeitet mit der Auftragszeile. Fragen Sie einen Artikel ab, bekommen Sie in Sekunden eine Antwort. Fragen Sie eine Charge ab, bekommen Sie ein Telefonat mit dem Lager.
Wo die Charge unterwegs herausfällt
Ein GS1-Barcode auf dem Umkarton trägt vier Angaben: Artikelnummer, Charge, Verfallsdatum, Menge. Die Schnittstelle liest davon Artikelnummer und Menge, weil das die beiden Felder sind, die das Zielsystem verlangt. Die anderen beiden sind optional, und optional heißt im ersten Mapping: weg.
Manchmal fällt sie schon vorher heraus, beim Wareneingang. Jemand scannt die Palette, das Lagersystem legt Charge und Verfallsdatum an, und die Buchung ins ERP überträgt eine Summe: Artikel, Menge, Lieferscheinnummer. Was danach im Bestand steht, ist eine Zahl ohne Herkunft. Alles, was die Automatisierung später darauf aufbaut, erbt diese Lücke, und keine Prüfung am Warenausgang holt sie zurück.
Dann der Fall, den kein Datenmodell vorsieht. Selten reicht eine Charge für eine Bestellmenge, 80 Stück kommen aus 24-118, 40 aus 24-121. Vorgesehen ist ein Feld pro Position. Entweder gewinnt der letzte Scan, oder es entsteht ein Textfeld mit dem Inhalt "24-118, 24-121", das ein Mensch lesen kann und keine Abfrage.
Beim Verfallsdatum liegt es am Format. Auf dem Etikett steht 0926. Im System landet "0926", manchmal "09/26", je nach Scanner auch "26-09". Eine Regel wie "nicht ausliefern bei weniger als sechs Monaten Restlaufzeit" kann darauf nicht rechnen, deshalb wird sie gar nicht erst gebaut.
Und dann sind da noch die Retouren. Rücksendungen laufen fast überall über einen eigenen Prozess, der später gebaut wurde und dünner ist. Der Artikel geht zurück ins Lager, die Charge wird nicht erfasst, und ab diesem Moment liegt Ware im Bestand, deren Herkunft niemand mehr rekonstruieren kann.
Warum keine Testphase das zeigt
In der Abnahme fällt nichts davon auf, weil der Testfall der einfache Fall ist. Auftrag anlegen, eine Position von einem Lagerplatz kommissionieren, Lieferschein drucken. Eine Charge, ein Verfallsdatum, alles passt.
Die Fälle, die brechen, brauchen Zustände, die im Test niemand herstellt: einen Restbestand, der nicht reicht, eine Retoure aus einer alten Charge, einen Lieferanten, der mitten im Jahr auf eine neue Losgröße umgestellt hat. Den Rückruf testet ohnehin niemand, der klingt nach Katastrophe und nicht nach Anforderung.
Dazu kommt, dass die Kette dabei grün bleibt. Eine fehlende Charge erzeugt keinen Fehler, sondern ein leeres Feld, und leere Felder brechen keinen Lauf ab. Bemerkbar macht sich das erst, wenn jemand rückwärts fragt, und diese Frage kommt Monate nach der Inbetriebnahme.
Was das im Alltag kostet, auch ohne Rückruf
Der Rückruf ist der Fall, den alle nennen, und der seltenste. Die anderen laufen leiser.
Im Klinik- und Laboreinkauf ist eine Mindesthaltbarkeit von zwei Dritteln der Gesamtlaufzeit üblich, oft steht sie im Rahmenvertrag. Kennt die Automatisierung nur Bestände und keine Verfallsdaten, verschickt sie Ware, die formal in Ordnung und vertraglich eine Reklamation ist. Die Gutschrift kommt zwei Wochen später.
Der Bestand kann dabei stimmen und trotzdem falsch sein. 600 Stück auf Lager, sagt der Shop, sagt die Disposition, sagt die Nachbestellregel. Dass 420 davon in fünf Wochen ablaufen, sagt niemand, weil eine Summe keine Chargen kennt. Der Einkauf bestellt nicht nach, weil der Bestand hoch aussieht, und schreibt sechs Wochen später ab.
Ohne Verfallsdatum im Datensatz entscheidet außerdem der kürzeste Weg im Lager, welche Charge rausgeht. Die frische Ware liegt vorne, die alte wandert nach hinten und läuft ab. Nach Haltbarkeit auslagern kann nur, wer das Datum im System hat und nicht bloß auf dem Etikett.
Der Punkt, der am seltensten zur Sprache kommt, ist der auf der Kundenseite. Eine Klinik muss bei implantierbaren Produkten belegen, welche Charge bei welchem Patienten verwendet wurde. Kommt Ihr Lieferschein ohne maschinenlesbare Charge, tippt das dort jemand ab. Das ist ein Grund, den Lieferanten zu wechseln, und er taucht in keiner Verkaufsstatistik auf.
Wie wir das bauen
Die Charge gehört an die Lieferposition, nicht an den Auftrag. Der Auftrag bleibt, wie er ist, Artikel und Menge. Die Zuordnung entsteht beim Kommissionieren und hängt an der Lieferung. Das sind zwei Ebenen statt einer, und die untere ist die, die zählt.
Erfasst wird sie dort, wo sie entsteht, und das ist der Wareneingang. Wer die Charge erst am Warenausgang nachpflegen will, pflegt sie nicht, weil dort niemand Zeit hat und die Palette längst aufgelöst ist. Der Scan beim Einlagern kostet zwei Sekunden, die Rekonstruktion hinterher kostet ein Wochenende.
Mehrere Chargen je Position müssen abbildbar sein. Eine Lieferposition bekommt eine Liste aus Charge, Menge und Verfallsdatum. Kann das Zielsystem keine Liste, wird die Position beim Kommissionieren gesplittet. Ein Textfeld mit Komma darin löst nichts, es verschiebt die Arbeit auf den Tag des Rückrufs.
Das Verfallsdatum wird als Datum geführt, nicht als Zeichenkette. Das Format aus dem Barcode wird beim Scan normalisiert, ISO, ein Feld. Eine Angabe ohne Tag wie 0926 wird auf den letzten Tag des Monats gesetzt, so ist sie gemeint. Danach ist die Regel zur Restlaufzeit eine Zeile Logik statt eines Projekts.
Bei chargenpflichtigen Artikeln geht nichts ohne Charge raus. Das ist eine harte Prüfung vor dem Druck des Lieferscheins und kein Eintrag im Log. Der Artikelstamm sagt, ob ein Artikel chargenpflichtig ist. Fehlt die Charge, bleibt die Lieferung stehen und jemand bekommt eine Aufgabe zugewiesen.
Und die Rückverfolgung muss in beide Richtungen eine Abfrage sein: von der Charge zu allen Kunden, die sie bekommen haben, und vom Kunden zu allen Chargen, die bei ihm gelandet sind. Wer dafür telefonieren muss, hat einen Ordner und keine Rückverfolgbarkeit.
Die Prüfung dauert zehn Minuten
Nehmen Sie einen chargenpflichtigen Artikel und eine Lieferung aus dem letzten Quartal. Dann beantworten Sie drei Fragen, ohne im Lager anzurufen: Welche Charge ist rausgegangen? Welches Verfallsdatum hatte sie? Welche anderen Kunden haben aus derselben Charge etwas bekommen?
Wenn Sie für eine dieser Antworten einen gedruckten Lieferschein aus einem Ordner holen müssen, kennt Ihre Automatisierung Ihren Katalog, aber nicht Ihre Ware.