Technische Systemintegration: warum Standard-PM hier an Grenzen stößt

Kategorie: Branchen-Guides

Ein Standard-PM-Tool kennt drei Dinge über Ihr Projekt: eine Aufgabe, einen Termin, einen Verantwortlichen. Ein Integrationsprojekt besteht aber aus Systemen, Schnittstellen und Reifegraden, und keines davon lässt sich in diese drei Felder zwingen. Das Ergebnis ist ein Plan, der auf Grün steht, während die Inbetriebnahme bereits vier Wochen blockiert ist.

Wen trifft die Fehlpassung zuerst?

Systemintegratoren liefern kein Produkt, sondern ein funktionierendes Zusammenspiel. Eine Schaltanlage mit übergeordnetem Leitsystem. Eine Robotik-Zelle mit Sicherheitstechnik, Bildverarbeitung und MES-Anbindung. Ein Prüfstand mit Messtechnik, Klimatisierung und Auswertesoftware. Der Auftrag ist erst erfüllt, wenn alle Teilsysteme miteinander reden, nicht wenn alle Teilsysteme fertig sind.

Genau diese Unterscheidung bildet ein Terminplan nicht ab. Er zeigt Ihnen, dass „SPS-Programmierung“ zu 80 Prozent fertig ist. Er zeigt Ihnen nicht, dass die 80 Prozent den Funktionsumfang abdecken, für den die Schnittstellenbeschreibung des Kunden bereits in Revision 3 vorliegt, während die Programmierung noch gegen Revision 1 arbeitet.

Die Konsequenz zeigt sich immer spät und immer teuer. Der Projektleiter meldet bis Woche 30 planmäßigen Fortschritt. In Woche 31 beginnt die interne Integration, und dort fallen die Widersprüche zwischen den Teilsystemen in Serie auf. Was in der Planung acht Tage Integration waren, wird zu sechs Wochen Fehlersuche. Der FAT-Termin verschiebt sich, die Reisekosten für das Inbetriebnahmeteam laufen doppelt, und die Pönale beginnt zu greifen.

Wie groß ist der Schaden messbar?

Die Zahlen aus der Projektforschung sind eindeutig, und sie verschlechtern sich mit der Komplexität. Die Standish Group misst im CHAOS-Report 2020 eine Erfolgsquote von 31 Prozent, 50 Prozent der Projekte gelten als „challenged“, 19 Prozent scheitern vollständig (Standish Group, CHAOS 2020). Entscheidend für Integratoren ist die Größenverteilung derselben Studie: kleine Projekte erreichen rund 90 Prozent Erfolg, große Projekte liegen unter 10 Prozent (Standish Group, CHAOS 2020). Komplexität ist kein Randfaktor, sie ist der dominante Faktor.

Das PMI beziffert den Kapitalverlust: 11,4 Prozent jeder Projektinvestition gehen durch schlechte Projektperformance verloren (PMI, Pulse of the Profession 2020). Organisationen, die Projektmanagement nicht als strategische Kompetenz führen, verzeichnen 67 Prozent mehr komplett gescheiterte Projekte (PMI, Pulse of the Profession 2020). Zwei Jahre früher lag der Verlustwert bei 9,9 Prozent jedes investierten Dollars, also 99 Millionen Dollar je Milliarde (PMI, Pulse of the Profession 2018).

Für große technische Vorhaben liefert die Auswertung von McKinsey und der Universität Oxford den Rahmen: durchschnittlich 45 Prozent über Budget, 7 Prozent über Zeit, und 56 Prozent weniger Wert als geplant (McKinsey / Universität Oxford, 2012). Der dritte Wert ist der unterschätzte. Das Projekt endet, die Rechnung ist gestellt, und die Anlage leistet nicht, was die Spezifikation versprochen hat. Flyvbjerg fasst das Muster über Branchen hinweg zusammen: 9 von 10 Großprojekten überschreiten Kosten und Zeit (Flyvbjerg, Oxford Global Projects). In technisch komplexen Projekten gehen nach interner Ableitung 37 Prozent des Budgets verloren [interne Ableitung aus PMI/Standish, Beleg ergänzen].

Was fehlt einem Standard-PM-Tool konkret?

Ein klassischer Terminplan ist ein Modell der Zeit. Ein Integrationsprojekt braucht zusätzlich ein Modell des Systems. Fünf Dimensionen bleiben im Standardwerkzeug ohne Ort.

