Datenaustausch mit dem ERP: warum Schichtzettel und Lieferscheine einen Tag zu spät ankommen

Der Datenaustausch mit dem ERP entscheidet, ob die Zahlen aus der Fertigung heute oder morgen im Büro stehen. Bei den meisten Betrieben, die uns anrufen, stehen sie morgen: Die Schicht schreibt in eine Tabelle, der Fahrer bringt den Lieferschein mit, und abends tippt jemand beides ab.

Warum die Zahlen aus der Halle einen Tag brauchen

Der Verzug entsteht selten im System. Er entsteht an der Stelle, an der ein Mensch etwas liest und an einer anderen Stelle wieder eingibt. Zwischen diesen beiden Stellen liegt eine Schicht, ein Feierabend oder ein Wochenende, und genau so lange ist der Bestand im System eine Erinnerung an gestern.

Die Folgen sind in jedem Betrieb dieselben. Der Einkauf disponiert auf Zahlen, die einen Tag alt sind. Die Reichweite eines knappen Rohstoffs kennt nur der Meister, und er kennt sie im Kopf. Wenn ein Wert fehlt, fällt das erst beim Monatsabschluss auf, und dann kann niemand mehr sagen, welche Schicht ihn nicht eingetragen hat. Fragt man nach, hört man: „Das steht in der Tabelle“ — und die Tabelle steht auf einem Rechner in der Halle.

Deshalb beginnt diese Arbeit nicht mit einer neuen Oberfläche für die Schicht, sondern mit einer nüchternen Frage: Welcher Wert entsteht wo, wer schreibt ihn auf, und welchen Weg müsste er nehmen, damit ihn niemand ein zweites Mal anfassen muss?

93 Lagerpositionen: Datenaustausch mit dem ERP als Abgleich, nicht als Formular

In einem Betrieb der Lebensmittelproduktion lagen Bestände und Materialverbrauch nur in einer von Hand gepflegten Tabelle. Im System war der Lagerbestand nirgends sichtbar, und die Summenformeln der Tabelle waren an mehreren Stellen fehlerhaft — das Blatt widersprach sich selbst, ohne dass es jemandem auffiel.

Wir haben die Tabelle nicht abgeschafft. Die Schicht schreibt weiter dort, wo sie immer geschrieben hat; geändert hat sich nur, was danach passiert. Ein einseitiger Abgleich alle 30 Minuten nimmt beide Tabellenblätter auf, normalisiert Zugang und Verbrauch, rechnet die Bestände aus den Bewegungen und meldet von sich aus, was nicht stimmen kann: negative Bestände, knappe Reichweite, nicht ausgefüllte Arbeitstage.

Seither stehen 93 Lagerpositionen und rund 1 100 Tagesbewegungen ohne einen einzigen Handeintrag im System. Der Bestand wird dabei nicht abgeschrieben, sondern aus den Bewegungen gerechnet — wer die Bewegung kennt, kann den Bestand jederzeit nachvollziehen, und ein falscher Wert lässt sich auf seine Zeile zurückführen.

Eine Grenze gehört zu diesem Aufbau dazu: Der Abgleich ist einseitig. Wir lesen aus der Tabelle und schreiben in die Datenbank, nicht zurück. Zwei Systeme, die beide dieselbe Zahl ändern dürfen, brauchen eine Regel für den Widerspruch, und diese Regel muss jemand fachlich verantworten. Solange sie nicht geschrieben ist, bleibt die Richtung eine.

Fotos von Lieferscheinen: was mit dem Papier passiert

Der zweite Weg ist der des Papiers. In einem Produktions- und Filialbetrieb lief die lebendigste Arbeitsgruppe über Fotos: Der Fahrer fotografierte den Lieferschein, die Werkstatt stellte das Bild in die Gruppe, und dort blieb es liegen. Das System bekam nur den Text mit. 296 von 1 022 Aufträgen hatten deshalb keinen Betrag, obwohl er auf einem Foto stand.

Heute läuft der Bilderstrom der Gruppe durch eine nächtliche Erkennung nach einem Lieferschein-Schema. Die Belegnummer wird mitgelesen und verbindet Produkt und Kassenbeleg, die erkannten Werte stehen im Auftrag neben ihrer Quelle. Ausgewertet sind auf diesem Weg 8 425 Nachrichten mit rund 5 790 Fotos, die vorher niemand gelesen hat.

Auch hier die ehrliche Einschränkung: Eine Erkennung liegt manchmal daneben, besonders bei einem geknickten, feuchten oder schräg fotografierten Beleg. Deshalb überschreibt sie nichts still. Jeder Wert trägt seine Quelle, der Verantwortliche sieht das Bild neben der Zahl und kann sie korrigieren. Eine Automatik, die man nicht überprüfen kann, ist keine Entlastung, sondern eine zweite Unsicherheit.

Datenaustausch mit dem ERP: so gehen wir vor

Wir beschreiben zuerst den Weg und bauen ihn dann. Welches Feld kommt woher, in welche Richtung fließt es, was gilt bei Widerspruch, und woran ist ein Lauf gescheitert — das steht als Leistungsbeschreibung fest, bevor die erste Zeile Code entsteht, und dieselbe Beschreibung ist später der Maßstab für die Abnahme des Ergebnisses. Den laufenden Austausch zwischen Halle, Lager und Kontor übernimmt danach unsere Prozessautomatisierung zwischen Halle, Lager und ERP; wo ein eigenes Programm am Arbeitsplatz nötig ist — ein Terminal an der Maschine, ein Scanner im Lager —, entsteht es in der Softwareentwicklung für Fertigung und Lager. An der Steuerung der Anlagen ändern wir dabei nichts: Wir lesen, was sie ausgibt.