Projekt einer industriellen Anwendung: Wie bereitet man die Eingangsdaten vor?

Die Aufbereitung der Eingangsdaten für ein Projekt mit einer Industrieanwendung ist heute kein administrativer Schritt mehr, den man „nebenbei erledigt“, sondern eine Entscheidung, die sich unmittelbar auf die Inbetriebnahmezeit, die Kosten von Änderungen und die Verantwortlichkeiten nach der Implementierung auswirkt. Im Produktionsumfeld arbeitet eine Anwendung nur selten isoliert: Sie muss in die bestehende Automatisierung, in Qualitätsprozesse, in die Instandhaltung und häufig auch in Anforderungen an Rückverfolgbarkeit und Konformität eingebunden werden. Fehlt zu Beginn eine eindeutige Beschreibung des Prozesses, der Datenquellen, der betrieblichen Ausnahmen und der Verantwortungsgrenzen zwischen den Beteiligten, entwickelt das Team keine Lösung, sondern rekonstruiert die Realität im Versuch-und-Irrtum-Verfahren. Genau dann verlängert sich der Zeitplan nicht wegen der Programmierung, sondern durch Korrekturen von Annahmen, zusätzliche Vor-Ort-Termine, Diskussionen über den Leistungsumfang und die Notwendigkeit von Nacharbeiten nach den Tests an der Anlage.

Der größte Fehler besteht meist darin, als „Eingangsdaten“ ausschließlich die Liste der von der Anwendung erwarteten Funktionen zu betrachten. Für ein Industrieprojekt sind jedoch die Randbedingungen genauso wichtig: Wer gibt wann Daten ein, welche Signale kommen aus dem Steuerungssystem, was passiert bei einem Kommunikationsausfall, welche manuellen Umgehungen sind zulässig, welche Ereignisse müssen aufgezeichnet werden und welche Entscheidungen des Bedieners Auswirkungen auf Qualität oder Sicherheit haben. Aus geschäftlicher Sicht ist diese Unterscheidung entscheidend, weil genau an diesen Schnittstellen die teuersten Änderungen entstehen. Wenn die Anwendung die Produktion unterstützen und nicht nur Daten anzeigen soll, wird ein unpräziser Projekteingang sehr schnell zu einem Problem der Zusammenarbeit von Integrator, Softwareanbieter und Instandhaltung. Jede dieser Parteien sieht einen anderen Ausschnitt des Prozesses, die Folgen einer falschen Entscheidung trägt jedoch in der Regel der Investor: in Form von Stillständen, zusätzlichen Abnahmen und Streitigkeiten darüber, ob eine bestimmte Funktion „selbstverständlich“ war oder doch außerhalb des vereinbarten Umfangs lag.

In der Praxis zeigt sich das gut an einem einfachen Beispiel einer Anwendung zur Überwachung von Rezepturen, Produktionschargen oder einem Register von Qualitätsereignissen. Beginnt das Team die Arbeiten, ohne festzulegen, welche Daten führend sind, welche nur abgeleitet, wer sie korrigieren darf und ob eine Korrektur nachvollziehbar bleiben muss, wird das Problem nicht in der Mock-up-Phase sichtbar, sondern erst bei der Inbetriebnahme oder im internen Audit. Plötzlich stellt sich heraus, dass die Anwendung „funktioniert“, sich auf ihrer Grundlage aber weder der Verlauf einer Charge rekonstruieren noch eine Abweichung erklären oder nachweisen lässt, warum der Bediener eine bestimmte Entscheidung getroffen hat. Dann geht das Thema der Vorbereitung der Eingangsdaten ganz natürlich in die Auslegung der Produkt- und Prozessrückverfolgbarkeit über und mitunter auch in die Budgetierung der Konformität, weil jede späte Änderung an der Art der Datenerfassung eine Überarbeitung von Logik, Schnittstellen und Abnahmetests erfordert.

