Die Entwicklung einer Fabrik und die IT-/OT-Architektur – warum sich provisorische Integrationen nach einigen Jahren rächen?

Warum dieses Thema heute relevant ist

Die Weiterentwicklung einer Fabrik besteht immer seltener darin, einfach nur eine einzelne Maschine hinzuzufügen oder eine weitere Linie isoliert in Betrieb zu nehmen. In der Regel bedeutet sie den Ausbau einer Umgebung, in der Produktionssysteme, Instandhaltung, Qualität, Planung, Lager und Management-Reporting Daten austauschen müssen und sich gegenseitig auf die Verfügbarkeit des Prozesses auswirken. In einem solchen Gefüge ist die IT/OT-Architektur keine technische Frage mehr, die man „später klärt“, sondern eine Projektentscheidung mit finanziellen und organisatorischen Folgen. Provisorische Integrationen funktionieren in der Anlaufphase, weil sie ein akutes Problem lösen: Sie binden eine neue Maschine schnell an, exportieren einige Signale in einen Bericht oder umgehen die Grenzen einer älteren Steuerung. Nach einigen Jahren rächt sich das, wenn der Betrieb die Leistung steigern, neue Compliance-Anforderungen erfüllen oder die Arbeitsweise der Anlage sicher ändern will. Dann zeigt sich, dass nicht ein einzelnes Kabel oder Skript das Problem ist, sondern das Fehlen konsistenter Regeln für Kommunikation, Verantwortlichkeiten und die Trennung von Funktionen.

Der größte Fehler besteht darin, solche Lösungen als kostenneutral zu betrachten. Sie verschieben die Kosten nur in die Zukunft – und meist genau in den ungünstigsten Moment: bei einer Erweiterung, einem Audit, einem Vorfall oder einem Lieferantenwechsel. Aus Projektsicht führt das nicht nur zu höheren Kosten für die Umsetzung der nächsten Ausbaustufe, sondern auch zum Verlust an Planbarkeit. Das Team weiß nicht mehr, welche Abhängigkeiten für die Produktionskontinuität kritisch sind, wo die Verantwortung des Integrators endet und wo die Verantwortung des Anlagenbetreibers beginnt, und auch nicht, welche Änderungen eine erneute Risikobeurteilung erfordern. In der Praxis beginnt genau hier der Bereich der versteckten Kosten fehlerhafter Projektentscheidungen: zusätzliche Stillstände, kurzfristige Serviceeinsätze, wiederholte Abnahmen, Schwierigkeiten bei der Dokumentation von Änderungen und Streitigkeiten über den Umfang der Gewährleistung. Wenn die Architektur nicht als bewusstes Modell der Fabrikentwicklung beschrieben wurde, ist jede weitere Ausbaustufe mit technischer und organisatorischer Schuld belastet.

Ein guter Praxistest ist nicht die Frage, ob die Integration „funktioniert“, sondern ob sie sich nach zwei oder drei weiteren Investitionsstufen sicher und planbar ändern lässt. Wenn eine neue Linie an mehreren Stellen ein manuelles Signal-Mapping erfordert, das Wissen über die Verbindungen auf verschiedene Lieferanten verteilt ist und die vollständige Datenkette nur durch die Analyse von Steuerungscode, Zwischendatenbanken und nicht dokumentierten Diensten nachvollzogen werden kann, befindet sich das Projekt bereits auf einem Pfad mit erhöhtem Risiko. Sinnvoll ist eine Bewertung anhand von drei messbaren Kriterien: der Zeit, die für eine kontrollierte Änderung benötigt wird, der Möglichkeit, für jeden Datenaustausch eindeutig einen Verantwortlichen zu benennen, sowie der Fähigkeit, die Auswirkungen eines Ausfalls oder einer Änderung auf Produktion und Sicherheit nachzuvollziehen. Wenn diese drei Punkte nicht greifbar sind, betrifft das Problem nicht den Komfort des Teams, sondern die Steuerbarkeit des gesamten Vorhabens.

