Projektmanagement für die industrielle Automatisierung: Projektlebenszyklus, KPIs und Best Practices

Ein Projekt zur Linienintegration kann trotz korrekter Planung den geplanten Starttermin verpassen. Die Sicherheits-SPS ist korrekt spezifiziert, der Integrator kompetent, das Layout freigegeben. Doch dann verzögert sich die Lieferung eines Servoantriebs mit langer Lieferzeit um elf Wochen, die Abnahmekriterien für den Durchsatz werden während der Werksprüfung neu interpretiert, die beiden Automatisierungsingenieure, die die Funktionsspezifikation erstellt haben, werden für die Modernisierung eines zweiten Werks abgezogen, und die für neun Tage vorgesehenen Inbetriebnahmearbeiten werden in einen fünftägigen Stillstand komprimiert, der bereits Monate zuvor geplant wurde und nicht verschoben werden kann.

Das Projektmanagement im Bereich der industriellen Automatisierung ist die Disziplin, die genau diese Entwicklung verhindert. Es umfasst die Planung, Steuerung und Leitung von Projekten, die automatisierte industrielle Systeme entwerfen, beschaffen, integrieren, testen, in Betrieb nehmen, validieren oder modernisieren, und es existiert, weil technische Kompetenz allein nicht ausreicht, um diese Projekte termingerecht abzuschließen.

Dieser Leitfaden bietet Ihnen einen zwölfstufigen Lebenszyklus mit expliziten Entscheidungspunkten, ein originelles Risiko-Governance-Framework namens CONTROL, ein ausgefülltes Risikoregister, das Sie anpassen können, einen Vergleich der Verschiebungen von Governance-Prioritäten in Industrie- und regulierten Sektoren, eine Übersicht der beteiligten Tool-Ebenen und eine strukturierte Methode, um zu entscheiden, ob Enterprise-Projekt- und Portfoliomanagement-Software in Ihre Umgebung gehört.

Das Projektmanagement für industrielle Automatisierung umfasst die Planung, Steuerung und Leitung von Projekten, die automatisierte Industriesysteme entwickeln, beschaffen, integrieren, testen, in Betrieb nehmen, validieren oder modernisieren. Es koordiniert die technischen Leistungen, Investitionsgüter, Lieferanten, Produktionsbeschränkungen, Sicherheits- und Cybersicherheitsauflagen, Tests und die Übergabe an den Betrieb, um sicherzustellen, dass die automatisierte Technologie termingerecht, im Rahmen des Budgets und gemäß den Spezifikationen eine stabile Produktion erreicht.

Diese Definition hat mehr Gewicht, als es auf den ersten Blick scheint. Jeder einzelne Absatz benennt etwas, das regelmäßig kaputt geht.

Was unterscheidet diese Projekte von anderen?

Im herkömmlichen Projektmanagement geht man davon aus, dass das Arbeitsergebnis hauptsächlich aus Informationen besteht: Entwürfen, Dokumenten, Software und Entscheidungen. Industrielle Automatisierungsprojekte hingegen erzeugen physische, sicherheitsrelevante und produktionskritische Anlagen, die in einer üblicherweise noch laufenden Produktionsstätte installiert werden müssen. Daraus ergeben sich fünf strukturelle Unterschiede.

Das Ergebnis ist physisch und in Teilen unumkehrbar. Code lässt sich umstrukturieren. Eine in einen Boden gegossene Förderbandbasis oder elf Wochen Vorlaufzeit für eine Antriebsanlage lassen sich nicht ohne Weiteres umstrukturieren.

Die Testphase ist stufenweise und mit Kontrollpunkten versehen. Die Abnahme erfolgt mindestens zweimal, im Werk des Anbieters und erneut vor Ort, und jeder Kontrollpunkt kann das Projekt zurückwerfen.

Die Anlage gibt den Zeitplan vor. Installationen erfordern häufig einen Produktionsstopp, der unter Berücksichtigung von Nachfrage, Wartungsarbeiten und saisonalen Einschränkungen geplant wurde, manchmal sogar ein Jahr im Voraus.

Sicherheit und Schutz sind nicht verhandelbar und werden extern bewertet. Sicherheitsfunktionen und Netzwerkrisiken werden anhand von Standards und, in einigen Sektoren, den Erwartungen der Regulierungsbehörden beurteilt.

