Eine Monte-Carlo-Simulation zeigt nicht ein Enddatum, sondern eine Wahrscheinlichkeit. Mit dem neuen MCP-Server in Merlin Project bitten Sie Claude in einem Satz, Ihren Plan auszulesen und 10.000 Projektverläufe zu berechnen. So gehen Sie dabei vor.
Eine Monte-Carlo-Simulation übersetzt Unsicherheit in Wahrscheinlichkeit. Statt eines einzelnen Termins bekommen Sie eine Verteilung möglicher Endtermine. Mit dem MCP-Server in Merlin Project braucht das kein Spezial-Add-in und keine mühsam gepflegten Schätzungen mehr; ein Satz an Claude genügt.
Was eine Monte-Carlo-Simulation genau ist und warum sie den kritischen Pfad schlägt, erklärt unser Guide zu Monte Carlo im Projektmanagement. Hier geht es um die Praxis: wie Sie die Simulation mit Merlin Project und dem MCP-Server tatsächlich rechnen.
Merlin Project und der MCP-Server
Merlin Project bringt einen MCP-Server mit. MCP steht für Model Context Protocol, einen offenen Standard, der KI-Assistenten eine strukturierte und sichere Verbindung zu externen Anwendungen gibt. Der Server läuft lokal auf Ihrem Mac und ist nicht aus der Ferne erreichbar; er lädt von sich aus nichts hoch und gibt nur preis, was die KI aktiv abfragt. Was die KI ausliest, verarbeitet sie allerdings beim jeweiligen Anbieter: Bei einem Cloud-Client wie Claude gehen die gelesenen Plandaten an dessen API. Sie behalten die Kontrolle darüber, welches Projekt Sie freigeben, ganz im Sinne der digitalen Souveränität. Sie aktivieren ihn pro Projekt über den Button „KI-Tools" in der Symbolleiste des Dokuments. Die vollständige Einrichtung für Claude Desktop, Claude Code und weitere Clients steht in der MCP-Dokumentation.
Der Lesezugriff genügt
Der MCP-Server bietet derzeit ausschließlich Lesezugriff auf Projektdaten. Für eine Monte-Carlo-Simulation ist das genau richtig: Der Client kann den Plan nur lesen, am Plan selbst kann nichts verändert werden. Die Simulation liest den Plan nur einmal aus; die gesamte stochastische Rechnung läuft außerhalb von Merlin. Nichts wird in den Live-Plan zurückgeschrieben. Ihre Projektstruktur bleibt die unangetastete Single Source of Truth, und Sie können beliebig oft und auf beliebigen Planständen simulieren.
Aus dem Plan liest die KI drei Dinge. Erstens die Vorgänge mit ihrer geplanten Dauer. Zweitens die Netzplanlogik, also die Abhängigkeiten zwischen Vorgänger und Nachfolger, samt Anordnungsbeziehung und Puffer. Drittens die Verortung der Unsicherheit, also an welchem Vorgang ein Risiko hängt. Die Netzplanlogik ist der Kern: Ohne die Abhängigkeitskanten würden Sie nur Dauern addieren, statt einen Netzplan zu rechnen.
Der Knackpunkt: die Unsicherheit steckt noch nicht im Plan
Merlin speichert pro Vorgang eine Plandauer und später einen Ist-Wert, aber keine native Drei-Punkt-Schätzung. Es gibt drei Wege, dies zu lösen:
- Eigene Felder. Sie legen O und P als benutzerdefinierte Felder im Template an und lesen sie per MCP mit aus. Die sauberste Lösung, wenn Sie das Template kontrollieren.
- Globales Unsicherheitsband. Plandauer plus oder minus X Prozent als Dreieck oder PERT, bei Bedarf nach Phase oder Vorgangstyp skaliert.
- Hybrid. Annotierte Risikovorgänge bekommen ihr eigenes Band, der Rest einen Default.
Welchen Weg Sie auch wählen: Zeigen Sie transparent, woher die Unsicherheit kommt. Genau das macht eine Simulation glaubwürdig.
Der agentische Ablauf, und der Denkfehler, den Sie vermeiden müssen
Hier liegt der häufigste Irrtum: Claude geht die 10.000 Iterationen nicht selbst durch. Kein Sprachmodell zieht 10.000 Zufallsstichproben im Kopf. Das wäre nicht nur tokenintensiv, sondern statistisch wertlos, denn Sprachmodelle sind schlechte Zufallsgeneratoren. Die Iterationen gehören in Code.
Der Trick ist nicht „Python-Skript gegen MCP-Client", sondern Codeausführung durch den Client. Der Ablauf hat drei Schritte:
- Lesen. Claude ruft die Read-Tools des Merlin-MCP-Servers und holt Vorgänge, Dauern und Abhängigkeiten.
- Rechnen. Claude schreibt sich selbst die Simulation in wenigen Zeilen numpy und führt sie in einer Code-Umgebung aus, als Teil der Antwort. Das setzt einen Client mit Codeausführung voraus, etwa Claude Code; ein reines Chatfenster ohne Codeausführung kann die Iterationen nicht rechnen. Pro Iteration zieht das Modell für jeden Vorgang eine Dauer, läuft in topologischer Reihenfolge durch den Netzplan (Vorgänger und Lags beachten) und nimmt als Projektende das späteste Ende aller Endknoten.
- Erklären. Claude gibt die S-Kurve, P50, P80 und P90 sowie ein Tornado-Diagramm zurück und interpretiert das Ergebnis in verständlicher Sprache.
Aus Ihrer Sicht ist die Erzählung einfach. Sie stellen eine Frage in natürlicher Sprache:
Lies das aktive Projekt aus Merlin Project und simuliere 10.000 mögliche
Projektverläufe. Nimm pro Vorgang die Plandauer plus/minus 20 Prozent als
PERT-Verteilung an. Zeige mir die S-Kurve und die Termine für P50, P80 und P90.Claude liest den Plan, rechnet und zeigt Ihnen die Wahrscheinlichkeitskurve. Der Code dahinter ist Implementierungsdetail, kein Lernschritt. Es ist wie beim Taschenrechner: Sie nutzen ihn, statt im Kopf zu multiplizieren.
Übrigens sind nicht die Iterationen tokenintensiv (in Code sind sie praktisch gratis), sondern das Hineinziehen einer 300-Zeilen-Vorgangsliste in den Kontext. Für den Einstieg gilt deshalb: ein bewusst kleiner, sauberer Beispielplan mit 15 bis 25 Vorgängen. Das ist groß genug für Pfadkonvergenz und einen interessanten Tornado, und klein genug, dass die ganze Konversation auf eine Bildschirmseite passt.
Das Ergebnis aus 10.000 Läufen
So sieht Claudes Antwort auf den Prompt von oben aus, gerechnet auf einem kleinen Bauprojekt-Plan. Claude verbindet sich mit dem aktiven Dokument, liest Vorgänge, Verknüpfungen (26-mal Ende-Anfang, einmal Anfang-Anfang) und den Kalender (Montag bis Freitag, 8 Stunden pro Tag), baut das Netz nach und validiert es gegen den Plan-Endtermin. Das Modell reproduziert ihn exakt: 60 Arbeitstage, also der 21.08.2026. Dann laufen die 10.000 Durchläufe.
Dieses Beispielprojekt umfasst nur rund zwei Dutzend Vorgänge, deren Termin von einer langen, seriellen Kette bestimmt wird. Deshalb ist die Spanne zwischen P10 und P90 mit etwa einer Woche bewusst schmal; größere oder stärker verzweigte Projekte streuen meist deutlich weiter.
| Konfidenz | Datum | Gegenüber Plan (21.08.) |
|---|---|---|
| Plantermin | 21.08.2026 | rund 49 Prozent Trefferwahrscheinlichkeit |
| P50 | 24.08.2026 | plus 1 Arbeitstag |
| P80 | 25.08.2026 | plus 2 Arbeitstage |
| P90 | 26.08.2026 | plus 3 Arbeitstage |
Die Spannweite über alle 10.000 Läufe reicht von frühestens 17.08. bis spätestens 01.09.
Die Lesart ist eindeutig: Der Plantermin ist ein 50/50-Termin. In rund der Hälfte der Durchläufe wird er gehalten, in der anderen Hälfte gerissen. Das ist der typische Befund, denn eine deterministische Planung landet fast immer auf dem optimistischen P50, nicht auf einem belastbaren Liefertermin. Wer mit 90 Prozent Sicherheit zusagen will, kommuniziert den 26.08., also rund drei Arbeitstage Puffer.
Claude legt dabei die eigenen Annahmen offen: Hier diente die Plandauer als wahrscheinlichster Wert, mit O bei −20 Prozent und P bei +20 Prozent als symmetrische PERT-Beta-Verteilung. Mit den echten, teils asymmetrischen Drei-Punkt-Schätzungen aus dem Plan würde der rechte Auslauf länger und P90 später. Die diskreten Risikoereignisse, der Lieferantenausfall und der Statiker-Ausfall, sind hier noch nicht modelliert; das war reine Dauerstreuung. Genau die rechnen wir in den nächsten beiden Beispielen durch.
Beispiel A: der Lieferantenvergleich
Das stärkste Beispiel beantwortet eine Entscheidungsfrage, nicht nur eine Prognosefrage. Stellen Sie sich einen Vorgang vor, der an einer Lieferung hängt. Lieferant A liefert erfahrungsgemäß in einem Teil der Fälle pünktlich, sonst mit einigen Tagen Verzug. Wichtig ist dabei der Nenner: 10 verspätete von 100 Lieferungen sind ein anderes Risiko als 10 von 15. Genau hier zeigt Monte Carlo seine Stärke, denn es verrechnet keine Luftannahmen, sondern übersetzt gelebte Lieferhistorie in eine Prognose.
Der eigentliche Mehrwert ist der Geld-gegen-Risiko-Trade-off. Lieferant A ist günstiger, aber unzuverlässiger; Lieferant B ist teurer, aber stabil und kostet 4.000 Euro mehr. Lohnt sich der Aufpreis? Diese Frage versteht eine Geschäftsführung sofort, und Monte Carlo beantwortet sie mit einer Zahl statt mit einem Bauchgefühl.
Eine solche Frage stellen Sie Claude in einem Satz:
Vorgang 19 „Material verbaut" hängt an einer Lieferung. Lieferant A liefert
erfahrungsgemäß in 85 Prozent der Fälle pünktlich, sonst mit 10 Tagen Verzug.
Simuliere, wie sich das auf den Endtermin auswirkt, und vergleich es mit
Lieferant B, der immer pünktlich liefert, aber 4.000 Euro mehr kostet.Claude hängt den Risiko-Schalter an die Lieferung und rechnet beide Lieferanten mit denselben Zufallsziehungen (Common Random Numbers), damit der Unterschied sauber nur an der Lieferung hängt. Das Ergebnis ist verblüffend eindeutig (AT steht für Arbeitstage):
| Konfidenz | Lieferant A (85 % pünktlich, sonst +10 AT) | Lieferant B (immer pünktlich, +4.000 €) |
|---|---|---|
| P50 | 21.08.2026 | 21.08.2026 |
| P80 | 25.08.2026 | 25.08.2026 |
| P90 | 25.08.2026 | 25.08.2026 |
| Plantermin gehalten | 50,5 % | 50,5 % |
| Endtermin-Rutsch durch A | 0,00 % | Referenz |
In keinem einzigen der 10.000 Durchläufe verschiebt der unzuverlässige Lieferant A den Endtermin. Die beiden Verteilungen sind deckungsgleich. Der Grund steckt im Plan: Vorgang 19 „Material verbaut" hängt an zwei Vorgängern, der Lieferung und dem Dach auf dem kritischen Pfad. Das Dach wird systematisch später fertig, also wartet „Material verbaut" ohnehin auf das Dach, nicht auf die Fassadenlieferung. Zwischen Lieferung und Einbau liegen im Median 21 Arbeitstage Puffer, selbst im am stärksten gestauchten Lauf noch gut 17. Ein Verzug von 10 Arbeitstagen erreicht diese Grenze nie.
Am besten sieht man das an der Sensitivität: Wie groß müsste der Verzug überhaupt werden, um den Endtermin zu bewegen?
Erst oberhalb dieser Pufferkante, also jenseits von rund 17 bis 21 Arbeitstagen, beginnt überhaupt etwas durchzuschlagen: Bei 25 Tagen rutschen 7 Prozent der Läufe, bei 30 Tagen rund 15. Die Kostenentscheidung ist damit klar. Die 4.000 Euro für Lieferant B kaufen unter diesen Annahmen null Termingewinn, der erwartete vermiedene Verzug beträgt 0,0 Arbeitstage. Aus reiner Terminsicht ist Lieferant A die rationale Wahl; das Geld wäre für ein Risiko bezahlt, das der Plan über seinen Puffer schon trägt. B lohnt sich erst, wenn sich eine Annahme verschiebt: wenn der Verzug deutlich größer als 10 Tage wird (ein Importcontainer statt regionaler Lieferung), wenn der Rohbau viel früher fertig wird und der Puffer schrumpft, oder wenn auf dem Fassadenstrang eigene vertragsstrafenbewehrte Zwischentermine hängen. Genau das könnte ein rein deterministischer Plan nie zeigen.
Eine ehrliche Randnotiz: Die beiden Beispiele sind eigene Simulationsläufe mit den jeweiligen Risiko-Schaltern. Ein Tag Abweichung im Basistermin gegenüber der S-Kurve weiter oben ist normales Sampling-Rauschen, kein Widerspruch. Monte Carlo schätzt eine Verteilung, es ist kein Taschenrechner mit festen Nachkommastellen.
Beispiel B: der Ressourcenausfall
Das zweite Beispiel dreht an einer anderen Schraube: nicht an der Dauer, sondern an einem diskreten Ereignis. Eine Schlüsselressource könnte ausfallen, hier der Statiker, der an zwei Vorgängen arbeitet, der Tragwerksplanung früh im Projekt und der statischen Abnahme spät. Fällt er aus, und wenn ja, wann trifft es härter?
Simuliere mein Projekt für drei Fälle: Ressource „Statiker" fällt nicht aus,
fällt in Woche 3 für 10 Tage aus, fällt in Woche 8 für 10 Tage aus. Zeige mir
je P50/P80/P90 und welcher Ausfallzeitpunkt den Endtermin am stärksten trifft.Wieder rechnet Claude alle drei Fälle mit denselben Zufallsziehungen, damit die Unterschiede sauber nur am Ausfall hängen:
| Fall | P50 | P80 | P90 | Verschiebung |
|---|---|---|---|---|
| Kein Ausfall | 21.08.2026 | 25.08.2026 | 25.08.2026 | Basis |
| Ausfall früh (Tragwerksplanung) | 04.09.2026 | 08.09.2026 | 08.09.2026 | +10 AT |
| Ausfall spät (statische Abnahme) | 02.09.2026 | 04.09.2026 | 07.09.2026 | +8 AT |
Beide Ausfälle reißen den Plantermin sicher, die Trefferwahrscheinlichkeit fällt von 50 auf 0 Prozent. Interessant ist die Differenz: Der frühe Ausfall trifft härter. In 100 Prozent der Läufe verschiebt er den Endtermin weiter als der späte, im Mittel um 2 Arbeitstage. Der Grund ist wieder die Pufferlage, nicht der Zeitpunkt an sich. Die Tragwerksplanung liegt voll auf dem kritischen Pfad, ohne Puffer; ihre zehn Ausfalltage schlagen 1:1 durch, glatte plus 10 Arbeitstage in jedem Lauf. Die statische Abnahme dagegen zieht einen kleinen Restpuffer aus einem parallelen Strang, der zwei der zehn Tage schluckt, bevor sie selbst zum bindenden Vorgang wird. Übrig bleiben plus 8 Arbeitstage.
Das ist die handfeste Lehre aus Beispiel B: Ein gleich langer Ausfall kostet unterschiedlich viel, je nachdem, wie viel Puffer der betroffene Vorgang hat. Vertretung, Vorlauf und Reserve gehören zuerst an die Ressourcen auf dem kritischen Pfad, die keinen Puffer haben.
Kritischer Pfad gegen Puffer: die gemeinsame Pointe
Beide Beispiele sagen im Kern dasselbe: Nicht das Risiko allein entscheidet, sondern wo es im Netzplan sitzt. Derselbe Verzug kostet auf einem Vorgang mit Puffer nichts und auf dem kritischen Pfad alles. Monte Carlo zeigt eben nicht „Verzug ist schlecht", sondern wann ein Risiko durchschlägt und wann der Plan es absorbiert. Deshalb war der billige Lieferant in Beispiel A die rationale Wahl und der frühe Ausfall in Beispiel B der teure: Im ersten Fall fängt ein Puffer das Risiko, im zweiten fehlt er. Wie Sie den kritischen Pfad in Merlin Project gezielt anpassen, zeigt diese Anleitung.
Probieren Sie es aus
Die Technik hinter Monte Carlo ist Jahrzehnte alt. Neu ist, wie einfach sie geworden ist. Mit dem MCP-Server von Merlin Project liegt Ihr Plan bereits in einer Form vor, die eine KI lesen und rechnen kann. Aus einem Spezial-Add-in mit eigener Datenpflege wird ein Satz an Claude.
Wenn Sie Merlin Project schon nutzen, aktivieren Sie den MCP-Server für ein Projekt und stellen Sie Ihre erste Frage. Die Einrichtung steht in der MCP-Dokumentation. Wenn Sie Merlin Project noch nicht kennen, lernen Sie es auf der Produktseite kennen oder laden Sie es direkt zum Testen herunter.
Und niemand muss die Ergebnisse von Hand zusammenschreiben. Auf Wunsch bündelt Claude den ganzen Lauf in einem fertigen Bericht für Ihre Stakeholder. Wie das aussieht, zeigt der vollständige Bericht zu diesem Beispielprojekt: Monte-Carlo-Bericht herunterladen (PDF, auf Englisch).
Haben Sie Fragen zu diesem Blogartikel oder möchten darüber diskutieren, freuen wir uns auf Ihren Beitrag bei uns im Forum.
Häufige Fragen
Brauche ich Programmierkenntnisse für eine Monte-Carlo-Simulation mit dem MCP-Server?
Nein. Sie stellen Ihre Frage in natürlicher Sprache, und Claude schreibt die Simulation selbst in Code und führt sie aus. Voraussetzung ist nur ein Client mit Codeausführung wie Claude Code.
Schreibt die Simulation Änderungen in meinen Merlin-Project-Plan zurück?
Nein. Für die Simulation genügt der reine Lesezugriff. Die KI liest den Plan einmal aus, rechnet außerhalb von Merlin und schreibt nichts in den Live-Plan zurück. Ihre Projektstruktur bleibt unangetastet.
Welchen Client brauche ich, um die Simulation zu rechnen?
Einen MCP-Client mit Codeausführung, zum Beispiel Claude Code. Ein reines Chatfenster ohne Codeausführung kann die 10.000 Iterationen nicht rechnen.
Sind meine Projektdaten beim MCP-Server sicher?
Der MCP-Server selbst läuft lokal auf Ihrem Mac und ist nicht aus der Ferne erreichbar; er lädt von sich aus nichts hoch. Was die KI ausliest, verarbeitet sie aber beim jeweiligen Anbieter: Bei einem Cloud-Client wie Claude werden die gelesenen Plandaten an dessen API übertragen. Sie geben pro Projekt frei, was die KI sehen darf, und nichts wird in den Plan zurückgeschrieben.
Wie groß sollte mein Plan für den Einstieg sein?
Ein bewusst kleiner Plan mit 15 bis 25 Vorgängen ist ideal: groß genug für Pfadkonvergenz und einen aussagekräftigen Tornado, klein genug, dass die ganze Konversation übersichtlich bleibt.
