Maßgeschneiderte Software für die Industrie – wann ein Standard-System für Fertigungssteuerung oder ERP keine sinnvolle Wahl mehr ist

Ein fertiges ERP-System kann eine sinnvolle Wahl sein, aber nur dann, wenn sich der tatsächliche Produktionsablauf ohne wesentliche Vereinfachungen abbilden lässt. Andernfalls bringt das System zwar Ordnung in die Erfassung, jedoch auf Kosten der Beherrschbarkeit des Prozesses. An diesem Punkt verliert die Frage nach dem Funktionskatalog an Bedeutung. Entscheidend ist, ob das Werk Produktion, Qualität und Instandhaltung weiterhin selbst steuert oder ob es beginnt, seine Arbeitsweise an die Grenzen des Werkzeugs anzupassen. Wenn kritische Entscheidungen, Ausnahmen und Sperren überwiegend außerhalb des Systems abgewickelt werden, ist individuelle Software für die Industrie keine Wunschlösung. Sie wird zum Mittel, um Datenkonsistenz, Verantwortlichkeit und operative Kontrolle zurückzugewinnen.

Nicht jede Produktion lässt sich seriös in ein Standardsystem pressen

Ein fertiges ERP-System funktioniert dort gut, wo der Prozess tatsächlich wiederholbar ist, Verantwortlichkeiten eindeutig sind und das Datenmodell das Bild des Werks nicht verfälscht. Unter solchen Bedingungen schafft Standardisierung Ordnung im Informationsfluss, begrenzt die Zahl lokaler Auslegungen und ermöglicht Entscheidungen auf Basis einer konsistenten Ereignisdokumentation. Das Problem beginnt früher als bei fehlenden Funktionen. Es entsteht dort, wo der reale Ablauf von Produktion, Qualität, Instandhaltung und Planung nicht mehr ohne Prozessverluste in die Logik des Systems passt.

Hier verläuft die Grenze zwischen sinnvoller Standardisierung und dem Verlust operativer Kontrolle. Wenn die Organisation beginnt, den eigenen Prozess zu umgehen, damit die Daten „im System stimmen“, dient die Informationsarchitektur nicht mehr der Produktion. Sie verformt sie. Manche Regeln lassen sich per Konfiguration oder Verfahrensanweisung sinnvoll vereinheitlichen. Es gibt jedoch auch technologische Abhängigkeiten, Kontrollpunkte und Verantwortungswege, die nicht verwässert werden dürfen, ohne die Produktqualität, die Prozesssicherheit oder die Nachvollziehbarkeit von Entscheidungen zu beeinträchtigen. Deshalb ist die Gegenüberstellung „Standard oder Eigenentwicklung“ meist falsch gestellt. Die treffendere Frage lautet: Welche Elemente des Prozesses sind gemeinsamer Standard, und welche bilden den Kern des Wettbewerbsvorteils des Werks, eine Risikoursache oder einen Bereich mit Compliance-Pflichten und müssen daher originalgetreu abgebildet werden.

In der Praxis sind nicht fehlende Module am teuersten, sondern die Umgehungslösungen, die sich stillschweigend zur täglichen Arbeitsweise entwickeln. Tabellen neben dem System, manuelles Übertragen von Daten zwischen Schicht und Büro, Notizen der Bediener, informelle Abstimmungen zu Ausnahmen und parallele Informationsflüsse sind keine kleine Unannehmlichkeit. Sie sind ein Signal dafür, dass das Modell der Prozesssteuerung Risse bekommt. Dann sollte man nicht die Zahl der Funktionen messen, sondern die Zahl manueller Punkte der Datenübergabe zwischen Produktion, Qualität, Instandhaltung und Planung, die Zahl kritischer Ausnahmen, die außerhalb des Systems bearbeitet werden, sowie den Anteil operativer Entscheidungen, die auf Daten beruhen, die nicht direkt aus dem Quellregister stammen. Wenn diese Kennzahlen steigen, liegt das Problem in der Regel nicht an einer schwachen Konfiguration, sondern an der falschen Annahme, der Prozess lasse sich ohne Kosten an das Werkzeug anpassen.

