Schnittstellenprojekte steuern: Warum Systemintegratoren mehr als ein Gantt-Chart brauchen

Kategorie: Branchen-Guides

Ein Gantt-Chart zeigt Ihnen 240 Balken. Es zeigt Ihnen nicht, dass Teilsystem C seit elf Tagen auf eine Signalfreigabe von Teilsystem A wartet, weil diese Abhängigkeit technisch besteht und nicht terminlich modelliert ist. In Schnittstellenprojekten liegt genau dort der Schaden: nicht in den Vorgängen, sondern in den Übergängen zwischen ihnen.

Warum scheitert die Steuerung an den Übergängen?

Systemintegratoren verantworten das Zusammenspiel, nicht die Einzelleistung. Ein Leitsystem, drei Schaltanlagen, eine Antriebsebene, eine MES-Anbindung und eine Sicherheitsarchitektur ergeben zusammen die vertraglich geschuldete Funktion. Jedes Teilsystem kann für sich fertig sein, und das Projekt ist trotzdem nicht lieferbar.

Die Steuerungsfrage lautet deshalb nie „ist der Vorgang fertig“, sondern „passt System X zu System Y, in welcher Revision, geprüft durch wen“. Der Terminplan kann diese Frage nicht beantworten. Er kennt Anordnungsbeziehungen, also zeitliche Reihenfolgen. Eine Schnittstelle ist aber ein technischer Vertrag: Signalumfang, Protokoll, Adressraum, Fehlerverhalten, Verantwortlicher auf beiden Seiten.

Dazu kommt, dass die Beteiligten selten in einer Organisation sitzen. Ihr eigenes Engineering, zwei Unterlieferanten, die Hausleittechnik des Kunden, ein Softwarehaus für die Auswertung. An jeder Organisationsgrenze liegt ein Verantwortungsübergang, und an jedem Verantwortungsübergang entsteht die Annahme, die andere Seite habe die Sache verstanden.

Die Konsequenz ist ein wiederkehrendes Muster. Bis zur Integrationsphase meldet jeder Beteiligte planmäßigen Fortschritt, denn jeder misst nur das eigene Gewerk. Mit dem Start der Integration fallen die Widersprüche gebündelt an. Der Projektleiter erfährt in zwei Wochen alles, was über sechs Monate verborgen blieb, und zwar zu dem Zeitpunkt, an dem Korrekturen am teuersten sind.

Was sagen die Zahlen über komplexe Integrationsprojekte?

Die Erfolgsquote fällt mit der Zahl der Beteiligten. Die Standish Group misst 31 Prozent erfolgreiche Projekte, 50 Prozent „challenged“ und 19 Prozent gescheitert, wobei kleine Projekte rund 90 Prozent Erfolg erreichen und große unter 10 Prozent bleiben (Standish Group, CHAOS 2020). Große technische Vorhaben liegen im Schnitt 45 Prozent über Budget und liefern 56 Prozent weniger Wert als geplant (McKinsey / Universität Oxford, 2012). Über Branchen hinweg überschreiten 9 von 10 Großprojekten Kosten und Zeit (Flyvbjerg, Oxford Global Projects).

Der Verlust ist bezifferbar. 11,4 Prozent jeder Projektinvestition gehen durch schlechte Projektperformance verloren, und Organisationen ohne Projektmanagement als strategische Kompetenz verzeichnen 67 Prozent mehr vollständig gescheiterte Projekte (PMI, Pulse of the Profession 2020). Der Abstand zwischen Spitze und Feld ist groß: „Champions“ erreichen 92 Prozent erfolgreiche Projekte, „Underperformer“ 32 Prozent (PMI, Pulse of the Profession 2018).

Die Zersplitterung der Information kostet zusätzlich Arbeitszeit. Wissensarbeiter verbringen 19 Prozent ihrer Zeit mit der Suche nach Informationen 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, 54 Prozent nennen schlechte Kommunikation und wiederholte Fehler als größtes Problem (Formstack, State of Workflow Automation 2018). 42 Prozent der Unternehmen erkennen veraltende Pläne unmittelbar (techconsult, Project Performance Index), was im Umkehrschluss bedeutet: in der Mehrheit steuert man mit einem Plan, dessen Alter niemand kennt.

Warum entsteht die Lücke zwischen Plan und Technik?

Drei strukturelle Ursachen greifen ineinander.

Erstens das Datenmodell. Ein Terminplan kennt Vorgang, Dauer, Ressource, Anordnungsbeziehung. Schnittstelle, Teilsystem und Reifegrad sind darin nicht vorgesehen. Wer sie trotzdem abbilden will, missbraucht Vorgangsnamen und Freitextfelder. Damit ist die Information vorhanden, aber nicht auswertbar.

