El problema real: los consejos ya no quieren oír «ROI»
Llevo suficientes años sentado del lado técnico y del lado del consejo como para reconocer el patrón apenas empieza la presentación.
El equipo de TI o el CIO abre con arquitectura. Habla de modelos, de plataformas, de capacidades. En algún momento, alguien en la mesa pregunta: «¿y esto qué le hace al negocio?» Y ahí es donde la mayoría de los proyectos de datos e IA empiezan a morir.
No mueren por falta de capacidad técnica. Mueren por falta de rigor comercial.
Un consejo de administración no está evaluando si la tecnología funciona. Da por hecho que funciona — para eso te contrataron o te promovieron. Lo que está evaluando es si tú, como responsable de esa inversión, entiendes el riesgo que le estás pidiendo que tome con el capital de los accionistas.
«ROI» ya no convence a nadie en una sala de consejo. Lo han escuchado cientos de veces, casi siempre sin sustento operativo detrás. Un número de retorno sin una decisión de negocio específica detrás es una promesa, no una tesis.
La diferencia entre un proyecto que se aprueba y uno que se archiva casi nunca está en la tecnología. Está en si el que presenta habla el idioma del consejo — capital, riesgo, margen — o el idioma de TI — features, plataformas, roadmap.
Este artículo es sobre cómo cruzar ese puente. No con storytelling. Con estructura.
El caso: cómo se ve la decisión que sí llegó a aprobarse
Vale la pena empezar con un patrón que hemos visto repetirse en manufactura, porque ahí se nota con más claridad.
La primera versión de este tipo de proyecto casi siempre se presenta como catálogo de capacidades: sensores, integración OT/IT, modelos predictivos, un dashboard con visión de planta. Técnicamente sólido. Comercialmente huérfano. Un consejo no puede aprobar un catálogo — no sabe qué está comprando en términos de negocio.
La versión que sí convence empieza distinto. No abre con la plataforma. Abre con una decisión operativa concreta: reducir el costo de producción perdida por mantenimiento no planeado y por variación en OEE (Eficiencia General del Equipo).
Esa reformulación cambia todo lo que sigue. Ya no se está pidiendo presupuesto para «un proyecto de datos e IA en planta». Se está pidiendo presupuesto para una decisión específica: ¿cuánto capital estamos dispuestos a arriesgar para recuperar el margen que hoy se pierde por paros no planeados y variabilidad de calidad?
Este es el enfoque detrás de lo que en Grupo Scanda llamamos inteligencia operativa de planta — un concepto de best practice, no la bitácora de un cliente en particular: conectar OEE, calidad, mantenimiento y supply chain en un solo modelo de datos, con la práctica Factory 360 como la forma en que lo ejecutamos. El business case que se presenta al consejo no habla de sensores ni de arquitectura de datos como argumento central. Habla de impacto en OEE, de reducción de paros no planeados, y de ahorros que en implementaciones de este tipo han superado los $2 millones de dólares anuales cuando el proyecto opera a régimen.
La profundidad técnica — la integración OT/IT, los modelos de mantenimiento predictivo, el gemelo digital del activo — sigue estando ahí. Pero no es el argumento. Es la evidencia de que la tesis es ejecutable, no la tesis en sí misma.
Ese es el cambio de postura que un consejo necesita ver: alguien que no está vendiendo tecnología, sino administrando una inversión con la misma disciplina con la que administraría cualquier otro capital de la empresa.
El framework de 4 capas para construir la tesis
Lo que sigue es la estructura que uso — y que enseño a los equipos que preparamos para presentar ante consejo — para convertir un proyecto de datos e IA en una tesis de inversión defendible. Cuatro capas. Si falta una, la tesis cojea.
Capa 1 — Identificación de la decisión operativa (la palanca de negocio)
Antes de mencionar un solo dato, una sola plataforma o un solo modelo, hay que responder una pregunta: ¿qué decisión de negocio va a cambiar si esto funciona?
No «vamos a tener mejor visibilidad de planta». Eso no es una decisión, es un estado deseado. La palanca de negocio es específica y accionable: «vamos a decidir cuándo intervenir un equipo antes de que falle, en lugar de después». O: «vamos a decidir qué SKU producir primero según margen real, no según orden de llegada».
Si en tu organización nadie puede nombrar la decisión operativa que cambia, no tienes un proyecto de datos e IA. Tienes un experimento con presupuesto de proyecto — y los consejos, con razón, son cada vez más duros con esa diferencia.
Esta capa es responsabilidad del área de negocio, no de TI. Si TI llega sola a construir esta capa, ya perdiste antes de empezar.
Capa 2 — Documentación de la línea base (la realidad, sin adornos)
Aquí es donde más proyectos se debilitan, porque documentar la línea base obliga a exponer números incómodos: cuánto se está perdiendo hoy, con cuánta variabilidad, y con qué tanta certeza se conoce ese número.
Un consejo no le va a creer una proyección de ahorro si no puedes mostrarle primero, con precisión, cuál es el costo actual del problema que dices que vas a resolver. Sin línea base, cualquier cifra de mejora es una opinión disfrazada de resultado.
Documentar la línea base significa: costo actual medido (no estimado a ojo), fuente de ese dato, calidad de esa fuente, y el rango de incertidumbre que hoy existe alrededor de esa cifra. Si la línea base tiene huecos, se documentan los huecos también. Un consejo respeta más una línea base honesta con vacíos declarados que una cifra perfecta sin sustento.
Esta capa toma más tiempo del que los equipos quieren invertir. Es, sin excepción, la capa que más determina si la tesis sobrevive las preguntas del consejo.
Capa 3 — La palanca de datos (qué dato específico cambia la decisión)
Aquí — y solo aquí — entra la conversación técnica. Pero entra con una restricción: cada fuente de datos, cada modelo, cada capacidad que propongas tiene que estar conectada explícitamente a la decisión de la Capa 1.
La pregunta que hay que responder por cada componente técnico es: ¿qué decisión operativa se vuelve posible, o mejor, con este dato específico? Si no puedes trazar esa línea directa, ese componente no entra en la primera fase de la tesis — se vuelve una fase futura, no el núcleo de lo que estás pidiendo aprobar hoy.
En este tipo de proyecto de inteligencia operativa de planta, la palanca de datos no es «tener todos los datos de la planta». Es, específicamente, la combinación de datos de mantenimiento, calidad y disponibilidad de equipo que permite anticipar una falla antes de que detenga producción. Todo lo demás —el resto del modelo de datos, la analítica avanzada, el catálogo completo de casos de uso— vive en fases posteriores, no en la tesis inicial.
Esta disciplina evita el error más común: presentar un proyecto de datos e IA como una transformación integral cuando lo que el consejo necesita aprobar es una apuesta acotada, medible y con un camino claro a la siguiente fase.
Capa 4 — Criterio de cancelación (cuándo detener el proyecto si no hay tracción)
Esta es la capa que más diferencia a quien administra capital de quien vende tecnología. Y es, casi siempre, la capa que nadie lleva a la presentación.
Un consejo de administración no solo quiere saber cómo se ve el éxito. Quiere saber, con la misma claridad, cómo se ve la señal de que esto no está funcionando — y qué se hace cuando aparece esa señal.
El criterio de cancelación se define antes de arrancar, no después de que el proyecto ya lleva seis meses de inercia y nadie quiere ser quien lo detenga. Se define en términos concretos: si en X semanas no se observa movimiento en la métrica de la Capa 2, el proyecto se detiene, se revisa la hipótesis, o se reasigna el capital.
Llevar un criterio de cancelación explícito a la presentación no debilita la tesis. La fortalece. Le dice al consejo que quien está pidiendo el capital entiende que también es responsable de reconocer cuándo la apuesta no está funcionando — y que no va a necesitar que el consejo sea quien detenga el proyecto por él.
Las preguntas que el consejo va a hacer — y para cuál capa te estás preparando
Si construiste bien las cuatro capas, ya tienes respuesta para las preguntas que un consejo con experiencia va a hacer. Si no las construiste, estas mismas preguntas son las que van a exhibir el hueco en tiempo real, frente a todos.
- «¿Qué decisión concreta cambia si esto funciona?» — Es la pregunta de la Capa 1. Si la respuesta suena a visión o a estado deseado en lugar de a una decisión operativa específica, el consejo lo va a notar antes de que termines la frase.
- «¿De dónde sale ese número de ahorro proyectado?» — Es la pregunta de la Capa 2. Aquí es donde se nota si documentaste la línea base con rigor o si estás presentando una proyección sin punto de partida verificable.
- «¿Por qué este dato y no otro? ¿Por qué no arrancamos con el modelo completo de una vez?» — Es la pregunta de la Capa 3. La respuesta correcta no es defender el alcance completo. Es explicar por qué acotaste la primera fase a la palanca de datos que mueve la decisión de la Capa 1, y en qué momento entra el resto.
- «¿Y si en seis meses no vemos nada? ¿Quién lo detiene, y cuándo?» — Es la pregunta de la Capa 4. Muy pocos equipos llegan con respuesta a esto. Los que sí llegan, generalmente salen de la sala con el capital aprobado — porque le acaban de quitar al consejo el riesgo de tener que ser ellos quienes frenen un proyecto que ya tomó vida propia.
Nota algo importante en este patrón: las cuatro preguntas no son técnicas. Son preguntas de administración de capital. Un consejo experimentado no va a auditar tu arquitectura de datos en la sala — para eso existen comités técnicos y due diligence posterior. Lo que va a auditar, en el momento de la presentación, es si tú entiendes el riesgo que estás pidiendo que se apruebe.
Prepararte para estas cuatro preguntas no es un ejercicio de comunicación de última hora. Es la consecuencia natural de haber construido bien las cuatro capas desde el principio. Si te preparas para las preguntas sin haber hecho el trabajo de fondo, el consejo lo detecta — con la misma facilidad con la que detecta un ROI sin sustento.
El rigor es un acto de gobierno corporativo
Vale la pena decir esto sin rodeo: construir una tesis de inversión con estas cuatro capas no es un ejercicio de comunicación. Es un acto de gobierno corporativo.
Un consejo de administración tiene la responsabilidad fiduciaria de asignar capital donde el riesgo esté entendido y administrado, no donde la presentación fue más convincente. Cuando un equipo llega con una decisión operativa nombrada, una línea base documentada, una palanca de datos acotada y un criterio de cancelación explícito, le está facilitando al consejo cumplir esa responsabilidad. Cuando llega con una demo impresionante y un ROI sin sustento, le está pidiendo al consejo que confíe a ciegas.
Esa distinción —entre pedir confianza y facilitar gobierno— es, en mi experiencia, la que determina si un proyecto de datos e IA se aprueba en la primera presentación o si se archiva indefinidamente después de la segunda.
La tecnología, en todo esto, es la parte fácil. Lo difícil, y lo que realmente evalúa un consejo, es si quien está al frente del proyecto administra el capital con el mismo rigor con el que administraría cualquier otra decisión estratégica de la empresa.
Siguiente paso
Si tienes un proyecto de datos e IA que ya fue rechazado una vez —o que todavía no te atreves a llevar a consejo porque sabes que la tesis no aguanta las preguntas— eso es exactamente lo que trabajamos en el AI Value Discovery de Grupo Scanda: un diagnóstico de dos semanas que construye las cuatro capas de la tesis con tu equipo, con un mapa de iniciativas GO/NO-GO listo para presentar.
Escríbenos. Vamos a ver si tu proyecto está listo para el consejo, o si todavía le falta rigor antes de pedir el capital.
Español 
English