Besonders deutlich zeigt sich das in Werken, in denen der Ablauf eines Auftrags nicht nur von der technologischen Route abhängt, sondern auch vom tatsächlichen Zustand der Maschine, den Ergebnissen der Zwischenprüfung, Materialfreigaben, Einsatzchargen, Einstellparametern und Entscheidungen, die mehrere Bereiche gleichzeitig unter Zeitdruck treffen. Wenn ein Standardsystem diese Abhängigkeiten nicht in einer einzigen belastbaren Datenkette halten kann, zerfällt die Wahrheit über den Prozess auf mehrere Orte. Ein Teil bleibt im System, ein Teil an der Maschine, ein Teil in den Qualitätsdokumenten und ein Teil im Wissen der Menschen. Ein solcher Zustand erschwert die Abbildung des Produktionsprozesses, verkompliziert die Verantwortlichkeiten der Umsetzungsbeteiligten und erhöht das Projektrisiko an der Schnittstelle zur Automatisierung und zu Systemen mit Einfluss auf die Maschinensicherheit. Individuelle Software ist nicht dann sinnvoll, wenn ein Werk „etwas Eigenes“ möchte, sondern dann, wenn die Einheit von Prozess, Quelldaten und Entscheidungen dort erhalten bleiben muss, wo Vereinfachung einen realen Kontrollverlust bedeuten würde.

Aus Sicht von Compliance und operativer Aufsicht ist diese Unterscheidung grundlegend. Wenn zentrale Regeln und Kontrollpunkte ausschließlich in der Praxis des Teams existieren und nicht im System erzwungen oder zumindest eindeutig abgebildet werden, wird Verantwortlichkeit nur noch eingeschränkt nachweisbar. In manchen Branchen ist das vor allem ein Problem der Qualität und der Rekonstruierbarkeit des Chargenverlaufs, in anderen zusätzlich eine Frage sektoraler Anforderungen, der Rückverfolgbarkeit, des Änderungsmanagements oder der Abgrenzung der Verantwortlichkeiten zwischen Anlagenbetreiber, Integrator und Softwarelieferant. Deshalb sollte der Entscheidung, den Prozess dem System oder das System dem Prozess unterzuordnen, keine Funktionspräsentation vorausgehen, sondern eine ehrliche Analyse der Ausnahmen, wie sie etwa in einer Benutzeranforderungsspezifikation strukturiert werden kann. Erst dann wird sichtbar, welche davon organisatorisches Chaos sind und welche reale technologische, informationelle und sicherheitsbezogene Anforderungen widerspiegeln.

Die Kosten steigen dort, wo das System das tatsächliche Risiko nicht erkennt

Die höchsten Kosten einer Systemfehlanpassung entstehen nicht in einfachen Auftragsabläufen oder Tagesberichten, sondern an der Schnittstelle von Produktion, Qualität, Instandhaltung und Prozesssicherheit. Genau dort müssen Entscheidungen schnell getroffen, dokumentiert und auf einer vollständigen Kontextbasis gefällt werden: auf Grundlage des aktuellen Maschinenzustands, der Chargenparameter, der Interventionshistorie, des Status der Qualitätsfreigabe und der geltenden Sperren. Wenn ein Standard-Produktionsleitsystem oder ERP nur einen Teil dieses Bildes erfasst, beschränkt sich der Preis nicht auf mangelnden Bedienkomfort. Es entsteht operative Variabilität. Verschiedene Schichten treffen ähnliche Entscheidungen auf Basis unterschiedlicher Daten, Ausnahmen werden nach Ermessen behandelt, und die Verantwortung verwischt zwischen System, Verfahren und gelebter Praxis in der Produktion.