Zweitens die Verteilung der Wahrheit. Die Systemstruktur liegt im Engineering-Werkzeug, die Signalliste in Excel, die Anforderungen im Lastenheft mit Nachträgen, die Beistellzusagen im E-Mail-Verlauf, Termine im PM-Tool, Kosten im ERP. Jede Quelle hat einen eigenen Stand und einen eigenen Pfleger. Es gibt keinen Ort, an dem „Schnittstelle 27 ist geprüft“ und „Vorgang 118 ist fertig“ dieselbe Aussage sind.

Drittens der Planungszeitpunkt. Der Terminplan entsteht bei Angebotsabgabe, also beim geringsten Wissensstand über die tatsächliche Schnittstellenzahl. Die Planning Fallacy führt dabei zu systematischer Unterschätzung von Dauer und Kosten (Kahneman & Tversky 1979). Der Integrationsaufwand wächst überproportional mit der Zahl der Schnittstellen, während der Plan ihn linear als Phase am Ende führt.

Die Folge ist eine Pufferillusion. Am Ende des Terminplans stehen vier Wochen Integration und zwei Wochen FAT-Vorbereitung. Diese sechs Wochen sind in der Praxis keine Reserve, sondern der Zeitraum, in dem alle verdeckten Abweichungen sichtbar werden.

Was zeigt das Gantt und was nicht?

Ein zweites Werkzeug macht dieselbe Lücke sichtbar: die Schnittstellenmatrix. Sie tragen alle Teilsysteme sowohl in die Zeilen als auch in die Spalten ein und markieren jedes Feld, in dem eine technische Kopplung besteht. Neun Teilsysteme ergeben 72 mögliche Kopplungen. Sind davon 68 tatsächlich belegt, liegt ein hochvermaschtes System vor, dessen Integration sich nicht sequenziell planen lässt. Die Matrix beantwortet vor Projektstart zwei Fragen, die der Terminplan nie stellt: wie viele Schnittstellen es überhaupt gibt und welche Teilsysteme so stark gekoppelt sind, dass sie gemeinsam getestet werden müssen. Der Integrationsaufwand folgt der Zahl der belegten Felder, nicht der Zahl der Teilsysteme.

Die linke Spalte ist nicht falsch. Sie ist nur nicht die Information, aus der eine Integrationsentscheidung folgt. Ein Balken, der auf Grün steht, sagt nichts über die technische Passung der beiden Systeme, deren Arbeit er beschreibt.

Wie steuern Sie Schnittstellen statt Vorgänge?

Der Ansatz besteht aus Artefakten, die neben dem Terminplan stehen und mit ihm verknüpft sind. Keines ersetzt das Gantt, jedes beantwortet Fragen, die das Gantt nicht beantwortet.

1. Schnittstellenregister anlegen. Eine Zeile je Schnittstelle, mit ID, Quellsystem, Zielsystem, Art (elektrisch, mechanisch, Daten, Signal), Protokoll, vereinbartem Umfang, Verantwortlichem auf Quellseite, Verantwortlichem auf Zielseite, vereinbarter Revision, Status und Prüfnachweis. Das Register entsteht in der Klärungsphase und gilt als vertragsnahes Dokument, nicht als Notiz.
2. Verantwortungsübergänge explizit vereinbaren. Für jede Schnittstelle definieren Sie, wer liefert, wer abnimmt und woran die Abnahme erkennbar ist. Der Satz „der Kunde stellt das Netzwerk bereit“ ist kein Übergang. „Kunde stellt bis KW 18 zwei VLAN-Ports mit dokumentierter Adressvergabe bereit, Nachweis durch Ping-Protokoll, Ansprechpartner benannt“ ist einer.
3. Kundenbeistellungen im kritischen Pfad führen. Jede Beistellung erhält Zusagedatum, zuletzt bestätigten Stand, Verzugswirkung in Wochen und den Namen der verantwortlichen Person beim Kunden. Beistellungen mit Wirkung auf den kritischen Pfad gehören in jeden Statustermin, auch wenn sich nichts geändert hat. Ein unveränderter Status ist bei einer Beistellung eine Information, keine Entwarnung.
4. Reifegrad je Teilsystem tracken. Sechs Stufen reichen: Spezifikation freigegeben, Design abgeschlossen, implementiert, Modultest bestanden, Integrationstest bestanden, abgenommen. Jedes Teilsystem hat genau eine Stufe. Ein Prozentwert innerhalb der Stufe ist zulässig, ersetzt sie aber nicht.
5. Integrationsplan getrennt vom Terminplan führen. Der Integrationsplan ordnet Schnittstellen zu Integrationsstufen: Punkt-zu-Punkt-Prüfung, Teilsystemverbund, Gesamtverbund, Leistungsnachweis. Er hat eine eigene Reihenfolge, die sich aus der Technik ergibt und nicht aus der Ressourcenverfügbarkeit. Erst danach spiegeln Sie ihn in den Terminplan.
6. Abnahmekriterien vom ersten Tag an als Testfälle führen. Jedes Kriterium aus dem Lastenheft bekommt einen Testfall, eine Prüfumgebung und einen Zeitpunkt. Kriterien, die erst beim FAT in Testfälle übersetzt werden, sind die häufigste Ursache für Nacharbeit am Abnahmetag.

