Wie organisiert man die Zusammenarbeit von Integrator, Softwarehaus und Instandhaltungsabteilung in einem gemeinsamen Projekt?

Warum dieses Thema heute relevant ist

Die Zusammenarbeit zwischen Integrator, Softwarehaus und Instandhaltung ist längst keine Frage organisatorischer Bequemlichkeit mehr. In der Praxis entscheidet sie heute darüber, ob ein Projekt ohne Streit über den Leistungsumfang in Betrieb genommen werden kann, ob eine Softwareänderung die technische Abnahme nicht blockiert und ob der Betrieb die Lösung nach der Implementierung sicher instand halten kann. Je mehr Prozesslogik in die Softwareebene verlagert wird und je weniger in den Standardfunktionen von Steuerungen und Geräten verbleibt, desto wichtiger werden klar definierte Verantwortungsgrenzen. Werden sie nicht gleich zu Beginn festgelegt, steigen die Projektkosten in der Regel nicht linear, sondern durch Nacharbeiten an der falschen Stelle: Der Integrator korrigiert Schnittstellen, das Softwarehaus baut die Geschäftslogik um, und die Instandhaltung bringt betriebliche Anforderungen erst ganz am Ende ein, die zuvor niemand dokumentiert hat.

Das ist nicht nur ein technisches, sondern auch ein Budgetthema. In vielen Projekten wird aus der Frage nach der Zusammenarbeit der Beteiligten sehr schnell die Frage, wie individuelle Software für die Industrie im Investitionsbudget einzuordnen ist: als Teil der Investition, als Instandhaltungskosten oder als Mischung aus beidem. Wenn die Lösungsarchitektur vorsieht, dass zentrale Funktionen für Prozessführung, Reporting, Rezepturen, Chargenverfolgung oder die Integration in Werksysteme außerhalb des Standardumfangs der Automatisierung entstehen, muss das vor der Beauftragung erkannt werden und nicht erst nach dem ersten Prototypen. Das praktische Kriterium ist einfach: Wenn sich wegen eines fehlenden Entscheidungseigentümers für die Grenze zwischen Automatisierung, Anwendung und Betrieb Anforderungen, Tests und Änderungskosten nicht eindeutig zuordnen lassen, bewegt sich das Projekt bereits in einem Bereich erhöhten Risikos und das Zusammenarbeitsmodell muss korrigiert werden.

Am deutlichsten zeigt sich das bei der Modernisierung einer Linie, bei der der Integrator für Steuerung und Inbetriebnahme verantwortlich ist, das Softwarehaus für die Anwendungsebene und den Datenaustausch und die Instandhaltung das System später für den Dauerbetrieb übernehmen soll. Wird die Instandhaltung erst zur Abnahme eingebunden, treten meist Probleme zutage, die keine „Mängel“ sind, sondern fehlende Entscheidungen: Es gibt kein Verfahren zur Wiederherstellung nach einem Ausfall, keine Anforderungen an Servicekonten, keine festgelegten Update-Fenster, eine nicht berücksichtigte Abhängigkeit von einem externen Lieferanten oder eine unzureichende Beobachtbarkeit von Fehlern. Dann geht es im Streit nicht mehr um Codequalität oder die Korrektheit des Schaltschrankes, sondern darum, wer die Kosten für die Anpassung des Systems an die realen Bedingungen im Werk tragen soll. An diesem Punkt verbindet sich das Thema ganz natürlich mit den versteckten Kosten von Projekt und Konformität, denn eine verzögerte Abnahme oder eine späte Änderung von Sicherheitsfunktionen, technischer Dokumentation oder Validierung ist oft gerade die Folge schlecht organisierter Zusammenarbeit und nicht eines einzelnen Ausführungsfehlers.

Der Aspekt der Konformität wird relevant, wenn die Aufgabenteilung die Produkteigenschaften, sicherheitsbezogene Funktionen, die Dokumentation oder die Art der Inbetriebnahme der Lösung beeinflusst. Nicht jede Integration einer Anwendung in eine Maschine löst dieselben Pflichten aus, aber schon die Unklarheit darüber, wer für die Funktionsbeschreibung, das Änderungsmanagement und die Vollständigkeit der Dokumentation verantwortlich ist, ist ein Warnsignal. Das gilt besonders für Projekte im eigenen Werk, für schrittweise durchgeführte Modernisierungen und für Lösungen zum Eigengebrauch, bei denen die Grenze zwischen „Instandhaltungsarbeit“ und Herstellung oder wesentlichem Umbau rechtlich relevant sein kann. Deshalb darf die Entscheidung über das Zusammenarbeitsmodell nicht erst dann fallen, wenn der erste Konflikt auftritt, sondern muss bereits bei der Definition des Umfangs getroffen werden: wer die betrieblichen Anforderungen beschreibt, wer die Architektur freigibt, wer für die Tests zwischen den Ebenen verantwortlich ist und wer das System nach der Inbetriebnahme mit der tatsächlichen Fähigkeit zu seiner Instandhaltung übernimmt.