Das zentrale Problem beginnt, wenn das System die tatsächliche Abfolge der Tätigkeiten, die Sperrbedingungen, die Versionierung technologischer Parameter oder die Verantwortlichkeit für die Freigabe einer Abweichung nicht abbildet. In der Dokumentation kann dann alles korrekt aussehen, obwohl die Ausführung anders verlief. Es entsteht eine Lücke zwischen dem Ereignis und seiner digitalen Spur. Daraus ergeben sich sehr konkrete Projektentscheidungen: ob kritische Prozesssperren systemseitig oder nur prozedural wirken sollen; ob Maschinendaten als operativer Nachweis oder lediglich als Hilfsmaterial dienen, was sich bereits im Factory Acceptance Test sauber prüfen lässt; und ob Ausnahmen über einen definierten Entscheidungsworkflow abgewickelt oder dem Ermessen überlassen werden. Wenn ein Werk auf manuelle Nachträge, zusätzliche Tabellen oder Schnittstellen angewiesen ist, die ständige menschliche Eingriffe erfordern, darf die Datenzuverlässigkeit nicht daran gemessen werden, ob sich ein Abschlussbericht erzeugen lässt, sondern daran, ob sich der Verlauf einer einzelnen Nichtkonformität, Reklamation oder eines Linienstillstands eindeutig und ohne Streit rekonstruieren lässt.

Ein besonderes Risiko zeigt sich in Werken mit umfangreichem Maschinenpark, in denen das System mit der Automatisierungstechnik, Bedienplätzen und Mess- und Prüfgeräten zusammenarbeiten muss. Wenn die Geräteintegration nur teilweise umgesetzt ist, Prozessdaten uneinheitlich erfasst werden und die Änderungshistorie zwischen Steuerung, Panel, Produktionsdatenbank und Servicenotizen verteilt ist, werden Chargenverfolgung und Produktgenealogie zu bedingten Größen. Ähnlich verhält es sich beim Management technologischer Änderungen. Eine Änderung der Rezeptur, des Toleranzschwellenwerts oder der Umrüstlogik kann formal freigegeben sein, doch ohne konsistente Versionierung und Archivierung lässt sich später nicht nachweisen, welche Konfiguration zum Zeitpunkt des Ereignisses tatsächlich galt. Das ist kein Problem architektonischer Ästhetik, sondern der Reproduzierbarkeit, der Ermittlung von Grundursachen und der Abgrenzung von Verantwortlichkeiten zwischen Produktion, Instandhaltung, Qualität und Integrationsdienstleistern.

Die Kosten einer solchen Fehlanpassung sind im Einführungsbudget nur selten sichtbar. Sie treten später in Form von Diagnose-Stillständen, wachsendem manuellem Aufwand, Reklamationen, Streitigkeiten über die Ursache eines Ereignisses und dem Verlust der Möglichkeit auf, den Prozessverlauf eindeutig nachzuvollziehen. Deshalb reicht es bei der Bewertung einer Lösung nicht aus zu fragen, ob das System „die Produktion unterstützt“. Zu prüfen ist, wie viele Schnittstellen manuelle Korrekturen erfordern, wie viele kritische Parameter nicht automatisch versioniert oder konsistent archiviert werden und wie viel Zeit die Rekonstruktion eines einzelnen operativen Vorfalls beansprucht. Wenn die Antwort lautet: langwierig, inkonsistent und unter Einbeziehung mehrerer unabhängiger Quellen, dann geht es nicht um Benutzerkomfort, sondern um die Beherrschbarkeit des Risikos. Genau hier kann eine eigene Lösung oder zumindest eine dedizierte Schicht über dem Standardsystem gerechtfertigt sein: nicht um die Vergangenheit besser zu berichten, sondern um sichere operative Entscheidungen in dem Moment zu unterstützen, in dem das Werk unter Zeit- und Verantwortungsdruck arbeitet.

Aus Sicht der Compliance bedeutet das noch etwas anderes. Überall dort, wo Software den Ablauf von Entscheidungen beeinflusst, die für Qualität, Rückverfolgbarkeit oder Prozesssicherheit relevant sind, sollte der Umfang kritischer Funktionen aus einer realen Risikobewertung abgeleitet werden und nicht aus dem Katalog von Standardmodulen. Das betrifft insbesondere die Integration mit Maschinen, den Umgang mit Ausnahmezuständen sowie die Stellen, an denen das System eine bestimmte Reihenfolge von Tätigkeiten erzwingen oder den Übergang zur nächsten Stufe sperren soll. In solchen Bereichen ist es sinnvoll, reine Erfassungsfunktionen von denjenigen zu trennen, die Teil der operativen Kontrolle werden und eine belastbarere Projektbegründung erfordern, auch im Kontext der Maschinensicherheit und der Verantwortung des Integrators, wie sie bei der Auswahl des Automatisierungsintegrators vorab geklärt werden sollte.