Die Steuerungslogik verschiebt sich dadurch. Im wöchentlichen Statustermin prüfen Sie nicht 240 Balken, sondern zwei Kennzahlen: die Zahl der Schnittstellen je Status und die Reifegradverteilung über die Teilsysteme. Beide Größen bewegen sich früh und sichtbar, während der Fertigstellungsgrad bis kurz vor der Integration stabil aussieht.

Praxisbeispiel: Leittechnik-Modernisierung in einem Wasserwerk

Ein Systemintegrator mit 140 Mitarbeitern modernisiert die Leittechnik eines kommunalen Wasserwerks. Auftragswert 2,4 Millionen Euro, Laufzeit 46 Wochen, SAT geplant in Woche 42. Beteiligt sind das eigene Engineering, ein Schaltanlagenbauer, ein Lieferant für Messtechnik und die IT-Abteilung des Betreibers.

Der Umfang besteht aus neun Teilsystemen mit 68 Schnittstellen, davon 23 zu Fremdsystemen und 6 zu Kundenbeistellungen. Geführt wird das Projekt in einem Terminplan mit 310 Vorgängen. Die Signalliste liegt in zwei Excel-Ständen, einer beim Integrator, einer beim Schaltanlagenbauer.

In Woche 9 ändert der Betreiber die Adressvergabe im Prozessnetz. Die Information erreicht das eigene Engineering, nicht aber den Messtechniklieferanten. In Woche 14 verzögert sich die Freigabe der Brandmeldeanbindung, eine Kundenbeistellung. Im Plan ist sie ein Meilenstein ohne ausgewiesene Verzugswirkung, der Statusbericht bleibt unauffällig.

Bis Woche 30 melden alle Beteiligten 85 bis 95 Prozent Fertigstellung. In Woche 31 startet der Teilsystemverbund. Innerhalb von neun Arbeitstagen fallen 31 Schnittstellenabweichungen auf, davon 12 mit Auswirkung auf den SAT-Termin.

Drei Befunde aus der Nachbetrachtung erklären den Verlauf. Die Signalliste existierte in zwei Ständen ohne Abgleichroutine. Für keine der 23 Fremdschnittstellen war ein Verantwortlicher auf der Gegenseite namentlich benannt. Die Abnahmekriterien lagen als Lastenheft-Text vor und wurden erst in Woche 38 in Testfälle übersetzt.

Die Adressänderung aus Woche 9 hätte in einem gepflegten Schnittstellenregister 22 betroffene Schnittstellen markiert und rund zwei Personentage Korrektur ausgelöst. Sie blieb 22 Wochen unentdeckt. Die Kosten entstehen nicht durch den technischen Sachverhalt, sondern durch die Liegezeit bis zur Entdeckung.

Fazit

Ein Terminplan ordnet Arbeit in der Zeit. Integrationsprojekte scheitern aber nicht an der Zeit, sondern an ungeklärten Übergängen zwischen Systemen, Firmen und Revisionsständen. Wer Schnittstellen, Reifegrade und Beistellungen als eigene Objekte führt und den Integrationsplan getrennt vom Terminplan aufsetzt, verschiebt die Fehlerentdeckung um Monate nach vorn. Das ist der einzige Hebel, der in der Integrationsphase noch wirkt, weil dort jede Korrektur ein Vielfaches ihres ursprünglichen Aufwands kostet.

Weiterführend: Technische Systemintegration: warum Standard-PM hier an Grenzen stößt · Anlagenbau-Projekte über mehrere Gewerke steuern: die größten Koordinationsprobleme

Mehr zu Projektmanagement für technisch komplexe Projekte: Aligia