Ein praktisches Kriterium zur Beurteilung der Situation ist einfach: Vor Beginn der Implementierung muss sich für jede Schlüsselinformation ihr Verantwortlicher, ihre Quelle, ihr Entstehungszeitpunkt, ihre Validierungsregel und die Auswirkung eines Fehlers benennen lassen. Wenn das Team dazu nicht in der Lage ist, ohne sich auf Vermutungen oder ein „Prüfen an der Anlage“ zu stützen, sind die Eingangsdaten nicht bereit, und das Projekt wird die Defizite zum denkbar teuersten Zeitpunkt aufholen müssen. Es lohnt sich, nicht nur den Termin der Fertigstellung der Anwendung zu messen, sondern auch die Zahl der Umfangsänderungen nach Freigabe der Analyse, die Zahl der Fragen, die die Implementierung blockieren, die Zeit für gewerkeübergreifende Abstimmungen sowie die Zahl der Korrekturen, die erst in Tests in der Produktion sichtbar werden. Das sind Kennzahlen für die Qualität der Projektvorbereitung und nicht ausschließlich für die Qualität der Arbeit des Auftragnehmers.

Erst vor diesem Hintergrund wird die Bedeutung des Themas Konformität deutlich. Wenn die Anwendung die Funktion einer Maschine, ihre Bedienweise, die Aufzeichnung sicherheitsrelevanter Ereignisse oder die Dokumentation von Prozessparametern beeinflusst, kann die Art, wie die Eingangsdaten definiert werden, auch den Umfang der Konformitätsbewertung und der technischen Dokumentation beeinflussen. Nicht immer betrifft das den Bereich der CE-Kennzeichnung, denn das hängt von der Rolle der Anwendung selbst und von der Systemarchitektur ab, aber diesen Zusammenhang zu Beginn des Projekts zu ignorieren, erhöht fast immer die Kosten späterer Abstimmungen. Deshalb muss die Entscheidung jetzt getroffen werden: Behandeln wir die Vorbereitung des Projekteingangs als Formalität vor der Beauftragung der Arbeiten oder als Engineering-Phase, in der Verantwortlichkeiten geordnet, Änderungsrisiken begrenzt und die Voraussetzungen für eine tatsächlich kürzere Implementierung geschaffen werden.

Wo Kosten oder Risiken am häufigsten steigen

Die meisten Kosten entstehen in der Regel nicht in der eigentlichen Programmierung der Industrieanwendung, sondern dort, wo die Eingangsdaten unvollständig oder widersprüchlich sind oder nur das erwartete Geschäftsergebnis beschreiben, nicht aber die technischen Bedingungen zu seiner Erreichung. Wenn zu Beginn nicht klar ist, welche Signale die maßgebliche Datenquelle sind, welche Grenzzustände der Prozess hat, wer die Alarmierungsregeln freigibt und welche Ereignisse aufgezeichnet werden sollen, beginnt das Projektteam, Ersatzentscheidungen zu treffen. Genau dann steigt die Zahl der Umfangsänderungen nach Freigabe der Analyse, es entstehen Fragen, die die Implementierung blockieren, und die Abstimmungen zwischen Automatisierung, Instandhaltung, Qualität und Sicherheit dauern länger. Für das Projekt bedeutet das nicht nur eine Verzögerung, sondern auch eine Verschiebung der Verantwortung: Der Auftragnehmer verantwortet eine Lösung, deren Annahmen oft stillschweigend zugrunde gelegt und nicht bewusst abgestimmt wurden.

