Projektmanagement in der Automatisierung: PLC-, SCADA- und Leitsystemprojekte von URS bis zur Inbetriebnahme führen

Was ist Projektmanagement in der Automatisierung

Projektmanagement in der Automatisierung ist die Disziplin, industrielle Automatisierungsprojekte zu planen, durchzuführen, zu koordinieren und zu liefern, die Leitsysteme (PLC, SCADA, DCS, Sicherheitssysteme) in einem Produktionswerk oder einer Prozessanlage installieren, konfigurieren und integrieren. Es liegt am Schnittpunkt von ingenieurtechnischem Projektmanagement, IT-Projektmanagement und betrieblichem Projektmanagement, schöpft aus allen dreien, geht aber in keinem davon auf, denn Automatisierungsprojekte haben besondere Eigenschaften, die generische Projektmanagementansätze nicht vollständig abdecken.

Die Definition und wo Automatisierungsprojekte einzuordnen sind

Ein Automatisierungsprojekt beginnt, wenn eine Fertigungsorganisation beschließt, neue Leittechnik zu installieren oder bestehende Leitsysteme zu modernisieren, und endet, wenn das installierte System sicher und zuverlässig in der Produktion läuft und die zu Beginn definierten betrieblichen Anforderungen erfüllt. Der Umfang umfasst typischerweise Auswahl und Beschaffung der Hardware, Konfiguration und Programmierung der Software, Integration mit bestehenden Anlagensystemen, Tests in mehreren Stufen, Validierung von Sicherheit und Cybersicherheit, Bedienerschulung und formelle Übergabe an den Betrieb. Häufige Projekttypen sind Greenfield-Installationen (neue Anlage, keine Altlasten), Brownfield-Modernisierungen (Austausch veralteter Leitsysteme bei laufender Anlage), Kapazitätserweiterungen (neue Produktionslinien in einer bestehenden Automatisierungsarchitektur) und Aufrüstungen von Sicherheitssystemen (Anhebung bestehender Installationen auf aktuelle Normen wie IEC 61511 Edition 2).

Wie sich Automatisierungsprojekte von typischen Fertigungsprojekten unterscheiden

Ein Automatisierungsprojekt ist kein typisches Fertigungsprojekt, obwohl es innerhalb eines Produktionsunternehmens stattfindet. Vier Unterschiede sind entscheidend. Erstens ist das Ergebnis ein System und kein Produkt: Das Resultat ist eine funktionierende Automatisierungsarchitektur, kein einzelnes verkaufsfertiges Produkt, sodass sich die Erfolgskriterien auf die Betriebsleistung konzentrieren und nicht auf Produkteigenschaften. Zweitens ist die Arbeit von Natur aus multidisziplinär in einer Weise, wie es gewöhnliche Fertigungsprojekte nicht sind: Mechanik, Elektrik, Steuerungssoftware, IT-Infrastruktur und Verfahrenstechnik müssen auf denselben Installationstermin zulaufen, oft mit verschiedenen Auftragnehmern, die unterschiedliche Disziplinen verantworten. Drittens ist die Validierungsreihenfolge verbindlich und unumkehrbar: FAT vor SAT vor Inbetriebnahme, ohne mögliche Abkürzungen, weil die physischen Abhängigkeiten die Reihenfolge erzwingen. Viertens tragen Anforderungen an Sicherheit und Compliance oft ein regulatorisches Gewicht, dem generische Fertigungsprojekte nicht in gleicher Intensität begegnen, von Normen der funktionalen Sicherheit über Cybersicherheitsanforderungen bis zu branchenspezifischen Vorschriften.

Wie sich Automatisierungsprojekte von IT-Projekten unterscheiden

Automatisierungsprojekte werden manchmal fälschlich wie IT-Projekte geführt, weil beide Software beinhalten. Die Unterschiede sind erheblich. IT-Projekte erlauben in der Regel iterative Bereitstellung, stufenweisen Rollout an Teilgruppen von Nutzern und Hotfixes nach der Freigabe. Automatisierungsprojekte werden in einer physischen Anlage bereitgestellt, in der die Software physische Prozesse mit realen Folgen steuert: eine im laufenden Betrieb gepatchte PLC in einem chemischen Reaktor ist nicht dieselbe Art von Änderung wie eine gepatchte Webanwendung. IT-Projekte lassen sich pausieren; laufende Anlagen oft nicht. Das Scheitern eines IT-Projekts führt typischerweise zu Datenverlust oder Nutzerunannehmlichkeiten; das Scheitern eines Automatisierungsprojekts kann Sicherheitsvorfälle, Umweltfreisetzungen oder Verstöße gegen Vorschriften verursachen. Deshalb existiert die Disziplin FAT-SAT-Inbetriebnahme und deshalb erzeugt ihre Verkürzung teure Folgen, die IT-Projektmanager anfangs möglicherweise nicht erkennen.

Die sechs Phasen eines Automatisierungsprojekts: von URS bis zur Inbetriebnahme

Automatisierungsprojekte folgen einer etablierten sechsphasigen Struktur, die branchenübergreifend zum Standard geworden ist, in der Chemie, Pharma, Lebensmittel- und Getränkeindustrie, Energie und der allgemeinen Fertigung. Die Phasen sind: Benutzeranforderungsspezifikation (URS), Funktions- und Detailspezifikation (FDS, DDS), Engineering und Bau, Werksabnahmetest (FAT), Installation und Standortabnahmetest (SAT) sowie Inbetriebnahme. Jede Phase hat definierte Eingaben, Ausgaben und Gate-Kriterien, und die Disziplin, Gate-Kriterien zwischen den Phasen durchzusetzen, trennt termingerecht gelieferte Automatisierungsprojekte von jenen, die ihr Budget in Nacharbeit in späten Phasen verbrauchen.

Phase 1: Benutzeranforderungsspezifikation (URS)

Die URS definiert, was das Automatisierungssystem aus betrieblicher Sicht leisten muss: Zieldurchsatz der Produktion, Produktspezifikationen, Steuerungsphilosophie, Sicherheitsanforderungen, regulatorische Randbedingungen, Erwartungen an die Bedienoberfläche und Integrationspunkte mit bestehenden Anlagensystemen und der Unternehmens-IT. Eine gut geschriebene URS ist, ähnlich wie ein Projektauftrag, funktional und nicht technisch: Sie beschreibt das gewünschte Ergebnis, ohne die technische Lösung vorzuschreiben. Die Qualität der URS ist der stärkste Einzelprädiktor für die Ergebnisse eines Automatisierungsprojekts, weil jede nachfolgende Phase Unklarheit oder Vollständigkeit aus diesem Dokument erbt. Projekte, die die URS überspringen oder als Formalität behandeln, entdecken bei SAT oder Inbetriebnahme wiederholt, dass verschiedene Beteiligte unterschiedliche Annahmen über grundlegende Funktionen hatten, und zu diesem Zeitpunkt sind die Kosten der Angleichung um Größenordnungen höher, als sie in der URS-Phase gewesen wären.

Phase 2: Funktions- und Detailspezifikation (FDS, DDS)

Die FDS übersetzt die URS in einen funktionalen Entwurf: welche PLC, welches SCADA, welche Netzwerktopologie, welche Regelkreise, welche sicherheitsgerichteten Funktionen, welche Alarme und wie sie miteinander und mit der Anlageninfrastruktur verbunden sind. Die DDS geht dann bis zur technischen Detailtiefe, die für Engineering und Beschaffung nötig ist: konkrete Hardwaremodelle, I/O-Zahlen, Verdrahtungspläne, Schaltschrankaufbau, Softwarearchitektur, HMI-Bildschirmentwürfe. Die Phasen FDS und DDS umfassen Designreviews mit dem Kunden, und die Freigabe am Ende der DDS ist das Design-Freeze-Äquivalent des Automatisierungsprojekts. Änderungen nach diesem Punkt erfordern formelles Änderungsmanagement und verlängern in der Regel den Terminplan.

