Una simulación de Monte Carlo no muestra una fecha de fin, sino una probabilidad. Con el nuevo servidor MCP en Merlin Project, pide a Claude en una frase que lea su plan y calcule 10.000 trayectorias de proyecto. Así procede.
Una simulación de Monte Carlo traduce la incertidumbre en probabilidad. En lugar de una única fecha, recibe una distribución de posibles fechas de fin. Con el servidor MCP en Merlin Project, eso ya no requiere un complemento especializado ni estimaciones mantenidas con esfuerzo; basta una frase a Claude.
Qué es exactamente una simulación de Monte Carlo y por qué supera a la ruta crítica lo explica nuestra guía sobre Monte Carlo en la gestión de proyectos. Aquí se trata de la práctica: cómo calcular realmente la simulación con Merlin Project y el servidor MCP.
Merlin Project y el servidor MCP
Merlin Project trae consigo un servidor MCP. MCP significa Model Context Protocol, un estándar abierto que da a los asistentes de IA una conexión estructurada y segura con aplicaciones externas. El servidor se ejecuta localmente en su Mac y no es accesible de forma remota; por sí mismo no sube nada y solo revela lo que la IA consulta activamente. Lo que la IA lee, sin embargo, lo procesa en el proveedor correspondiente: con un cliente en la nube como Claude, los datos de plan leídos van a su API. Usted mantiene el control sobre qué proyecto comparte, en pleno sentido de la soberanía digital. Lo activa por proyecto mediante el botón «Herramientas de IA» en la barra de herramientas del documento. La configuración completa para Claude Desktop, Claude Code y otros clientes está en la documentación de MCP.
Basta con el acceso de lectura
El servidor MCP ofrece actualmente solo acceso de lectura a los datos del proyecto. Para una simulación de Monte Carlo, eso es justo lo correcto: el cliente solo puede leer el plan, nada en el plan puede modificarse. La simulación lee el plan una sola vez; todo el cálculo estocástico transcurre fuera de Merlin. Nada se reescribe en el plan en vivo. Su estructura de proyecto sigue siendo la fuente única de verdad, intacta, y puede simular tantas veces como quiera y sobre cualquier estado del plan.
Del plan, la IA lee tres cosas. Primero, las tareas con su duración planificada. Segundo, la lógica del diagrama de red, es decir, las dependencias entre predecesor y sucesor, junto con la relación de precedencia y el margen. Tercero, la ubicación de la incertidumbre, es decir, de qué tarea pende un riesgo. La lógica del diagrama de red es el núcleo: sin las aristas de dependencia, solo sumaría duraciones en lugar de calcular un diagrama de red.
El punto clave: la incertidumbre aún no está en el plan
Merlin guarda por tarea una duración planificada y, más tarde, un valor real, pero ninguna estimación nativa de tres puntos. Hay tres maneras de resolverlo:
- Campos propios. Define O y P como campos personalizados en la plantilla y los lee también mediante MCP. La solución más limpia si controla la plantilla.
- Banda de incertidumbre global. Duración planificada más o menos X por ciento como triángulo o PERT, escalada en caso necesario por fase o tipo de tarea.
- Híbrido. Las tareas de riesgo anotadas reciben su propia banda, el resto un valor por defecto.
Cualquiera que sea el camino que elija: muestre de forma transparente de dónde procede la incertidumbre. Justamente eso hace creíble una simulación.
El flujo agéntico, y el error de razonamiento que debe evitar
Aquí está el malentendido más frecuente: Claude no recorre las 10.000 iteraciones por sí mismo. Ningún modelo de lenguaje extrae 10.000 muestras aleatorias mentalmente. Eso no solo sería intensivo en tokens, sino estadísticamente inútil, pues los modelos de lenguaje son malos generadores de aleatoriedad. Las iteraciones van en el código.
El truco no es «script de Python contra cliente MCP», sino la ejecución de código por parte del cliente. El flujo tiene tres pasos:
- Leer. Claude invoca las herramientas de lectura del servidor MCP de Merlin y obtiene tareas, duraciones y dependencias.
- Calcular. Claude se escribe a sí mismo la simulación en unas pocas líneas de numpy y la ejecuta, como parte de la respuesta. Esto requiere un cliente con ejecución de código, como Claude Code; una simple ventana de chat sin ejecución de código no puede ejecutar las iteraciones. Por iteración, el modelo extrae una duración para cada tarea, recorre el diagrama de red en orden topológico (atendiendo a predecesores y desfases) y toma como fin de proyecto el fin más tardío de todos los nodos finales.
- Explicar. Claude devuelve la curva S, P50, P80 y P90, así como un diagrama de tornado, e interpreta el resultado en lenguaje comprensible.
Desde su punto de vista, el relato es sencillo. Plantea una pregunta en lenguaje natural:
Lee el proyecto activo de Merlin Project y simula 10.000 posibles
trayectorias de proyecto. Toma por tarea la duración planificada más/menos 20 por ciento
como distribución PERT. Muéstrame la curva S y las fechas para P50, P80 y P90.Claude lee el plan, calcula y le muestra la curva de probabilidad. El código detrás es un detalle de implementación, no un paso de aprendizaje. Es como con la calculadora: la usa, en lugar de multiplicar mentalmente.
Por cierto, no son las iteraciones lo intensivo en tokens (en código son prácticamente gratuitas), sino el arrastrar una lista de 300 líneas de tareas al contexto. Para empezar, por tanto, vale: un plan de ejemplo a conciencia pequeño y limpio, con 15 a 25 tareas. Es lo bastante grande para la convergencia de rutas y un tornado interesante, y lo bastante pequeño para que toda la conversación quepa en una pantalla.
El resultado de 10.000 pasadas
Así se ve la respuesta de Claude al prompt de arriba, calculada sobre un pequeño plan de proyecto de construcción. Claude se conecta con el documento activo, lee tareas, vínculos (26 veces fin-comienzo, una vez comienzo-comienzo) y el calendario (de lunes a viernes, 8 horas por día), reconstruye la red y la valida contra la fecha de fin planificada. El modelo la reproduce con exactitud: 60 días laborables, es decir, el 21.08.2026. Luego se ejecutan las 10.000 pasadas.
Este proyecto de ejemplo comprende solo unas dos docenas de tareas, cuyo plazo está determinado por una larga cadena serial. Por eso la franja entre P10 y P90 es deliberadamente estrecha, de alrededor de una semana; los proyectos más grandes o con mayor ramificación suelen dispersarse bastante más.
| Confianza | Fecha | Frente al plan (21.08.) |
|---|---|---|
| Fecha planificada | 21.08.2026 | en torno al 49 por ciento de probabilidad de acierto |
| P50 | 24.08.2026 | más 1 día laborable |
| P80 | 25.08.2026 | más 2 días laborables |
| P90 | 26.08.2026 | más 3 días laborables |
El rango sobre las 10.000 pasadas va desde el 17.08. como muy pronto hasta el 01.09. como muy tarde.
La lectura es inequívoca: la fecha planificada es una fecha 50/50. En aproximadamente la mitad de las pasadas se mantiene, en la otra mitad se incumple. Ese es el hallazgo típico, pues una planificación determinista aterriza casi siempre en el P50 optimista, no en una fecha de entrega sólida. Quien quiera comprometerse con un 90 por ciento de seguridad, comunica el 26.08., es decir, en torno a tres días laborables de margen.
Claude revela asimismo sus propias hipótesis: aquí, la duración planificada sirvió como valor más probable, con O en −20 por ciento y P en +20 por ciento como distribución PERT-Beta simétrica. Con las estimaciones de tres puntos reales, en parte claramente asimétricas, del plan, la cola derecha se alargaría y P90 sería más tardío. Los eventos de riesgo discretos, la baja del proveedor y la del calculista de estructuras, no se modelan aquí a conciencia; esto fue pura dispersión de duración. Justamente eso lo calculamos en los dos ejemplos siguientes.
Ejemplo A: la comparación de proveedores
El ejemplo más potente responde a una pregunta de decisión, no solo a una pregunta de pronóstico. Imagine una tarea que pende de una entrega. El proveedor A entrega, por experiencia, puntualmente en una parte de los casos, y el resto con algunos días de retraso. Lo importante aquí es el denominador: 10 entregas tardías de 100 son un riesgo distinto a 10 de 15. Justo aquí Monte Carlo muestra su fortaleza, pues no calcula con hipótesis al aire, sino que traduce el historial de entregas vivido en un pronóstico.
El verdadero valor añadido es el equilibrio dinero contra riesgo. El proveedor A es más barato, pero menos fiable; el proveedor B es más caro, pero estable, y cuesta 4.000 euros más. ¿Compensa el sobreprecio? Esta pregunta la entiende una dirección al instante, y Monte Carlo la responde con una cifra en lugar de con una corazonada.
Una pregunta de este tipo se la plantea a Claude en una sola frase:
La tarea 19 «Material instalado» pende de una entrega. El proveedor A entrega
por experiencia puntualmente en el 85 por ciento de los casos, y el resto con 10 días de retraso.
Simula cómo repercute esto en la fecha de fin, y compáralo con
el proveedor B, que entrega siempre puntualmente, pero cuesta 4.000 euros más.Claude cuelga el interruptor de riesgo de la entrega y calcula ambos proveedores con las mismas extracciones aleatorias (Common Random Numbers), para que la diferencia penda limpiamente solo de la entrega. El resultado es asombrosamente inequívoco (dl significa días laborables):
| Confianza | Proveedor A (85 % puntual, resto +10 dl) | Proveedor B (siempre puntual, +4.000 €) |
|---|---|---|
| P50 | 21.08.2026 | 21.08.2026 |
| P80 | 25.08.2026 | 25.08.2026 |
| P90 | 25.08.2026 | 25.08.2026 |
| Fecha planificada mantenida | 50,5 % | 50,5 % |
| Deslizamiento de fin por A | 0,00 % | Referencia |
En ninguna de las 10.000 pasadas el poco fiable proveedor A desplaza la fecha de fin. Ambas distribuciones son coincidentes. La razón está en el plan: la tarea 19 «Material instalado» pende de dos predecesores, la entrega y el tejado en la ruta crítica. El tejado se termina sistemáticamente más tarde, así que «Material instalado» espera de todos modos al tejado, no a la entrega de la fachada. Entre entrega e instalación hay, en la mediana, 21 días laborables de margen, e incluso en la pasada más comprimida aún unos 17. Un retraso de 10 días laborables nunca alcanza ese límite.
Eso se ve mejor en la sensibilidad: ¿de qué tamaño tendría que ser siquiera el retraso para mover la fecha de fin?
Solo por encima de este borde de margen, más allá de unos 17 a 21 días laborables, empieza siquiera algo a repercutir: con 25 días se deslizan el 7 por ciento de las pasadas, con 30 días en torno al 15. La decisión de coste queda así clara. Los 4.000 euros del proveedor B compran, bajo estas hipótesis, cero ganancia de plazo; el retraso evitado esperado es de 0,0 días laborables. Desde la pura perspectiva de plazo, el proveedor A es la elección racional; el dinero se pagaría por un riesgo que el plan ya soporta a través de su margen. B compensa solo cuando se desplaza una hipótesis: cuando el retraso es claramente mayor de 10 días (un contenedor de importación en lugar de una entrega regional), cuando la obra gruesa se termina mucho antes y el margen se encoge, o cuando en la rama de fachada penden fechas intermedias propias con penalización contractual. Justamente eso un plan puramente determinista nunca podría mostrarlo.
Una nota honesta al margen: los dos ejemplos son pasadas de simulación propias con sus respectivos interruptores de riesgo. Un día de desviación en la fecha base frente a la curva S de más arriba es ruido de muestreo normal, no una contradicción. Monte Carlo estima una distribución, no es una calculadora con decimales fijos.
Ejemplo B: la baja de recurso
El segundo ejemplo mueve otra palanca: no la duración, sino un evento discreto. Un recurso clave podría caer, aquí el calculista de estructuras, que trabaja en dos tareas, la planificación de la estructura, temprano en el proyecto, y la recepción estructural, tarde. ¿Cae?, y si cae, ¿cuándo golpea más fuerte?
Simula mi proyecto para tres casos: el recurso «calculista de estructuras» no cae,
cae en la semana 3 durante 10 días, cae en la semana 8 durante 10 días. Muéstrame
P50/P80/P90 de cada uno y qué momento de baja golpea más fuerte la fecha de fin.De nuevo, Claude calcula los tres casos con las mismas extracciones aleatorias, para que las diferencias pendan limpiamente solo de la baja:
| Caso | P50 | P80 | P90 | Desplazamiento |
|---|---|---|---|---|
| Sin baja | 21.08.2026 | 25.08.2026 | 25.08.2026 | Base |
| Baja temprana (planificación de la estructura) | 04.09.2026 | 08.09.2026 | 08.09.2026 | +10 dl |
| Baja tardía (recepción estructural) | 02.09.2026 | 04.09.2026 | 07.09.2026 | +8 dl |
Ambas bajas incumplen la fecha planificada con seguridad, la probabilidad de acierto cae del 50 al 0 por ciento. Interesante es la diferencia: la baja temprana golpea más fuerte. En el 100 por ciento de las pasadas desplaza la fecha de fin más que la tardía, en promedio 2 días laborables. La razón es de nuevo la situación de margen, no el momento en sí. La planificación de la estructura está de lleno sobre la ruta crítica, sin margen; sus diez días de baja repercuten 1:1, unos limpios más 10 días laborables en cada pasada. La recepción estructural, en cambio, extrae un pequeño margen residual de una rama paralela, que absorbe dos de los diez días, antes de convertirse ella misma en la tarea vinculante. Quedan más 8 días laborables.
Esa es la lección concreta del ejemplo B: una baja de igual duración cuesta distinto según cuánto margen tenga la tarea afectada. Suplencia, antelación y reserva van primero a los recursos sobre la ruta crítica, que no tienen margen.
Ruta crítica contra margen: la moraleja común
Ambos ejemplos dicen en el fondo lo mismo: no decide el riesgo por sí solo, sino dónde se sitúa en el diagrama de red. El mismo retraso no cuesta nada en una tarea con margen y lo cuesta todo en la ruta crítica. Monte Carlo no muestra «el retraso es malo», sino cuándo un riesgo repercute y cuándo el plan lo absorbe. Por eso el proveedor barato fue la elección racional en el ejemplo A y la baja temprana, la cara en el ejemplo B: en el primer caso un margen amortigua el riesgo, en el segundo falta. Cómo ajustar la ruta crítica de forma dirigida en Merlin Project lo muestra esta guía.
Pruébelo
La técnica detrás de Monte Carlo tiene décadas. Lo nuevo es lo sencilla que se ha vuelto. Con el servidor MCP de Merlin Project, su plan ya está en una forma que una IA puede leer y calcular. De un complemento especializado con mantenimiento de datos propio se pasa a una frase a Claude.
Si ya usa Merlin Project, active el servidor MCP para un proyecto y plantee su primera pregunta. La configuración está en la documentación de MCP. Si aún no conoce Merlin Project, conózcalo en la página de producto o descárguelo directamente para probarlo.
Y nadie tiene que redactar los resultados a mano. Si lo pide, Claude reúne toda la simulación en un informe listo para sus stakeholders. El informe completo de este proyecto de ejemplo lo demuestra: Descargar el informe Monte Carlo (PDF, en inglés).
Si tiene alguna pregunta sobre este artículo del blog o desea debatirlo, esperamos su contribución en nuestro foro.
Preguntas frecuentes
¿Necesito conocimientos de programación para una simulación de Monte Carlo con el servidor MCP?
No. Usted plantea su pregunta en lenguaje natural, y Claude escribe por sí mismo la simulación en código y la ejecuta. El único requisito es un cliente con ejecución de código, como Claude Code.
¿La simulación escribe cambios de vuelta en mi plan de Merlin Project?
No. Para la simulación basta con el acceso de solo lectura. La IA lee el plan una sola vez, calcula fuera de Merlin y no escribe nada en el plan en vivo. Su estructura de proyecto permanece intacta.
¿Qué cliente necesito para calcular la simulación?
Un cliente MCP con ejecución de código, por ejemplo Claude Code. Una simple ventana de chat sin ejecución de código no puede calcular las 10.000 iteraciones.
¿Están seguros mis datos de proyecto con el servidor MCP?
El propio servidor MCP se ejecuta localmente en su Mac y no es accesible de forma remota; por sí mismo no sube nada. Lo que la IA lee, sin embargo, lo procesa en el proveedor correspondiente: con un cliente en la nube como Claude, los datos de plan leídos se transmiten a su API. Usted decide por proyecto qué puede ver la IA, y nada se reescribe en el plan.
¿De qué tamaño debería ser mi plan para empezar?
Un plan a conciencia pequeño, con 15 a 25 tareas, es ideal: lo bastante grande para la convergencia de rutas y un tornado significativo, lo bastante pequeño para que toda la conversación se mantenga abarcable.
