*Kategorie: Problem & Praxis · Kernproblem 2: Fehlpassung Tool vs. technische Realität · Lesezeit: ca. 8 Minuten*
Ein Sondermaschinenbauer hat seine Anlage in CAD, PLM und ERP vollständig digital abgebildet: jede Baugruppe, jede Schnittstelle, jeder Freigabestand. Sein Projektplan im PM-Tool kennt davon nichts. Er besteht aus 240 Vorgängen mit Namen wie „Konstruktion Modul 3" und einer Dauer von 15 Tagen.
Diese Lücke ist der Grund, warum technische Projekte trotz sauberer Engineering-Daten aus dem Ruder laufen. Der Plan bildet nicht das ab, was gebaut wird. Er bildet ab, wie lange jemand glaubt, dass es dauert.
Für wen ist das ein Problem – und woran merkt man es?
Betroffen sind Unternehmen, deren Projekte ein physisches oder technisches System liefern: Sondermaschinen, Anlagen, Prüfstände, integrierte Systeme aus Mechanik, Elektrik und Software. Kurz: alle, bei denen der Liefergegenstand eine Struktur hat, die sich während des Projekts ändert.
Die typischen Symptome:
- Der Projektplan ist nach vier Wochen veraltet, weil sich die Systemstruktur geändert hat und niemand die Änderung auf 40 abhängige Vorgänge übertragen hat.
- Die Frage „Welche Vorgänge sind betroffen, wenn wir die Steuerung von Hersteller A auf B wechseln?" braucht einen halben Tag Recherche statt eine Abfrage.
- Meilensteine werden als erreicht gemeldet, obwohl die zugehörigen Freigaben im PLM noch offen sind.
- Der Projektleiter pflegt zwei Wahrheiten: eine im PM-Tool für den Lenkungskreis, eine in Excel für sich selbst.
Die Konsequenz: Entscheidungen werden auf Basis eines Plans getroffen, der die Technik nicht mehr abbildet. Änderungen werden zu spät erkannt, Aufwände falsch bewertet, Abhängigkeiten übersehen.
Welche Zahlen belegen das?
Standish Group (CHAOS 2020) meldet, dass 50 % aller Projekte „challenged" enden – zu spät, zu teuer oder mit reduziertem Umfang – und weitere 19 % scheitern. Bei großen Projekten liegt die Erfolgsquote unter 10 %.
PMI (Pulse of the Profession 2020) beziffert den Anteil verschwendeter Investition auf 11,4 %. Als Hauptursachen nennt PMI seit Jahren dieselben Faktoren: unklare Anforderungen, unzureichendes Änderungsmanagement, fehlende Transparenz über Abhängigkeiten.
McKinsey und die Universität Oxford (2012) fanden bei großen Technologieprojekten eine durchschnittliche Budgetüberschreitung von 45 % und eine Wertlieferung, die 56 % unter Plan lag. Die Autoren führen dies zu einem großen Teil auf das Auseinanderfallen von technischem Inhalt und Projektsteuerung zurück.
Alle drei Quellen beschreiben denselben Mechanismus: Der Plan und das System driften auseinander, und niemand bemerkt es rechtzeitig.
Warum können Standard-PM-Tools das nicht abbilden?
Standard-Projektmanagement-Tools – MS Project, Jira, Asana, Monday und vergleichbare – sind für einen bestimmten Zweck gebaut: Sie verwalten Aufgaben, Termine und Verantwortlichkeiten. Das tun sie gut. Sie sind branchenneutral, weil der Aufgaben-Termin-Verantwortlicher-Dreiklang in jeder Branche funktioniert.
Genau diese Neutralität ist das Problem in technischen Projekten. Drei Ebenen fehlen:
1. Die Systemstruktur
Eine Anlage hat eine Produktstruktur: Anlage → Modul → Baugruppe → Bauteil. Diese Struktur ist die eigentliche Ordnung des Projekts. Änderungen finden auf dieser Ebene statt („Baugruppe 4.2 wird neu konstruiert"), nicht auf Vorgangsebene.
Standard-Tools kennen nur die Vorgangsstruktur. Der Projektleiter muss die Produktstruktur in Vorgänge übersetzen und bei jeder Änderung neu übersetzen. Diese Übersetzung ist Handarbeit, fehleranfällig und der Grund für veraltete Pläne.
2. Die Schnittstellen
Der kritische Pfad in einem technischen Projekt verläuft selten entlang der geplanten Vorgangsfolge. Er verläuft entlang der Schnittstellen: mechanisch-elektrisch, Steuerung-Sensorik, Anlage-Gebäude. Eine Änderung an einer Schnittstelle betrifft beide Seiten und alle nachgelagerten Vorgänge auf beiden Seiten.
Standard-Tools kennen Vorgangsabhängigkeiten („B startet nach A"), aber keine technischen Abhängigkeiten („B ist betroffen, wenn sich die Spezifikation von A ändert"). Der Unterschied entscheidet darüber, ob eine Änderung ihre Auswirkungen sichtbar macht oder nicht.
3. Die Reifegrade
„Konstruktion abgeschlossen" ist im Maschinenbau kein binärer Zustand. Es gibt Entwurf, Vorabfreigabe, Freigabe zur Fertigung, Freigabe zur Montage. Ein Meilenstein, der als erreicht gilt, weil ein Datum verstrichen ist, sagt nichts über den tatsächlichen Reifegrad aus.
Standard-Tools führen Prozentwerte („60 % fertig"). Technische Projekte brauchen Zustände, die an reale Freigaben gekoppelt sind.
Was ist ein digitaler Zwilling des Projekts?
Der Begriff „digitaler Zwilling" wird meist für Produkte oder Anlagen verwendet: ein virtuelles Abbild, das den realen Zustand kennt. Übertragen auf das Projekt bedeutet er: Der Projektplan kennt den realen Zustand des Systems, das gebaut wird.
Konkret heißt das:
| Klassischer Projektplan | Digitaler Zwilling des Projekts |
|---|---|
| Vorgänge mit Dauer und Verantwortlichem | Vorgänge, die an Elemente der Systemstruktur gebunden sind |
| Abhängigkeiten zwischen Vorgängen | Abhängigkeiten zwischen technischen Elementen und daraus abgeleitete Vorgangsabhängigkeiten |
| Fortschritt als Prozentwert | Fortschritt als Reifegrad, gekoppelt an Freigaben in PLM/ERP |
| Änderung wird manuell übertragen | Änderung an der Struktur propagiert automatisch in betroffene Vorgänge |
| Status wird berichtet | Status wird aus dem Systemzustand abgeleitet |
Der Unterschied ist nicht kosmetisch. Er entscheidet, ob eine Änderung am Montag im Plan sichtbar ist oder am übernächsten Freitag im Statusbericht.
Wie geht man das grundsätzlich an?
Der Aufbau eines digitalen Projektzwillings ist keine Softwarefrage allein, sondern eine Strukturfrage. Drei Schritte:
- Systemstruktur als führende Struktur festlegen. Der Projektstrukturplan wird aus der Produktstruktur abgeleitet, nicht aus Phasen. Phasen (Konstruktion, Fertigung, Montage) werden zu Zuständen der Strukturelemente, nicht zu eigenständigen Gliederungsebenen.
- Technische Abhängigkeiten explizit machen. Jede Schnittstelle wird als Beziehung zwischen zwei Strukturelementen erfasst. Daraus ergibt sich, welche Vorgänge betroffen sind, wenn sich eines der beiden ändert.
- Reifegrade an Systeme koppeln. Ein Element gilt als „konstruiert", wenn im PLM die Freigabe vorliegt – nicht, wenn jemand einen Haken setzt. Das erfordert Schnittstellen zwischen Projektsteuerung und Engineering-Systemen.
Der Aufwand liegt im ersten Schritt. Die Struktur muss einmal sauber angelegt werden. Danach reduziert sich die Pflege, weil Änderungen an einer Stelle erfasst werden und nicht an vierzig.
Praxisbeispiel: Prüfstandbauer mit Schnittstellenproblem
Ein Hersteller von Prüfständen für die Automobilindustrie liefert Anlagen mit rund 1.200 Bauteilen, 40 Baugruppen und typischerweise 25 kritischen Schnittstellen zwischen Mechanik, Hydraulik, Messtechnik und Software. Projektlaufzeit 10 bis 14 Monate.
Ausgangslage: Projektplan in MS Project mit 300 Vorgängen. Änderungen aus dem PLM wurden in einem wöchentlichen Meeting besprochen und manuell übertragen. Eine Auswertung über sechs Projekte ergab, dass im Schnitt 23 % der Vorgänge zum Zeitpunkt der Montage nicht mehr zur tatsächlichen Konstruktion passten.
Konkreter Fall: Der Kunde änderte die Messschnittstelle von analog auf digital. Die Änderung wurde im PLM erfasst. Im Projektplan blieben die 14 abhängigen Vorgänge (Verkabelung, Schaltschrankaufbau, Software-Integration, Inbetriebnahme) unverändert. Die Abweichung fiel bei der Verdrahtung auf – sieben Wochen später. Mehrkosten: rund 85.000 €, Terminverzug fünf Wochen.
Nach der Umstellung auf einen strukturorientierten Plan, in dem die Messschnittstelle als Element mit 14 abhängigen Vorgängen hinterlegt war, wäre dieselbe Änderung am Tag der Erfassung als Planabweichung in allen 14 Vorgängen sichtbar gewesen.
Fazit
Standard-PM-Tools scheitern nicht, weil sie schlecht sind, sondern weil sie eine Struktur verwalten, die in technischen Projekten nicht die führende Struktur ist. Solange der Plan das System nicht kennt, bleibt jede Änderung eine manuelle Übersetzung – und jede Übersetzung eine Gelegenheit, etwas zu übersehen. Der digitale Zwilling des Projekts schließt diese Lücke, indem er die Systemstruktur zur Basis der Steuerung macht.
---
*Mehr zu modernem Projektmanagement in technisch komplexen Projekten: Aligia*