Phase 3: Engineering und Bau

Engineering und Bau umfassen Hardwarebeschaffung, Schaltschrankbau, Softwareentwicklung (PLC-Code, SCADA-Bilder, Sicherheitslogik, Historian-Konfiguration), Installation der Netzwerkinfrastruktur sowie mechanische und elektrische Montage vor Ort. Diese Phase läuft parallel über mehrere Disziplinen und Lieferanten, und hier verbraucht die disziplinübergreifende Koordination den größten Teil der Aufmerksamkeit des Projektmanagers. Komponenten mit langer Lieferzeit, die während der FDS identifiziert wurden (Sonderinstrumente, sicherheitszertifizierte Steuerungen, spezialisierte Netzwerktechnik), müssen früh genug bestellt worden sein, damit das Engineering ohne Warten auf Hardware fortschreiten kann. Die Softwareentwicklung für PLC und SCADA erfolgt typischerweise nach der DDS parallel zur Hardwarebeschaffung, sodass beide gemeinsam für den FAT bereit sind.

Phase 4: Werksabnahmetest (FAT)

Der FAT findet im Werk des Lieferanten oder Integrators statt, vor dem Versand zum Standort. Das vollständige Leitsystem (PLC-Hardware, SCADA-Software, Sicherheitssysteme) wird in einer kontrollierten Umgebung mit simulierten Ein- und Ausgängen aufgebaut und getestet. Der FAT validiert, dass die Hardware der DDS entspricht, die Software die Funktionslogik korrekt umsetzt, Alarme und Verriegelungen sich wie entworfen verhalten, HMI-Bilder Informationen wie spezifiziert darstellen und die Integration zwischen Teilsystemen funktioniert. Der FAT ist die letzte kosteneffiziente Gelegenheit, Fehler zu entdecken: Korrekturen beim FAT kosten etwa zehnmal weniger als dieselben Korrekturen beim SAT und hundertmal weniger als bei der Inbetriebnahme entdeckte Fehler. Das Überspringen oder Verkürzen des FAT ist die häufigste Einzelursache für teure Projektüberschreitungen in der Automatisierung.

Phase 5: Installation und Standortabnahmetest (SAT)

Nach der FAT-Freigabe wird das System zum Standort versandt, von mechanischen und elektrischen Auftragnehmern installiert und durchläuft den SAT. Der SAT verifiziert, dass die Installation den Zeichnungen entspricht, physische I/O korrekt mit Instrumenten und Aktoren verbunden sind, die Integration mit bestehenden Anlagensystemen wie entworfen funktioniert und durchgängige Funktionstests unter realen Installationsbedingungen bestehen. Bei SCADA- und kontinuierlichen Prozessprojekten umfasst der SAT häufig einen verlängerten Probelauf von ein bis zwei Wochen, um stabilen Betrieb ohne größere Probleme nachzuweisen. Wenn mehrere Teilsysteme verschiedener Lieferanten gemeinsam getestet werden müssen, wird nach den einzelnen SATs ein Standort-Integrationstest (SIT), formell eingeführt in IEC 62381:2024, durchgeführt, um den integrierten Betrieb nachzuweisen.

Phase 6: Inbetriebnahme

Bei der Inbetriebnahme wird das validierte System in die laufende Produktion überführt. Die Kaltinbetriebnahme testet Systeme ohne Prozessmaterial oder mit unbedenklichen Medien. Die Warminbetriebnahme führt schrittweise reales Prozessmaterial ein, mit Abstimmung der Regelkreise und Sequenzen und Optimierung auf die Zielleistung. Die Inbetriebnahme endet mit der formellen Übergabe an den Betrieb, die abgeschlossene Bedienerschulung, Dokumentationslieferung (As-built-Zeichnungen, Betriebsanleitungen, Wartungsanweisungen), Ersatzteilverfügbarkeit und die Erfüllung vereinbarter Abnahmekriterien erfordert. Supportzeiträume nach der Inbetriebnahme (typischerweise 30 bis 90 Tage) erlauben es dem Integrator, Probleme zu beheben, die erst unter realen Produktionsbedingungen auftreten.

Das Validierungsrückgrat: FAT, SAT, SIT und Inbetriebnahme

Die Validierungsstufen zwischen dem Ende des Engineerings und dem Beginn der stabilen Produktion bilden die prägende Disziplin des Projektmanagements in der Automatisierung. Ihre Reihenfolge ist verbindlich und lässt sich nicht verkürzen: Hardware und Software müssen zuerst in einer kontrollierten Umgebung validiert werden (FAT), dann in der installierten Umgebung verifiziert (SAT), dann mit benachbarten Teilsystemen integriert (SIT) und schließlich unter realen Prozessbedingungen nachgewiesen werden (Inbetriebnahme). Jede Stufe hat andere Ziele, andere Abnahmekriterien und dramatisch andere Ökonomie beim Entdecken und Beheben von Fehlern.

FAT: Fehler am günstigsten Punkt entdecken

Der Werksabnahmetest findet im Werk des Lieferanten statt, im Beisein des Kunden oder eines unabhängigen Prüfers. Das vollständige Leitsystem, oder eine funktional vollständige Teilmenge, wird auf dem Prüfstand des Lieferanten aufgebaut und gegen eine simulierte Anlagenumgebung mit I/O-Simulatoren, HMI-Stimulation und aus der FDS abgeleiteten Funktionstestskripten geprüft. Der typische FAT-Umfang deckt die I/O-Verifizierung und den Loop-Check ab (jeder Ein- und Ausgangskanal funktioniert und ist korrekt zugeordnet), Tests der Steuerungslogik und Funktionen (Verriegelungen, Freigaben, Alarme, Abläufe gegen P&IDs und die Funktionsspezifikation validiert), Hardware- und Verdrahtungsinspektion (Schaltschrankmaße, Aderkennzeichnung, Erdung, Bauteilmontage), Kalibrier- und Instrumentenprüfungen sowie Cybersicherheitsvalidierung für netzwerkverbundene Systeme. Ein ordnungsgemäß durchgeführter FAT dauert je nach Systemkomplexität typischerweise ein bis fünf Tage im Werk des Lieferanten. Der wirtschaftliche Grund für einen gründlichen FAT ist klar: Fehler im Werk zu beheben kostet typischerweise um Größenordnungen weniger als im Feld, weil die Korrektur im Werk keinen Einfluss auf den Anlagenterminplan hat, keine Standortlogistikkosten, keine Betriebsunterbrechung und keine erneute Mobilisierung von Gewerken.

SAT: reale Installation und Integration verifizieren

Der Standortabnahmetest findet nach der Installation in den Räumlichkeiten des Kunden statt. Er bestätigt, dass die Installation den Zeichnungen entspricht, dass physische I/O korrekt mit Instrumenten und Aktoren in der realen Anlage verbunden sind, dass die Integration mit bestehenden Anlagensystemen (vor- und nachgelagerte Prozesse, MES-, ERP-Schnittstellen) wie entworfen funktioniert und dass durchgängige Funktionstests unter realen Installationsbedingungen bestehen. Der SAT deckt häufig Probleme auf, die der FAT nicht erfassen konnte: falsch verdrahtete Instrumente, fehlerhafte Feldgerätekonfigurationen, Integrationsdiskrepanzen mit Altsystemen, EMV-Störungen durch benachbarte Anlagen. Der SAT bei SCADA- und kontinuierlichen Prozessinstallationen umfasst typischerweise einen verlängerten Stabilitätslauf von ein bis zwei Wochen, um nachzuweisen, dass das System ohne größere Probleme kontinuierlich läuft. Die SAT-Freigabe ist das Gate zur Inbetriebnahme.