Systemstruktur. Ein Projektstrukturplan gliedert nach Arbeit, nicht nach Technik. Das Leitsystem taucht als Arbeitspaket auf, nicht als Objekt mit Eigenschaften, Schnittstellen und Zustand. Fragen wie „welche Vorgänge zahlen auf die Sicherheitsfunktion der Zelle ein“ sind aus einem Vorgangsbaum nicht beantwortbar.

Schnittstellen. Ein Gantt-Chart kennt Vorgänger und Nachfolger. Eine Schnittstelle ist aber kein Zeitbezug, sondern ein technischer Vertrag zwischen zwei Systemen, mit Signalliste, Protokoll, Adressraum und zwei verantwortlichen Personen auf unterschiedlichen Seiten der Organisationsgrenze. Diese Information landet in einer Excel-Datei neben dem Projektplan, und ab diesem Moment driften beide auseinander.

Reifegrade. „70 Prozent fertig“ ist in der Integration keine Aussage. Ein Teilsystem durchläuft Spezifikation, Design, Implementierung, Modultest, Integrationstest und Abnahme. Ein Systemstatus ohne Reifegradstufe verdeckt genau die Information, die den Integrationsstart bestimmt.

Fremdsysteme und Beistellungen. Der Kunde liefert die Netzwerkanbindung, ein Drittanbieter die Antriebsregler, ein Lieferant das Kamerasystem samt Software. Als Meilenstein mit Datum sieht jede dieser Zusagen gleich verbindlich aus. Tatsächlich unterscheiden sie sich in Zusagequalität und Auswirkung massiv.

Versionierung. Anforderungen ändern sich, in der Regel bis kurz vor der Abnahme. Ohne Versionsstand am Anforderungsobjekt kann niemand sagen, welches Teilsystem gegen welche Revision getestet wurde. Genau daraus entstehen die Fehler, die erst im FAT auffallen.

Warum entsteht diese Lücke strukturell?

Standard-PM-Tools stammen aus dem Bau- und Terminplanungskontext. Ihr Datenmodell heißt Vorgang, Dauer, Ressource, Anordnungsbeziehung. Dieses Modell trägt dort, wo die technische Struktur stabil ist und der Fortschritt physisch sichtbar bleibt. Eine Betondecke ist gegossen oder nicht.

In der Systemintegration ist die technische Struktur selbst das Projektergebnis und verändert sich während der Laufzeit. Der Plan entsteht zum Zeitpunkt des geringsten Wissens, und die Planning Fallacy sorgt für systematische Unterschätzung von Dauer und Kosten (Kahneman & Tversky 1979). Integrationsaufwand ist davon am stärksten betroffen, weil er sich aus der Anzahl der Schnittstellen ergibt und diese Anzahl bei Angebotsabgabe noch nicht feststeht.

Dazu kommt die Zersplitterung der Datenhaltung. Die Systemstruktur liegt im Engineering-Werkzeug, die Signalliste in Excel, die Anforderungen in einem Lastenheft-PDF, der Termin im PM-Tool, die Beistellzusagen im E-Mail-Verlauf. Wissensarbeiter verbringen 19 Prozent ihrer Zeit mit Informationssuche und 28 Prozent mit E-Mail (McKinsey Global Institute, The social economy 2012). 55 Prozent der Manager wenden mindestens acht Stunden pro Woche für administrative Aufgaben auf, und 54 Prozent nennen schlechte Kommunikation und wiederholte Fehler als größtes Problem (Formstack, State of Workflow Automation 2018).

Der Projektleiter kompensiert die Lücke manuell. Er hält die Schnittstellenliste im Kopf, fragt Reifegrade telefonisch ab und übersetzt beides in einen Prozentwert. Diese Übersetzung ist die eigentliche Fehlerquelle, denn sie erzeugt genau die Zahl, die dann im Statusbericht als Wahrheit gilt.

Wie schließen Sie die Lücke methodisch?

Der Ansatz ist nicht ein größeres Gantt, sondern eine zweite Informationsebene neben dem Terminplan. Fünf Schritte, in dieser Reihenfolge.