Wo Kosten oder Risiken am häufigsten steigen

In Projekten, die gemeinsam von Integrator, Softwarehaus und Instandhaltung umgesetzt werden, steigen die Kosten nur selten wegen eines einzelnen großen Fehlers. Meist wachsen sie an den Schnittstellen der Verantwortlichkeiten, also dort, wo niemand die volle Verantwortung dafür trägt, ein Thema bis zum Abschluss zu bringen. Am teuersten sind nicht technische Fehler an sich, sondern vertagte Entscheidungen oder Entscheidungen ohne klaren Verantwortlichen: eine nicht abgestimmte Kommunikationsarchitektur, nicht beschriebene Grenzen zwischen Steuerungslogik und Anwendungsebene, ein nicht festgelegtes Vorgehen für Tests nach Änderungen sowie die Übernahme des Systems in den Betrieb ohne tatsächliche Fähigkeit zu seiner Instandhaltung. In der Praxis bedeutet das Nacharbeiten nach der Inbetriebnahme, Streit über den Vertragsumfang und die Verlagerung der Verantwortung für Stillstände in eine Phase, in der jede Änderung am teuersten ist. Ein einfaches Kriterium zur Beurteilung der Situation ist die Frage, ob sich für jede kritische Funktion eine Partei benennen lässt, die für die Anforderung verantwortlich ist, eine für die Umsetzung und eine für die Abnahme. Lautet die Antwort „das kommt darauf an“, ist das Projekt bereits mit organisatorischem Risiko belastet.

Ein zweiter Verlustbereich entsteht dann, wenn Konstruktionsentscheidungen ohne Einbindung der Instandhaltung getroffen werden – oder umgekehrt: wenn die Instandhaltung Lösungen vorgibt, die zwar servicefreundlich sind, aber nicht zur Systemarchitektur passen. Der Integrator betrachtet das Projekt in der Regel aus Sicht der Inbetriebnahme und der Zusammenarbeit mit den Anlagen, das Softwarehaus aus Sicht der Geschäftslogik und der Schnittstellen, und die Instandhaltung aus Sicht von Verfügbarkeit, Diagnosemöglichkeiten und Wiederanlaufzeit. Treffen diese Perspektiven nicht bereits bei der Definition der Anforderungen zusammen, schlagen sie später als Änderungskosten wieder zu Buche: zusätzliche Signale, der Umbau von Berechtigungen, fehlende Aufzeichnung von Ereignissen für die Diagnose, die Unmöglichkeit, Updates sicher durchzuführen, oder das Fehlen eines Verfahrens zur Störungsüberbrückung. An diesem Punkt geht das Thema ganz natürlich in die Rolle des Engineering-Projektleiters über, denn das Problem ist dann nicht mehr eine einzelne technische Entscheidung, sondern das Management von Abhängigkeiten, Abstimmungsterminen und Eskalationsverantwortung.

Ein typisches Praxisbeispiel ist eine Implementierung, bei der die übergeordnete Anwendung Aufträge, Rezeptur und Reporting steuern soll, während der Integrator für Steuerung, Antriebe und die Maschinenabläufe verantwortlich ist. Wird die Verantwortungsgrenze nur funktional beschrieben, ohne Zwischenzustände, Fehlerbedingungen und das Verhalten bei Kommunikationsverlust festzulegen, entwickelt jede Seite ihre eigenen „sicheren“ Annahmen. Das Softwarehaus geht davon aus, dass eine fehlende Bestätigung die Wiederholung des Befehls bedeutet, der Integrator nimmt an, dass der Befehl nur einmal gesendet wird, und die Instandhaltung erhält ein System, das sich im Stillstand nicht diagnostizieren lässt. Die Folgen sind vorhersehbar: eine lange Inbetriebnahme, mehrdeutige Fehler, Nachbesserungen an den Schnittstellen und Spannungen bei der Frage, wer für den ungeplanten Stillstand verantwortlich ist. Bei der Bewertung einer solchen Situation sollte man nicht nur den Übergabetermin messen, sondern auch die Anzahl der Schnittstellenänderungen nach Projektfreigabe, die Zahl der Mängel, die erst vor Ort erkannt werden, sowie die Zeit, die benötigt wird, um die Störungsursache zu rekonstruieren. Steigen diese Kennzahlen trotz Projektfortschritt, liegt das Problem meist in der Organisation der Zusammenarbeit und nicht in der Leistungsfähigkeit eines einzelnen Lieferanten.