Ein typisches Beispiel aus der Praxis: Ein Werk nimmt einen neuen Produktionsbereich in Betrieb und bindet Prozessdaten für einen schnellen Start über Zwischenlösungen an Geschäftssysteme an, die außerhalb der Zielarchitektur entstanden sind. Eine Zeit lang wirkt alles korrekt, weil der Datenfluss für Reporting und laufende Überwachung ausreicht. Das Problem zeigt sich erst bei weiterer Automatisierung, bei der Integration mit der Instandhaltung oder bei einer Änderung der Maschinenlogik. Dann wirkt sich eine einzelne Änderung in der operativen Ebene auf Berichte, Alarme, Rezepte oder den Fernzugriff aus, und die Abhängigkeiten sind nicht mehr offensichtlich. Wenn die Lösung zusätzlich in Funktionen eingreift, die mit Stopp, Energieabschaltung oder der Verhinderung eines Wiederanlaufs zusammenhängen, ist das Thema nicht mehr nur eine IT-Frage. Es fällt dann in den Bereich der funktionalen Sicherheit und erfordert eine gesonderte Analyse, einschließlich der Prüfung, ob die Annahmen zum Schutz vor unerwartetem Anlauf nicht verletzt wurden. An dieser Stelle berührt die IT/OT-Architektur unmittelbar die Risikobeurteilung im Projekt zur Fabrikentwicklung sowie Entscheidungen, die später auch den Umfang der Konformitätsbewertung und der technischen Dokumentation beeinflussen.

Deshalb muss dieses Thema jetzt entschieden werden und nicht erst nach Abschluss der Inbetriebnahme. Nicht weil jede Integration von Anfang an umfassend ausgelegt sein muss, sondern weil bereits zu Beginn zwischen einer temporären Lösung und einer Lösung unterschieden werden muss, die Teil der dauerhaften Architektur des Werks werden soll. Diese Unterscheidung muss sich im Projekt niederschlagen: durch einen eigenen Entscheidungsverantwortlichen, Bedingungen für die Rücknahme der Umgehungslösung, Dokumentationsanforderungen und Kriterien für eine erneute Bewertung bei Erweiterungen. Wenn das Werk weitere Investitionsstufen, die Modernisierung von Maschinen oder die Vorbereitung auf eine Konformitätsbewertung plant, erhöht das Fehlen einer solchen Unterscheidung nahezu immer die Änderungskosten und erweitert den Verantwortungsumfang auf Seiten des Investors. Genau deshalb ist die IT/OT-Architektur heute kein Zusatz zum Projekt mehr, sondern eine der Voraussetzungen, um Kosten, Terminplan und Risiko unter Kontrolle zu halten.

Wo Kosten oder Risiken am häufigsten steigen

Die größten Kosten bei der Weiterentwicklung einer Fabrik entstehen meist nicht durch die Schnittstellen zwischen IT und OT selbst, sondern durch die Folgen von Entscheidungen, die „nur vorübergehend“ getroffen wurden und nach einigen Jahren faktisch zur dauerhaften Architektur werden. Provisorische Integrationen rächen sich dann nicht deshalb, weil sie technisch unvollkommen waren, sondern weil niemand ihre Grenzen festgelegt hat: Wer ist für Änderungen verantwortlich, welche Daten sind führend, wie lässt sich die Konfiguration nach einem Ausfall wiederherstellen und zu welchem Zeitpunkt muss die Behelfslösung entfernt werden. In der Praxis steigen die Kosten dort, wo eine temporäre Lösung ohne formale Entscheidung in Instandhaltung, Produktion, Qualität oder Management-Reporting übernommen wird und damit faktisch zu einem kritischen Element wird. Für das Projekt bedeutet das später Streit über Budget und Umfang, für die Organisation zudem eine Verwischung der Verantwortlichkeiten: Ein Ausfall wirkt wie ein technisches Problem, obwohl seine Ursache eine nicht abgeschlossene Architekturentscheidung war. Ein hilfreiches Bewertungskriterium ist hier eine einfache Frage: Lässt sich nach dem Ausbau des Werks ein Prozesseigner, ein Dateneigner und ein Verfahren für sichere Änderungen benennen, ohne „die einzige Person, die weiß, wie das funktioniert“ einbeziehen zu müssen? Wenn nicht, ist das Risiko bereits im Projekt angelegt.