SIT: mehrere Teilsysteme integrieren

Moderne Industrieanlagen verlassen sich selten auf eine einzige Automatisierungsplattform. Eine typische Prozessanlage integriert mehrere PLCs, DCS-Steuerungen, sicherheitsgerichtete Systeme, Brand- und Gasmeldesysteme, Package-Einheiten, Motorsteuerungszentren, Frequenzumrichter, Analysatoren, elektrische Schutzsysteme, Historians, Asset-Management-Systeme und Bedienerarbeitsplätze, oft von verschiedenen Lieferanten. Jedes Teilsystem kann FAT und SAT einzeln bestehen, aber sobald die Systeme reale Prozessdaten auszutauschen beginnen, treten häufig Integrationsprobleme auf. Der Standort-Integrationstest (SIT), formell als Standardstufe in IEC 62381:2024 eingeführt, testet alle Automatisierungsteilsysteme im Zusammenspiel als eine Prozessleitlösung. Der SIT ist die passende Antwort auf die Komplexität mehrerer Lieferanten, die einzelne FATs und SATs nicht bewältigen können.

Inbetriebnahme: Produktionsreife nachweisen

Die Inbetriebnahme überführt das validierte System in die laufende Produktion. Die Kaltinbetriebnahme prüft das System ohne Prozessmaterial oder mit unbedenklichen Simulanzien: Pumpen laufen, Ventile fahren, Sequenzen laufen ab, Alarme melden, aber kein Produkt ist gefährdet. Die Warminbetriebnahme führt schrittweise reales Prozessmaterial ein, stimmt Regelkreise ab (PID-Parameter, Kaskadenkonfigurationen, Vorsteuerungen) und optimiert Sequenzen (Chargenrezepte, Anfahr- und Abfahrprozeduren) auf die Zielleistung. Die Inbetriebnahme ist der Moment, in dem die aufsummierte Qualität von URS, FDS, Engineering, FAT und SAT sichtbar wird: Ein Projekt, das die früheren Phasen richtig gemacht hat, wird in Tagen oder Wochen in Betrieb genommen, während ein Projekt, das frühere Phasen übersprungen oder verkürzt hat, Monate in der Inbetriebnahme mit dem Beheben von Problemen verbringen kann, die weiter oben hätten entdeckt werden müssen.

Multidisziplinäre Koordination in Automatisierungsprojekten

Automatisierungsprojekte sind von Natur aus multidisziplinär in einer Weise, wie es gewöhnliche Fertigungsprojekte nicht sind, ein Bereich, in dem Prinzipien des schlanken Projektmanagements helfen. Ein typisches mittelgroßes Automatisierungsprojekt umfasst mindestens fünf verschiedene Ingenieurdisziplinen, die parallel arbeiten, oft aus verschiedenen Unternehmen, die alle auf dieselben Installations- und Inbetriebnahmetermine zulaufen müssen. Die Koordination der Übergaben zwischen diesen Disziplinen beansprucht den größten Teil der Aufmerksamkeit des Automatisierungsprojektmanagers, und die Reduzierung von Reibung bei den Übergaben ist der größte Hebel auf die gesamte Projektdauer.

Maschinenbau und Bau

Mechanische Auftragnehmer installieren die physische Infrastruktur, von der die Automatisierung abhängt: Rohrleitungen, Ventile, Aktoren, Motorhalterungen, Instrumentenständer, Kabelpritschen. Ihre Arbeit läuft vor der Elektro- und Leitsysteminstallation ab, und Verzögerungen im mechanischen Bau pflanzen sich in jede nachgelagerte Disziplin fort. Der mechanische Umfang umfasst auch die Bereitstellung der pneumatischen und hydraulischen Versorgung, die Instrumente und Aktoren benötigen, was mit Instrumentenauswahl und -installation koordiniert werden muss, um Diskrepanzen bei der Inbetriebnahme zu vermeiden.

Elektrotechnik und Installation

Elektrische Auftragnehmer installieren Energieverteilung, Motorsteuerungszentren, Kabelführung, Schaltschrankverdrahtung und Feldgeräteanschlüsse. Ihre Abfolge folgt dem mechanischen Bau und geht der Inbetriebnahme des Leitsystems voraus. Elektrische Auftragnehmer verantworten typischerweise auch das Erdungs- und Potentialausgleichskonzept, das sowohl für die Sicherheit (elektrischer Schutz) als auch für die Zuverlässigkeit des Leitsystems (Störunterdrückung auf Signalkabeln) entscheidend ist. Die Koordination zwischen elektrischen Auftragnehmern und Leitsystemintegratoren rund um Kabellisten, Schaltschrankaufbauten und Klemmenlisten ist eine dauerhafte Reibungsquelle im Projekt, um die erfahrene Automatisierungsprojektmanager herumplanen.

Leitsystem-Engineering und Integration

Der Leitsystemintegrator verantwortet Auswahl und Programmierung der PLC-Hardware, SCADA-Konfiguration und Bildentwicklung, Entwurf und Validierung des Sicherheitssystems, Netzwerkarchitektur, Historian- und Berichtskonfiguration. Dies ist die Disziplin, die die Automatisierungsfunktionalität, die der Betrieb nutzen wird, am unmittelbarsten liefert. Leitsystemintegratoren vergeben spezifische Elemente (Programmierung des Sicherheitssystems, Cybersicherheitsbewertung, Netzwerkentwurf) häufig an spezialisierte Firmen, was eine weitere Koordinationsebene hinzufügt, die der Projektmanager steuern muss.

IT- und OT-Netzwerktechnik

Moderne Automatisierungssysteme sind netzwerkintegriert und erfordern eine eigene Netzwerkinfrastruktur, getrennt von der Unternehmens-IT, mit definierten Schnittstellen dort, wo sie sich überschneiden. Die IT/OT-Netzwerktechnik umfasst die Architektur des Steuerungsnetzwerks (typischerweise Varianten von Industrial Ethernet), die Segmentierung zwischen Steuerungs- und Unternehmenszone, Cybersicherheitsmaßnahmen nach IEC 62443, Regelungen für Fernzugriff und die Integration mit Anlagen-Historian und MES-Systemen. IT/OT-Ingenieure standen historisch außerhalb von Automatisierungsprojekten und wurden spät eingebunden, doch moderne Projekte profitieren davon, sie ab der URS einzubeziehen, weil Netzwerkentscheidungen den physischen Schaltschrankentwurf und die Kabelführung beeinflussen.

Verfahrenstechnik und Betrieb

Verfahrensingenieure liefern die Steuerungsphilosophie, die PLC und SCADA umsetzen: welche Kreise welche Regelstrategie brauchen, welche Verriegelungen vor welchen Ausfallmodi schützen, welche Alarme Bediener sehen müssen. Der Betrieb steuert das betriebliche Wissen bei, das zum Inhalt der URS wird: wie die Anlage tatsächlich läuft, was Bediener auf ihren Bildschirmen brauchen, welche Sequenzen welche Optionen benötigen, welche Informationen zur Fehlersuche um drei Uhr morgens helfen. Automatisierungsprojekte, die Verfahrenstechnik und Betrieb von der URS bis zur Inbetriebnahme eingebunden halten, übertreffen durchgängig Projekte, die sie als konsultierte Stakeholder und nicht als aktive Projektbeteiligte behandeln.