Der Betrieb übernimmt das Ergebnis dauerhaft. Wenn die Bediener und Wartungstechniker das System nicht betreiben und reparieren können, ist das Projekt unabhängig von den Angaben im Abnahmeprotokoll gescheitert.

Brownfield-Automatisierungsprojekte profitieren daher von expliziter Zeit und einem festgelegten Budget für die Bestandsaufnahme, bevor die Planungsgrundlagen festgelegt werden. Vorhandene Zeichnungen und Dokumentationen sollten überprüft und nicht automatisch als aktuell behandelt werden.

Wenn eine Schnittstelle, eine Abhängigkeit oder ein bestehender Zustand noch nicht verifiziert wurde, können die Teams dies als Annahme oder Projektrisiko erfassen, einen Verantwortlichen zuweisen und das Problem lösen, bevor es zu einem Problem bei der Integration oder Inbetriebnahme in einer späteren Phase wird.

Diese beiden Ausdrücke tauchen in denselben Suchanfragen auf, haben aber unterschiedliche Bedeutungen. Sie zu verwechseln ist der häufigste Kategorienfehler in diesem Themenbereich.

Das Projektmanagement im Bereich der industriellen Automatisierung steuert Projekte, die automatisierte physische Systeme aufbauen oder modernisieren. Die Automatisierung des Projektmanagements reduziert den administrativen Aufwand innerhalb der Projektmanagementpraxis selbst.

Die Überschneidung ist real und nützlich. Ein Automatisierungsprogramm zu betreiben, ohne die eigenen Genehmigungen, Benachrichtigungen und Statusberichte zu automatisieren, verschwendet wertvolle Entwicklungsressourcen für administrative Aufgaben. Die Automatisierung des Papierkrams allein reicht jedoch nicht für das Projektmanagement aus. Achten Sie darauf, diese Unterscheidung auch intern klar zu kommunizieren, da Anbieter und Suchergebnisse sie ständig verwischen.

Zwölf wiederkehrende Druckfaktoren. Die meisten Terminüberschreitungen lassen sich auf eine Kombination aus drei oder vier dieser Faktoren zurückführen und nicht auf eine einzige Ursache.

• Interdisziplinäre Abhängigkeiten – Mechanik, Elektrotechnik, Steuerungstechnik, Prozesstechnik, IT, Qualitätssicherung und Betrieb tragen alle zum selben Ergebnis bei. Eine mechanische Änderung verändert die Sensorpositionen, was wiederum die Logik und schließlich den Testplan beeinflusst. Ohne ein Abhängigkeitsmodell bleiben diese Auswirkungen unbemerkt, bis sie sich als Verzögerung bemerkbar machen.

• Unklare Anforderungen  – „Durchsatzsteigerung“ ist keine Anforderung. „82 Einheiten pro Minute für die Produktfamilien A und B mit einer Umrüstzeit von unter 12 Minuten, gemessen über einen 72-Stunden-Lauf, aufrechterhalten“ hingegen schon. Diese Unklarheit übersteht die Designprüfung, weil jeder sie unterschiedlich interpretiert, und führt schließlich bei der Werksabnahmeprüfung (FAT) zu Streitigkeiten.

• Integration bestehender Systeme – Schnittstellen bestehender Anlagen sind häufig undokumentiert, nur teilweise oder fehlerhaft dokumentiert. Der ursprüngliche Programmierer hat das Unternehmen verlassen. Die Bestandspläne stimmen nicht mit dem Bedienfeld überein.

• Beschaffung mit langen Lieferzeiten – Bestimmte Steuerungen, Antriebe, Roboter und kundenspezifisch gefertigte Anlagen haben Lieferzeiten von mehreren Monaten. Werden diese Komponenten erst nach der Designfreigabe und nicht während der Designphase bestellt, wird der Liefertermin der Hardware und nicht der Entwicklungsaufwand zum eigentlichen Engpass des Projekts.

• Produktionsunterbrechung – Jede Stunde Installationsaufwand in einer laufenden Anlage verursacht Opportunitätskosten, die die Betriebsleitung unmittelbar zu spüren bekommt. Dies verringert die Zeitfenster und erhöht die politischen Kosten von Kostenüberschreitungen.