Eine eigenständige Risikoursache besteht darin, Tests und Dokumentation als Nebenprodukt der Inbetriebnahme zu behandeln. Überall dort, wo das System Einfluss auf das Verhalten der Maschine, den Bedienerzugang, die Diagnose, Prozessparameter oder sicherheitsbezogene Funktionen hat, ist eine späte Änderung keine gewöhnliche Programmkorrektur. Sie kann eine erneute Bewertung der Projektannahmen, die Aktualisierung der technischen Dokumentation, die Wiederholung eines Teils der Prüfungen und in bestimmten Konstellationen auch eine erneute Analyse der Pflichten auf Seiten des Nutzers oder der Stelle erfordern, die die Änderung einführt. Das lässt sich nicht abstrakt für jedes Projekt gleich entscheiden, aber die praktische Regel ist einfach: Je stärker eine Änderung das Verhalten des Systems in normalen und anormalen Zuständen beeinflusst, desto weniger darf sie „im laufenden Abstimmungsprozess“ umgesetzt werden. Hier beginnt auch der Bereich typischer Fehler beim Bau und bei der Modernisierung von Maschinen: fehlende Sperren gegen Fehlkonfiguration, keine erzwungene Reihenfolge von Handlungen und keine Mechanismen zur Vermeidung von Bedien- oder Servicefehlern. Wenn solche Schutzmaßnahmen nicht von Anfang an im Leistungsumfang verankert sind, kommen sie später als Kosten, Stillstand oder Streit über die Verantwortung zurück.

Wie man das Thema praktisch angeht

In der Praxis sollte die Zusammenarbeit von Integrator, Softwarehaus und Instandhaltung nicht entlang von Unternehmensgrenzen organisiert werden, sondern entlang der Verantwortungsgrenzen für konkrete technische Entscheidungen. Das entscheidet darüber, wer für die Steuerungslogik verantwortlich ist, wer für Anwendungsebene und Kommunikation, wer für Servicebedingungen, Backups, Wiederherstellung nach Störungen und die sichere Umsetzung von Änderungen an der Anlage. Bleiben diese Grenzen nur allgemein beschrieben, beginnt das Projekt auf Basis von Annahmen zu laufen: Der Integrator setzt voraus, dass die betrieblichen Anforderungen vom Werk geliefert werden, das Softwarehaus geht davon aus, dass die Prozesslogik bereits abgeschlossen ist, und die Instandhaltung erhält ein System, das sich ohne den Autor des Codes nicht wirksam instand halten lässt. Die Folge ist nicht nur organisatorischer Natur. Die Kosten der Inbetriebnahme steigen, die Störungsbeseitigung dauert länger, und im Streitfall ist schwerer festzustellen, ob das Problem aus einem Implementierungsfehler, unvollständigen Annahmen oder einer unkontrollierten Änderung nach der Abnahme resultiert.

Deshalb sollte die erste Entscheidung nicht die Wahl des Werkzeugs oder der Zeitplan für Workshops sein, sondern die Festlegung eines gemeinsamen Verantwortungsmodells für den gesamten Lebenszyklus der Lösung. Für das Management ist das praktische Kriterium einfach: Jede Funktion, die Einfluss auf den Betrieb einer Maschine oder Linie hat, muss in vier Projektzuständen einen klar benannten Verantwortlichen haben – Planung, Inbetriebnahme, Abnahme und Instandhaltung. Wenn sich für eine bestimmte Funktion nicht eindeutig beantworten lässt, wer die Anforderung freigibt, wer die Änderung umsetzt, wer die Auswirkungen testet und wer die Verantwortung für die Wiederherstellung der Funktion nach einer Störung trägt, dann ist der Leistungsumfang nicht umsetzungsreif. An dieser Stelle wird die Rolle des Engineering-Projektleiters ganz natürlich sichtbar: nicht als Person „für Termine“, sondern als Verantwortlicher für eine geordnete Entscheidungsstruktur zwischen Gewerken und Lieferanten.