Ein zweiter Bereich mit steigenden Kosten ist die fehlende Trennung zwischen der Steuerungsebene und der Ebene des geschäftsbezogenen Datenaustauschs. In der ersten Investitionsphase wirkt eine solche Abkürzung oft verlockend: Derselbe Server vermittelt die Kommunikation mit der Maschine, archiviert Daten, speist den Bericht und ermöglicht den Fernzugriff für den Service. Bei einer einzelnen Linie funktioniert das scheinbar korrekt, doch mit jeder weiteren Ausbaustufe wirkt sich jede Änderung für einen Zweck auch auf die übrigen aus. Ein durch das Unternehmenssystem erzwungenes Update kann die Produktionskontinuität beeinträchtigen, und der Bedarf an schnellerem Reporting kann Eingriffe in die Konfiguration von Geräten nach sich ziehen, die zuvor stabil gearbeitet haben. Dann bestehen die versteckten Kosten fehlerhafter Projektentscheidungen nicht nur im zusätzlichen Kauf von Hardware oder in Leistungen des Integrators. Deutlich schwerer wiegen die Kosten für Stillstände, erneute Tests, Nachtarbeit während der Implementierung sowie die Notwendigkeit, Wissen zu rekonstruieren, das nirgends dokumentiert wurde. Aus Sicht des Projektmanagements ist das vernünftige Minimum die Prüfung, ob ein Ausfall oder eine Änderung im IT-Teil die operative Funktion der Maschine oder Linie stillsetzen kann. Wenn die Antwort ja lautet, muss die Architektur korrigiert werden – unabhängig davon, dass sie „im Moment funktioniert“.

Ein typisches Beispiel zeigt sich bei der Anbindung neuer Maschinen an die bestehende Infrastruktur des Werks. Der Lieferant nimmt die Anlage schnell in Betrieb, weil Abnahme und Produktionsstart anstehen, und realisiert die Kommunikation mit den Werksystemen daher über einen zusätzlichen Rechner, ein Skript zum Dateiexport oder eine manuell geänderte Signalzuordnung. Nach einem Jahr kommt die nächste Maschine hinzu, nach zwei Jahren ändert sich das übergeordnete System, und nach drei Jahren stellt sich heraus, dass niemand mehr eindeutig beschreiben kann, welche Meldungen für den Prozess kritisch sind, welche nur dem Reporting dienen und welche für Diagnose oder Chargenrückverfolgbarkeit relevant sind. An diesem Punkt geht das Thema bereits teilweise in den Bereich der Erstellung von Betriebsanleitungen für Maschinen über, denn wenn Bediener, Instandhaltung oder Service keine dokumentierten Regeln für den Umgang mit Kommunikationsausfall, manuellen Umgehungen oder der Wiederherstellung von Parametern nach dem Austausch einer Komponente haben, ist das Problem nicht mehr ausschließlich informativer Natur. Es wird zu einem Bestandteil der Organisation eines sicheren Betriebs und der späteren Verantwortung für die Art der Nutzung sowie für Änderungen.