Eine zweite Risikoursache ist die Verwechslung funktionaler Anforderungen mit Konstruktions- oder Designentscheidungen. In der Praxis zeigt sich das so, dass der Auftraggeber einen Bildschirm, einen Bericht oder die Art der Steuerung beschreibt, aber weder das operative Ziel noch Randbedingungen und Ausnahmen definiert. Dann wirkt jede spätere Prozessänderung wie eine „kleine Korrektur“, obwohl tatsächlich die Logik überarbeitet, Tests angepasst und Abstimmungen erneut geführt werden müssen. Ein gutes Bewertungskriterium ist einfach: Wenn sich für eine bestimmte Anforderung nicht eindeutig beantworten lässt, wer die Entscheidung trifft, auf welcher Datengrundlage, in welchem Zeitfenster und mit welchen Auswirkungen auf den Prozess, dann sind die Eingangsdaten noch nicht belastbar. An dieser Stelle führt das Thema ganz natürlich zu den häufigsten Fehlern in Industrieprojekten, denn das Problem betrifft nicht nur die Dokumentation, sondern die Art und Weise, wie die Lösung überhaupt definiert wird.

Ein praktisches Beispiel ist eine Anwendung, die das Umrüsten einer Linie überwachen und den Start bei Abweichungen in den Rezepturparametern sperren soll. Wenn sich die Projektvorgabe auf die Aussage beschränkt, dass „das System auf korrekte Einstellungen achten soll“, ist das Risiko nahezu vorprogrammiert. Es muss geklärt werden, welche Parameter kritisch sind, woher sie stammen, ob der Bediener sie überschreiben darf, wie ein Kommunikationsausfall behandelt wird, was als Bestätigung der Übereinstimmung gilt und ob die Sperre rein prozessbezogen ist oder die Sicherheitsfunktion der Maschine beeinflusst. Ohne diese Festlegungen werden die Abschlusstests fast immer einen Streit über Zuständigkeiten offenlegen: Die Produktion erwartet Flexibilität, die Qualitätssicherung verlangt einen Audit-Trail, und die Instandhaltung braucht die Möglichkeit einer sicheren Umgehung im Servicebetrieb. Das sind keine Ausführungsdetails, sondern fehlende Eingangsdaten, die am Ende des Projekts am meisten kosten.

Eine eigene Risikokategorie entsteht, wenn die Anwendung in die Maschinenlogik, die Arbeitssequenz, die Art der Alarmquittierung oder die Aufzeichnung sicherheits- und qualitätsrelevanter Ereignisse eingreift. Dann ist das Thema nicht mehr nur ein IT-Thema. Wenn das Projekt die Nutzungsbedingungen der Maschine, das Reaktionsverhalten bei Fehlern oder den Umfang der Informationen verändert, die zum Nachweis der Konformität erforderlich sind, kann es in den Bereich der Risikobeurteilung im Projekt fallen und in der Folge auch die Vorbereitung der Maschine auf die Konformitätsbewertung und die technische Dokumentation betreffen. Das ist nicht in jedem Fall für die CE-Kennzeichnung relevant, denn entscheidend ist die tatsächliche Rolle der Anwendung in der Systemarchitektur. Das Kriterium ist jedoch klar: Wenn ein Fehler der Anwendung das Prozessverhalten so verändern kann, dass Sicherheit, Produkt oder Dokumentationspflichten betroffen sind, muss dieser Punkt vor der Implementierung geklärt werden und nicht erst nach den Abnahmetests.

Aus Sicht des Einführungsmanagements sind daher nicht einzelne technische Fehler am teuersten, sondern fehlende Entscheidungen zum richtigen Zeitpunkt. Deshalb sollte die Qualität der Eingangsdaten nicht nach dem Umfang der Beschreibung bewertet werden, sondern danach, ob sich Streitpunkte noch vor Beginn der Programmierarbeiten ausräumen lassen. Wenn nach den Kick-off-Workshops weiterhin nicht eindeutig feststeht, welche Anforderungen kritisch sind, welche nur eine Nutzerpräferenz darstellen, was validiert werden muss und welcher Änderungsumfang eine zusätzliche Risikobeurteilung oder Konformitätsabstimmungen auslöst, dann ist der Terminplan nur scheinbar sicher. In der Praxis bedeutet das, dass Kosten und Verantwortung lediglich in eine Projektphase verschoben wurden, in der Korrekturen am langsamsten und am teuersten sind.

Wie man das Thema praktisch angeht

