Esta temporada empezó con una incomodidad muy concreta: me di cuenta de que llevaba años sentado del lado del CEO, ayudando a decidir con datos e inteligencia artificial, y que este año empecé a sentarme también del otro lado — en el consejo. Y desde ahí, el mismo proyecto se ve completamente distinto.
Lo que siguió fueron cuatro capítulos que, vistos por separado, parecen temas distintos: una reflexión personal, un diagnóstico sobre la composición de los consejos, un experimento con un agente de IA, y ahora, un framework práctico. Vistos juntos, son la misma pregunta persiguiéndome de un lado a otro de la mesa: ¿qué decisión de negocio va a cambiar con esto, y cómo lo vamos a saber? Este artículo es el hub de los cuatro — un lugar donde quedan conectados, con cómo leo esa misma pregunta, en la práctica, desde la silla del consejo, cuando lo que se está aprobando es un proyecto de transformación digital.
Cuatro capítulos, un mismo criterio
No planeé esta temporada como una progresión ordenada desde el primer día. Fue apareciendo capítulo a capítulo, porque cada vez que resolvía una parte del problema, aparecía la siguiente parte sin resolver. Si ya viste el post del martes pasado o leíste el newsletter de esta semana, el resumen capítulo por capítulo ya te lo sabes — así que lo dejo corto, con el link de cada uno, y me voy directo a lo que sí es nuevo aquí: cómo leo, en la práctica, un proyecto desde la silla del consejo.
- Capítulo 1 — Me senté del otro lado de la mesa. Asesorar y vigilar no son el mismo oficio — la reflexión que abrió la temporada.
- Capítulo 2 — El consejero que no sabe de tecnología ya no alcanza. Por qué el perfil financiero, legal o de industria ya no cubre el riesgo de un proyecto de datos o IA. En el blog de Scanda →
- Capítulo 3 — El patrón de preguntas que haría un consejero con criterio técnico, antes de aprobar un proyecto. Reflexión en primera persona — sin oferta ni link que ofrecer en este recap.
- Capítulo 4 — Este mismo artículo. Cómo leo, en la práctica, un proyecto de transformación digital desde la silla del consejo.
El problema que conecta los cuatro capítulos
En los tres capítulos anteriores describí el mismo vacío desde ángulos distintos: la diferencia entre asesorar y vigilar, el perfil que falta en la mesa, y un intento de estructurar el patrón de preguntas que ese perfil produciría. Lo que no había hecho todavía era explicar, de forma directa y aplicable, cómo leo yo, en la práctica, un proyecto de transformación digital cuando llega a mi mesa como consejero — no como asesor, no como consultor externo, sino con la responsabilidad de decidir si ese capital se compromete o no.
La diferencia entre las dos posturas es más grande de lo que parece. Como asesor, mi trabajo es construir la mejor respuesta posible dentro del alcance que me dieron. Como consejero, mi trabajo es verificar que la pregunta se haya hecho con rigor antes de que alguien construyera una respuesta — y eso exige un proceso de lectura distinto, no solo una lista de preguntas sueltas.
Cómo leo un proyecto de transformación digital desde la silla del consejo
Cuando un proyecto de transformación digital llega a mi mesa como consejero, no empiezo preguntando por la tecnología. La tecnología casi nunca es el punto débil de la propuesta — el punto débil está, casi siempre, en alguno de los cinco pasos que describo aquí, y mi trabajo es identificar cuál.
Primero, qué decisión de negocio se supone que va a cambiar. No qué proceso se va a modernizar, ni qué sistema se va a reemplazar — qué decisión, tomada por una persona específica, va a cambiar como resultado de este proyecto. Si nadie en la presentación puede nombrar esa decisión con precisión, el proyecto todavía no está listo para aprobarse, sin importar qué tan sofisticada sea la tecnología detrás.
Segundo, cómo se va a medir el éxito, definido antes de arrancar. Un proyecto que se aprueba sin una métrica de éxito explícita casi siempre termina evaluándose de forma retroactiva y subjetiva, lo que hace prácticamente imposible que el consejo aprenda algo útil de esa decisión para la siguiente. Pregunto, siempre, cuál es el número que en doce o dieciocho meses nos va a decir si esto funcionó — y me detengo si la respuesta llega vaga.
Tercero, qué tan confiables son los datos o los sistemas de origen. La mayoría de los proyectos de transformación digital dependen de una base — datos, procesos, sistemas heredados — que nadie en la sala ha verificado directamente. No hace falta auditar esa base línea por línea desde el consejo; hace falta preguntar si alguien lo hizo, y qué encontró.
Cuarto, qué supuesto, si resulta falso, hace que todo el caso de negocio se caiga. Todo proyecto de transformación digital descansa sobre dos o tres supuestos centrales — de adopción, de ahorro, de velocidad de implementación. Identificar cuál de esos supuestos es el más frágil, y preguntar directamente cómo se validó, revela más sobre la solidez del proyecto que cualquier otra pregunta individual.
Quinto, quién es responsable de cada una de las respuestas anteriores. Un proyecto puede tener las cuatro respuestas correctas y seguir siendo un mal proyecto para aprobar, si nadie específico es responsable de que esas respuestas se mantengan ciertas conforme avanza la implementación. Pregunto, siempre, quién pierde algo concreto si el proyecto no cumple lo prometido — y si la respuesta es “el equipo”, en general, sin un nombre, ahí está la primera señal de alerta.
Estas cinco preguntas no son exclusivas de proyectos de inteligencia artificial — aplican a cualquier proyecto de transformación digital: una migración de ERP, un rediseño de procesos, una nueva plataforma comercial. Lo que cambia, de proyecto a proyecto, es dónde específicamente se rompe la cadena. Mi trabajo en la mesa no es tener la respuesta de antemano — es identificar, con estas cinco preguntas, en qué eslabón está la debilidad de esta propuesta en particular.
Un ejemplo de cómo se ve esto en la práctica
Para que el framework no se quede en abstracto, vale la pena mostrarlo aplicado — sin nombrar organizaciones ni exponer información de nadie, sobre un tipo de proyecto que he visto repetirse, con variaciones, en más de un consejo.
Un equipo directivo presenta un proyecto de modernización de su plataforma comercial: nuevo CRM, integración con IA para scoring de leads, dashboards en tiempo real para el equipo de ventas. La presentación es sólida, el proveedor tiene buenas referencias, y el caso de negocio proyecta un incremento de conversión del orden de dos dígitos.
Primera pregunta: ¿qué decisión de negocio cambia con esto? La respuesta inicial suele ser genérica — “vamos a vender más” — y ahí es donde me detengo a pedir precisión. ¿Qué decisión, tomada por quién, cambia? En este tipo de proyecto, la respuesta correcta normalmente es algo como: el equipo comercial va a decidir en qué cuentas invertir tiempo de prospección, con base en un score de probabilidad de cierre que hoy no existe. Esa es una decisión específica, tomada por una persona específica. Si la respuesta se queda en “vender más”, el proyecto no está listo para que el consejo lo apruebe con criterio.
Segunda pregunta: ¿cómo se mide el éxito, definido antes de arrancar? Aquí es común encontrar que la métrica de éxito se definió después del hecho — “vamos a ver cómo va” — en vez de antes. La respuesta que busco es un número concreto, con fecha: por ejemplo, incrementar la tasa de conversión de oportunidad a cierre en un porcentaje específico, medido a los doce meses, comparado contra una línea base ya documentada. Si esa línea base no existe todavía, esa es la primera señal de que el proyecto se está aprobando antes de tiempo.
Tercera pregunta: ¿qué tan confiables son los datos de origen? En este tipo de proyecto, casi siempre hay múltiples fuentes de datos de clientes — el CRM viejo, hojas de cálculo del equipo comercial, un sistema de facturación separado — sin una definición común de qué es un cliente único. Un modelo de scoring construido sobre datos no gobernados va a producir resultados que parecen precisos y no lo son. Pregunto, siempre, si existe un proceso de Data Quality antes del proyecto de IA, no después.
Cuarta pregunta: ¿qué supuesto, si resulta falso, tira el caso de negocio? En este ejemplo, casi siempre el supuesto más frágil es la tasa de adopción del equipo comercial — el modelo puede ser excelente, pero si el equipo de ventas no confía en el score y sigue trabajando por intuición, el retorno proyectado nunca se materializa. Pregunto cómo se validó esa adopción, más allá de una encuesta de intención.
Quinta pregunta: ¿quién es responsable de que estas respuestas se mantengan ciertas? Normalmente hay un dueño del proyecto durante la implementación, pero nadie con responsabilidad explícita sobre el resultado de negocio doce meses después. Esa es la pregunta que más incomoda, y la que más frecuentemente revela que, en realidad, nadie en la sala se está jugando algo concreto si el proyecto no cumple.
Ninguna de estas cinco preguntas requiere entender el modelo de scoring por dentro. Todas requieren, simplemente, que alguien las haga antes de aprobar el capital — y que el consejo tenga el criterio suficiente para reconocer cuándo una respuesta es sólida y cuándo es una versión bien presentada de “todavía no lo sabemos”.
Lo que este framework no reemplaza
Vale la pena decir esto con la misma claridad con la que lo dije en el Capítulo 3: este framework no reemplaza el criterio de nadie en la mesa, ni convierte a un consejo entero en expertos en transformación digital. Es una secuencia de verificación — un orden en el que hacer las preguntas correctas, no un sustituto de tenerlas.
Tampoco resuelve, por sí solo, el vacío que describí en el Capítulo 2: si nadie en el consejo tiene el criterio técnico para entender las respuestas a estas cinco preguntas, hacerlas no sirve de mucho. El framework ayuda a estructurar el proceso; el criterio para juzgar las respuestas sigue dependiendo de que exista, en algún lugar de la mesa, la capacidad de evaluarlas con rigor.
Qué significa esto para tu consejo, en términos prácticos
Si estás leyendo esto porque formas parte de un consejo o un comité directivo, la aplicación inmediata es simple de describir y difícil de sostener: la próxima vez que un proyecto de transformación digital llegue a tu mesa, recorre las cinco preguntas en orden, antes de escuchar la recomendación final de quien presenta. No para desconfiar por sistema, sino para tener, tú también, una lectura propia del proyecto antes de que la presentación te convenza de una.
Si te falta el criterio técnico para juzgar alguna de las cinco respuestas, ese es exactamente el vacío que describí en el Capítulo 2 — y el mismo que exploré en el Capítulo 3, preguntándome qué tanto se puede sostener esa disciplina de preguntar mientras ese perfil se incorpora de forma permanente. Ni el framework de este artículo ni esa reflexión sustituyen la necesidad de tener, eventualmente, a alguien con ese criterio sentado en la mesa de forma estructural.
Hay una forma sencilla de empezar a instalar esta disciplina sin esperar a resolver el vacío de perfil de una vez: documentar las cinco respuestas de cada proyecto de transformación digital en el acta de la sesión donde se aprueba, no solo la decisión final de aprobar o rechazar. Con el tiempo, esa documentación se vuelve un historial que el consejo puede revisar — qué tan seguido las respuestas eran sólidas, qué tan seguido eran vagas, y qué tan bien predijeron el resultado real del proyecto doce meses después. Ese historial, más que cualquier framework, es lo que termina desarrollando criterio real en una mesa.
También vale la pena decir qué pasa cuando estas cinco preguntas se hacen tarde, no nunca. He visto consejos que empiezan a aplicarlas a la mitad de un proyecto ya aprobado, cuando los resultados empiezan a verse ambiguos. No es el momento ideal, pero tampoco es inútil: las mismas cinco preguntas, aplicadas a un proyecto en marcha, sirven para decidir si vale la pena seguir invirtiendo o si es momento de detenerse antes de comprometer más capital. La disciplina de preguntar no pierde todo su valor por llegar tarde — pierde una parte, no toda.
Lo que cambió en mí durante estas tres temporadas
No quiero cerrar esta temporada sin decir algo que solo tiene sentido en primera persona, no como framework. Empecé julio pensando que el problema principal era de conocimiento — que si el CEO, el equipo que arma el caso, y el consejo simplemente supieran más de datos e IA, las decisiones mejorarían. Termino septiembre convencido de que el problema, con más frecuencia, es de responsabilidad, no de conocimiento: alguien en la sala casi siempre tiene la capacidad de hacer la pregunta correcta, pero nadie tiene la obligación explícita de hacerla antes de que sea tarde.
Eso cambió cómo yo mismo participo en las mesas donde estoy sentado. Ya no doy por hecho que, porque alguien más en la sala tiene más experiencia técnica que yo, la pregunta se va a hacer sin que yo la haga. La hago yo, aunque no sea la persona con más autoridad formal sobre el tema, porque de las tres temporadas me queda claro que la responsabilidad de preguntar no se delega solo por sentarse en la silla equivocada.
Preguntas frecuentes
¿Este framework aplica solo a proyectos de inteligencia artificial? No. Aplica a cualquier proyecto de transformación digital que un consejo tenga que aprobar — IA, migraciones de sistemas, rediseño de procesos, nuevas plataformas. Lo que cambia es dónde se rompe la cadena en cada caso, no las cinco preguntas.
¿En qué orden debo hacer las cinco preguntas? El orden que describo — decisión de negocio, métrica de éxito, confiabilidad de los datos, supuesto crítico, responsable — funciona porque cada pregunta depende de la anterior. Si la primera no tiene una respuesta clara, las siguientes cuatro pierden sentido.
¿Qué hago si mi consejo no tiene el criterio técnico para evaluar las respuestas? Es el mismo vacío que describo en el Capítulo 2 de esta temporada. La solución de fondo es incorporar ese criterio a la mesa, de forma permanente. Mientras eso sucede, documentar las cinco preguntas de este framework en cada sesión —así como lo describo más arriba— es lo que a mí me ha funcionado para sostener la disciplina sin depender de que llegue el perfil ideal.
¿Dónde encuentro el detalle de cómo MaIA construye la base de datos confiable que estas preguntas necesitan? Ese detalle está en los artículos del Capítulo 1 y el Capítulo 2 de esta temporada, publicados en el blog de Scanda — ahí conecto este mismo criterio con la práctica de Data Intelligence de MaIA.
¿Este framework sirve también fuera de un consejo formal, por ejemplo en un comité directivo? Sí. El mismo patrón de cinco preguntas aplica a cualquier órgano que tenga que aprobar capital para un proyecto de transformación digital, tenga o no la estructura formal de un consejo de administración — comités directivos, comités de inversión, o incluso un equipo de liderazgo que decide sin ese formalismo.
Siguiente paso
Esta temporada empezó con una pregunta incómoda y termina con un framework que puedes usar la próxima vez que tu consejo tenga que aprobar un proyecto de transformación digital. Si algo de estos cuatro capítulos resonó contigo — si te reconociste en el CEO que todavía no pregunta a tiempo, en el consejo sin el perfil técnico adecuado, o en la mesa que aprueba más rápido de lo que debería — el siguiente paso concreto es un AI Value Discovery: dos semanas, un mapa de oportunidades de IA con veredicto GO/NO-GO por iniciativa, hecho a la medida de tu organización. Agenda el tuyo https://ai-discovery-form.netlify.app/, o deja un comentario en cualquiera de las piezas de esta temporada.
Gracias por acompañar estos tres meses. Octubre trae un tema nuevo.