Erst in diesem Stadium wird sichtbar, warum das Thema auch bei der Konformitätsbewertung, der technischen Dokumentation und der Budgetierung von Änderungen wiederkehrt. Wenn die Integration Funktionen der Maschine, die Logik von Verriegelungen, die Art der Zustandsbestätigung oder die dem Benutzer übermittelten Informationen beeinflusst, kann eine erneute Risikobeurteilung erforderlich sein sowie die Prüfung, ob die Dokumentation noch der tatsächlichen Lösung entspricht. Der Umfang dieser Bewertung hängt von der Art der Änderung ab und lässt sich daher nicht seriös mit einem einzigen universellen Satz festlegen. Gerade deshalb sind Provisorien so teuer: Sie erschweren die Feststellung, was tatsächlich geändert wurde und welche rechtlichen sowie betrieblichen Folgen daraus entstehen. Für das Entscheidungsteam gilt als praktisches Kriterium: Wenn sich eine Integrationsänderung nicht in der Konfigurationsdokumentation, im Prüfverfahren und in den Betriebsregeln beschreiben lässt, ohne auf informelles Wissen zurückzugreifen, ist das Projekt bereits in einen Bereich eingetreten, in dem nicht nur die technischen Kosten steigen, sondern auch die Verantwortung des Investors, des Projektleiters und der Personen, die die Lösung für den Betrieb freigeben.

Wie man das Thema praktisch angeht

In der Praxis lautet die Frage nicht, ob IT und OT schneller integriert werden sollen, sondern wo die Grenze zwischen einer temporären Lösung und einer Architekturschuld zu ziehen ist, die in einigen Jahren die Weiterentwicklung der Fabrik blockiert. Provisorische Verbindungen entstehen meist unter Inbetriebnahmedruck: Daten müssen schnell aus der Maschine ausgelesen, eine neue Linie ergänzt, das Qualitätssystem mit Produktionsregistern verbunden oder ein Fernzugriff für den Service ermöglicht werden. Das Problem beginnt in dem Moment, in dem eine „nur vorübergehend“ eingeführte Lösung zur Grundlage weiterer Projektentscheidungen wird. Das Team verliert die klare Aufteilung der Verantwortlichkeiten, und jede Erweiterung erfordert die Rekonstruktion von Wissen aus Korrespondenz, lokalen Einstellungen und der Praxis der Bediener. Das ist keine kleine technische Unannehmlichkeit mehr, sondern ein Faktor, der Terminplan, Änderungskosten und die Fähigkeit beeinflusst, nachzuweisen, wer eine bestimmte Lösung auf welcher Grundlage für den Betrieb freigegeben hat.

Deshalb beginnt der richtige Ansatz mit einer Architekturentscheidung und nicht mit der Auswahl eines Werkzeugs. Der Manager oder Bereichsverantwortliche sollte verlangen, dass für jede neue Integration ein operatives Ziel, ein Verantwortlicher auf beiden Seiten der IT/OT-Grenze sowie die Bedingungen für den Betrieb nach der Inbetriebnahme festgelegt sind. Wenn unklar ist, wer für die Datenquelle verantwortlich ist, wer Konfigurationsänderungen freigibt, wer die Auswirkungen auf den Prozess testet und wer über den Notbetrieb entscheidet, dann verlagert das Projekt das Risiko faktisch in die Betriebsphase. Genau hier beginnt die Rolle des Projektleiters bei IT/OT-Entscheidungen: nicht als Koordinator von Terminen, sondern als die Person, die eine Klärung der Verantwortlichkeiten erzwingt, bevor ein Provisorium als „schnelle Umgehungslösung“ in Budget und Terminplan aufgenommen wird. Ein praktisches Bewertungskriterium ist einfach: Wenn sich die geplante Integration nach einem Lieferantenwechsel, dem Austausch der Steuerung oder einer Erweiterung der Linie nicht ohne Mitwirkung des Autors der ursprünglichen Behelfslösung warten lässt, dann ist sie keine Übergangslösung, sondern ein künftiger Projektkostenfaktor.