• Sicherheit und Cybersicherheit – Sicherheitsfunktionen erfordern sorgfältige Konzeption, Verifizierung und dokumentierte Begründung. Die durch neue Verbindungen entstehende Netzwerkgefährdung muss bewertet und kontrolliert werden, insbesondere bei Fernzugriffen von externen Anbietern.

• Regulierte Validierung – In der pharmazeutischen Industrie, der Medizinprodukteherstellung sowie in Teilen der Lebensmittel- und Chemieindustrie benötigen Systeme, die die Produktqualität beeinflussen, dokumentierte Validierungsnachweise. Diese Nachweise sind nicht nur ein nachträglich hinzugefügtes Dokument, sondern prägen von Anfang an die Anforderungen, die Testprotokolle und den Änderungskontrollprozess.

• Lieferantenkoordination – Mehrere Lieferanten mit unterschiedlichen Zeitplänen, Qualitätssicherungssystemen und wirtschaftlichen Anreizen, die jeweils einen Teil eines voneinander abhängigen Ganzen ausmachen. Fehlende Zuständigkeiten an den Schnittstellen sind die Ursache für Terminverzögerungen.

• Fachkräftemangel – Automatisierungstechniker mit der nötigen Plattformerfahrung sind in den meisten Automatisierungsportfolios der limitierende Faktor. Sie werden üblicherweise projekt- und standortübergreifend eingesetzt, was die Planung einzelner Projekte irreführend macht. Die Kapazität muss entweder auf Portfolioebene oder gar nicht modelliert werden.

• Umfangserweiterung – Automatisierungsprojekte ziehen zusätzliche Anforderungen nach sich: ein weiterer Datenpunkt, ein weiterer Berichtsbildschirm, eine zweite Produktvariante. Einzeln betrachtet ist jede dieser Anforderungen gering. Zusammengenommen verbrauchen sie jedoch die für die Integration vorgesehenen Ressourcen.

Der Projektlebenszyklus umfasst sieben Phasen . Jede Phase hat eine Kontrollstelle. Eine Kontrollstelle, die nicht fehlschlagen kann, ist keine Kontrollstelle.

1. Chancen und Geschäftsmodell

Definieren Sie das operative Problem und das messbare Ergebnis, bevor Sie eine Technologie auswählen. Quantifizieren Sie die Ausgangslage: aktueller Durchsatz, Ausbeute, Ausfallzeiten, Arbeitsaufwand, Qualitätskosten und Sicherheitsrisiken. Ein Business Case scheitert meist dann, wenn er dazu dient, bereits ausgewählte Ausrüstung zu rechtfertigen.

Ergebnisse: Problembeschreibung, Ausgangsmessung, Nutzenhypothese, Kostenschätzung, strategische Ausrichtung. Meilenstein: Freigabe der Mittel für die Machbarkeitsstudie. Verantwortlich: Werks- oder Betriebsleitung mit Finanzabteilung.

2. Machbarkeitsstudie und Projektauswahl

Prüfen Sie die technische Machbarkeit und vergleichen Sie sie mit Portfolio-Alternativen. Hier konkurriert das Kapital. Ein Projekt, das für sich genommen attraktiv erscheint, kann dennoch das falsche Projekt sein, wenn es die einzigen verfügbaren Automatisierungstechniker während der Stilllegung eines anderen Standorts bindet.

Leistungen: Machbarkeitsstudie, Konzeptoptionen, Kosten- und Zeitrahmenvorgabe, Portfoliobewertung, Ressourcenverfügbarkeitsprüfung. Meilenstein: Portfolioauswahl und Freigabe der Finanzierung. Verantwortlich: Kapitalausschuss oder Projektmanagementbüro.

3. Definition der Anforderungen und des Projektumfangs

Die wichtigste Phase im Projekt. Definieren Sie funktionale Anforderungen, Leistungskriterien, Schnittstellen, Sicherheitsanforderungen, Datenanforderungen und – ganz entscheidend – Abnahmekriterien. Anforderungen müssen einzeln identifizierbar sein, damit sie während des gesamten Prozesses – von der Entwicklung über die Tests bis zur Abnahme – nachvollziehbar sind.