Häufige Fallstricke in Automatisierungsprojekten

Fünf Fehlermuster treten wiederholt über Automatisierungsprojekte hinweg auf, unabhängig von der Branche, und jedem lässt sich mit konkreten Gegenmaßnahmen vorbeugen. Die Muster zu benennen macht sie in künftigen Projekten früher erkennbar, wenn sie sich für einen Bruchteil der Kosten ihrer Behebung bei der Inbetriebnahme abfangen lassen.

Unzureichend spezifizierte URS ins Engineering übernommen

Das erste Muster ist, die URS als frühe Formalität zu behandeln statt als Fundament, auf dem das gesamte Projekt ruht. Die URS wird schnell entworfen, um das Engineering freizugeben, Unklarheiten bleiben im Dokument mit der Annahme, dass sie später geklärt werden, und das Engineering schreitet gegen einen unzureichend definierten Anforderungssatz voran. Die Folgen zeigen sich bei SAT und Inbetriebnahme: Der Betrieb entdeckt, dass das System etwas nicht tut, was er für selbstverständlich hielt, oder etwas tut, was er nie wollte, und die Behebung erfordert eine Neukonstruktion, die eine ordentliche URS verhindert hätte. Die Gegenmaßnahme ist, die Kalenderzeit für eine gründliche URS mit ausdrücklicher Stakeholder-Freigabe und definierten Abnahmekriterien vor Beginn des Engineerings zu investieren, auch wenn es das Projekt zu verzögern scheint.

Verkürzter oder übersprungener FAT

Das zweite Muster ist, den FAT als optionalen Schritt zu behandeln, den man verkürzen kann, wenn der Terminplan unter Druck steht. Der Lieferant hat die Software fertiggestellt und die Hardware ist aufgebaut, aber der Kunde entscheidet, dass der FAT unnötig sei, weil der Lieferant intern gut teste, oder dass der FAT auf eine Vorführung statt eines vollständigen Funktionstests verkürzt werden könne. Die Folgen erscheinen bei SAT und Inbetriebnahme, wo jeder Fehler, den der FAT abgefangen hätte, nun zehn- bis hundertmal mehr zu beheben kostet. Die Gegenmaßnahme ist, den FAT unabhängig vom Termindruck als nicht verhandelbar zu behandeln und den FAT-Umfang so konkret zu strukturieren, dass eine Vorführung nicht als Test durchgehen kann.

Lücken in der Mehrlieferantenkoordination ohne SIT

Das dritte Muster ist anzunehmen, dass einzelne FATs und SATs der Lieferanten ausreichen, wenn mehrere Teilsysteme zusammenarbeiten müssen. Das System jedes Lieferanten besteht seine eigenen Tests, aber die Schnittstellen zwischen den Systemen wurden nicht gemeinsam validiert, und Integrationsprobleme treten während der Inbetriebnahme auf, wenn ihre Lösung am teuersten ist. Die Gegenmaßnahme ist, einen ausdrücklichen Standort-Integrationstest zu planen, wenn das Projekt mehrere Teilsysteme verschiedener Lieferanten umfasst, und den SIT-Umfang bereits während der URS zu definieren, damit die Lieferanten wissen, dass sie vertraglich zur Teilnahme an integrierten Tests verpflichtet sind und nicht nur zur Validierung des eigenen Teilsystems.

Verzögerungen benachbarter Gewerke, die in die Automatisierung überschwappen

Das vierte Muster ist, die Dauer des Automatisierungsprojekts so zu behandeln, als wäre sie unabhängig von den anderen Gewerken am Standort. Der mechanische Bau verzögert sich, die Elektroinstallation verzögert sich, und das Automatisierungsteam trifft ein, um den SAT zu beginnen, nur um festzustellen, dass die Anlage nicht bereit ist, es aufzunehmen. Die Terminpläne des Automatisierungsteams können sich in der Regel nicht in dieselbe Richtung verschieben, weil die Inbetriebnahmefenster an Anlagenstillstände oder Anfahrfenster gebunden sind, die lange im Voraus festgelegt wurden. Die Gegenmaßnahme ist, die Terminpläne des Automatisierungsprojekts ausdrücklich mit den mechanischen und elektrischen Terminplänen zu integrieren, mit Meilensteinen für die Bereitschaft jedes Gewerks für Automatisierungstätigkeiten und mit Eskalationsauslösern, wenn ein Gewerk über den Puffer hinaus rutscht.

Aufgeschobene Validierung von Sicherheit und Cybersicherheit

Das fünfte Muster ist, funktionale Sicherheitstests und Cybersicherheitsvalidierung als zeremonielle Aktivitäten am Ende zu behandeln statt als kontinuierliche Arbeitsströme über das gesamte Projekt. Sicherheitsgerichtete Funktionen erfordern eine Validierung gegen die Sicherheitsanforderungsspezifikation über den gesamten Lebenszyklus, vom Entwurf über FAT und SAT bis zur Inbetriebnahme, und Cybersicherheit nach IEC 62443 erfordert ebenso Maßnahmen zur Entwurfszeit statt eines Audits am Projektende. Die Gegenmaßnahme ist, Arbeitsströme für Sicherheit und Cybersicherheit mit ausdrücklichen Ergebnissen je Phase zu definieren, sie getrennt vom Funktionstest zu besetzen und die Abnahme von Sicherheit und Cybersicherheit als eigene Gates zu behandeln statt als Punkte auf der allgemeinen Abnahmeliste.

Sicherheit und Compliance in Automatisierungsprojekten

Automatisierungsprojekte agieren in regulatorischen und normativen Rahmen, denen generische Fertigungsprojekte selten in gleicher Intensität begegnen. Funktionale Sicherheit, Cybersicherheit, branchenspezifische Vorschriften und Industrienormen stellen alle Anforderungen, die von der URS an in die Projektstruktur eingebaut werden müssen, nicht bei der Inbetriebnahme nachgerüstet. Ein Compliance-Versagen bei der Übergabe ist bestenfalls teuer und blockiert schlimmstenfalls den Betrieb, und die Disziplin, Compliance in den Projektablauf einzubauen, trennt Automatisierungsprojektmanager, die termingerecht liefern, von jenen, die den letzten Monat mit der Suche nach Auditnachweisen verbringen.

Funktionale Sicherheit nach IEC 61511 und IEC 61508

Sicherheitsgerichtete Systeme in der Prozessindustrie folgen der IEC 61511 (mit IEC 61508 als zugrunde liegender Norm). Die Lebenszyklusanforderungen umfassen Gefahren- und Risikoanalyse, Zuordnung von Sicherheitsfunktionen zu sicherheitsgerichteten Funktionen (SIF) mit Sicherheitsintegritätsleveln (SIL), Sicherheitsanforderungsspezifikation, Entwurf und Engineering mit SIL-Verifizierung, Validierung bei Installation und Inbetriebnahme sowie Betriebs- und Wartungsprozeduren. Sicherheit lässt sich nicht bei der Inbetriebnahme ergänzen; sie muss in jeder Phase vorhanden sein. Automatisierungsprojekte, die Sicherheit ab der URS als eigenen Arbeitsstrom behandeln, erzeugen auditfähige Ergebnisse als natürlichen Output des Projekts, während Projekte, die Sicherheit als abschließende Abnahmetätigkeit behandeln, typischerweise spät entdecken, dass Dokumentationslücken oder Entwurfsprobleme Nacharbeit erfordern.

