Un cliente de manufactura estaba a una firma de comprometer $8 millones de d\u00f3lares en una l\u00ednea de producci\u00f3n nueva. El comit\u00e9 de inversi\u00f3n ya hab\u00eda aprobado el presupuesto. El proveedor ten\u00eda el cronograma listo. Faltaba la firma.<\/p>\n\n\n\n
Antes de que llegara ese momento, nos hicimos una pregunta que deber\u00eda ser est\u00e1ndar en cualquier aprobaci\u00f3n de CAPEX y casi nunca lo es: \u00bfqu\u00e9 pasa si simulamos esta decisi\u00f3n antes de comprometer el capital?<\/p>\n\n\n\n
La respuesta cambi\u00f3 el resultado. No porque el dise\u00f1o de la l\u00ednea estuviera mal \u2014los ingenieros hab\u00edan hecho bien su trabajo\u2014, sino porque nadie hab\u00eda modelado qu\u00e9 pod\u00eda fallar en la operaci\u00f3n real antes de aprobar el gasto. El comit\u00e9 estaba a punto de tomar una decisi\u00f3n de $8 millones basada en la certeza del proveedor, no en un modelo de decisi\u00f3n propio.<\/p>\n\n\n\n
Esto es lo que veo una y otra vez en inversiones de capital: el rigor t\u00e9cnico del dise\u00f1o no tiene relaci\u00f3n con el rigor de la decisi\u00f3n de invertir. Se audita la ingenier\u00eda. Se negocia el precio. Se revisa el cronograma. Pero casi nadie se sienta a modelar qu\u00e9 pasa si el escenario base no se cumple.<\/p>\n\n\n\n
Esto no es un problema exclusivo de manufactura. Es un problema de c\u00f3mo los comit\u00e9s de inversi\u00f3n aprueban business cases en general: la mayor\u00eda se aprueba con la tesis de inversi\u00f3n de quien vende o de quien la propone, no con una tesis de inversi\u00f3n propia, validada de forma independiente.<\/p>\n\n\n\n
La diferencia entre simular y adivinar no es sem\u00e1ntica. 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\u00f3n que te dice, con datos, qu\u00e9 tan sensible es tu retorno a los supuestos que est\u00e1s dando por hecho.<\/p>\n\n\n\n
En este caso, antes de que el cliente comprometiera el capital, construimos un gemelo digital de la l\u00ednea de producci\u00f3n propuesta. No fue un ejercicio de ingenier\u00eda de detalle \u2014 fue un modelo de decisi\u00f3n: \u00bfqu\u00e9 pasa con el retorno si el arranque toma m\u00e1s tiempo del planeado? \u00bfQu\u00e9 pasa si la tasa de rechazo de calidad en las primeras semanas supera lo que asume el caso base del proveedor? \u00bfQu\u00e9 pasa si el suministro de insumos cr\u00edticos tiene la variabilidad que ya hab\u00edamos visto en l\u00edneas comparables?<\/p>\n\n\n\n
Cada uno de esos escenarios, probado en el gemelo digital, cost\u00f3 cero pesos adicionales. Probarlos en la planta real, despu\u00e9s de haber comprometido los $8 millones, habr\u00eda costado meses de ineficiencia no presupuestada en el mejor caso, o un redise\u00f1o de proceso despu\u00e9s de la puesta en marcha, en el peor.<\/p>\n\n\n\n
El hallazgo no fue un error de dise\u00f1o. Fue un riesgo en la secuencia de arranque que el caso base del proveedor no contemplaba \u2014 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\u00fameros exactos de este caso son informaci\u00f3n del cliente; lo que compartimos es el proceso y el tipo de hallazgo, que es replicable en cualquier decisi\u00f3n de capital de este tama\u00f1o.)<\/p>\n\n\n\n
Aqu\u00ed est\u00e1 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\u00edtica fallan por problemas de calidad de datos, no por problemas de modelo. Puedes tener el mejor algoritmo de simulaci\u00f3n del mercado y seguir tomando una mala decisi\u00f3n si los datos de entrada \u2014tiempos de ciclo hist\u00f3ricos, tasas de falla, variabilidad de insumos\u2014 no son confiables.<\/p>\n\n\n\n
Por eso, antes de simular, hicimos el trabajo de Data Quality: limpiar, validar y conciliar las fuentes de datos operativos del cliente \u2014de mantenimiento, de calidad, de supply chain\u2014 para que el modelo de decisi\u00f3n no heredar\u00e1 los mismos sesgos y huecos que ya exist\u00edan en los sistemas de origen. Un gemelo digital construido sobre datos sucios no reduce el riesgo de la decisi\u00f3n. Lo disfraza con una interfaz m\u00e1s sofisticada.<\/p>\n\n\n\n
Esta es la disciplina que aplicamos en cualquier iniciativa de gemelos digitales o modelos de decisi\u00f3n: primero la calidad del dato, despu\u00e9s el modelo. En ese orden. Invertir el orden es la raz\u00f3n por la que muchas iniciativas de Industria 4.0 producen dashboards atractivos y decisiones igual de arriesgadas que antes.<\/p>\n\n\n\n
La primera objeci\u00f3n que escuchamos en discovery es de tiempo: el comit\u00e9 ya aprob\u00f3, el proveedor ya tiene fecha de arranque, detener el proceso para simular se siente como una fricci\u00f3n innecesaria. En este caso, el diagn\u00f3stico de calidad de dato y el modelo de decisi\u00f3n completo se resolvieron en semanas, no en meses \u2014 bastante menos tiempo del que le habr\u00eda tomado al cliente descubrir el riesgo de arranque una vez en operaci\u00f3n real.<\/p>\n\n\n\n
La segunda objeci\u00f3n es de confianza en los datos existentes: \u00abya tenemos los datos de la planta, ya sabemos c\u00f3mo se comporta\u00bb. Es cierto, casi siempre, que los datos existen. Lo que casi nunca es cierto es que est\u00e9n limpios, conciliados entre sistemas y listos para alimentar un modelo de decisi\u00f3n sin sesgo. Confirmar eso \u2014o corregirlo\u2014 es el primer paso, no un paso opcional.<\/p>\n\n\n\n
El cliente no cancel\u00f3 el proyecto. Lo aprob\u00f3, pero con un plan de arranque ajustado para absorber el riesgo que el gemelo digital hab\u00eda identificado \u2014 y con un comit\u00e9 que, por primera vez en ese proceso, vio la sensibilidad completa del retorno antes de firmar, no solo el escenario optimista del proveedor.<\/p>\n\n\n\n
Ese es el cambio real que produjo la simulaci\u00f3n: no necesariamente un n\u00famero distinto en el business case, sino una decisi\u00f3n tomada con los ojos abiertos al riesgo, en vez de con la confianza ciega en el caso base de quien vend\u00eda.<\/p>\n\n\n\n
Si tienes una inversi\u00f3n de capital grande en el pipeline de decisiones de tu comit\u00e9, la pregunta que deber\u00edas estar haciendo no es \u00ab\u00bfqu\u00e9 garantiza el proveedor?\u00bb. Es: \u00ab\u00bfqu\u00e9 modelo de decisi\u00f3n propio tenemos, construido sobre datos confiables, antes de comprometer el capital?\u00bb<\/p>\n\n\n\n
Primero, diagn\u00f3stico de calidad de dato: qu\u00e9 fuentes existen, qu\u00e9 tan confiables son, qu\u00e9 huecos hay que cerrar antes de que cualquier simulaci\u00f3n tenga sentido. Segundo, modelo de decisi\u00f3n: no necesariamente un gemelo digital de ingenier\u00eda de detalle, sino un modelo que responda a las preguntas espec\u00edficas que el comit\u00e9 necesita para aprobar con rigor. Tercero, business case con escenarios: no un n\u00famero \u00fanico, sino un rango, con el presupuesto de contingencia dimensionado por dato. Cuarto, la decisi\u00f3n: con el comit\u00e9 viendo no solo el caso base del proveedor, sino la sensibilidad completa del retorno.<\/p>\n\n\n\n
El mismo patr\u00f3n se repite en cualquier sector donde una decisi\u00f3n 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\u00f3rico de un canal sin modelar la variabilidad de demanda real. En banca, en decisiones de originaci\u00f3n que dependen de un cliente \u00fanico cuando los sistemas de origen todav\u00eda tienen duplicados y datos inconsistentes entre canales. En textil, en decisiones de producci\u00f3n por temporada que se comprometen antes de simular la sensibilidad del margen a la variabilidad de insumos importados.<\/p>\n\n\n\n
En todos los casos, el error no es de sector. Es de secuencia: se decide primero y se valida despu\u00e9s, cuando deber\u00eda ser al rev\u00e9s. Y en todos los casos, el mismo principio aplica \u2014 el modelo de decisi\u00f3n es tan bueno como el gobierno de datos que lo sostiene. Esa es la raz\u00f3n por la que la pr\u00e1ctica de Data Quality, Cliente \u00danico y MDM no es un proyecto de TI aislado. Es la condici\u00f3n de entrada para que cualquier simulaci\u00f3n, en cualquier industria, sea algo m\u00e1s que un ejercicio de visualizaci\u00f3n con apariencia de rigor.<\/p>\n\n\n\n
La mayor\u00eda de los comit\u00e9s de inversi\u00f3n piden un business case. Muy pocos exigen ver la sensibilidad del retorno a los supuestos cr\u00edticos antes de aprobar. Esa distinci\u00f3n \u2014pedir versus exigir\u2014 es la que separa a las organizaciones que toman decisiones de capital con disciplina de las que las toman con optimismo bien presentado.<\/p>\n\n\n\n
Exigir sensibilidad no significa desconfiar del equipo que trae la propuesta. Significa reconocer que ning\u00fan equipo, por bueno que sea, tiene incentivo para modelar activamente el escenario en el que su propio proyecto no funciona como se plane\u00f3. 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\u00f3n de este tama\u00f1o.<\/p>\n\n\n\n
La pr\u00f3xima vez que tu comit\u00e9 est\u00e9 a punto de aprobar un business case de capital grande, antes de firmar, haz la misma pregunta que le hicimos a este cliente: \u00bfqu\u00e9 pasa si simulamos esto primero?<\/p>\n\n\n\n
Solicita una sesi\u00f3n de diagn\u00f3stico con nuestros especialistas para evaluar la viabilidad de tus proyectos de inversi\u00f3n<\/p>","protected":false},"excerpt":{"rendered":"
Un cliente de manufactura estaba a una firma de comprometer $8 millones de d\u00f3lares en una l\u00ednea de producci\u00f3n nueva. El comit\u00e9 de inversi\u00f3n ya hab\u00eda aprobado el presupuesto. El proveedor ten\u00eda el cronograma listo. Faltaba la firma. Antes de que llegara ese momento, nos hicimos una pregunta que deber\u00eda ser est\u00e1ndar en cualquier aprobaci\u00f3n […]<\/p>\n","protected":false},"author":3,"featured_media":344567,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"off","_et_pb_old_content":"","_et_gb_content_width":"","content-type":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-344566","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/posts\/344566","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/comments?post=344566"}],"version-history":[{"count":1,"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/posts\/344566\/revisions"}],"predecessor-version":[{"id":344568,"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/posts\/344566\/revisions\/344568"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/media\/344567"}],"wp:attachment":[{"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/media?parent=344566"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/categories?post=344566"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/tags?post=344566"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}