Kategorie: KI im Projektmanagement
9 von 10 Großprojekten überschreiten Kosten und Zeit (Flyvbjerg, Oxford Global Projects). Der Grund ist selten Unvermögen. Er ist strukturell: Der Plan entsteht zu dem Zeitpunkt, an dem am wenigsten bekannt ist, und er entsteht rückwärts vom Wunschtermin. Kahneman und Tversky beschrieben die systematische Unterschätzung von Dauer und Kosten bereits 1979 als Planning Fallacy. Ein Gantt-Diagramm ändert daran nichts, wenn die Balken von Hand auf den Liefertermin gezogen werden.
Der KI-Terminoptimierer in Aligia dreht die Reihenfolge um: Er berechnet den Zeitplan aus Vorgangsdauern, Abhängigkeiten, Ressourcen und Material. Der Wunschtermin ist eine Prüfgröße, kein Ausgangspunkt.
Warum sind händisch gezogene Zeitpläne Wunschdenken?
Drei Mechanismen, die jeder Projektleiter kennt:
Rückwärtsplanung vom Liefertermin. Der Kunde will die Anlage in Woche 40. Die Inbetriebnahme dauert vier Wochen, also Woche 36. Die Montage acht Wochen, also Woche 28. Und so weiter, bis die Konstruktion in Woche 3 fertig sein muss, obwohl das Lastenheft erst in Woche 5 freigegeben wird. Der Plan ist konsistent und falsch.
Ressourcen als Annahme. Der Plan setzt voraus, dass zwei Monteure ab Woche 28 verfügbar sind. Ob sie es sind, steht in einem anderen Projektplan, den niemand daneben gelegt hat. Ressourcenkonflikte verursachen 49 % Mehrkosten [Aligia-Ableitung aus Standish, Beleg intern].
Material als Fußnote. Der Servoantrieb hat 14 Wochen Lieferzeit. Im Plan steht das nirgends, weil der Plan Vorgänge kennt, keine Bestellungen. Die Verzögerung wird in Woche 22 sichtbar, wenn die Montage beginnen soll.
Ein Plan, der diese drei Größen nicht als Eingabe hat, kann sie nicht berücksichtigen. Er ist ein Foto des Wunsches.
Was macht der KI-Terminoptimierer in Aligia anders?
Der Optimierer nimmt vier Eingaben aus dem Projekt und berechnet daraus einen Zeitplan:
Eingabe | Woher sie kommt |
|---|---|
Vorgänge mit Dauer und Aufwand | Aus der Projektstruktur (Segment, Arbeitspaket, Aufgabe) |
Abhängigkeiten und Terminbindungen | Aus den hinterlegten Vorgänger-Nachfolger-Beziehungen, Gates, Meilensteinen, „Nicht vor“-Bedingungen |
Personen und Equipment mit Verfügbarkeit | Aus Arbeitskalendern, Abwesenheiten und bestehenden Buchungen, projektübergreifend |
Materialbedarf gegen Bestand und Bestellungen | Aus dem Materialbedarf der Vorgänge, dem Lagerbestand und offenen Aufträgen |
Es gibt nichts zu konfigurieren. Ein Lauf plant jedes ausgewählte Projekt gegen seine Priorität und seinen gewünschten Endtermin, mit einem festen Suchbudget von 10 Sekunden, maximal 40. Bis zu 50 Projekte lassen sich in einem Lauf gemeinsam planen, aus der Priorisierungstabelle des Portfolios heraus. Das ist der Unterschied zur Einzelprojektsicht: Die Monteure, die in Projekt A verplant sind, fehlen in Projekt B, und der Optimierer weiß das.
Das Ergebnis ist ein Entwurf. Am realen Plan ändert sich nichts, bis Sie ihn anwenden.
Wie lesen Sie das Ergebnis?
Der Entwurf hat vier Ansichten:
- Projekte. Eine Zeile pro Projekt: berechneter Endtermin, pünktlich oder verspätet gegenüber dem Wunschtermin, Kosten des eigenen Ressourceneinsatzes, Anzahl verschobener Vorgänge, und die Probleme, auf die der Optimierer gestoßen ist (ein Gate, das verletzt würde, ein Vorgang, der nicht besetzt werden kann), jeweils mit Vorschlag, wo möglich.
- Ressourcen. Eine Auslastungs-Heatmap über alle Personen und Equipment im Plan, mit den bestehenden Buchungen als Kontext.
- Material. Was die geplanten Vorgänge noch zu beschaffen haben und bis wann, aus dem Bedarf gegen Bestand und Bestellungen, über den ganzen Lauf gebündelt. Die Beschaffungsvorschläge des Optimierers werden beim Anwenden als Beschaffungsanfragen angelegt, mit Ankunftstag und Bestelltag.
- Zeitplan. Der Entwurf als Gantt, mit dem aktuellen Plan als Schatten darüber. Sie sehen exakt, was sich verschoben hat. Gates, Meilensteine und Ereignisse sind markiert: gehalten, verpasst, unbekannt oder bereits erledigt.
Findet der Optimierer keinen gangbaren Plan, zeigt er statt eines Zeitplans eine Diagnose: fehlende Ressourcen, widersprüchliche Bedingungen. Das ist eine Information, die ein handgezogener Plan nie liefert. Er sieht immer machbar aus.
Was tun Sie, wenn der berechnete Termin nach dem Wunschtermin liegt?
Das ist der Normalfall bei der ersten Anwendung, und er ist der Sinn des Werkzeugs. Der Optimierer zeigt, was die Vorgangsdauern hergeben. Ab hier haben Sie Entscheidungen, keine Hoffnungen:
- Vorgang fixieren. Sie pinnen im Entwurf einen Vorgang auf einen berechneten Start und probieren weiter. Pinnen gilt nur für den aktuellen Entwurf. Soll die Position künftige Läufe überdauern, befördern Sie sie: Ein Vorgang wird als echte „Nicht vor“-Bedingung zurückgeschrieben, ein Gate oder Meilenstein als festes Datum.
- Ressource ergänzen. Die Heatmap zeigt, wo der Engpass liegt. Ein zusätzlicher Monteur in Woche 28 bis 31 ist eine Entscheidung mit Kosten, die Sie jetzt treffen, nicht in Woche 30.
- Beschaffung vorziehen. Die Materialansicht zeigt den Bestelltag, der den Plan hält. Wer ihn verpasst, weiß es sofort.
- Mit dem Kunden sprechen. Mit einem berechneten Termin und einer Begründung, statt mit einer Zusage, die auf Rückwärtsrechnung beruht.
Polaris kann diesen Prozess begleiten: den Lauf anstoßen, vorab prüfen, ob die Voraussetzungen erfüllt sind, das Ergebnis zusammenfassen und den Unterschied zum aktuellen Plan darstellen. Die Anwendung bleibt ein manueller Schritt mit Administratorrolle.
Was passiert beim Anwenden?
Anwenden schreibt Vorgangstermine und Ressourcenbuchungen in den realen Plan und legt die Beschaffungsanfragen an. Für ein Projekt in einer frühen Phase (Initial, Definition, Planung) ist das Anwenden zugleich der Übergang in die Ausführung. Ein Projekt kommt in Aligia nicht ohne einen berechneten Plan in die Ausführungsphase. Das ist eine bewusste Hürde gegen den Plan aus Wunschdenken.
Und es ist umkehrbar. Wird ein Projekt später aus der Ausführung zurück in die Planung gesetzt, warnt Aligia und stellt den Zustand vor dem Anwenden wieder her: Vorgangspositionen, Zuweisungen und Termine, soweit sie seitdem niemand geändert hat. Die Buchungen und offenen Beschaffungsanfragen des Optimierers werden zurückgezogen. Bereits gebuchte Arbeitszeit bleibt unberührt.
Praxisbeispiel: Sondermaschinenbau, 1,6 Mio. Euro, Wunschtermin Woche 34
Ein Sondermaschinenbauer mit 70 Mitarbeitenden plant eine Montagelinie, Auftragswert 1,6 Mio. Euro. Der Vertrieb hat Woche 34 zugesagt. Der händisch gezogene Plan endet in Woche 34.
Der Optimierer berechnet aus 212 Vorgängen, 4 Gates, 11 Personen, 2 Prüfständen und 38 Materialpositionen einen Endtermin in Woche 39. Die Projektansicht nennt zwei Probleme: Das Gate „Elektrofreigabe“ wird um 6 Werktage verletzt, weil der einzige Elektrokonstrukteur in Woche 9 bis 11 in einem anderen Projekt gebucht ist. Und die Materialansicht zeigt, dass der Bestelltag für die Linearachsen bereits vor drei Tagen war.
Der Projektleiter trifft drei Entscheidungen: Die Linearachsen werden heute bestellt. Für die Elektrokonstruktion wird ein externer Konstrukteur für drei Wochen beauftragt, Kosten 18.000 Euro. Der Kunde wird über Woche 36 informiert, mit dem berechneten Plan als Grundlage. Der zweite Lauf mit dem zusätzlichen Konstrukteur ergibt Woche 36. Der Projektleiter wendet an.
Ohne Optimierer wäre Woche 34 im Plan geblieben, bis die Realität ihn in Woche 22 eingeholt hätte. Die 18.000 Euro für den Konstrukteur wären dann teurer gewesen, weil sie als Eskalation statt als Planung angefallen wären.
Was ist der Optimierer nicht?
Kein Automat, der von selbst nachplant. Der Lauf wird von einem Menschen oder von Polaris auf Auftrag gestartet, und angewendet wird von einem Menschen. Eine zeitgesteuerte Neuberechnung, etwa jede Nacht, oder eine ereignisgesteuerte, etwa bei jeder Lieferverzögerung, ist in Aligia noch nicht freigegeben. Workflow-Definitionen, die so etwas orchestrieren könnten, laufen heute manuell.
Fazit
Ein Zeitplan aus Vorgangsdauern, Ressourcen und Material ist unbequemer als einer vom Wunschtermin rückwärts. Er zeigt früher, was nicht geht. Das ist sein Wert: Entscheidungen fallen in Woche 3 statt in Woche 22, und sie kosten in Woche 3 weniger. Der KI-Terminoptimierer in Aligia ist dafür gebaut, mit vier Ansichten zum Prüfen und einem Anwenden, das umkehrbar bleibt.
Lassen Sie eines Ihrer Projekte durchrechnen. In 10 Minuten zeigen wir Ihnen, was der Optimierer aus Ihren Vorgangsdauern macht und wo er Probleme meldet. Demo anfragen · Kostenlos · Unverbindlich · Persönlich
Weiterführend: Der Plan ist Wunschdenken: Warum Projektpläne bei geringstem Wissen entstehen (Problem & Praxis) · Polaris: Wie ein KI-Chat direkt im Projekt schreibt