Cybersicherheit nach IEC 62443

Industrielle Automatisierungs- und Leitsysteme sehen sich Cybersicherheitsbedrohungen gegenüber, die IT-Sicherheitsrahmen nicht vollständig abdecken. Die IEC 62443 definiert Cybersicherheitsanforderungen für die industrielle Automatisierung, einschließlich Netzwerksegmentierung zwischen IT- und OT-Zonen, sicherem Fernzugriff, Patch-Management für Leitsysteme, Protokollierung von Sicherheitsereignissen und Schwachstellenmanagement. Cybersicherheitsanforderungen müssen während der URS definiert und in FDS, DDS und Engineering abgebildet werden. Cybersicherheit bei der Inbetriebnahme nachzurüsten ist teuer und liefert selten zufriedenstellende Ergebnisse, weil die grundlegenden Architekturentscheidungen bereits getroffen wurden.

Branchenspezifische Vorschriften

Verschiedene Industriebranchen fügen Automatisierungsprojekten spezifische Compliance-Anforderungen hinzu. Pharma- und Life-Sciences-Projekte folgen EU-GMP Annex 15, der die Rollen von FAT und SAT in der Qualifizierung ausdrücklich anerkennt und dokumentierte Nachweise für kritische Instrumentierung, Kalibrierung und Prozessverifizierung verlangt. FDA 21 CFR Part 11 gilt für elektronische Aufzeichnungen und Signaturen in den Life Sciences. Lebensmittel- und Getränkeprojekte folgen HACCP-Prinzipien mit branchenspezifischen Normen für hygienegerechte Gestaltung und Rückverfolgbarkeit. Energie- und Versorgungsprojekte folgen NERC CIP für die Cybersicherheit des Netzes. Projekte der allgemeinen Industrie erfordern den Nachweis der CE-Kennzeichnung und einschlägige ISO-Normen für Sicherheit, Leistung und technische Spezifikationen. Branchenanforderungen müssen während der URS identifiziert werden, und der Projektterminplan muss die Audit- und Dokumentationstätigkeiten berücksichtigen, die sie auferlegen.

Mehrere Automatisierungsprojekte auf Portfolioebene managen

Ein Ingenieurbüro, das Automatisierungsprojekte liefert, oder ein Hersteller mit mehreren gleichzeitigen Automatisierungsinitiativen, hat selten nur ein Projekt in Arbeit. Typischer umfasst das Portfolio mehrere Projekte in verschiedenen Phasen, die um dieselben Ingenieurtalente, Testeinrichtungen, Integratorkapazitäten und Inbetriebnahmefenster konkurrieren. Die Portfoliosicht ist der Ort, an dem Projektmanagement in der Automatisierung von einer Projektdisziplin zu einer organisatorischen Fähigkeit wird, und wo die größten Zuwächse im Gesamtdurchsatz verfügbar sind.

Das Portfolio-Dashboard für Automatisierungsprojekte

Ein Portfolio-Dashboard für Automatisierungsprojekte zeigt alle aktiven Projekte kategorisiert nach Phase (URS, FDS, Engineering, FAT, SAT, Inbetriebnahme), mit Einblick, welche Projekte sich Gate-Reviews nähern, welche blockiert sind und wie viele in jeder Phase stehen. Das Dashboard offenbart Muster, die Einzelprojektsichten verbergen: systematische Engpässe bei der FAT-Terminierung mit demselben Integrator, Inbetriebnahmefenster, die sich in schmalen Kalenderbändern häufen, Ressourcenkonkurrenz bei spezialisierten Fähigkeiten wie der Programmierung von Sicherheitssystemen. Mustererkennung auf Portfolioebene treibt systemische Verbesserung an statt reaktiver Brandbekämpfung je Projekt.

Ressourcenkonkurrenz bei spezialisierten Fähigkeiten

Automatisierungsprojekte hängen von spezialisierten Fähigkeiten ab, die oft knapp sind: Programmierer für Sicherheitssysteme, Cybersicherheitsspezialisten, Netzwerkarchitekten, Experten für bestimmte PLC-Plattformen, Inbetriebnahmeingenieure mit Branchenerfahrung. Geteilte Ressourcen werden zur größten Quelle ungeplanter Verzögerungen über ein Mehrprojektportfolio hinweg. Ressourcenkonkurrenz, die auf Projektebene unsichtbar ist, wird auf Portfolioebene sichtbar, wo derselbe Spezialist, der gleichzeitig in mehreren Projektterminplänen auftaucht, die Doppelbuchung offenlegt, die einzelne Projektmanager nicht sehen können. Effektives Portfoliomanagement erkennt diese Engpässe früh und fügt entweder Kapazität hinzu, ordnet Projekte an, um die Konkurrenz zu verringern, oder akzeptiert die Verzögerungen als sichtbare Portfolioentscheidungen.

Standardisierung über Projekte hinweg

Reife Portfolios von Automatisierungsprojekten standardisieren wiederkehrende Elemente: URS-Vorlagen nach Projekttyp, FDS-Strukturen, Formate für FAT-Testskripte, SAT-Abnahmekriterien, Inbetriebnahme-Checklisten, Vorlagen für Sicherheitsdokumentation, Verfahren zur Cybersicherheitsbewertung. Standardisierung verhindert das Neuerfinden routinemäßiger Elemente in jedem Projekt und macht Ingenieuraufmerksamkeit für die Teile frei, die sich wirklich unterscheiden. Standardisierung ermöglicht auch projektübergreifendes Lernen: Ein beim FAT eines Projekts aufgedecktes Fehlermuster aktualisiert die Vorlagen, sodass nachfolgende Projekte dieselbe Fehlerklasse früher abfangen. Ingenieurbüros mit reifer Standardisierung liefern Projekte schneller und mit weniger Variabilität als Firmen, in denen jedes Projekt seinen eigenen Ansatz neu erfindet.

Kapazitätsplanung und Angebotsentscheidungen auf Portfolioebene

Einblick auf Portfolioebene in die aktuelle Projektauslastung und die prognostizierte Ressourcenverfügbarkeit unterstützt die kaufmännischen Entscheidungen, die Ingenieurbüros fortlaufend treffen: welche Angebote abzugeben, welche Liefertermine zuzusagen, wann einzustellen, wann zu bestimmten Gelegenheiten Nein zu sagen. Firmen ohne Kapazitätsdaten auf Portfolioebene übernehmen sich typischerweise in optimistischen Phasen und halten sich in konservativen Phasen zurück, wobei die resultierende Liefervariabilität Kundenbeziehungen und Mitarbeiterbindung beeinträchtigt. Firmen mit Portfoliodaten können Angebotsentscheidungen auf Basis der tatsächlichen Lieferkapazität treffen statt auf Basis von Optimismus darüber, wie viel das Team verkraften kann.

Fallstudie A: Smart Automation, disziplinierte Portfoliodurchführung

Smart Automation ist ein Ingenieurbüro aus Olsztyn, Polen, das seit 2009 in der industriellen Automatisierung tätig ist. Die Firma entwirft und liefert komplette Automatisierungssysteme, von Maschinenkonzepten und Machbarkeitsanalysen über die Programmierung von Leitsystemen und Bildverarbeitungssysteme bis zur robotergestützten Prozessautomatisierung und zum Bau spezialisierter Maschinen. Die Teamerfahrung summiert sich auf über 300 Jahre in Automatisierung, Robotik und Mechatronik. Die Firma hat mehr als 1.000 Projekte für Kunden wie IKEA, Michelin, Siemens Energy, Unilever und Danone abgeschlossen, was in der Praxis mehrere Dutzend gleichzeitige Projekte zu jedem Zeitpunkt bedeutet, unterschiedlich in Umfang, Komplexität und Standort.