Liefergegenstände: Anforderungsspezifikation, Funktionsspezifikation, Schnittstellenregister, Abnahmekriterien, Rückverfolgbarkeitsmatrix, Basisumfang. Meilenstein: Genehmigung des Anforderungs-Basisumfangs. Verantwortlich: Technischer Leiter in Zusammenarbeit mit Betrieb und Qualitätssicherung.

4. Konzept und detaillierte Planung

Steuerungsarchitektur, Netzwerkdesign, Schaltschrankdesign, mechanische Integration, Softwarearchitektur, Sicherheitsdesign. Komponenten mit langen Lieferzeiten müssen hier und nicht erst später identifiziert werden.

Liefergegenstände: Konstruktionsdokumente, Zeichnungen, Netzwerk- und Sicherheitsarchitektur, Begründung des Sicherheitsdesigns, Stückliste, Liste der Artikel mit langer Lieferzeit. Meilenstein: Designprüfung und Freigabe an die Beschaffung. Verantwortlicher: Technischer Leiter oder Leiter der Steuerungstechnik.

5. Beschaffung und Lieferantenkoordination

Bestellen Sie Artikel mit langer Lieferzeit so früh wie möglich, soweit es die Planung zulässt. Integrieren Sie Lieferantenmeilensteine ​​als echte Abhängigkeiten und nicht als Notizen in den Masterplan.

Liefergegenstände: Bestellungen, Lieferantenpläne, Integratorvertrag mit Abnahmekriterien, Dokumentationsliste, Beschleunigungsplan. Meilenstein: Beschaffungszusage. Verantwortlicher: Beschaffung in Zusammenarbeit mit der Entwicklungsabteilung.

6. Aufbau und Konfiguration

Schaltschrankbau, mechanische Fertigung, Entwicklung der Steuerungslogik, HMI- und SCADA-Konfiguration, Rezeptur- und Parametereinstellung. Die Konfigurationskontrolle beginnt hier: Versionierung jedes Programms, jeder Zeichnung und jedes Parametersatzes.

Liefergegenstände: Gebaute Hardware, entwickelte Software, Konfigurationsbasislinie, interne Testprotokolle. Meilenstein: Integrationsbereitschaft. Verantwortlich: Integrator oder interne Entwicklungsabteilung.

7. Integration und Fehlersuche

Teilsysteme treffen aufeinander. Schnittstellen versagen. Diese Phase wird systematisch unterschätzt, da ihre Dauer eher von der Fehlererkennung als vom geplanten Aufwand abhängt.

Liefergegenstände: Integriertes System, Schnittstellentestprotokolle, Fehlerprotokoll mit Bearbeitungsstatus. Meilenstein: Bereitschaft zur Werksabnahmeprüfung (FAT). Verantwortlicher: Integrationsleiter.

Konzentrieren Sie sich auf einen festgelegten Bereich. Es werden keine allgemeingültigen Benchmark-Werte vorgegeben, da glaubwürdige Ziele organisations- und branchenspezifisch sind; legen Sie im ersten Quartal Ihre eigene Ausgangsbasis fest und messen Sie die Entwicklung anhand dieser Basis.

Risiko, Problem, Annahme, Abhängigkeit, Änderungsantrag

Teams, die diese fünf Aspekte verwischen, verlieren die Fähigkeit, aussagekräftige Berichte zu erstellen.

Praktiken, die Ergebnisse verändern, wobei der Mechanismus erläutert wird. Ratschläge ohne Mechanismus sind bloße Dekoration.

• Erstellen Sie den Business Case, bevor Sie die Technologie auswählen – Definieren Sie zunächst das operative Problem und die messbare Ausgangslage. Wird die Technologie zuerst ausgewählt, entsteht der Business Case im Nachhinein, und die Akzeptanzkriterien übernehmen diese Unklarheit.

• Definieren Sie messbare Ergebnisse und Akzeptanzkriterien bereits in der Anforderungsphase – jede Anforderung sollte getestet werden. Jede Leistungsangabe sollte Bedingungen, Produktmix und Dauer spezifizieren. Diese einfache Vorgehensweise beseitigt die häufigste Ursache für Streitigkeiten bei der Werksabnahmeprüfung (FAT).
• Beteiligen Sie Bediener und Wartungsteams frühzeitig an festgelegten Überprüfungen – nicht nur „Stakeholder einbeziehen“. Konkret bedeutet dies: Ein Betriebs- und ein Wartungsvertreter nehmen an der Anforderungs- und der Konstruktionsprüfung teil, ihre Anmerkungen werden protokolliert und entsprechend behandelt. So decken sie Probleme hinsichtlich Bedienbarkeit und Wartungsfreundlichkeit auf, die bei technischen Prüfungen systematisch übersehen werden.