Zuerst das Entscheidungsdesign, dann der Code

Eine sinnvolle Entscheidung über die Weiterentwicklung eines Systems im Werk beginnt nicht mit einer Funktionsliste, sondern mit einer Landkarte der operativen Entscheidungen, die die Software unterstützen oder erzwingen soll. Es muss geklärt werden, wer die Entscheidung trifft, auf Basis welcher Daten, in welchem Zeitfenster und mit welchen Folgen für Produktion, Qualität, Rückverfolgbarkeit oder Prozesssicherheit. Erst vor diesem Hintergrund wird sichtbar, ob ein Standard-Produktionsleitsystem oder ERP den Kern des Problems erfasst oder lediglich die Dokumentation im Nachhinein ordnet. Wenn nicht die bloße Erfassung eines Ereignisses kritisch ist, sondern die Sperre für den Start des nächsten Arbeitsschritts, die Bedingung für die Chargenfreigabe, die Bestätigung der Konformität von Maschineneinstellungen oder die Behandlung einer Abweichung, dann lautet die Frage nicht „ob das System diese Funktion hat“, sondern „ob es die richtige Entscheidung zum richtigen Zeitpunkt erzwingen kann“.

Diese Denkweise schafft auch Klarheit bei der Gestaltung der Architektur. In der Praxis bewährt sich meist ein hybrides Modell. Ein Standard-ERP oder ein System zur Produktionssteuerung sollte dort bleiben, wo der Prozess gemeinsam, wiederholbar und durch ein ausgereiftes Datenmodell gut beschrieben ist: in der Planung, der Produktionsabrechnung, der Lagerwirtschaft sowie der grundlegenden Erfassung von Aufträgen und Chargen. Eine dedizierte Schicht ist dann sinnvoll, wenn sie die für den konkreten Standort kritische Logik übernimmt: die Integration mit Maschinen, die Validierung von Ereignissen aus mehreren Quellen, die Behandlung von Ausnahmen, Freigabe-Workflows, den Audit-Trail sowie die Zuordnung von Entscheidungen zu einer konkreten Charge, Maschine und verantwortlichen Person. Voraussetzung für den Erfolg ist jedoch, die Verantwortungsgrenzen vorab festzulegen. Das Team muss klären, was zum technologischen Prozess gehört und auf der Seite von Automatisierung oder Steuerung verbleibt, was in den Zuständigkeitsbereich von ERP oder Produktionssteuerung fällt, was die Integrationsschicht übernimmt und was weiterhin in organisatorischen Verfahren geregelt werden muss. Gerade dafür lohnt sich ein Blick auf die Entwicklung einer Fabrik und die IT-/OT-Architektur, wenn provisorische Verbindungen schleichend zu dauerhaften Abhängigkeiten werden.

Ohne eine solche Aufteilung entsteht teure Improvisation. Dieselbe Bedingung wird dann an mehreren Stellen hinterlegt, Ausnahmen werden manuell entschieden, und nach einigen Monaten kann niemand mehr eindeutig benennen, welches System für eine sperrende oder freigebende Entscheidung im Prozess verantwortlich ist. Ein gutes Individualprojekt besteht daher nicht darin, eine fertige Lösung im kleineren Maßstab zu duplizieren. Seine Aufgabe ist es, eine konkrete Entscheidungslücke zu schließen. Deshalb lohnt es sich, bereits in der Projektphase die Liste der kritischen Entscheidungen zu erfassen, die heute keine systemseitige Unterstützung oder Durchsetzung haben, und sie anschließend der Zahl der Prozessausnahmen gegenüberzustellen, die die Lösung ab dem ersten Go-live abdecken soll. Das ist wichtiger als eine umfangreiche Spezifikation von Bildschirmmasken und passt zu den Grundsätzen von effektivem Projektmanagement.