Ein guter Testfall ist die Erweiterung einer bestehenden Linie um eine zusätzliche Station, die Daten an das übergeordnete System übermitteln und zugleich auf Zustände des bereits laufenden Anlagenteils reagieren soll. Wenn sich das Team für das direkte Aufschalten von Signalen und eine informelle Datenübersetzung entscheidet, „weil es so schneller geht“, kann anfangs alles korrekt funktionieren. Mit der Zeit treten jedoch Nebenwirkungen auf: Es wird schwieriger festzustellen, ob ein Fehler aus der Maschinenlogik, der Kommunikationsebene oder der Reporting-Anwendung stammt; die Abnahmetests decken nur Standardszenarien ab; die Modernisierung eines Elements erzwingt gleichzeitig Anpassungen an mehreren Stellen. Dann werden auch die versteckten Kosten fehlerhafter Projektentscheidungen sichtbar: zusätzliche Stillstände für die Diagnose, die kostspielige Anwesenheit des Integrators bei jeder Änderung, Streitigkeiten über den Umfang der Gewährleistung und Verzögerungen in den nächsten Investitionsphasen. Deshalb sollte man nicht nur die Inbetriebnahmezeit messen, sondern auch die Anzahl der Integrationspunkte, die eine manuelle Konfiguration erfordern, die Zeit für die Analyse eines Vorfalls nach einer Änderung sowie die Zahl der Änderungen, die bereichsübergreifend statt lokal getestet werden müssen.

Erst vor diesem Hintergrund ist der Bezug zu Sicherheits- und Compliance-Anforderungen sinnvoll. Wenn die Integration Einfluss auf Maschinenzustände, Verriegelungen, Signalquittierungen sowie die Start- oder Stoppsequenz hat, ist sie kein neutrales IT-Add-on mehr. Je nach Art der Änderung kann dies eine erneute Risikobeurteilung, die Aktualisierung der technischen Dokumentation sowie die Prüfung erforderlich machen, ob die Art des Betriebs noch den für die betreffende Maschine oder Linie zugrunde gelegten Annahmen entspricht. Besonders deutlich zeigt sich das dort, wo die Integrationsschicht mittelbar auf die Bedingungen für einen sicheren Zugang, die Energieabschaltung oder die Verhinderung eines unerwarteten Anlaufs einwirkt. In einem solchen Fall wechselt die Architekturentscheidung vom Bereich des Umsetzungskomforts in den Bereich der rechtlichen und technischen Verantwortung. Wenn das Team nicht nachweisen kann, welche Verbindungen ausschließlich informativen Charakter haben und welche das Verhalten der Maschine beeinflussen, ist das ein Signal, das Thema aus der Ebene der „Systemintegration“ herauszunehmen und als Änderung zu behandeln, die für Sicherheit, Budget und die Verantwortung der Personen relevant ist, die die Lösung freigeben.

Worauf bei der Umsetzung zu achten ist

Die meisten Probleme entstehen nicht aus der IT/OT-Integration selbst, sondern daraus, dass sie im Projekt als schnelles Mittel zur Aktivierung einer neuen Funktion behandelt wird und nicht als dauerhafter Bestandteil der Fabrikarchitektur. Genau dann rächen sich provisorische Verbindungen nach einigen Jahren: bei der Erweiterung der Linie, beim Austausch von Steuerungen, beim Wechsel des Anbieters des übergeordneten Systems oder bei einem Sicherheitsaudit zeigt sich, dass niemand den Eigentümer der Schnittstelle, ihre Funktionsregeln oder die Auswirkungen eines Ausfalls eindeutig benennen kann. Für das Projekt bedeutet das nicht nur die Kosten technischer Altlasten, sondern auch organisatorische Kosten: mehr Abstimmungen, längere bereichsübergreifende Tests, schwierigere Abnahmen und ein höheres Risiko, dass die Verzögerung erst am Ende sichtbar wird, wenn der Terminplan bereits am wenigsten flexibel ist. An diesem Punkt geht das Thema ganz natürlich in den Bereich der versteckten Kosten fehlerhafter Projektentscheidungen über, denn die Ursache des Problems ist nicht ein einzelner Ausführungsfehler, sondern die Entscheidung, eine saubere Architektur auf später zu verschieben.

