ERP-Anbindung: Was wir auf dem Weg von der Fertigung ins ERP gelernt haben

Anfragen zur ERP-Anbindung beginnen meist harmlos: „Die Stückzahlen sollen im ERP landen, das reicht.“ Am Ende der Besprechung ist die Liste länger: dazu noch Stillstandsgründe, Ausschuss, ein Schichtbericht, und auf dem Handy wollen wir es auch sehen. Das ist nichts Schlechtes; sobald ein Werk seine Daten sieht, will es mehr davon, das ist ganz natürlich. Das Problem entsteht, wenn diese Wünsche mitten in ein Projekt geschoben werden, dessen Preis und Zeitplan bereits feststehen.

Was folgt, haben wir in Projekten gelernt, in denen wir Daten aus der Fertigung ins ERP gebracht haben. Ob im Projekt, in dem wir den Lackverbrauch grammgenau auf den Fertigungsauftrag buchen, oder in den anderen: Wir haben jedes Mal dieselben Fragen gestellt.

Die ersten Wünsche sind immer überschaubar; dann kommt „das hier noch, und das auch“. Wir versuchen nicht, das zu verhindern, wir halten es fest. Im Pflichtenheft muss für jeden Datenpunkt einzeln stehen, aus welcher Quelle er kommt, in welchem Takt und in welches Feld des ERP er geschrieben wird. Und genauso, was nicht zum Umfang gehört. Wir beginnen erst vor Ort, wenn klar geplant und vereinbart ist, was umsetzbar ist.

Das ERP ist meist ein System im lokalen Netz des Werks, und die IT des Werks schickt jede Software, die es berührt, durch festgelegte Sicherheitsprozesse. Deshalb führen wir die erste technische Besprechung einer Anbindung nicht mit dem ERP-Berater, sondern mit der IT: Auf welchen Server, über welchen Port, mit welchem Benutzer und mit welchen Rechten greifen wir zu?

Die Übertragung an ein Dashboard oder ins ERP läuft meist über eine REST-API innerhalb desselben lokalen Netzes; die Berechtigung erteilt die IT. In manchen Konzernen sind die Sicherheitsvorgaben sehr streng: gesperrte Ports, eingeschränkte Benutzerrechte, ein Virenscanner, der Dienste stillschweigend blockiert, Updates, die auf Freigabe warten. Schon die Frage, ob der eingesetzte Rechner unter Linux oder Windows läuft, bringt jeweils eigene Probleme mit sich. Bevor wir vor Ort beginnen, arbeiten wir mit der IT diese Liste durch:

• Welcher Server, welcher Port, welcher Weg: REST-API, Datenbank oder Dateiübertragung?
• Wer verwaltet den Dienstbenutzer, mit welchen Rechten; wann und von wem wird sein Passwort erneuert?
• Auf welchem Rechner läuft die Middleware: Linux, Windows oder eine virtuelle Maschine?
• Beeinträchtigen Virenscanner, Firewall oder Update-Richtlinie den Dienst?
• Gibt es eine Testumgebung, oder schreiben wir direkt ins produktive ERP?
• Gibt es Fernzugriff für Installation und Wartung, oder geschieht alles vor Ort?

Daten von einer Maschine im Werk abzugreifen ist ein Projekt für sich, unabhängig vom Schreiben ins ERP, und wird separat kalkuliert. Liegen die Daten in der Steuerung der Maschine vor, werden sie über die SPS gelesen; andernfalls kommen aufgabenspezifische Sensoren hinzu: Wägezelle, Zähler, Drehgeber, Strom, Temperatur. Jeder Sensor hat sein eigenes Kommunikationsprotokoll, und eine SPS oder ein Industrie-PC sammelt diese Daten. Die richtige Hardware auszuwählen ist der Kern der Sache: Ein unnötig genauer Sensor frisst das Budget, ein zu ungenauer die Daten.

Das ist die wichtigste Frage überhaupt. Holen wir nur Daten ab, ist die Software ein Beobachter neben der Maschine; fällt sie aus, läuft die Produktion weiter. Greift die Software dagegen in die Arbeitslogik der Maschine ein (sie sendet Rezepturen, startet Fertigungsaufträge, gibt eine Verriegelung frei), ist sie Teil der Produktion. Dann bekommen Fehlerszenarien, Sicherheit und Testumfang eine ganz andere Größenordnung.

Beides gehört nicht in dasselbe Angebot. Wir fragen das im ersten Gespräch direkt ab und schreiben die Antwort ins Pflichtenheft.

Bürosoftware wird nach Feierabend geschlossen; Software in der Fertigung hat diesen Luxus nicht. Die Geräteverbindung reißt ab, der ERP-Server geht in die Wartung, ein Switch startet neu, ein Sensor liefert einen unsinnigen Wert. All diese Szenarien müssen von Anfang an durchdacht sein: Daten werden ohne Verlust gepuffert, nach der Wiederverbindung der Reihe nach gesendet, und kein Datensatz wird doppelt geschrieben.

Wenn etwas schiefgeht, muss auch die Meldung so ankommen, wie das Unternehmen es will: bei den einen per E-Mail, bei anderen per SMS, bei wieder anderen als rote Zeile im Dashboard. „Ein Fehler ist aufgetreten, wir haben ihn ins Log geschrieben“ bedeutet in der Fertigung gar nichts; dieses Log liest niemand.

Nicht jedes Unternehmen will dieselbe Anbindung. Die einen wollen nur den Monatsbericht nicht mehr von Hand eintippen, andere die Produktion in Echtzeit verfolgen, wieder andere die Maschine über den Fertigungsauftrag steuern. Auf der Softwareseite gibt es viele Optionen; die Lösung richtet sich nach dem Kunden. Wir wägen zuerst die grundsätzliche Anforderung des Unternehmens ab und wählen danach die Architektur. Eine Anbindung, die klein anfängt und wächst, ist fast immer gesünder als eine, die vom ersten Tag an alles können soll.