Die meisten Probleme entstehen an der Schnittstelle zwischen Steuerung und kundenspezifischer Software. Ein typisches Beispiel ist eine Anwendung, die die Auswahl von Rezepturen verändert, die Arbeitsfolge parametriert oder die Berechtigungen des Bedieners beeinflusst. Für ein Softwarehaus mag das wie eine gewöhnliche Funktionsänderung aussehen, für den Integrator und die Instandhaltung ist es jedoch ein Eingriff in das Verhalten des Systems, die Diagnose und die Umrüstverfahren. Wenn vor der Implementierung nicht festgelegt wurde, wo die Verantwortung für die Schnittstelle endet und wo die Verantwortung für die Prozesslogik beginnt, kann eine Korrektur „in der Produktion“ erneute Tests, Aktualisierungen der Anleitungen und mitunter sogar eine Überarbeitung der Serviceverfahren erforderlich machen. Genau hier berührt das Thema auch das Budget: Die Kosten für kundenspezifische Software für die Industrie im Investitionsbudget ergeben sich nicht nur aus dem Schreiben des Codes, sondern auch daraus, wie viel Verantwortung das Projekt in die Phasen Validierung, Dokumentation und spätere Instandhaltung verlagert.

Um das zu vermeiden, sollte der Projektstand nicht nach den Erklärungen der Lieferanten bewertet werden, sondern nach Artefakten, die sich überprüfen lassen. Das Mindestpaket umfasst eine abgestimmte Liste der Schnittstellen, eine Beschreibung der Versionierung, ein Verfahren zur Meldung und Freigabe von Änderungen, Szenarien für Abnahmetests sowie einen Instandhaltungsplan für die Zeit nach der Inbetriebnahme. Bewährt hat sich hier ein kurzer Entscheidungsfilter:

• ob die Änderung die Prozesslogik, die Betriebsparameter oder das Verhalten des Bedieners beeinflusst,
• ob sie sich ohne Mitwirkung des Autors der Lösung reproduzieren, testen und zurücknehmen lässt,
• ob die Dokumentation nach der Implementierung es dem Werk ermöglicht, das System ohne das nur im E-Mail-Postfach des Auftragnehmers verborgene Wissen zu betreiben.

Wenn eine dieser Fragen mit „nein“ beantwortet wird, muss der Projektumfang präzisiert werden, statt die Arbeiten zu beschleunigen. Erst in diesem Stadium ist ein sinnvoller Bezug zu formalen Anforderungen möglich: nicht, um allgemeine Vorbehalte in den Vertrag aufzunehmen, sondern um zu prüfen, ob der Charakter der Änderungen bereits Auswirkungen auf Dokumentations- oder Abnahmepflichten oder auf die Bewertung der Verantwortung auf Seiten des Nutzers hat. Das ist besonders dort wichtig, wo das Werk die Lösung selbst mitentwickelt, sie mit eigenen Kräften weiterentwickelt oder Teile des Systems für den internen Gebrauch aufbaut. Dann ist die Zusammenarbeit der drei Parteien nicht mehr nur eine Frage der Projektorganisation, sondern fällt auch in den Bereich der rechtlichen Pflichten des Werks.

Worauf bei der Implementierung zu achten ist

Die meisten Probleme treten nicht dann auf, wenn dem Team die Kompetenz fehlt, sondern dann, wenn die Projektbeteiligten innerhalb ihrer eigenen Grenzen korrekt arbeiten, aber niemand die Schnittstelle zwischen ihnen steuert. In einem Projekt, in dem der Integrator für die Ausführungsebene und die Anbindung an die Automatisierung verantwortlich ist, das Softwarehaus für die Anwendungslogik und die Instandhaltung für die Betriebskontinuität des Werks, führt eine fehlerhafte Organisation der Implementierung fast immer dazu, dass das Risiko in die Inbetriebnahmephase verlagert wird. Genau dort zeigt sich, ob Projektentscheidungen mit Blick auf den gesamten Lebenszyklus der Lösung getroffen wurden oder nur darauf, dass die einzelnen Auftragnehmer ihren Leistungsumfang abschließen. Für das Projekt bedeutet das in der Regel eines von drei Dingen: kostspielige Nachbesserungen nach der Inbetriebnahme, Streit über die Verantwortung für Ausfälle oder eine verzögerte Abnahme, weil das System nur unter Laborbedingungen funktioniert, nicht aber im realen Prozess.