In der Praxis beginnt eine kürzere Einführungszeit nicht mit schnellerem Programmieren, sondern damit, die Zahl der Entscheidungen zu verringern, die erst während der Implementierung getroffen werden müssen. Die Eingangsdaten für ein Projekt mit einer Industrieanwendung sollten daher nicht um die Funktionsbeschreibung herum organisiert sein, sondern um die Punkte, an denen das Projekt ins Stocken geraten kann: Zuständigkeitsgrenzen, Betriebsbedingungen, Abhängigkeiten von der Automatisierung, Auswirkungen auf die Prozesssicherheit, Validierungsanforderungen und Regeln für Änderungen. Wenn das Team eine umfangreiche Beschreibung der Nutzererwartungen erhält, aber nicht geklärt ist, wer die Alarmlogik freigibt, welche Signale die maßgebliche Datenquelle sind, wie der Notbetrieb aussieht und was ohne erneute Folgenbewertung geändert werden darf, dann ist der Terminplan nur scheinbar stabil. In einem solchen Setup entstehen die Kosten später in Form von Nacharbeiten, Abnahmekonflikten und einer zwischen den Lieferanten verwischten Verantwortung.

Deshalb lohnt es sich, zu Beginn ein einfaches Kriterium für die Qualität des Eingangsmaterials festzulegen: Lässt sich auf seiner Grundlage eine technische Entscheidung eindeutig einem Verantwortlichen, einer Freigabebedingung und einer Verifikationsmethode zuordnen? Dieses Kriterium strukturiert das Thema besser als die allgemeine Aussage, dass „die Anforderungen beschrieben sind“. Für den Manager bedeutet das, vor der Beauftragung einige Punkte verbindlich zu klären: Visualisiert die Anwendung den Prozess nur oder steuert sie auch sein Verhalten; hat sie Einfluss auf die Qualitätsparameter des Produkts; wird sie in die bestehende Steuerungslandschaft integriert; soll die Instandhaltung die Konfiguration nach der Einführung übernehmen; und sind Änderungen nach der Inbetriebnahme vorgesehen. Wenn die Antworten auf diese Fragen nur unter Vorbehalt gelten oder über E-Mails verstreut sind, dann verfügt das Projekt noch nicht über belastbare Eingangsdaten, sondern nur über eine Sammlung von Arbeitsannahmen. Der Unterschied ist wesentlich, denn Arbeitsannahmen bestehen die Realität der Produktionshalle in der Regel nicht.

Ein gutes Beispiel ist eine Anwendung, die Daten aus der Linie erfassen, den Zustand der Anlagen anzeigen und dem Bediener ermöglichen soll, einen Teil der Einstellungen zu ändern. In der Vertriebsphase wird ein solcher Umfang oft als „Standard-Bedienebene“ behandelt. Für die Umsetzung ist jedoch entscheidend, klar zu unterscheiden, welche Einstellungen rein betrieblicher Natur sind und welche den Prozessablauf, die Produktqualität oder das Verhalten der Maschine in anormalen Zuständen beeinflussen. Wird das nicht vor der Implementierung geklärt, erstellt der Programmierer einen Mechanismus zur Bearbeitung von Parametern, der Integrator bindet ihn an die Steuerung an, und erst bei der Abnahme stellt sich die Frage, ob die Änderung eines bestimmten Werts eine Sperre, eine Änderungsverfolgung, eine zusätzliche Freigabe oder eine erneute Risikobeurteilung im Projekt erfordert. Dann ist das Problem nicht mehr technischer Natur. Es wird zu einer Frage der Verantwortung: Wer hat die Funktion zur Nutzung freigegeben, wer hätte ihren Einfluss auf die Sicherheit bewerten müssen und wer trägt die Folgen, wenn sich nach der Inbetriebnahme herausstellt, dass die Berechtigungen zu weit gefasst waren.