Ein praktisches Beispiel ist einfach. Ein Standardsystem kann die Produktion, den Materialverbrauch und die Lagerzugänge korrekt verbuchen, ohne dabei spezifische Qualitätssperren im Zusammenhang mit der bedingten Freigabe einer Charge abzudecken. Eine Charge kann formal produziert und gebucht sein und dennoch nicht in den nächsten Schritt übergehen dürfen, solange bestimmte Prüfergebnisse, der Zustand der Linienumrüstung oder die Beseitigung einer Abweichung aus dem vorherigen Arbeitsschritt nicht bestätigt sind. Wenn eine solche Bedingung heute per Telefon, Tabelle oder Unterschrift auf einem Ausdruck überwacht wird, ist das kein ästhetisches Problem des Prozesses, sondern eine Lücke in der Verantwortungssteuerung. In einer solchen Situation ist ein Umbau des gesamten ERP oder der Produktionssteuerung in der Regel nicht begründet. Ausreichend ist eine dedizierte Schicht, die Daten aus Maschinen und Quellsystemen übernimmt, die Vollständigkeit der Ereignisse prüft, den richtigen Freigabeweg startet und an das übergeordnete System einen eindeutigen Chargenstatus übergibt. Der Standard bleibt Standard, und die kritische Logik wird dort abgebildet, wo sie sich tatsächlich steuern und pflegen lässt.

Wenn im Werk noch keine Kostendaten vorliegen, muss man sie nicht schätzen. Es reicht, zunächst zu messen, wie viel Zeit pro Monat manuelle Umgehungslösungen, zusätzliche Abstimmungen, Chargenkorrekturen und die Prüfung von Abweichungen zwischen System und tatsächlichem Prozesszustand beanspruchen. Auf dieser Grundlage lässt sich eine begründete dedizierte Schicht von einem Projekt unterscheiden, das nur vorsorglich entwickelt wird. Das erleichtert auch die richtige Rollenverteilung auf der Business-Seite. Über den Umfang der im System abgebildeten Logik sollten nicht allein die IT-Abteilung oder der Integrator entscheiden, sondern gemeinsam Produktion, Qualität, Instandhaltung, die für die Digitalisierung verantwortlichen Personen sowie – wo dies relevant ist – die Zusammenarbeit zwischen Integrator, Softwarehaus und Instandhaltung sowie Maschinensicherheit und operative Konformität. Gerade die Klärung der Verantwortungsgrenzen zwischen Werk, Integrator und Softwarelieferant entscheidet hier oft über den Projekterfolg.

Aus Sicht der Projektverantwortung hat das noch eine weitere Konsequenz. Je stärker Software in Prozessübergänge, Operationssperren, die Korrektheit von Handlungssequenzen oder in Daten eingreift, die direkt von der Maschine stammen, desto weniger lässt sie sich als neutrales IT-Add-on behandeln. In diesem Bereich braucht es klare Projektannahmen, eine Beschreibung der Einsatz- und Wartungsgrenzen, Regeln für das Änderungsmanagement sowie einen nachvollziehbaren Nachweis darüber, wer die kritische Logik auf welcher Grundlage freigegeben hat. Deshalb sollte vor der ersten Codezeile nicht nur die funktionale Anforderung freigegeben werden, sondern vor allem das Entscheidungsdesign: was das System erzwingen soll, was es nicht zulassen darf und an welcher Stelle der Mensch die letzte verantwortliche Instanz bleibt.

Konformität ist das Ergebnis eines guten Projekts, nicht Dekoration nach der Implementierung

In einem Industriebetrieb ist Software kein neutrales Add-on zum Prozess, sondern Teil seiner Ausführung. Sie kann die Reihenfolge von Tätigkeiten festlegen, den Übergang in die nächste Stufe blockieren, die Vollständigkeit von Daten erzwingen, den Freigabeweg steuern und darüber entscheiden, ob sich nach einem Ereignis der Entscheidungsverlauf und die Verantwortung nachvollziehen lassen. Deshalb beginnt Konformität nicht damit, am Ende der Implementierung formale Anforderungen nachzutragen. Sie beginnt im Projekt, in dem bewusst festgelegt wird, welche Entscheidungen das System selbst trifft, welche es nur unterstützt, welche Daten als verbindlich gelten und wer Eigentümer von Regeln, Ausnahmen und Änderungen ist.