1. Systemstruktur getrennt vom Projektstrukturplan führen. Legen Sie eine Objektliste an: Anlage, Teilsysteme, Komponenten, jeweils mit eindeutiger ID. Jeder Vorgang im Terminplan verweist auf mindestens ein Objekt. Damit lässt sich jederzeit von der Technik auf den Termin und zurück navigieren.
2. Schnittstellenregister als eigenes Artefakt anlegen. Eine Zeile je Schnittstelle, mit Quellsystem, Zielsystem, Signal- oder Datenumfang, Protokoll, Verantwortlichem auf beiden Seiten, vereinbarter Revision und Prüfstatus. Das Register ist das Rückgrat des Integrationsplans, nicht ein Anhang.
3. Reifegrade je Teilsystem definieren und stur anwenden. Fünf oder sechs Stufen reichen: Spezifikation freigegeben, Design abgeschlossen, implementiert, Modultest bestanden, Integrationstest bestanden, abgenommen. Ein Teilsystem hat genau eine Stufe. Prozentwerte innerhalb einer Stufe sind zulässig, ersetzen die Stufe aber nicht.
4. Fremdleistungen und Beistellungen als eigene Risikoklasse behandeln. Jede Beistellung bekommt Zusagedatum, letzten bestätigten Stand, Auswirkung bei Verzug in Wochen und eine benannte Person beim Kunden. Beistellungen mit Auswirkung auf den kritischen Pfad gehören in jeden Statustermin, unabhängig davon, ob sich der Status geändert hat.
5. Anforderungen versionieren und die Version an das Teilsystem binden. Jedes Teilsystem trägt die Revision, gegen die es gebaut und getestet wurde. Bei einer Änderung sehen Sie sofort, welche Teilsysteme und welche Tests ungültig werden.

Die Aufwandsverteilung verschiebt sich dadurch nach vorn. Sie investieren in den ersten Projektwochen mehr Zeit in Struktur und Register, und Sie sparen diese Zeit in der Integrationsphase, wo ein Tag deutlich teurer ist. Steuerung heißt in dieser Logik: Reifegrad und Schnittstellenstatus prüfen, nicht Prozentwerte einsammeln.

Praxisbeispiel: Robotik-Zelle für einen Automobilzulieferer

Ein Systemintegrator mit 95 Mitarbeitern liefert eine verkettete Robotik-Zelle mit Bildverarbeitung, Sicherheitssteuerung und MES-Anbindung. Auftragswert 1,8 Millionen Euro, geplante Laufzeit 34 Wochen, geplanter FAT in Woche 28.

Die Zelle besteht aus sieben Teilsystemen mit 41 Schnittstellen. Geführt wird das Projekt in einem Terminplan mit 180 Vorgängen. Die Signalliste liegt in einer Excel-Datei, die Anforderungen in einem Lastenheft mit drei Nachträgen.

In Woche 12 ändert der Kunde das Datenformat der MES-Anbindung. Die Änderung geht per E-Mail an den Softwareverantwortlichen, das Lastenheft wird auf Revision 2 gehoben. Der Terminplan bleibt unverändert, weil kein Vorgang sichtbar länger dauert. Die Bildverarbeitung, geliefert durch einen Unterlieferant, arbeitet weiter gegen Revision 1. Niemand bemerkt die Abweichung, weil keine Stelle den Revisionsstand je Teilsystem führt.

Parallel verzögert sich eine Kundenbeistellung: die Netzwerkfreigabe im Produktionssegment. Im Plan steht sie als Meilenstein in Woche 20 und rutscht auf Woche 24. Da der Meilenstein keine ausgewiesene Auswirkung trägt, bleibt der Statusbericht auf Grün.

In Woche 26 beginnt die interne Integration. Das Format-Delta zwischen Bildverarbeitung und MES fällt sofort auf. Die Korrektur kostet vier Wochen, davon zwei Wochen Wartezeit auf den Unterlieferanten. Die fehlende Netzwerkfreigabe verhindert zusätzlich den Test der übergeordneten Kommunikation.

Ein geführtes Schnittstellenregister hätte die Revisionsabweichung in Woche 12 sichtbar gemacht, in dem Moment, in dem die Korrektur rund zwölf Stunden Programmieraufwand gekostet hätte. Die Kostendifferenz entsteht nicht durch den Fehler, sondern durch seine Liegezeit von 14 Wochen.

Fazit

Ein Terminplan beantwortet die Frage, wann etwas passieren soll. Er beantwortet nicht, ob die Systeme zueinander passen, mit welchem Reifegrad sie in die Integration gehen und gegen welche Anforderungsrevision sie gebaut wurden. Solange diese Information nur im Kopf des Projektleiters existiert, ist der grüne Status eine Schätzung mit unbekannter Fehlerbreite. Wer Schnittstellen, Reifegrade und Revisionsstände als eigene, geführte Objekte behandelt, verschiebt die Fehlerentdeckung von der Inbetriebnahme in die Engineering-Phase, und dort kostet die Korrektur ein Bruchteil.

Weiterführend: Schnittstellenprojekte steuern: Warum Systemintegratoren mehr als ein Gantt-Chart brauchen · Warum 37 % des Budgets in technisch komplexen Projekten verloren gehen

Mehr zu Projektmanagement für technisch komplexe Projekte: Aligia