• Identifizieren Sie Artikel mit langen Lieferzeiten bereits in der Detailplanungsphase und platzieren Sie diese auf dem kritischen Pfad. Führen Sie ein Verzeichnis der Artikel mit langen Lieferzeiten, in dem Bestelldatum und gewünschter Liefertermin erfasst werden. Verfolgen Sie Lieferantenmeilensteine ​​als terminliche Abhängigkeiten, sodass Lieferverzögerungen automatisch zu einer Verschiebung der nachfolgenden Termine führen und nicht durch optimistische Planungen aufgefangen werden.

• Die Entscheidungsbefugnis muss vor der Umsetzung schriftlich festgelegt werden: Wer genehmigt Änderungen bis zu welchem ​​Wert, wer genehmigt bestimmte Meilensteine, wer kann auf einen Meilenstein verzichten (idealerweise niemand, um Sicherheitsmaßnahmen zu gewährleisten) und wie sieht der Eskalationsweg aus? Unklare Zuständigkeiten führen zu Verzögerungen bei Entscheidungen.

• Definieren Sie die grundlegenden Anforderungen und den Umfang und begründen Sie diese Grundlage –  eine Grundlage, auf die nie Bezug genommen wird, ist keine Grundlage. Vergleichen Sie die Ist-Werte in jedem Statusbericht mit dieser Grundlage.

• Weisen Sie die Zuständigkeit für Konfiguration und Dokumentation bereits in der Build-Phase zu – jedes Programm, jede Zeichnung und jeder Parametersatz muss versioniert werden. Benennen Sie die Person, die nach der Übergabe für die Dokumentation verantwortlich ist. Die Vollständigkeit der Dokumentation sollte eine Voraussetzung und keine bloße Abschlussformalität sein.

• Nutzen nach der Übergabe im Vergleich zur ursprünglichen Ausgangslage verfolgen – Die Überprüfung sollte bei der Genehmigung des Business Case geplant werden, damit sie im Kalender steht, bevor jemand auf die Idee kommt, sie zu überspringen.

• Managen Sie Einzelprojekte als Teil eines Automatisierungsportfolios – Fachressourcen, Kapital und Stillstandszeiten werden standortübergreifend geteilt. Die Optimierung einzelner Projekte führt zu Konflikten auf Portfolioebene. Legen Sie die Reihenfolge auf Portfolioebene anhand von Kapazitäts- und Szenarioanalysen fest.

Die Prioritäten der Regierungsführung variieren je nach Sektor erheblich. Die folgende Tabelle umfasst fünfzehn Sektoren. Beachten Sie die Spalte „Typ“ besonders.

• Im Bereich der physikalischen industriellen Automatisierung werden Projekte durchgeführt, die automatisierte physikalische Systeme entwerfen, integrieren und in Betrieb nehmen.
• Die Bereiche Geschäftsprozess- und Projektworkflow-Automatisierung werden hier lediglich zum Vergleich herangezogen. Ihre Projekte umfassen Software-, Prozess- und Workflow-Automatisierung. Es handelt sich nicht um Projekte der industriellen Automatisierung; sie als solche zu behandeln, wäre ein Kategorienfehler, den dieser Artikel bewusst vermeidet.

Regulierte Umgebungen erfordern keinen anderen Projektlebenszyklus. Sie erhöhen lediglich die Beweisanforderungen an jedem Projektschritt.

• Rückverfolgbarkeit von Anforderungen – Jede Anforderung muss rückverfolgbar sein, von den Designelementen über die zugehörigen Tests bis hin zu den Testergebnissen und den erfüllten Anforderungen. Erstellen Sie die Rückverfolgbarkeitsmatrix während der Anforderungsdefinition. Eine spätere Rekonstruktion ist aufwändig und liefert weniger aussagekräftige Ergebnisse.