Der Ausgangspunkt vor der FlexiProject-Einführung war für Ingenieurbüros vertraut: Budgets wurden in Lösungen rund um das ERP-System geführt, weil dort Rechnungen, Zahlungen und Kosten liegen, aber jeder Projektmanager hatte einen persönlichen Ansatz zur Finanzkontrolle entwickelt. Werkzeuge für Terminplanung, Risikoüberwachung und Ressourcenplanung fehlten im Wesentlichen. Es gab keine vollständige Sicht auf ein einzelnes Projekt, geschweige denn auf das gesamte Portfolio. Die Firma beschloss, ein dediziertes Projektmanagementsystem zu suchen, das Terminpläne, Budgets, Risiken und Ressourcen an einem Ort vereint und zur einzigen Informationsquelle über Projekte wird.

Die Einführung erfasste die gesamte Organisation. Innerhalb von drei Monaten wurden alle 51 aktiven Projekte unterschiedlicher Komplexität in FlexiProject überführt. Alle Mitarbeitenden und wichtigen Subunternehmer nutzen das System heute, insgesamt 37 Personen, was durch einen flexiblen Lizenzpool praktikabel wurde. Wichtiger noch: Die Firma verstand die Einführung als Gelegenheit, einen gemeinsamen Projektmanagementstandard aufzubauen, nicht nur ein Werkzeug zu ersetzen. Jedes Projekt beginnt nun gleich: mit einem Projektauftrag, der Ziele, Umfang und Verantwortlichkeiten definiert, und mit einem Phasenmodell, das die Arbeit vom Konzept bis zur Übergabe ordnet. Terminpläne werden aus einer gemeinsamen Vorlage mit Gantt-Abhängigkeiten und Meilensteinen erstellt, und jeder Plan wird als Basisplan gespeichert: ein genehmigter Referenzpunkt, an dem Termin- und Kostenabweichungen gemessen werden.

Die Budgetdaten mussten mit dem ERP-System konsistent bleiben, daher wurde FlexiProject so mit dem ERP integriert, dass Kosteninformationen ohne Doppelerfassung zwischen den Systemen fließen. Über die Projekte hinaus erlaubte die flexible Struktur, den Angebotsprozess sowie Garantie- und Nachgarantieservice abzubilden. Zwei Faktoren trieben die Akzeptanz. Erstens agierte der Geschäftsführer als aktiver Projektsponsor, verlangte konsequent, dass alle Projektinformationen in einem System leben, und erwartete regelmäßige Aktualisierungen von jedem Projektmanager. Zweitens war die Einstiegshürde niedrig: Terminpläne und Budgets aufzubauen war intuitiv genug, dass jeder Projektmanager unabhängig von der Erfahrung die Schulung mit dem Eintragen eines eigenen realen Projekts beginnen konnte statt an künstlichen Beispielen zu üben. Die Ergebnisse zeigen sich in Entscheidungen: Budgetabweichungen mit Prognose bis zur Fertigstellung, Ressourcenauslastung als Eingabe für Angebotsentscheidungen und Einstellungspläne, Projektreviews alle zwei Wochen für aktive Projekte und monatlich für Projekte in der Planungsphase, alle auf Basis von Daten im System statt manuell erstellter Präsentationen.

Fallstudie B: Teslas Model-3-Automatisierungskrise, 2017-2018

Der Produktionshochlauf von Teslas Model 3 zwischen 2017 und 2018 ist eines der öffentlich am besten dokumentierten Scheitern eines Automatisierungsprojekts in der Industriegeschichte, ungewöhnlich durch Elon Musks Bereitschaft, es in eigenen Worten einzuräumen. Das Model 3 wurde 2016 als Teslas erstes Massenmarktfahrzeug zu einem Zielpreis von 35.000 USD angekündigt, und innerhalb von 24 Stunden nach dem Start hatten 115.000 Menschen Reservierungen abgegeben. Tesla setzte sich das ehrgeizige Produktionsziel von 5.000 Model-3-Fahrzeugen pro Woche bis Ende 2017 und verfolgte einen Ansatz, den Musk später als „alles automatisieren” beschrieb, in der Wette, dass eine umfangreiche Automatisierung das Volumen ermöglichen würde, das zur Bedienung des Vorbestellungsstaus nötig war.

Das Ergebnis war das, was Musk selbst „Produktionshölle” nannte. Tesla verfehlte das Ziel für Ende 2017 deutlich und produzierte im gesamten vierten Quartal 2017 2.425 Model-3-Fahrzeuge (gegenüber einem Ziel von 5.000 pro Woche). Das revidierte Ziel für Ende des ersten Quartals 2018 von 2.500 pro Woche wurde ebenfalls verfehlt, wobei Tesla in der letzten Woche des Q1 2.020 erreichte. Sowohl die Batteriemodulmontage in der Gigafactory als auch die Endmontagelinie in Fremont hatten Automatisierungsentwürfe, die sich bei Produktionsvolumen als unzuverlässig erwiesen. Bernstein-Analysten argumentierten öffentlich, dass die Überautomatisierung Teslas Fehler in die Produktionslinie einbrannte und mehr kostete, als sie einbrachte. Am 13. April 2018 räumte Musk öffentlich auf Twitter ein: „Ja, übermäßige Automatisierung bei Tesla war ein Fehler. Genauer gesagt, mein Fehler. Menschen werden unterschätzt.” In einem CBS-Interview beschrieb er den Rückbau eines „verrückten, komplexen Netzes von Förderbändern”, das nicht funktionierte, und Tesla kehrte schließlich Teile der Montagelinie zu manuellem Betrieb zurück, einschließlich der bekannten provisorischen „Zelt”-Montagelinie in Fremont, die Kapazität durch manuelle Arbeit statt durch weitere Automatisierung hinzufügte.

Drei Lehren lassen sich direkt auf jedes Automatisierungsprojekt übertragen. Erstens vervielfacht Automatisierungsehrgeiz ohne Pilotvalidierung das Risiko, statt es zu verringern: Teslas Entscheidung, neue Automatisierung im Produktionsmaßstab einzusetzen, bevor sie sie bei Pilotvolumen validierte, vervielfachte die Schwierigkeit jedes nachfolgenden Fehlersuchezyklus, während ein stufenweiser Hochlauf die Automatisierungsprobleme zu geringeren Kosten aufgedeckt hätte. Zweitens erzeugt die Überautomatisierung von Teilmontageschritten, die Anpassungsfähigkeit erfordern, schlechtere Ergebnisse als teilautomatisierte Alternativen, bei denen Menschen die Variation und Maschinen die wiederholbare Arbeit übernehmen: Dies ist ein bekanntes Prinzip der japanischen Fertigungspraxis, das Tesla unter Produktionsdruck faktisch wiederentdeckte. Drittens erzeugen Zusagen zum Projektterminplan, die davon ausgehen, dass die Technik wie beabsichtigt funktioniert, ohne ausreichenden Terminpuffer für das Aufdecken von Automatisierungsproblemen, einen Druck, der diszipliniertes Problemlösen eher erschwert als erleichtert. Tesla erreichte das Ziel von 5.000 pro Woche schließlich bis Ende Juni 2018 und verdoppelte den Gesamtausstoß von 2017 mehr als, aber der Preis, dies über eine Krise statt über einen disziplinierten Hochlauf zu erreichen, war beträchtlich.

Wie FlexiProject Automatisierungsprojekte unterstützt