Wenn diese Ordnung nicht bereits in der Architektur der Lösung angelegt wird, bleibt die spätere Berufung auf Qualitätsanforderungen, Prozesssicherheit oder Dokumentationspflichten reine Formsache. Das ist besonders dann relevant, wenn das System Entscheidungen beeinflusst, die für die Produktqualität, die Prozesssicherheit oder die Zusammenarbeit mit Maschinen und Anlagen wesentlich sind. In diesem Zusammenhang sind Konformitätsanforderungen operativ zu verstehen: als Erfordernis einer konsistenten Arbeitsweise, von Nachvollziehbarkeit, Änderungsbeherrschung und der Eignung der Lösung für den tatsächlichen Einsatz. Es geht nicht nur darum, dass eine Funktion verfügbar ist, sondern dass sich belegen lässt, warum sie genau so arbeitet, wer ihre Logik freigegeben hat und wie die Auswirkungen von Änderungen bewertet werden.

Die meisten Probleme zeigen sich in der Regel nicht bei der Inbetriebnahme, sondern erst nach einigen Monaten im Betrieb. Das Werk führt eine neue Produktionsvariante ein, ändert die Abnahmekriterien, bindet einen weiteren Arbeitsplatz an oder verlagert einen Teil der Verantwortung vom Bediener auf das System. Wurde zuvor nicht festgelegt, welche Klassen von Entscheidungen und Aufzeichnungen einen Audit-Trail hinterlassen müssen, entsteht schnell Streit darüber, wessen Änderung die Qualität, einen Stillstand oder eine fehlerhafte Reaktion des Systems beeinflusst hat. Erst dann wird der Unterschied zwischen einer funktionierenden und einer beherrschbaren Lösung sichtbar. Bei Letzterer ist von vornherein klar, welche Elemente der Logik einen formalen Freigabeprozess erfordern, wer die Referenzdaten überwacht, wer die Integration mit der Automatisierung betreut und ob die Projektdokumentation für Audit, Instandhaltung sowie die sichere Übernahme des Systems durch einen anderen Auftragnehmer ausreicht. Dabei helfen von Beginn an klar definierte Anforderungen, wie sie etwa in einer URS beschrieben werden.

• welche Entscheidungen das System im Bereich Qualität, Sicherheit und Zusammenarbeit mit der Maschine trifft oder mitprägt,
• welche Ereignisse, Änderungen und Freigaben einen reproduzierbaren Nachweis hinterlassen müssen,
• wer Eigentümer der Geschäftsregeln, Daten und Ausnahmen ist und wer deren Änderung freigibt.

Erst nach einer solchen Strukturierung ist es sinnvoll, das Projekt auf die rechtlichen und normativen Anforderungen zu beziehen, die für das konkrete Werk, das Produkt, die Branche und die Art der Integration mit Maschinen oder Anlagen gelten. Unter polnischen und europäischen Rahmenbedingungen lautet die Frage nicht nur, ob die Lösung funktioniert, sondern ob die Organisation nachweisen kann, warum sie auf diese Weise funktioniert, auf welcher Grundlage die Regeln freigegeben wurden und wie Änderungen gesteuert werden, ohne die Nachvollziehbarkeit zu schwächen. Der Umfang dieser Analyse hängt immer von der Anwendung ab: Ein Berichtssystem wird anders bewertet als eine Logik, die den Prozessablauf beeinflusst, und wiederum anders als eine Integration, die die Funktion einer Maschine, die Risikobeurteilung oder den Verantwortungsbereich des Integrators berührt. Je nach Maschinenbezug kann dabei auch der Rahmen der CE-Kennzeichnung relevant werden.

Die Schlussfolgerung ist einfach. Individuell entwickelte Software ist dann sinnvoll, wenn sie Verantwortlichkeiten ordnet und Risiken genau dort begrenzt, wo ein fertiges Fertigungsleitsystem oder ERP nur mit kostspieligen Kompromissen bei der Prozesslogik, der Änderungsüberwachung oder der Nachvollziehbarkeit von Handlungen einsetzbar wäre. Es geht also nicht darum, alles von Grund auf neu zu entwickeln, sondern Standard und kritische Logik so zu trennen, dass das System den tatsächlichen Prozess im Werk unterstützt, anstatt ihn auf Kosten von Qualität, Sicherheit und Nachvollziehbarkeit zu vereinfachen.