• Genehmigungsprozesse – Genehmigungen erfordern eine festgelegte Abfolge, klar definierte Genehmiger mit entsprechender Rolle und ein dokumentiertes Ergebnis mit Datum und Identität. Informelle Genehmigungen gelten in einem regulierten Kontext nicht als Genehmigungen.

• Nachweise und Dokumentation –  Protokolle, durchgeführte Arbeiten, Abweichungen und deren Behandlung sowie die Dokumentation des Ist-Zustands bilden die Nachweisdokumentation. Die entscheidende Frage an jedem Prüfpunkt ist, ob die Nachweise einen abwesenden Gutachter überzeugen würden.

• Änderungsmanagement – ​​Sobald eine Ausgangsbasis existiert, erfordern Änderungen eine Folgenabschätzung hinsichtlich Validierung, Sicherheit und Testauswirkungen sowie eine dokumentierte Genehmigung durch die zuständige Behörde. Notfallmaßnahmen sollten dokumentiert und nicht improvisiert werden.

• Rollenbasierte Verantwortlichkeit – Bestimmte namentlich genannte Personen müssen bestimmte Verantwortlichkeiten tragen. Unklare Zuständigkeiten sind an sich schon ein Befund.

• Prüfung und Abnahme – Vorab genehmigte Protokolle, die ausgeführt und bezeugt werden, wobei Abweichungen formell behandelt und nicht informell vermerkt werden.

• Validierungsplanung – Validierungsstrategie, -umfang und Akzeptanzkriterien werden vor der Durchführung definiert und beziehen sich auf die Risikobewertung, die den gewählten Grad an Strenge rechtfertigt.

Neun Ebenen. Wenn Organisationen diese verwechseln, kaufen sie am Ende das Falsche oder erwarten, dass ein System die Aufgaben eines anderen übernimmt.

1. Projekt- und Portfoliomanagement (PPM)

Verwaltet: Zeitpläne, Abhängigkeiten, Ressourcenkapazität, Budgets und Kosten, Risiken, Probleme, Änderungen, Genehmigungen, Meilensteine, Portfolio-Priorisierung, Berichterstattung. 

Nutzer: Projektmanager, PMO, Ressourcenmanager, Finanzabteilung, Führungskräfte. 

Beitrag: die Dokumentation der Unternehmensführung. Wer tut was bis wann, zu welchen Kosten, mit welchem ​​Risiko und auf wessen Entscheidung wartet? 

Nicht zu verwechseln mit: Ingenieurwesen oder Steuerungstechnik. PPM entwirft, programmiert oder betreibt keine physischen Anlagen. Es steuert die damit verbundenen Abläufe.

2. Konstruktion und Simulation im Ingenieurwesen

Verantwortlich für: CAD-Modelle, Elektroplanung, Layout, Prozesssimulation, digitale Modellierung von Durchsatz und Zykluszeit. 

Nutzer: Maschinenbau-, Elektro- und Verfahrenstechniker. 

Beiträge: Entwurfsunterlagen, Stücklisten, Machbarkeitsnachweise. 

Nicht zu verwechseln mit: PLM. Design-Tools erstellen die Artefakte; PLM steuert deren Lebenszyklus und Revisionen.

3. MES und Produktionssysteme

MES (Manufacturing Execution System): verwaltet die Produktionsabwicklung, Arbeitsaufträge, Genealogie, Rückverfolgbarkeit und Leistung einschließlich OEE (Gesamtanlageneffektivität). 

Nutzer: Produktionsmanagement, Qualitätssicherung, Betrieb. Beiträge: Produktionsleistungsdaten und Rückverfolgbarkeitsaufzeichnungen, oft die Grundlage für die Realisierung von Nutzen. 

Nicht zu verwechseln mit: SCADA (Supervisory Control) oder ERP (Resource Enterprise Planning and Control), das für Transaktionen und Finanzen steht.

4. ERP- und Finanzsysteme

ERP (Enterprise Resource Planning): Bestellungen, Rechnungen, Lagerbestand, Anlagevermögen, Hauptbuch. 

Nutzer: Finanzen, Beschaffung, Lieferkette. 

Beiträge: zugesagte und tatsächliche Ausgaben, Bestellstatus, Aktivierung. 

Nicht zu verwechseln mit: PPM-Kostenverfolgung. PPM prognostiziert und steuert die Projektkosten während der Projektdurchführung; ERP ist das System zur Erfassung der Finanztransaktionen.