FlexiProject unterstützt die Durchführungsebene des Projektmanagements in der Automatisierung mit Portfoliotransparenz, Terminplanmanagement, Risikoverfolgung, strukturierten Reviews und standardisierten Vorlagen. Die multidisziplinäre Koordination von Automatisierungsprojekten, insbesondere die Arbeit, die Funktionen aus Mechanik, Elektrik, Leitsystem, IT/OT und Verfahrenstechnik in Einklang zu bringen, bleibt in der Verantwortung der Organisation. FlexiProject liefert die operative Infrastruktur, die disziplinierte Durchführung von Automatisierungsprojekten im großen Maßstab handhabbar macht, keinen Ersatz für die ingenieurtechnische Zusammenarbeit, von der der Erfolg eines Automatisierungsprojekts abhängt.

Portfoliosicht für gleichzeitige Automatisierungsprojekte

FlexiProject bietet ein Portfolio-Dashboard, das alle aktiven Automatisierungsprojekte in einer Ansicht zeigt, kategorisiert nach Phase (URS, FDS, Engineering, FAT, SAT, Inbetriebnahme) und nach Kunde oder Geschäftsbereich, mit Einblick, welche Projekte sich Gate-Reviews nähern und welche blockiert sind. Die Portfoliosicht bringt Muster ans Licht, die Einzelprojektsichten verbergen, etwa Inbetriebnahmefenster, die sich in schmalen Kalenderbändern häufen, Ressourcenkonkurrenz bei spezialisierten Fähigkeiten und systematische Verzögerungen bei der FAT-Terminierung mit bestimmten Integratoren. Lenkungsausschüsse, die Entscheidungen auf Portfolioebene treffen, arbeiten aus derselben Portfoliosicht, statt unterschiedliche Projektberichte abzugleichen.

Terminplan mit Gantt-Diagramm, Aufgabenliste und Kanban

Der Terminplan in FlexiProject kombiniert eine Gantt-Diagramm-Ansicht für die Meilensteinverfolgung und die Visualisierung von Abhängigkeiten, eine Aufgabenlistenansicht für die detaillierte Durchführungsarbeit und eine Kanban-Ansicht für die Workflow-Disziplin innerhalb der Phasen. Automatisierungsprojekte profitieren von der Kombination: Das Gantt-Diagramm bewältigt die Struktur auf Phasenebene mit Abhängigkeiten von URS bis Inbetriebnahme und Gate-Review-Meilensteinen, Aufgabenlisten bewältigen die detaillierte Engineering- und Testarbeit innerhalb der Phasen, und Kanban verfolgt den Fluss konkreter Ergebnisse durch Prüfung und Freigabe. Warnsymbole an Terminplanaufgaben weisen auf Budget- oder Risikoprobleme hin, ohne separate Berichte zu erfordern.

Risikoregister, mit den Projektphasen verknüpft

Das Risikoregister in FlexiProject verfolgt automatisierungsspezifische Risiken mit Verantwortlichen, Minderungsplänen und Prüfungsrhythmus. Phasenspezifische Risiken (Verfügbarkeit von Komponenten mit langer Lieferzeit während des Engineerings, Lieferantenbereitschaft für den FAT, Standortbereitschaft für den SAT, Anlagenverfügbarkeit für die Inbetriebnahme, Validierung des Sicherheitssystems, Cybersicherheitsbewertung) sind mit den relevanten Phasenmeilensteinen verknüpft und werden am entsprechenden Gate geprüft. Die Verknüpfung zwischen Risiken, Aufgaben und Terminplan bedeutet, dass sich ein eintretendes Risiko sichtbar auf den zugehörigen Termin auswirkt, statt in einem separaten Register zu liegen, in das bei Terminentscheidungen niemand hineinschaut.

Projektreviews als Gate-Reviews

Projektreviews in FlexiProject lassen sich als formelle Gate-Reviews von Automatisierungsprojekten strukturieren, mit definierten Kriterien, strukturierter Nachweispräsentation und formellen Go/No-Go-Entscheidungen, die im Projektprotokoll festgehalten werden. Der Prüfungsrhythmus ist geplant (typischerweise am Ende jeder Projektphase und an jedem Übergang FAT/SAT/Inbetriebnahme), und die Prüfungsergebnisse fließen in standardisierte Vorlagen für Folgeprojekte ein. In den Vorlagen konfigurierte Gate-Kriterien gelten konsistent über Projekte desselben Typs, sodass ein FAT-Freigabegate eines Projekts dieselbe Kriterienstruktur nutzt wie ein FAT-Freigabegate eines anderen Projekts.

Standardisierte Vorlagen für Automatisierungsprojekte

FlexiProject bietet standardisierte Vorlagen für die wiederkehrende Struktur von Automatisierungsprojekten, mit dem Sechsphasenmodell, dem Validierungsrückgrat FAT-SAT-Inbetriebnahme, Standardergebnissen je Phase und für die Automatisierung passenden Standard-Gate-Kriterien. Ingenieurbüros können die Vorlagen anhand der Besonderheiten des Projekttyps erweitern (Greenfield, Brownfield-Modernisierung, Kapazitätserweiterung, Sicherheitsaufrüstung), ohne die zugrunde liegende Struktur aufzugeben. Vorlagenbasiertes Projektmanagement in der Automatisierung wirkt als digitales Äquivalent standardisierter Ingenieurpraxis: Es verhindert das Neuerfinden routinemäßiger Projektelemente und macht Ingenieuraufmerksamkeit für die Teile jedes Projekts frei, die sich wirklich unterscheiden.

Was FlexiProject nicht tut

FlexiProject führt kein Engineering durch (das ist die Arbeit des Leitsystemintegrators), führt weder FAT noch SAT durch (diese erfordern Prüfstände und Instrumentierung), qualifiziert keine Lieferanten (das erfordert Beschaffungs- und Qualitätsprozesse) und ersetzt nicht die Disziplin, Gate-Kriterien durchzusetzen (das erfordert das Engagement des Managements). Es liefert die Transparenz, Struktur und Rückverfolgbarkeit, die disziplinierte Durchführung von Automatisierungsprojekten über ein Portfolio hinweg handhabbar machen, aber die Disziplin selbst ist organisatorisch.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Projektmanagement in der Automatisierung und allgemeinem Projektmanagement?

Allgemeine Projektmanagementprinzipien gelten für Automatisierungsprojekte, aber Automatisierungsprojekte haben besondere Eigenschaften, die allgemeine Ansätze nicht vollständig abdecken: ein verbindliches sequenzielles Validierungsrückgrat (FAT vor SAT vor Inbetriebnahme), inhärente multidisziplinäre Komplexität über Mechanik, Elektrik, Steuerungssoftware, IT/OT und Verfahrenstechnik, Anforderungen an Sicherheit und Compliance mit regulatorischem Gewicht und Abhängigkeit von mehreren externen Lieferanten, deren Verzögerungen sich unvorhersehbar fortpflanzen. Automatisierungsprojektmanager haben in der Regel einen ingenieurtechnischen Hintergrund und spezifische Branchenerfahrung, weil der technische Inhalt der Entscheidungen die Projektergebnisse auf einer Ebene beeinflusst, die allgemeines Projektmanagement nicht ersetzen kann.

Wie lange dauert ein typisches Automatisierungsprojekt?

