Cómo elegir el primer caso de uso de IA que sí va a funcionar

Por qué la mayoría elige mal su primer caso de uso

Si ya hiciste el diagnóstico de madurez, tienes en la mesa una lista de candidatos: procesos que duelen, áreas que piden ayuda, ideas que salieron en la última reunión de innovación. El diagnóstico resuelve el “dónde nos duele”. Esta guía resuelve el problema siguiente, más peligroso: de esa lista, ¿cuál va primero?

El error casi nunca está en la lista de candidatos: está en el criterio, o la falta de criterio, para elegir uno. En la mayoría de comités gana el candidato más vistoso, el que suena mejor en una presentación de directorio, el que promete el número más grande, el que alguien con poder político ya decidió que quiere ver funcionando. Eso no es un criterio de negocio, es elegir para impresionar, no para ganar.

El costo de equivocarse aquí no es solo técnico. Un primer caso de uso que se atasca, que no entrega nada en tres meses, que depende de datos que nadie tiene limpios, quema la paciencia política que necesitas para el segundo intento, y la mayoría de empresas no tiene presupuesto ni paciencia para un segundo intento fallido.

Por eso el primer caso de uso no se elige por impacto potencial en abstracto, se elige por la combinación de impacto real y viabilidad concreta: un método que rara vez se aplica y casi siempre se reemplaza por intuición, jerarquía o simpatía con quien propuso la idea.

Qué significa elegir bien (y qué no)

Elegir bien el primer caso de uso no es encontrar “el proyecto de IA más importante” de la empresa. Es encontrar el proyecto con más probabilidad real de entregar un resultado medible en semanas, no en trimestres, con los recursos que la empresa realmente tiene hoy, no los que tendrá “cuando maduremos”.

Los seis criterios que de verdad predicen si un caso de uso va a funcionar

Cada candidato de tu lista se evalúa contra los mismos seis filtros. No son opcionales ni intercambiables: un candidato que falla en dos o más de estos, por más atractivo que sea el argumento de negocio, no debería ser el primero.

• Dolor real y medible: el proceso duele hoy, alguien se queja de él en voz alta, y existe un número (horas, errores, costo, tiempo de espera) que ya se mide o se puede medir sin inventar un sistema nuevo. Si nadie puede decir cuánto cuesta el problema actual, no vas a poder demostrar que lo resolviste.
• Volumen suficiente: el proceso ocurre con la frecuencia necesaria para que automatizarlo importe. Un proceso que pasa tres veces al año, por doloroso que sea, no genera el volumen de evidencia que necesitas en ocho semanas para mostrar resultado.
• Datos disponibles: la información que el caso de uso necesita ya existe, en un formato que se puede tocar, sin depender de un proyecto de limpieza de datos de seis meses que nadie ha empezado. Si la respuesta a “¿tenemos esos datos?” es “deberíamos”, ese candidato no es el primero.
• Dueño con nombre: hay una persona concreta, no un área genérica, responsable de que este caso de uso funcione y de defenderlo cuando algo salga mal en el camino. Un caso de uso sin dueño con nombre es un caso de uso sin nadie que pelee por él cuando aparezca el primer obstáculo.
• Tiempo de implementación corto: se puede llegar a una primera versión funcional en semanas, no en trimestres. Cuanto más larga la implementación, más tiempo tiene el comité para perder el interés o para que cambie la prioridad de la empresa.
• Bajo riesgo si falla: si el primer intento no funciona como se esperaba, el costo de ese fracaso (reputacional, financiero, operativo) es contenido. El primer caso de uso no es el lugar para apostar el proceso más crítico de la empresa; es el lugar para aprender rápido y barato.

Cómo armar la matriz de impacto vs. viabilidad (y cerrar la decisión)

Construye los dos ejes

La matriz tiene dos ejes. El eje de impacto combina el criterio de dolor real y medible con el de volumen suficiente: cuánto vale resolver esto y con qué frecuencia. El eje de viabilidad combina los otros cuatro: datos disponibles, dueño con nombre, tiempo de implementación corto y bajo riesgo si falla. No hace falta software especializado para esto: una hoja de cálculo con una fila por candidato y una columna por criterio es suficiente.

Puntúa cada candidato, no lo discutas primero

Cada persona que conoce el candidato le pone una nota de uno a cinco en cada uno de los seis criterios, por separado, antes de discutir en grupo. Si discutes primero, la nota termina reflejando quién habló más fuerte en la sala, no la viabilidad real del candidato. Suma las notas de impacto por un lado y las de viabilidad por el otro, y recién ahí compara resultados con el resto del comité.

Ubica cada candidato en el cuadrante correcto

Con el promedio de impacto en un eje y el promedio de viabilidad en el otro, cada candidato cae en uno de cuatro cuadrantes. El cuadrante de impacto alto y viabilidad alta es tu primer caso de uso: ahí es donde se elige, sin excepción. El cuadrante de impacto alto y viabilidad baja es la trampa: es el candidato vistoso, el que suena mejor en la presentación, el que no tiene datos ni dueño ni tiempo corto detrás. Ese va a la lista de “casos de uso número dos o tres”.

Cierra la sesión con una decisión escrita, no con una preferencia

