¿Por qué la mayoría de los pilotos de IA mueren en el tercer mes?
Casi nunca tiene la culpa el modelo. Son tres razones que se repiten siempre, y aquí está el arreglo de cada una.
Hemos visto morir muchos pilotos de IA, y casi nunca fue por el modelo, que por lo general hizo lo que se le pidió. Lo que cedió fue algo a su alrededor.
Pasa casi siempre en el mismo punto. La demo fue en el primer mes y la dirección quedó contenta. Luego viene un segundo mes tranquilo, y para el tercero alguien pregunta quién lo sigue usando y nadie sabe bien. El canal de Slack se quedó callado y el proveedor ya está con el siguiente cliente. Nadie canceló el piloto, pero ya no está.
Cuando volvemos a revisar, siempre es una de tres cosas, y por lo general son dos a la vez.
1. Nadie se hizo cargo después de la demo.
Todo piloto tiene a alguien que lo defiende, que consigue que lo aprueben, se sienta en las sesiones y se lo muestra al jefe. Después a esa persona la ascienden, se va de licencia o la mandan a atender la siguiente urgencia, y el contrato con el proveedor termina esa misma semana. Ahora el piloto es de todos, que es lo mismo que decir que no es de nadie.
La solución es aburrida y funciona. Del lado del cliente tiene que haber una persona con nombre y apellido que siga ahí en el sexto mes, con el piloto escrito en las funciones de su puesto y tiempo en su agenda para atenderlo, porque un comité de dirección no cumple ese papel.
2. Nunca tocó datos reales.
La demo corría sobre una muestra limpia, con veinte registros ordenados, unas cuantas preguntas bien hechas y un recorrido donde todo salía bien, y se veía de maravilla. Después se encontró con el CRM real, con las cuentas duplicadas, el campo que alguien usa como bloc de notas desde 2019 y ese quince por ciento de registros que no tienen ningún correo electrónico.
Los datos reales no pueden quedar para una fase posterior. Si al terminar la primera semana el piloto no puede correr sobre una copia en vivo del sistema real, es una presentación de diapositivas con pasos de más. Nosotros cargamos datos reales el tercer día, cuando el producto todavía es tan feo que a nadie le importa que se rompa.
3. Nadie pensó en el lunes.
¿Quién lo abre a las nueve de la mañana? ¿Qué hace cuando el sistema se equivoca, porque a veces se va a equivocar? ¿Quién lo arregla esa misma tarde? ¿Cuánto cuesta al mes y de qué presupuesto sale? Son preguntas aburridas, y de ellas depende todo.
Un piloto que tiene respuesta para cada una se convierte en producto, y el que no la tiene termina como la anécdota que alguien cuenta en la próxima presentación de un proveedor.
Resuelve esas tres cosas antes de escribir una sola línea de código y la parte de IA va a ser la más fácil.
Esto es lo que hacemos al respecto
Nuestro proyecto de diez días empieza con dos días dedicados justo a estas preguntas, que respondemos por escrito con las personas que pueden decir que sí. Es la parte menos vistosa del calendario y la única que nos negamos a saltar. Después vienen los datos reales el día tres, los usuarios reales el día seis y, el día diez, una demo que termina con una decisión: seguir, cambiar de rumbo o parar.
Si tienes un piloto que ya está estancado en el tercer mes, es una situación normal y casi siempre tiene arreglo. Tenemos una oferta hecha justo para eso.