Bei der Umsetzung sollte die Lösung daher nicht danach bewertet werden, ob sie „jetzt funktioniert“, sondern ob sie sich in vorhersehbarer Weise warten und sicher ändern lässt. Das praktische Kriterium ist einfach: Wenn für die geplante Integration der Verantwortungsbereich, das Ausfallverhalten, die Regeln der Versionierung sowie das Testverfahren nach Änderungen nicht beschrieben sind, ist sie noch nicht bereit für den produktiven Einsatz, selbst wenn sie am Testplatz funktioniert. Das ist besonders dort wichtig, wo dieselbe Schnittstelle die aktuelle Investitionsphase und den späteren Ausbau abdecken soll. Die Weiterentwicklung der Fabrik erhöht nahezu immer die Zahl der Abhängigkeiten zwischen den Systemen, und Provisorien funktionieren gerade dann am schlechtesten, wenn die Zahl der Ausnahmen, Umgehungslösungen und lokalen Absprachen wächst. Aus Sicht des Projektleiters bedeutet das, frühzeitig zu klären, wer Grenzentscheidungen zwischen Automatisierung, Instandhaltung, IT und Compliance freigibt, denn ohne diese Klärung verschwimmt die Verantwortung genau dort, wo später die größten Streitigkeiten über Kosten und Termine entstehen.

Ein typisches Praxisbeispiel ist die nachträgliche Ergänzung eines Datenaustauschs zwischen der Linie und dem Berichtssystem über ein zwischengeschaltetes Skript oder einen nicht dokumentierten Dienst, der auf einem Server läuft, der „ohnehin schon im Werk steht“. In der Inbetriebnahmephase wirkt diese Lösung plausibel: Sie erfordert keine Änderungen auf Seiten des Maschinenlieferanten, verkürzt die Umsetzung und ermöglicht es, schnell einen geschäftlichen Nutzen nachzuweisen. Das Problem zeigt sich erst später. Nach einem Update des Betriebssystems, einer Änderung der Adressierung, der Wiederherstellung eines Backups oder dem Austausch eines Geräts kann niemand sicher sagen, ob die Logik der Signalzuordnung noch immer dem tatsächlichen Prozess entspricht. Wenn dieser Mechanismus an Quittierungen, Verriegelungen, der Auftragsreihenfolge oder an Startbedingungen beteiligt ist, ist ein Ausfall kein reiner IT-Zwischenfall mehr, sondern wirkt sich auf die Verfügbarkeit der Linie, die Produktionsqualität und die Verantwortung für die Freigabe der Lösung zum Betrieb aus. An diesem Punkt geht das Thema nahtlos in die Risikoanalyse im Fabrikentwicklungsprojekt über, denn bewertet werden muss nicht nur die Ausfallwahrscheinlichkeit, sondern auch die Folgen fehlerhafter Informationen, fehlerhafter Abläufe und fehlerhafter Reaktionen des Bedieners.

Erst vor diesem Hintergrund ist der Bezug auf formale Anforderungen sinnvoll. Wenn die Integrationsschicht ausschließlich informativen Charakter hat und sich dies technisch nachweisen lässt, ist der Umfang der Pflichten ein anderer als in einer Situation, in der sie das Verhalten der Maschine oder der Linie beeinflusst. Greift sie jedoch in die Arbeitslogik, Startbedingungen, Stopps, Quittierungen oder Umgehungen ein, muss die Umsetzung als Änderung mit technischer und potenziell sicherheitsrelevanter Bedeutung behandelt werden und nicht als bloße Systemerweiterung. Das kann bedeuten, dass die Annahmen der Konformitätsbewertung, die technische Dokumentation und die für die jeweilige Lösung zugrunde gelegten Konformitätsbedingungen erneut überprüft werden müssen. In der Praxis lautet die sichere Entscheidung daher nicht „ob sich das anschließen lässt“, sondern „ob wir nach der Umsetzung nachweisen können, was diese Schnittstelle tut, wer dafür verantwortlich ist und wie wir die Änderung beherrschen“. Wenn die Antwort darauf nicht eindeutig ist, kehren die versteckten Kosten fehlerhafter Projektentscheidungen in der Regel bei der nächsten Modernisierung, Zertifizierung oder bei einem Zwischenfall zurück – und dann ist das nicht mehr nur ein technisches, sondern auch ein Managementproblem.