La sesión de decisión no termina en “creo que deberíamos ir por este”. Termina con el nombre del caso de uso elegido, el nombre del dueño, la fecha en que se espera la primera versión funcional, y el número exacto que se va a medir para saber si funcionó. Si el comité sale de la reunión sin esos cuatro datos escritos, no eligió un caso de uso: solo tuvo una conversación.

Errores comunes al elegir el primer caso de uso

• Elegir el caso de uso que mejor suena en la presentación de directorio, no el que mejor puntúa en la matriz. El argumento “esto va a impresionar a la junta” no es un criterio de viabilidad, es una trampa de ego.
• Saltarse la puntuación individual y decidir directamente en grupo. La discusión abierta desde el minuto uno favorece al que tiene más jerarquía o más carisma en la sala, no al candidato con mejores datos.
• Confundir “tenemos los datos en algún sistema” con “los datos están disponibles”. Si nadie puede extraerlos, limpiarlos y usarlos en un plazo razonable, ese criterio no está cumplido, aunque técnicamente el dato exista en algún servidor.
• Elegir un caso de uso sin dueño con nombre, asumiendo que “el área de operaciones” se va a hacer cargo. Un área no defiende un proyecto cuando se pone difícil; una persona sí, o debería.
• Tratar el primer caso de uso como el proyecto más importante de la estrategia de IA de la empresa, en vez de tratarlo como la primera prueba de que el sistema completo (datos, criterio, gente) puede sostener un segundo y un tercer caso de uso.

Qué hacer cuando dirección insiste en el caso ambicioso que no cumple los criterios

Esto va a pasar. Alguien en el comité, casi siempre con poder para imponerlo, va a insistir en el candidato que perdió en la matriz: el que promete transformar el área comercial completa, el que suena mejor para el reporte anual, el que ya prometió en una reunión externa antes de consultar con el equipo técnico.

• Muestra la matriz, no tu opinión. La conversación cambia cuando el argumento no es “yo creo que no es buena idea” sino “este candidato puntuó bajo en datos disponibles y en tiempo de implementación, y esto es lo que eso significa en riesgo real”.
• Ofrece el caso ambicioso como segundo o tercer proyecto, no como un “no” definitivo. Casi nadie insiste en un “nunca”; casi todos aceptan un “primero esto, y en ocho semanas retomamos el otro con mejor evidencia”.
• Propón una versión reducida del caso ambicioso que sí cumpla los criterios: un piloto acotado a una sola línea de producto, a una sola región, a un subconjunto de clientes, en vez del despliegue completo que dirección tiene en la cabeza.
• Si aun así se impone el candidato de alto riesgo, documenta por escrito qué criterios no cumple y qué riesgo específico se está aceptando. No para cubrirte cuando falle: para que la próxima decisión de priorización use el mismo criterio, no la misma jerarquía.

Cómo se ve esto en la práctica

Una empresa de manufactura mediana llegó al comité de priorización con dos candidatos principales tras su diagnóstico de madurez. El primero: un sistema de visión por computadora para inspección de calidad en línea de producción, presentado por el gerente de planta. El segundo: automatizar la clasificación y extracción de datos de facturas de proveedores para el área de contabilidad, un problema que nadie mencionaba en las reuniones de innovación porque sonaba aburrido.

En la matriz, el sistema de visión por computadora puntuó alto en impacto, pero bajo en viabilidad: los datos de imágenes etiquetadas no existían, el gerente de planta no tenía horas reales para dedicarle, y el plazo realista de implementación era de varios meses, no semanas. El caso de facturas puntuó más bajo en impacto percibido, pero alto en viabilidad: el volumen mensual era alto y constante, los datos ya existían en el sistema contable, había una persona de contabilidad dispuesta a ser dueña del proyecto, y una primera versión funcional se podía tener en menos de un mes.

El comité quería empezar por visión por computadora. La matriz mostró el riesgo en números, no en opiniones, y el comité optó por facturas como primer caso de uso, con visión por computadora documentado como segundo proyecto, una vez que hubiera datos etiquetados y presupuesto para un responsable de tiempo completo. Ocho semanas después, el proceso de facturas ya mostraba una reducción medible en tiempo de procesamiento, evidencia que destrabó presupuesto para preparar en serio el proyecto de visión por computadora.

Mi criterio

Cómo saber si elegiste bien

La señal de que elegiste bien no aparece el día que arrancas el proyecto. Aparece entre la semana seis y la semana diez, cuando deberías tener una primera versión funcional entregando el número que definiste antes de empezar.

• El caso de uso elegido llegó a una primera versión funcional dentro del plazo estimado en la sesión de decisión, sin extensiones silenciosas de “un mes más”.
• El número definido como meta (horas ahorradas, errores reducidos, tiempo de ciclo) se puede medir hoy contra la línea base documentada antes de empezar, no contra una impresión general de que “ya está mejor”.
• El dueño con nombre sigue siendo el dueño: no renunció al proyecto ni lo devolvió al equipo técnico en cuanto apareció el primer obstáculo.

Si después de diez semanas no hay número que mostrar, revisa primero los criterios: casi siempre el candidato fallaba en datos disponibles o en dueño con nombre desde el inicio, y el entusiasmo inicial tapó una puntuación de viabilidad que ya advertía el riesgo.