5. PLM und Dokumentenmanagement

PLM (Product Lifecycle Management): kontrollierter Lebenszyklus von Konstruktionen, Überarbeitungen und Änderungsaufträgen. 

Nutzer: Entwicklung, Konfigurationsmanagement, Qualitätssicherung. Beiträge: Kontrollierte Revisionen und Konfigurationsbaselines. 

Nicht zu verwechseln mit: allgemeiner Dateispeicherung. Versionskontrolle ist nicht Revisionskontrolle.

6. Qualitäts- und Validierungssysteme

Verwaltet: Abweichungen, CAPA, Validierungsprotokolle und durchgeführte Nachweise, kontrollierte elektronische Aufzeichnungen. 

Nutzer: Qualitätssicherung, Validierungsingenieure, Zulassungsabteilung. 

Beitrag: das regulierte Evidenzpaket. 

Nicht zu verwechseln mit: PPM-Genehmigungsworkflows. PPM kann koordinieren, wer was wann genehmigt; die Dokumentation der regulierten Nachweise gehört zum Qualitätssystem.

7. Instandhaltung und Anlagenmanagement

CMMS oder EAM: Anlagenverzeichnisse, vorbeugende Wartungspläne, Arbeitsaufträge, Ersatzteile. 

Anwender: Instandhaltung, Zuverlässigkeitstechnik. 

Beitrag: die tatsächliche Betriebssituation des Assets nach der Übergabe. Die Übergabe ist erst dann abgeschlossen, wenn das Asset, sein Wartungsplan und seine Ersatzteile hier vorhanden sind. 

Nicht zu verwechseln mit: dem Projektzeitplan. Projektaufgaben enden; Wartungspläne nicht.

8. Zusammenarbeit und Wissensmanagement

Verwaltet: Diskussionen, Dateien, Entscheidungen, Besprechungsprotokolle, Kommunikation mit Lieferanten und Kunden. 

Nutzer: Alle am Projekt Beteiligten. 

Trägt bei: die Entscheidungsdokumentation, die spätere Prüfungen und Nachbesprechungen ermöglicht. Nicht zu verwechseln mit: dem Dokumentationssystem. Eine im Chat getroffene, aber nicht im Projektprotokoll erfasste Entscheidung wurde aus Governance-Sicht nicht umgesetzt.

9. Cybersicherheit und Überwachung

Verwaltet: OT-Netzwerküberwachung, Segmentierung, Zugriffskontrolle, Schwachstellen- und Patch-Management. 

Anwender: OT-Sicherheit, IT-Sicherheit, Steuerungstechnik. 

Trägt bei: Gefährdungsbeurteilung und Zugriffsprotokolle. (Verifiziert anhand offizieller Celoxis-Quellen: NIST SP 800-82r3 deckt OT-Bedrohungen und -Schwachstellen, Risikomanagement, empfohlene Vorgehensweisen und Architekturen sowie Sicherheitsfunktionen und -werkzeuge für OT ab.) 

Nicht zu verwechseln mit: Projektsteuerung. PPM kann die Sicherheitsprüfung als zeitlich begrenzte Aufgabe mit protokollierter Genehmigung durchführen. Es kann kein Netzwerk bewerten oder überwachen.

Das Integrationsprinzip. Diese Ebenen sollten definierte Daten an definierten Punkten austauschen, anstatt zusammengeführt zu werden. Die PPM-Ebene benötigt typischerweise: Meilenstein- und Aufgabenstatus von den Lieferteams, Bestellstatus aus dem ERP-System und Ergebnisdaten aus dem MES-System zur Nutzenmessung. Sie benötigt keine Echtzeit-Prozessdaten und sollte diese auch nicht speichern.

Celoxis bietet die Projekt- und Portfoliomanagementebene für die industrielle Automatisierungstechnik. Es unterstützt Teams bei der Planung und Koordination von Zeitplänen, Ressourcen, Kosten, Risiken, Änderungen, Arbeitsabläufen und Portfolio-Reporting in einem vernetzten System, während spezialisierte Engineering- und Betriebsplattformen weiterhin ihre jeweiligen technischen Funktionen erfüllen.