Das hängt von Umfang, Komplexität und Branche ab. Eine einfache Greenfield-Installation mit begrenzter Integration kann in sechs bis neun Monaten abgeschlossen sein. Eine typische Brownfield-Modernisierung mit Integration in bestehende Anlagensysteme dauert in der Regel zwölf bis achtzehn Monate. Große Investitionsprojekte mit neuartiger Technik oder sicherheitskritischen Elementen können zwei bis drei Jahre dauern. Der größte Einzeltreiber des Terminplans ist oft nicht die Engineering-Komplexität, sondern die Koordinationskomplexität: Projekte mit vielen Lieferanten und Disziplinen dauern länger als Projekte mit weniger Beteiligten, selbst wenn die technische Arbeit ähnlich ist.

Wem gehört das Automatisierungsprojekt?

Ein Automatisierungsprojektmanager verantwortet Terminplan, Koordination, Gate-Reviews und disziplinübergreifende Abstimmung, aber die Arbeit ist von Natur aus multidisziplinär, und keine einzelne Funktion kontrolliert sie. Mechanische Auftragnehmer verantworten die physische Infrastruktur, elektrische Auftragnehmer verantworten Stromversorgung und Verdrahtung, der Leitsystemintegrator verantwortet die Lieferung von PLC und SCADA, IT/OT-Ingenieure verantworten die Netzwerkinfrastruktur, Verfahrensingenieure verantworten die Steuerungsphilosophie, und der Betrieb verantwortet die Anforderungen, die das System erfüllen muss. Der Automatisierungsprojektmanager ist Koordinator und Integrator über diese Funktionen hinweg. Unterstützung durch die Geschäftsleitung ist unerlässlich, weil Gate-Entscheidungen kaufmännische und sicherheitsbezogene Auswirkungen haben, die über die Befugnis des Projektmanagers hinausgehen.

Was ist der Unterschied zwischen FAT und SAT?

Der FAT (Werksabnahmetest) wird im Werk des Lieferanten oder Integrators vor dem Versand zum Standort durchgeführt, mit simulierten Ein- und Ausgängen, um Hardware und Software in einer kontrollierten Umgebung zu validieren. Der SAT (Standortabnahmetest) wird nach der Installation am Standort des Kunden durchgeführt und verifiziert, dass die Installation den Zeichnungen entspricht, dass physische I/O korrekt mit realen Instrumenten und Aktoren verbunden sind und dass die Integration mit bestehenden Anlagensystemen funktioniert. Der FAT fängt Fehler am günstigsten Punkt des Lebenszyklus ab; der SAT fängt Probleme ab, die erst in der realen Installationsumgebung auftreten. Keiner kann den anderen ersetzen, und beide sind in der Regel nötig.

Sind FAT und SAT gesetzlich vorgeschrieben?

Das hängt von der Branche ab. Pharma- und Life-Sciences-Projekte erfordern FAT und SAT faktisch nach EU-GMP Annex 15, der ihre Rollen in der Qualifizierung ausdrücklich anerkennt. Für allgemeine Industrieanlagen verlangen die CE-Kennzeichnung und einschlägige ISO-Normen den Nachweis, dass die Anlage Sicherheits-, Leistungs- und technische Spezifikationen erfüllt, und FAT und SAT sind die Standardmechanismen, um diesen Nachweis zu erbringen. Auch wo sie nicht streng gesetzlich vorgeschrieben sind, sind FAT und SAT in den meisten Industriebranchen gängige Praxis, weil der wirtschaftliche Grund, Fehler am frühestmöglichen Punkt abzufangen, gut belegt ist.

Können Automatisierungsprojekte agilen Methoden folgen?

Automatisierungsprojekte haben physische Abhängigkeiten, die die Anwendbarkeit rein agiler Methoden begrenzen: Hardware braucht Beschaffungsvorlaufzeit, die Inbetriebnahme erfordert Verfügbarkeitsfenster der Anlage, die Sicherheitsvalidierung folgt regulatorischen Abfolgen, die sich nicht iterieren lassen. Elemente agilen Denkens passen gut, insbesondere die iterative Verfeinerung der URS mit den Beteiligten vor dem Design-Freeze und das iterative Debugging während FAT und Inbetriebnahme. Aber die Phasenstruktur von URS bis Inbetriebnahme ist ein Wasserfallrückgrat, weil physische und regulatorische Randbedingungen es erzwingen, und Versuche, rein agile Methoden auf Automatisierungsprojekte anzuwenden, schneiden typischerweise schlechter ab als der disziplinierte Phase-Gate-Ansatz.

Projektmanagement in der Automatisierung ist die Disziplin, industrielle Automatisierungsprojekte von der Benutzeranforderungsspezifikation über Engineering, FAT, SAT und Inbetriebnahme bis zur stabilen Produktion zu liefern, unterschieden vom generischen Projektmanagement in der Fertigung durch sein verbindliches sequenzielles Validierungsrückgrat, seine inhärente multidisziplinäre Komplexität, die Intensität von Sicherheit und Compliance und die Abhängigkeit von der Koordination mehrerer Lieferanten. Die Sechsphasenstruktur von URS bis Inbetriebnahme liefert den Rahmen, und das Validierungsrückgrat FAT-SAT-SIT-Inbetriebnahme liefert die prägende Disziplin, wobei bei FAT entdeckte Fehler eine Größenordnung weniger kosten als bei SAT und zwei Größenordnungen weniger als während der Inbetriebnahme. Die multidisziplinäre Koordination zwischen den Funktionen Mechanik, Elektrik, Leitsystem, IT/OT und Verfahrenstechnik beansprucht den größten Teil der Aufmerksamkeit des Projektmanagers, und die Reduzierung von Übergabereibung ist der größte Einzelhebel auf die Gesamtprojektdauer. Fünf Fehlermuster (unzureichend spezifizierte URS, verkürzter FAT, Lücken in der Mehrlieferantenkoordination ohne SIT, überschwappende Verzögerungen benachbarter Gewerke, aufgeschobene Sicherheit und Cybersicherheit) lassen sich mit benannten Gegenmaßnahmen verhindern. Anforderungen an Sicherheit und Compliance einschließlich IEC 61511, IEC 62443 und branchenspezifischer Vorschriften müssen von der URS an in den Projektablauf eingebaut werden. Transparenz auf Portfolioebene über gleichzeitige Automatisierungsprojekte ermöglicht die Ressourcen-, Standardisierungs- und Kapazitätsentscheidungen, die Ingenieurbüros fortlaufend treffen. Der Fall Smart Automation zeigt, dass ein mittelgroßes Ingenieurbüro in Monaten einen disziplinierten Projektstandard rund um ein gemeinsames System aufbauen kann, während der Fall Tesla Model 3 zeigt, dass Automatisierungsehrgeiz ohne Pilotvalidierung und disziplinierte Phase-Gate-Durchführung „Produktionshölle” im größtmöglichen Maßstab erzeugt. FlexiProject unterstützt die Durchführungsebene des Projektmanagements in der Automatisierung mit Portfoliotransparenz, Terminplanmanagement, das Gantt-Diagramm-, Aufgabenlisten- und Kanban-Ansichten kombiniert, einem mit den Phasen verknüpften Risikoregister, strukturierten Reviews als Gate-Reviews und standardisierten Projektvorlagen. Die multidisziplinäre Ingenieurkoordination und die disziplinierte Durchsetzung von Gate-Kriterien bleiben organisatorische Verantwortungen. Wenn das Automatisierungsprojektportfolio eines Ingenieurbüros über Tabellenkalkulationen hinausgewachsen ist und ein System benötigt, das Disziplin über mehrere gleichzeitige Projekte und multidisziplinäre Teams hinweg unterstützt, sind dreißig Tage voller Zugang ohne Kreditkarte eine praktische Möglichkeit, die Eignung zu testen.