

Wie der Percent of Completion von einer subjektiven Einschätzung zu einer berechneten Steuerungskennzahl wird
Engineering-to-Order-Projekte sind durch ein hohes Maß an technischer Unsicherheit gekennzeichnet. Im Unterschied zur Serienfertigung, bei der Produkt, Fertigungsroute und Arbeitsabfolge in der Regel im Voraus stabilisiert sind, entstehen ETO-Projekte rund um einen individuellen Kundenauftrag: eine Maschine, eine Produktionslinie, ein technisches Modul, eine Anlage, ein industrielles System oder ein komplexes Set von Erzeugnissen.
In solchen Projekten laufen Konstruktion, Beschaffung, Fertigung, Montage und Installation häufig parallel. Ein Einzelteil kann noch geändert werden, nachdem es bereits an die Beschaffung übergeben wurde. Ein Lieferant kann den Liefertermin verschieben. Die Fertigung wartet möglicherweise auf eine aktualisierte Zeichnung. Die Montage plant Arbeiten, ohne ein vollständiges Bild über die Verfügbarkeit der Baugruppen zu haben. Der Projektleiter ist dabei gezwungen, den tatsächlichen Projektstatus aus mehreren Quellen zusammenzuführen: ERP, PLM/PDM, CAD, Excel, Kalendern, Besprechungen und persönlichen Nachrichten.
In der Folge bleibt eine der zentralen Projektkennzahlen — der Percent of Completion, also der Fertigstellungsgrad des Projekts — in vielen Engineering-Unternehmen keine berechnete, sondern eine expertenbasierte und subjektive Größe. Häufig entsteht sie nach dem Prinzip „ungefähr fertig“, „fast abgeschlossen“, „etwa 60 %“, „Beschaffung im Wesentlichen erledigt“, „Konstruktion fast abgeschlossen“. Für Management Accounting, Ressourcenplanung, Terminkontrolle und die frühzeitige Erkennung von Budgetrisiken ist ein solcher Ansatz nicht ausreichend.
PHASI schlägt eine andere Methodik vor: Die Fertigstellung eines Engineering-to-Order-Projekts wird nicht top-down und nicht auf Basis subjektiver Aufgabenstatus berechnet, sondern bottom-up — aus dem tatsächlichen Zustand der Arbeiten, die konkreten Einzelteilen, Baugruppen, Assemblies und Deliverables zugeordnet sind.
Diese Methodik lässt sich als struktur- und phasenbasiertes Management des Fertigstellungsgrads von ETO-Projekten definieren.
Das Kernproblem: die Lücke zwischen dem, was erstellt wird, und der Arbeit, die ausgeführt wird
Im Engineering-Projektmanagement existieren seit Langem zwei grundlegende Logiken.
Die Product Breakdown Structure, PBS, beantwortet die Frage: Was muss erstellt werden? Sie beschreibt die Produktstruktur: Maschine, System, Modul, Baugruppe, Assembly, Einzelteil, Kaufteil oder Deliverable.
Die Work Breakdown Structure, WBS, beantwortet die Frage: Welche Arbeit muss ausgeführt werden? Sie beschreibt die Arbeitsstruktur: Engineering, Prüfung, Beschaffung, Fertigung, Montage, Integration, Testing, Installation und Abnahme.
Beide Logiken sind in Project Controls, Construction, Engineering und komplexen technischen Projekten gut bekannt. In der Praxis existieren sie jedoch häufig getrennt voneinander.
ERP- und PLM/PDM-Systeme arbeiten gut mit Einzelteilen, BOMs, Stammdaten, Versionen, Bestellungen und Lieferterminen. Gantt-Tools zeigen Termine und Abhängigkeiten. Jira, Monday und ähnliche Systeme verwalten Aufgaben und Workflows. Excel bleibt ein flexibles Werkzeug für manuelle Kontrolle. Enterprise-Systeme für Project Controls unterstützen komplexe Modelle für Struktur, Leistungsumfang und Terminplanung, sind für eine schnelle Einführung in mittelgroßen Engineering-Teams jedoch oft zu schwergewichtig.
Die zentrale Lücke bleibt bestehen: Produktstruktur und Arbeitsstruktur sind selten in einem einfachen, täglichen und berechnungsfähigen Steuerungskreislauf miteinander verbunden.
Dadurch sieht der Projektleiter Aufgaben, aber nicht immer den tatsächlichen Fertigstellungsgrad des Produkts. Er sieht möglicherweise die BOM, aber nicht, welche Arbeitsphasen für jedes kritische Einzelteil tatsächlich abgeschlossen sind. Er sieht den Terminplan, versteht aber nicht, welche Verzögerungen in Konstruktion oder Beschaffung bereits Auswirkungen auf die Montage haben. Er sieht einen Fertigstellungsgrad, weiß aber nicht, woraus genau dieser berechnet wurde.
PHASI schließt diese Lücke.
Der Kern der PHASI-Methodik
Die PHASI-Methodik basiert auf einem einfachen Prinzip:
Der Fertigstellungsgrad eines Projekts muss aus dem Fertigstellungsgrad seiner Produktstruktur berechnet werden, und der Fertigstellungsgrad jedes Elements der Produktstruktur muss durch die tatsächlich abgeschlossenen Arbeitsphasen bestimmt werden.
Mit anderen Worten: Das Projekt wird nicht nur als Aufgabenliste und nicht nur als Terminplan betrachtet. Es wird als verbundenes Modell betrachtet:
Product Structure + Work Phases + Timeline State = Calculated Project Readiness
In diesem Modell erhält jedes Produktelement — Einzelteil, Baugruppe, Assembly, Modul oder Deliverable — nur diejenigen Arbeitsphasen, die tatsächlich relevant sind. Zum Beispiel:
- Requirements
- Engineering
- Design Review
- Procurement
- Manufacturing
- Assembly
- Integration
- Testing
- Installation
- Acceptance
Für jede Phasenkategorie können Gewichtungen definiert werden. Die Phasen werden auf der Timeline als Phasenbalken geplant. Wenn konkrete Phasenbalken abgeschlossen werden, berechnet das System den Fertigstellungsgrad des Elements neu. Anschließend wird der Fertigstellungsgrad in der Struktur nach oben aggregiert: vom Einzelteil zur Baugruppe, von der Baugruppe zum Assembly, vom Assembly zum Projekt. So ist der Percent of Completion keine Meinung mehr. Er wird zum Ergebnis eines Berechnungsmodells.
Warum gewöhnliches Task Management diese Aufgabe nicht löst
Auf den ersten Blick könnte es so erscheinen, als reiche es aus, Aufgaben zu verwalten: „Einzelteil konstruieren“, „Komponente bestellen“, „Platte fertigen“, „Modul montieren“. In ETO-Projekten liegt das Problem jedoch tiefer.
Eine Aufgabe allein zeigt nicht, welchen Teil der Produktstruktur sie abdeckt. Sie erklärt nicht immer, zu welcher Baugruppe eine Verzögerung gehört. Sie zeigt nicht, wie sich eine Änderung an einem konkreten Einzelteil auf Procurement, Production, Assembly und den finalen PoC auswirkt. Eine Aufgabe kann im Task Tracker geschlossen sein, während das Produktelement trotzdem noch nicht bereit für die nächste Stufe ist.
Die PHASI-Methodik verändert die Steuerungseinheit.
Anstatt nur eine Aufgabenliste zu verwalten, steuert das Team den Fertigstellungsgrad von Produktelementen. Arbeiten werden zu Phasen, die konkreten Einzelteilen und Baugruppen zugeordnet sind. Dadurch wird die Verbindung zwischen Engineering-Struktur und Projektfertigstellung explizit sichtbar.
Für Engineering-to-Order ist das entscheidend, weil gerade die Produktstruktur der Träger des Risikos ist. Verzögert ist nicht eine abstrakte Aufgabe, sondern ein konkretes Einzelteil. Geändert wird nicht ein allgemeiner Plan, sondern eine konkrete Baugruppe. Blockiert wird nicht sofort die gesamte Montage, sondern ein bestimmtes Assembly, das von bestimmten Komponenten und abgeschlossenen Phasen abhängt.
Grundprinzipien der struktur- und phasenbasierten Methodik
1. Die Produktstruktur ist die Grundlage der Steuerung
Das Projekt beginnt nicht mit einer abstrakten Aufgabenliste, sondern mit der Struktur dessen, was dem Kunden geliefert werden muss. Das kann eine Maschine, eine Produktionslinie, ein technologisches Modul, ein Set von Assemblies oder eine andere Hierarchie von Deliverables sein.
Die Struktur muss am ersten Tag nicht vollständig sein. In realen ETO-Projekten entwickelt sie sich im Zuge der Klärung von Anforderungen, der Konstruktion und der Lösungsdekomposition weiter. Die PHASI-Methodik berücksichtigt diese Realität: Neue Baugruppen, Assemblies, Einzelteile und Deliverables können im Projektverlauf ergänzt werden.
2. Arbeiten werden nur den Elementen zugeordnet, zu denen sie tatsächlich gehören
Nicht jedes Einzelteil durchläuft denselben Satz von Phasen. Eine Komponente erfordert Konstruktion, Beschaffung und mechanische Bearbeitung. Eine andere ist ein Kaufteil und benötigt keine Manufacturing-Phase. Eine dritte erfordert eine Konstruktionsprüfung, aber keine separate Procurement-Phase. Eine vierte gehört zur Installation oder Integration.
Deshalb wendet PHASI kein universelles Fertigstellungstemplate auf alle Elemente an. Phasen werden aus wiederverwendbaren Phasenkategorien nur dort zugeordnet, wo sie tatsächlich erforderlich sind. Wenn eine Phase für ein Element nicht relevant ist, wird sie nicht hinzugefügt und reduziert dessen Fertigstellungsgrad nicht.
Das schützt die Berechnung vor einem typischen Fehler: Ein Element wirkt nur deshalb „nicht vollständig fertig“, weil künstlich nicht relevante Stufen auf es angewendet wurden.
3. Der Fertigstellungsgrad wird anhand abgeschlossener Phasenbalken berechnet
Die Methodik verwendet Phasenbalken auf der Timeline. Jeder Phasenbalken repräsentiert eine konkrete Arbeit oder einen Teil einer Arbeit, die einem bestimmten Element der Produktstruktur zugeordnet ist.
Die Berechnung folgt dem Prinzip:
Beitrag der Kategorie = Gewichtung der Kategorie × abgeschlossene Phasenbalken / zugeordnete Phasenbalken
Wenn einem Einzelteil vier Engineering-Balken, ein Procurement-Balken und drei Manufacturing-Balken zugeordnet sind, wird der Fertigstellungsgrad aus den tatsächlich abgeschlossenen Balken in jeder Kategorie berechnet.
Zum Beispiel:
- Engineering: Gewichtung 20 %, abgeschlossen 2 von 4 Balken → Beitrag 10 %
- Procurement: Gewichtung 20 %, abgeschlossen 1 von 1 Balken → Beitrag 20 %
- Manufacturing: Gewichtung 30 %, abgeschlossen 1 von 3 Balken → Beitrag 10 %
Der gesamte Fertigstellungsgrad des Einzelteils über diese Kategorien beträgt somit 40 %.
Diese Berechnung ist transparent: Jeder Projektbeteiligte kann sehen, welche konkreten Phasen den aktuellen Percent of Completion bilden.
4. Der Fertigstellungsgrad wird bottom-up aggregiert
Ein ETO-Projekt sollte nicht nur auf der obersten Ebene bewertet werden. Wenn ein Projekt aus Assemblies besteht, Assemblies aus Baugruppen bestehen und Baugruppen aus Einzelteilen bestehen, dann muss die Berechnung des Fertigstellungsgrads dieser Struktur folgen.
PHASI verwendet eine Roll-up-Logik:
Part PoC → Assembly PoC → Project PoC
So lässt sich nicht nur der Gesamtfortschritt des Projekts erkennen, sondern auch, an welchen konkreten Stellen der Fertigstellungsgrad zurückliegt. Ein Projekt kann „insgesamt normal“ erscheinen, während ein kritisches Assembly die Installation blockiert. Das struktur- und phasenbasierte Modell macht solche Risiken früher sichtbar.
5. Milestones zeigen Terminrisiken, ersetzen aber nicht die Berechnung des Fertigstellungsgrads
Milestones sind wichtig, um Termine, Kontrollpunkte und Schedule Risk zu verstehen. Sie sollten jedoch nicht automatisch die Berechnung des tatsächlichen Fertigstellungsgrads ersetzen.
In PHASI liefern Milestones Kontext: Wo das Team laut Terminplan stehen sollte, welche Daten kritisch sind und welche Arbeiten sich einer Deadline nähern. Der Percent of Completion selbst wird jedoch nicht aus dem Milestone-Status gebildet, sondern aus dem Abschlussgrad der zugeordneten Phasen innerhalb der Produktstruktur.
Dadurch werden zwei unterschiedliche Managementfragen getrennt:
- Wie weit ist das Produkt tatsächlich fertiggestellt?
- Liegt dieser Fertigstellungsgrad im erforderlichen Terminplan?
Wie die Methodik im täglichen Projektmanagement funktioniert
Die praktische Anwendung von PHASI lässt sich als Abfolge von Steuerungsaktivitäten beschreiben.
Zunächst erstellt das Team die Projektstruktur: zentrale Deliverables, Assemblies, Baugruppen, Einzelteile, Module oder andere Elemente. Anschließend werden diesen Elementen relevante Arbeitsphasen zugeordnet: Engineering, Procurement, Manufacturing, Assembly, Integration und weitere. Danach werden die Phasen auf der Timeline platziert und erhalten Verantwortliche, Termine und Ausführungsstatus.
Im Verlauf der Arbeit aktualisieren die Teams den Status der Phasenbalken. Abgeschlossene Phasen wirken sich automatisch auf den Fertigstellungsgrad des Elements aus. Der Fertigstellungsgrad eines Elements beeinflusst den Fertigstellungsgrad des übergeordneten Knotens. Die Fertigstellungsgrade der Knoten bilden den Fertigstellungsgrad des gesamten Projekts.
Dieser Ansatz schafft einen einheitlichen operativen Steuerungskreislauf für mehrere Beteiligte:
- Engineering sieht, welche Elemente noch Konstruktion, Prüfung oder Änderung erfordern.
- Procurement versteht, welche Einzelteile für nachfolgende Phasen kritisch sind und wo Lieferantenverzögerungen Risiken erzeugen.
- Manufacturing sieht, welche Elemente produktionsbereit sind und welche noch von Engineering-Änderungen abhängen.
- Assembly und Installation erhalten frühere Signale zu fehlenden oder geänderten Teilen.
- Project Management erhält ein berechnetes Bild des Fertigstellungsgrads statt einer manuellen Rekonstruktion des Status.
Management Value: früher Hinweis statt später Erklärung
Der zentrale Wert von PHASI liegt nicht darin, dass das System einen optisch ansprechenden Prozentsatz zeigt. Der Wert liegt darin, dass dieser Prozentsatz zu einem frühen Steuerungssignal wird.
In vielen Engineering-Unternehmen werden Probleme zu spät sichtbar. Der Lieferant hat das Einzelteil bereits verzögert. Die Montage wartet bereits auf eine Komponente. Eine Konstruktionsänderung hat die Fertigung bereits beeinflusst. Das Budget beginnt bereits, den Rahmen zu überschreiten. Der Projektleiter erfährt davon erst nach mehreren Klärungen, Meetings und manuellen Abgleichen.
Die struktur- und phasenbasierte Methodik verlagert den Zeitpunkt der Risikoerkennung nach vorne.
Wenn sich eine Procurement-Phase für ein kritisches Einzelteil verzögert, ist dies auf Ebene dieses Einzelteils und des zugehörigen Assembly sichtbar. Wenn eine Engineering-Phase nicht abgeschlossen ist, Manufacturing jedoch bereits starten sollte, entsteht ein klar erkennbares Schedule Risk. Wenn die Montage auf eine Baugruppe wartet, deren berechneter Fertigstellungsgrad unter dem erforderlichen Wert liegt, wird das Problem sichtbar, bevor es tatsächlich zum Stillstand kommt.
Dadurch wird nicht die Folge verwaltet, sondern die Ursache.
Abgrenzung von PHASI gegenüber ERP, PLM, Primavera und Excel
PHASI ersetzt weder ERP, PLM, PDM, CAD noch Enterprise Project Controls.
ERP bleibt das System für Bestellungen, Lieferungen, Finanzen, Lager und Stammdaten. PLM/PDM bleibt die Quelle für Engineering-Daten, Versionen, BOMs und Change Management. CAD bleibt die Umgebung für die Konstruktion. Primavera und vergleichbare Enterprise-Systeme bleiben leistungsfähige Werkzeuge für komplexe Project Controls auf Ebene großer Organisationen.
PHASI besetzt eine andere Ebene.
Es ist ein focused planning layer für Engineering-to-Order-Teams, die eine leichte und verständliche Möglichkeit benötigen, Produktstruktur, phasenbasierte Arbeit, Timeline und berechneten Fertigstellungsgrad miteinander zu verbinden.
Im Vergleich zu Excel bietet PHASI eine lebendige Struktur, die mit Phasen und Roll-up-Berechnung verbunden ist. Im Vergleich zu einem gewöhnlichen Gantt-Tool bietet es die Zuordnung von Arbeiten zu Einzelteilen und Assemblies. Im Vergleich zu einem Task Tracker bietet es ein produktorientiertes Modell des Fertigstellungsgrads. Im Vergleich zu Enterprise-Systemen bietet es eine schlankere SaaS-Implementierung für Teams, die keinen vollständigen, schwergewichtigen Project-Controls-Kreislauf benötigen.
Warum dies eine neue Methodik speziell für Engineering-to-Order ist
Klassische PBS und WBS sind für sich genommen nicht neu. Die Neuheit von PHASI liegt nicht darin, dass Produktstruktur oder Arbeitsstruktur neu erfunden wurden.
Die Neuheit liegt in der methodischen Verbindung dieser Ansätze zu einem täglichen, berechnungsfähigen Modell für ETO-Projekte:
- Jedes Produktelement erhält seinen eigenen Satz relevanter Phasen.
- Jede Phase besitzt eine zeitliche Position und einen Status.
- Der Fertigstellungsgrad wird aus abgeschlossenen Phasen berechnet.
- Das Ergebnis wird entlang der Produkthierarchie aggregiert.
Dadurch eignet sich die Methodik besonders für Projekte, in denen:
- das Produkt für einen konkreten Kundenauftrag erstellt wird;
- sich die Produktstruktur während der Ausführung weiterentwickelt;
- Engineering, Procurement, Manufacturing und Assembly parallel laufen;
- Konstruktionsänderungen nach Projektstart auftreten;
- Lieferanten die Fertigstellung von Assemblies beeinflussen;
- Installation und Montage von der tatsächlichen Verfügbarkeit von Einzelteilen abhängen;
- manuelle Statuskontrolle viel Zeit beansprucht;
- der Percent of Completion für Management- und Finanzentscheidungen wichtig ist.
Gerade unter solchen Bedingungen reicht ein gewöhnlicher prozentualer Aufgabenfortschritt nicht aus. Erforderlich ist eine Readiness-Kennzahl, die mit der technischen Struktur des Projekts verbunden ist.
PHASI als operatives Modell, nicht nur als Dashboard
Ein Dashboard zeigt Daten an. Die PHASI-Methodik erzeugt Daten.
Das ist ein wichtiger Unterschied.
Wenn ein System nur Informationen aus ERP, PLM oder Task Trackern sammelt, zeigt es bereits vorhandene Status an. Wenn diese Status jedoch ursprünglich nicht mit Produktstruktur und Arbeitsphasen verbunden sind, löst ein Dashboard das Kernproblem nicht.
PHASI definiert die Art und Weise, wie ein Projekt geführt wird: wie die Struktur dekomponiert wird, wie Phasen zugeordnet werden, wie der Fertigstellungsgrad berechnet wird, wie der PoC entlang der Hierarchie nach oben aggregiert wird und wie die Timeline mit der technischen Realität verbunden wird.
Deshalb sollte PHASI nicht als visuelle Erweiterung betrachtet werden, sondern als Methodik zur Steuerung des Fertigstellungsgrads von ETO-Projekten, umgesetzt in einem SaaS-Produkt.
Fazit
Engineering-to-Order-Projekte erfordern einen anderen Ansatz zur Steuerung des Fertigstellungsgrads. Es reicht nicht aus zu wissen, welche Aufgaben offen sind und welche Termine im Plan stehen. Entscheidend ist zu verstehen, welche Produktelemente tatsächlich fertig sind, welche Phasen für sie abgeschlossen wurden und welche Verzögerungen bereits Auswirkungen auf Montage, Lieferung und Budget haben.
PHASI bietet eine struktur- und phasenbasierte Methodik, in der die Produkthierarchie mit Arbeitsphasen und Timeline verbunden wird und der Percent of Completion bottom-up berechnet wird — vom Einzelteil zum Assembly und vom Assembly zum Projekt.
Dieser Ansatz macht den Projektfertigstellungsgrad transparenter, reduziert die Abhängigkeit von subjektiven Einschätzungen, verringert den manuellen Aufwand zur Statuserhebung und gibt dem Projektleiter ein früheres Signal für Risiken.
Für Engineering-to-Order-Unternehmen bedeutet dies den Übergang von Steuerung über Vermutungen und Meetings hin zu Steuerung über ein berechnetes Modell des tatsächlichen Fertigstellungsgrads.
Der Percent of Completion ist damit keine ungefähre Meinung mehr.
Er wird zu einem Instrument der Projektsteuerung.