Die zentrale Falle besteht darin, dass die Implementierung oft als technische Phase behandelt wird, obwohl sie in der Praxis der Moment ist, in dem organisatorische Entscheidungen überprüft werden. Wenn der Integrator Änderungen an der Steuerung vornehmen kann, ohne die Auswirkungen auf die Anwendung vollständig zu kennen, das Softwarehaus Funktionen weiterentwickelt, ohne die Grenzen der Geräte und des industriellen Netzwerks bestätigt zu haben, und die Instandhaltung erst zur Abnahme einbezogen wird, liegt das Problem nicht in der Kommunikation, sondern in einer fehlerhaften Verteilung der Verantwortlichkeiten. Das praktische Bewertungskriterium ist einfach: Vor dem Einsatz vor Ort sollte jede Partei benennen können, welche Änderungen sie selbstständig durchführen darf, welche eine gemeinsame Freigabe erfordern und wer die Entscheidung trifft, die Arbeiten zu stoppen, wenn ein Risiko für den Prozess, die Sicherheit oder die Wiederherstellbarkeit der Konfiguration entsteht. Hängt die Antwort von „laufenden Abstimmungen“ ab, ist die Implementierung noch nicht vorbereitet, selbst wenn der Terminplan formal stimmt.

Ein typisches Beispiel ist eine scheinbar kleine Änderung: die Anpassung der Arbeitsfolge einer Station. Aus Sicht des Softwarehauses ist das eine Korrektur der Logik, für den Integrator bedeutet es andere Reaktionszeiten der Geräte, und für die Instandhaltung wirkt es sich auf die Diagnose und die Verfahren nach einer Störung aus. Gelangt eine solche Änderung ohne gemeinsame Folgenabschätzung in die Anlage, lässt sich nach der Inbetriebnahme nur schwer feststellen, ob die Ursache des Problems im Code, in der Konfiguration der Steuerung, in den Antriebsparametern oder in der Bedienweise des Operators liegt. Dann steigen die Kosten nicht nur durch die Korrektur selbst, sondern auch durch Stillstandszeiten, zusätzliche Tests und die Einbindung von Personen, die zuvor nicht an der Analyse beteiligt sein mussten. Deshalb lohnt es sich, nicht nur den Termin der Inbetriebnahme zu messen, sondern auch die Zahl der Implementierungsänderungen ohne vollständigen Freigabeweg, die Zeit bis zur Wiederherstellung der vorherigen Version sowie den Anteil der Mängel, die erst nach der Übergabe des Systems in den Betrieb erkannt werden. Das vermittelt ein realistisches Bild davon, ob die Zusammenarbeit der drei Parteien gesteuert wird oder nur situativ aufrechterhalten bleibt.

In dieser Phase zeigt sich naturgemäß auch die Grenze zwischen einer gewöhnlichen Implementierung und einer Situation, in der der Betrieb an der Lösung mitwirkt und damit seine formalen Pflichten beeinflusst. Wenn die Instandhaltung nicht nur Stellung nimmt, sondern selbst die Logik verändert, Komponenten des Systems auswählt oder einen Teil der konstruktiven Entscheidungen übernimmt, geht es nicht mehr ausschließlich um die Organisation der Zusammenarbeit, sondern auch um Maschinen für den Eigengebrauch. Das lässt sich nicht mit einer einzigen Regel für alle Projekte entscheiden; maßgeblich sind der Umfang des Eingriffs, der Grad der Eigenständigkeit des Betriebs und die Frage, wer die Eigenschaften der Lösung tatsächlich prägt. Ähnlich verhält es sich mit der Risikobeurteilung: Wenn eine Änderung die Prozessfunktion, das Verhalten des Bedieners, die Bedingungen für Serviceeingriffe oder die Abfolge von Notfallzuständen beeinflusst, geht es nicht mehr nur um die Frage „ob implementiert werden soll“, sondern auch darum, „ob das Risiko erneut bewertet und die Abnahmeannahmen aktualisiert werden müssen“. In der Praxis wird gerade hier die Rolle der projektverantwortlichen Person am deutlichsten sichtbar: nicht als Vermittler für Statusmeldungen, sondern als Verantwortlicher für die Entscheidung, wann eine bequeme Vereinfachung endet und technische sowie rechtliche Verantwortung beginnt.