Un cliente de manufactura estaba a una firma de comprometer $8 millones de dólares en una línea de producción nueva. El comité de inversión ya había aprobado el presupuesto. El proveedor tenía el cronograma listo. Faltaba la firma.

Antes de que llegara ese momento, nos hicimos una pregunta que debería ser estándar en cualquier aprobación de CAPEX y casi nunca lo es: ¿qué pasa si simulamos esta decisión antes de comprometer el capital?

La respuesta cambió el resultado. No porque el diseño de la línea estuviera mal —los ingenieros habían hecho bien su trabajo—, sino porque nadie había modelado qué podía fallar en la operación real antes de aprobar el gasto. El comité estaba a punto de tomar una decisión de $8 millones basada en la certeza del proveedor, no en un modelo de decisión propio.

El error no estaba en la ingeniería. Estaba en el proceso de decisión.

Esto es lo que veo una y otra vez en inversiones de capital: el rigor técnico del diseño no tiene relación con el rigor de la decisión de invertir. Se audita la ingeniería. Se negocia el precio. Se revisa el cronograma. Pero casi nadie se sienta a modelar qué pasa si el escenario base no se cumple.

Esto no es un problema exclusivo de manufactura. Es un problema de cómo los comités de inversión aprueban business cases en general: la mayoría se aprueba con la tesis de inversión de quien vende o de quien la propone, no con una tesis de inversión propia, validada de forma independiente.

La diferencia entre simular y adivinar no es semántica. Adivinar es asumir que el escenario base se va a cumplir porque el documento dice que se va a cumplir. Simular es construir un modelo de decisión que te dice, con datos, qué tan sensible es tu retorno a los supuestos que estás dando por hecho.

Antes de construir la línea física, construimos la línea digital

En este caso, antes de que el cliente comprometiera el capital, construimos un gemelo digital de la línea de producción propuesta. No fue un ejercicio de ingeniería de detalle — fue un modelo de decisión: ¿qué pasa con el retorno si el arranque toma más tiempo del planeado? ¿Qué pasa si la tasa de rechazo de calidad en las primeras semanas supera lo que asume el caso base del proveedor? ¿Qué pasa si el suministro de insumos críticos tiene la variabilidad que ya habíamos visto en líneas comparables?

Cada uno de esos escenarios, probado en el gemelo digital, costó cero pesos adicionales. Probarlos en la planta real, después de haber comprometido los $8 millones, habría costado meses de ineficiencia no presupuestada en el mejor caso, o un rediseño de proceso después de la puesta en marcha, en el peor.

El hallazgo no fue un error de diseño. Fue un riesgo en la secuencia de arranque que el caso base del proveedor no contemplaba — el tipo de riesgo que solo aparece cuando alguien se toma el trabajo de modelar el escenario adverso, y no solo el optimista. (Los números exactos de este caso son información del cliente; lo que compartimos es el proceso y el tipo de hallazgo, que es replicable en cualquier decisión de capital de este tamaño.)

Por qué la simulación es tan buena como el dato que la alimenta

Aquí está la parte que casi nadie discute cuando habla de gemelos digitales: el modelo es tan confiable como los datos que lo alimentan. El 70% de los proyectos de analítica fallan por problemas de calidad de datos, no por problemas de modelo. Puedes tener el mejor algoritmo de simulación del mercado y seguir tomando una mala decisión si los datos de entrada —tiempos de ciclo históricos, tasas de falla, variabilidad de insumos— no son confiables.

Por eso, antes de simular, hicimos el trabajo de Data Quality: limpiar, validar y conciliar las fuentes de datos operativos del cliente —de mantenimiento, de calidad, de supply chain— para que el modelo de decisión no heredará los mismos sesgos y huecos que ya existían en los sistemas de origen. Un gemelo digital construido sobre datos sucios no reduce el riesgo de la decisión. Lo disfraza con una interfaz más sofisticada.

Esta es la disciplina que aplicamos en cualquier iniciativa de gemelos digitales o modelos de decisión: primero la calidad del dato, después el modelo. En ese orden. Invertir el orden es la razón por la que muchas iniciativas de Industria 4.0 producen dashboards atractivos y decisiones igual de arriesgadas que antes.

«No tenemos tiempo» y «ya tenemos los datos» — las dos objeciones que siempre aparecen