Dies macht Celoxis besonders relevant, wenn die Herausforderung nicht in der SPS-Programmierung, der Steuerungstechnik, der Inbetriebnahme oder dem Anlagenbetrieb selbst besteht, sondern in der Koordination der beteiligten Personen, Zeitpläne, Abhängigkeiten, Governance-Strukturen, Kosten und des Management-Reportings.

Problem bei der Fähigkeitszuordnung:

Was Celoxis nicht ist

Celoxis sollte nicht als Ersatz für spezialisierte industrielle Ingenieurdienstleistungen oder Betriebssysteme betrachtet werden. Seine Rolle besteht darin, die Projekt- und Portfolioplanung, -durchführung, Ressourcenbereitstellung, Steuerung, Finanzkontrolle und Berichterstattung im Zusammenhang mit den Arbeiten zu unterstützen.

Spezialfunktionen wie Anlagensteuerung, SPS- oder SCADA-Programmierung, Fertigungssteuerung, Ingenieursimulation, Sicherheitsvalidierung, behördliche Zertifizierung, vorausschauende Wartung und digitale Zwillingsmodellierung sollten bei den dafür vorgesehenen Plattformen und Prozessen verbleiben.

Vermeiden Sie ebenso Aussagen über unveränderliche Prüfprotokolle, garantierte Kosten- oder Ausfallzeitreduzierungen oder native Integrationen, die nicht unabhängig verifiziert wurden. Celoxis sollte sich auf die Projektmanagement- und Governance-Probleme konzentrieren, für deren Lösung es entwickelt wurde, ohne den Eindruck zu erwecken, es ersetze jedes technische System in einem industriellen Automatisierungsprogramm.

Das Projektmanagement in der industriellen Automatisierung hängt stark von der Zusammenarbeit zwischen den verschiedenen Fachbereichen ab. Engineering, Beschaffung, Lieferanten, Betrieb, Sicherheit, IT/OT, Finanzen und Projektleitung tragen alle zum gleichen Ergebnis bei, und Schwächen bei den Übergaben zwischen diesen Bereichen können erhebliche Termin-, Kosten- und Lieferrisiken verursachen.

Definieren Sie Akzeptanzkriterien frühzeitig und stellen Sie sicher, dass die Anforderungen testbar sind. Planen Sie realistische Vorlaufzeiten, Ressourcenengpässe, Abhängigkeiten und Stillstandsfenster ein, bevor Sie Liefertermine festlegen. Legen Sie klare Entscheidungsbefugnisse und Änderungskontrollprozesse fest. Planen Sie Werksabnahmeprüfung (FAT), Systemabnahmeprüfung (SAT), Inbetriebnahme und andere erforderliche Abnahmeaktivitäten entsprechend den Projektanforderungen. Behandeln Sie Sicherheits- und Cybersicherheitsprüfungen als explizite Governance-Anforderungen und nicht als Aktivitäten, die bei Zeitdruck verkürzt werden können. Integrieren Sie Dokumentation, Schulung, Übergabe und Nutzenanalyse in den Projektplan und verschieben Sie diese nicht auf das Ende.

Für Organisationen, die das in diesem Leitfaden beschriebene CONTROL-Framework (Klarstellen, Ordnen, Verhandeln, Testen, Einschränken, Beobachten und Abschließen) anwenden, besteht das Ziel darin, diese Prinzipien in eine wiederholbare Projektsteuerung zu überführen. Das Framework lässt sich mit einfachen Tools anwenden. Mit zunehmender Komplexität von Automatisierungsportfolios erleichtert die Verknüpfung von Zeitplänen, Ressourcenkapazitäten, Risiken, Änderungen, Kosten und Berichten Teams und Führungskräften jedoch das Verständnis des aktuellen Projektstands und die Entscheidungsfindung.

Die Wahl des richtigen Projektmanagement-Tools hängt von der Komplexität ab. Celoxis ist für Organisationen konzipiert, die vernetzte Planung, Ressourcen- und Kapazitätsmanagement, Finanzkontrolle, Workflow-Steuerung, Risiko- und Problemmanagement sowie Projekt- und Portfolio-Reporting benötigen. Kleinere oder isolierte Automatisierungsprojekte erfordern möglicherweise nicht dieses umfassende Projekt- und Portfoliomanagement.