Deshalb sollte die praktische Aufbereitung der Eingangsdaten nicht nur mit einer Liste von Bildschirmen, Berichten oder Signalen enden, sondern mit einer kurzen, aber verbindlichen Beschreibung der Entscheidungslogik des Projekts. Diese Beschreibung sollte festlegen, welche Funktionen einer funktionalen Abnahme unterliegen, welche eine Bestätigung durch den Endanwender erfordern und welche zusätzliche Abstimmungen mit dem Integrator, der Instandhaltung oder der für die Konformität verantwortlichen Person auslösen. An diesem Punkt geht das Thema ganz natürlich in die Zusammenarbeit von Integrator, Softwarehaus und Instandhaltung über, denn ohne klar definierte Verantwortungsgrenzen kann selbst eine korrekt programmierte Anwendung an den Schnittstellen zwischen den Systemen scheitern. Beeinflusst die Anwendung dagegen Maschinenfunktionen in einer für die Sicherheit wesentlichen Weise oder verändert sie das beabsichtigte Verhalten des Systems, dann ist dasselbe Eingangsmaterial nicht mehr nur ein Projektdokument, sondern gewinnt Bedeutung für die weitere Konformitätsbewertung und die technische Dokumentation.

Normative Bezüge sollten erst dann eingeführt werden, wenn feststeht, dass die Anwendung tatsächlich den Bereich Sicherheit, Produktkonformität oder eine formale Validierung berührt. Nicht jede industrielle Anwendung fällt in diesen Bereich, aber das darf nicht ungeprüft angenommen werden. Das Kriterium ist praktisch: Wenn ein Funktionsfehler, eine fehlerhafte Konfiguration oder eine unbefugte Änderung eines Parameters den Zustand der Maschine, des Prozesses oder die Entscheidung des Bedieners in einer Weise verändern kann, die für Sicherheit, Qualität oder Dokumentationspflichten relevant ist, dann erfordert das Projekt nicht nur eine Präzisierung der Anforderungen, sondern auch eine frühzeitige Risikobeurteilung und die Bewertung der Auswirkungen auf die Konformität. Genau hier entscheidet sich meist, ob die Umsetzung wirklich kürzer wird oder nur schneller in die Phase kostspieliger Korrekturen gerät.

Worauf bei der Umsetzung zu achten ist

Selbst gut vorbereitete Eingangsdaten verkürzen die Umsetzung nicht, wenn das Team sie nur als Funktionsbeschreibung und nicht als Rahmenbedingungen für Verantwortung, Änderungen und Abnahme behandelt. Bei Projekten für industrielle Anwendungen entstehen Verzögerungen selten durch die Programmierung selbst. Häufiger liegt die Ursache darin, dass sich bei der Inbetriebnahme herausstellt, dass die Eingangsdaten nicht festlegen, wer Prozessparameter freigibt, wer für die Qualität der Gerätedaten verantwortlich ist, in welchem Modus Änderungen zulässig sind und was die Grundlage der Abnahme bildet. Dann entwickelt die Umsetzung ihre eigene Dynamik: Jede Unklarheit erfordert eine zusätzliche Entscheidung, jede Entscheidung eröffnet das Risiko eines Streits über den Leistungsumfang, und jede Korrektur vor Ort erhöht Kosten und Verantwortung auf beiden Seiten. Wenn das Ziel eine kürzere Umsetzungszeit ist, muss das Eingangsmaterial nicht nur für den Projektplaner nutzbar sein, sondern auch für den Integrator, die Instandhaltung, die Qualitätsabteilung und die für die Konformität verantwortlichen Personen.