La primera objeción que escuchamos en discovery es de tiempo: el comité ya aprobó, el proveedor ya tiene fecha de arranque, detener el proceso para simular se siente como una fricción innecesaria. En este caso, el diagnóstico de calidad de dato y el modelo de decisión completo se resolvieron en semanas, no en meses — bastante menos tiempo del que le habría tomado al cliente descubrir el riesgo de arranque una vez en operación real.

La segunda objeción es de confianza en los datos existentes: «ya tenemos los datos de la planta, ya sabemos cómo se comporta». Es cierto, casi siempre, que los datos existen. Lo que casi nunca es cierto es que estén limpios, conciliados entre sistemas y listos para alimentar un modelo de decisión sin sesgo. Confirmar eso —o corregirlo— es el primer paso, no un paso opcional.

El resultado

El cliente no canceló el proyecto. Lo aprobó, pero con un plan de arranque ajustado para absorber el riesgo que el gemelo digital había identificado — y con un comité que, por primera vez en ese proceso, vio la sensibilidad completa del retorno antes de firmar, no solo el escenario optimista del proveedor.

Ese es el cambio real que produjo la simulación: no necesariamente un número distinto en el business case, sino una decisión tomada con los ojos abiertos al riesgo, en vez de con la confianza ciega en el caso base de quien vendía.

La secuencia que recomendamos antes de la próxima aprobación de CAPEX

Si tienes una inversión de capital grande en el pipeline de decisiones de tu comité, la pregunta que deberías estar haciendo no es «¿qué garantiza el proveedor?». Es: «¿qué modelo de decisión propio tenemos, construido sobre datos confiables, antes de comprometer el capital?»

Primero, diagnóstico de calidad de dato: qué fuentes existen, qué tan confiables son, qué huecos hay que cerrar antes de que cualquier simulación tenga sentido. Segundo, modelo de decisión: no necesariamente un gemelo digital de ingeniería de detalle, sino un modelo que responda a las preguntas específicas que el comité necesita para aprobar con rigor. Tercero, business case con escenarios: no un número único, sino un rango, con el presupuesto de contingencia dimensionado por dato. Cuarto, la decisión: con el comité viendo no solo el caso base del proveedor, sino la sensibilidad completa del retorno.

Esto no es exclusivo de manufactura

El mismo patrón se repite en cualquier sector donde una decisión de capital o de negocio se aprueba antes de haber sido puesta a prueba. En retail, lo vemos en decisiones de sell-in y sell-out que se aprueban sobre el histórico de un canal sin modelar la variabilidad de demanda real. En banca, en decisiones de originación que dependen de un cliente único cuando los sistemas de origen todavía tienen duplicados y datos inconsistentes entre canales. En textil, en decisiones de producción por temporada que se comprometen antes de simular la sensibilidad del margen a la variabilidad de insumos importados.

En todos los casos, el error no es de sector. Es de secuencia: se decide primero y se valida después, cuando debería ser al revés. Y en todos los casos, el mismo principio aplica — el modelo de decisión es tan bueno como el gobierno de datos que lo sostiene. Esa es la razón por la que la práctica de Data Quality, Cliente Único y MDM no es un proyecto de TI aislado. Es la condición de entrada para que cualquier simulación, en cualquier industria, sea algo más que un ejercicio de visualización con apariencia de rigor.

Lo que un comité de inversión debería exigir, no solo pedir

La mayoría de los comités de inversión piden un business case. Muy pocos exigen ver la sensibilidad del retorno a los supuestos críticos antes de aprobar. Esa distinción —pedir versus exigir— es la que separa a las organizaciones que toman decisiones de capital con disciplina de las que las toman con optimismo bien presentado.

Exigir sensibilidad no significa desconfiar del equipo que trae la propuesta. Significa reconocer que ningún equipo, por bueno que sea, tiene incentivo para modelar activamente el escenario en el que su propio proyecto no funciona como se planeó. Ese ejercicio necesita venir de afuera del equipo que propone, con el mismo rigor con el que se audita cualquier otro supuesto financiero de una inversión de este tamaño.

El filtro antes de firmar

La próxima vez que tu comité esté a punto de aprobar un business case de capital grande, antes de firmar, haz la misma pregunta que le hicimos a este cliente: ¿qué pasa si simulamos esto primero?

Solicita una sesión de diagnóstico con nuestros especialistas para evaluar la viabilidad de tus proyectos de inversión