Besondere Vorsicht ist geboten, wenn die Anwendung mit heterogenen Daten arbeiten soll, die aus verschiedenen Steuerungen, Leitsystemen oder manuellen Eingaben des Bedieners stammen. Hier zeigt sich am häufigsten die Falle einer nur scheinbaren Vollständigkeit: Die Signalliste liegt vor, die Bildschirme sind beschrieben, aber es fehlen eindeutige Regeln für Prioritäten, die Bedeutung von Fehlerzuständen, die Gültigkeitsdauer der Daten und die Reaktion des Systems auf ausbleibende Aktualisierungen. In der Praxis führt das zu Fehlern, die formal kein Softwareausfall sind, sondern die Folge eines nicht festgelegten Betriebsmodells. Für den Projektleiter ist diese Unterscheidung wichtig, weil sie sich auf die Änderungskosten und die vertragliche Verantwortung auswirkt. Ein gutes Bewertungskriterium ist einfach: Wenn sich für eine Schlüsselfunktion nicht in einem Satz die Datenquelle, der Entscheidungsträger, die Bedingung für eine Zurückweisung und die Art der Bestätigung des korrekten Betriebs benennen lassen, dann sind die Eingangsdaten noch nicht belastbar genug, um sicher in die Umsetzung zu gehen.

Das zeigt sich gut am Beispiel einer Anwendung, die Prozesssollwerte berechnet und diese an das Ausführungssystem weitergibt oder dem Bediener als Entscheidungsgrundlage anzeigt. Wenn zu Beginn nicht festgelegt wurde, ob die Werte rein informativen, empfehlenden oder steuernden Charakter haben, weiß das Implementierungsteam nicht, welches Testregime anzusetzen ist und wer eine Abweichung vom erwarteten Verhalten freigeben darf. Eine solche Unklarheit wird meist erst bei der Inbetriebnahme sichtbar, wenn die Frage aufkommt, ob die Produktion trotz unvollständiger Validierung historischer Daten oder trotz manueller Umgehungen gestartet werden kann. Dann ist die Terminverkürzung durch „vorläufige“ Lösungen nur scheinbar: Das Risiko von Reklamationen und Stillständen steigt, im Extremfall auch die Haftung für Schäden infolge einer fehlerhaften Prozessentscheidung. Deshalb sollte vor der Implementierung ein messbares Kriterium festgelegt werden: Gibt es für jede Funktion, die die Prozessparameter beeinflusst, ein eindeutiges Abnahmetestszenario einschließlich der Definition fehlerhafter Daten, fehlender Daten und des Verhaltens nach Wiederherstellung der Kommunikation. Das ist kein Formalismus, sondern eine Voraussetzung für eine planbare Inbetriebnahme.

Erst vor diesem Hintergrund wird deutlich, wann das Thema nicht mehr nur eine Frage der Implementierungsorganisation ist, sondern in den Bereich der Risikobeurteilung im Projekt und der Vorbereitung der Maschine auf die weitere Konformitätsbewertung und CE-Kennzeichnung übergeht. Wenn die Anwendung die Funktionslogik der Maschine verändert, Entscheidungen des Bedieners in sicherheitsrelevanten Situationen beeinflusst oder Teil einer Funktion wird, von der der zulässige Prozesszustand abhängt, reicht es nicht aus, „die Anforderungen zu präzisieren“. Es muss geprüft werden, ob die Eingangsdaten den Nachweis der beabsichtigten Funktion, der Einsatzgrenzen und der Validierungsbedingungen ermöglichen, denn andernfalls kann die Implementierung technisch abgeschlossen sein, aber bei der Abnahme, in der technischen Dokumentation oder bei einem späteren Audit stecken bleiben. In der Praxis ist die Grenze klar: Wenn ein Datenfehler, eine fehlerhafte Konfiguration oder eine nicht autorisierte Parameteränderung Auswirkungen haben kann, die für die Sicherheit, die Produktqualität oder die Dokumentationspflichten wesentlich sind, sollte das Projekt mit einer separaten Risikobeurteilung verknüpft und nicht allein durch Funktionstests abgeschlossen werden. Gerade an der Schnittstelle zwischen Implementierung, Risikobeurteilung und den späteren Anforderungen im Zusammenhang mit der CE-Kennzeichnung entstehen am häufigsten die teuersten Korrekturen, die aus Sicht des Terminplans wie Kleinigkeiten wirken, das Projekt tatsächlich aber auf die Phase der Grundannahmen zurückwerfen.