Blog
Los proyectos de IA no fracasan al lanzarse. Se paran en el mes tres.
El día del lanzamiento suele ir bien. La cosa funciona, alguien la enseña, unos cuantos dicen que es impresionante y la factura se paga.
Lo que viene después es más silencioso. Sobre la semana ocho, la persona que hace el trabajo vuelve a abrir la hoja de cálculo de siempre, solo para este caso raro. En la semana doce la hoja está abierta todos los días. Nadie anuncia nada. Nadie escribe un informe diciendo que el proyecto ha fracasado, porque desde fuera no ha fracasado: se entregó, a tiempo y según lo pedido.
Ese es el modo de fallo que tiene este sector de verdad, y está lo bastante documentado como para que ya no sorprenda a nadie.
UNOS 11 MINUTOS DE LECTURA CON INVESTIGACIÓN PÚBLICA DETRÁS CITADA, NO PARAFRASEADA
LEÍDO
Qué dice la investigación publicada
Tres hallazgos, los tres públicos y los tres de gente que no te vende nada. Esta investigación no la hemos hecho nosotros. La citamos, y puedes ir a leerla.
Casi ningún piloto produce algo medible. El trabajo de NANDA en el MIT sitúa en torno al 95% la proporción de pilotos de IA generativa que no producen ningún retorno medible. No es que los modelos fallaran. Es que en las cuentas no apareció nada.
Los fracasos son organizativos, no técnicos. Las entrevistas de RAND con quienes llevaron estos proyectos sitúan las causas en cómo funcionan las organizaciones, no en lo que podía hacer la tecnología. Problema mal elegido, nadie responsable, ningún cambio en cómo pasa cada uno su jornada.
La escasez está en la integración, no en la capacidad. El análisis de BCG sobre dónde va ahora el dinero apunta al mismo sitio: las plataformas venden la capacidad, y lo escaso es el trabajo de meterla dentro de los sistemas y las costumbres que una empresa ya tiene.
Junta los tres y sale un resumen incómodo. La tecnología casi nunca es el motivo de que tu proyecto dejara de usarse. La tecnología es la parte que sí llegó.
Las cinco formas de pararse
Contadas como escenas, porque vas a reconocer antes la que estás viviendo que la categoría a la que pertenece.
-
Tenía padrino y nunca tuvo dueño
Alguien de arriba lo aprobó. A nadie se le nombró como la persona que lo mantiene en marcha, contesta las dudas y decide qué se cambia ahora.
El padrino aprueba. El dueño mantiene. Un sistema sin dueño no tiene por dónde convertir un problema pequeño en un arreglo pequeño, así que los problemas pequeños se acumulan hasta que la gente los esquiva de forma permanente.
-
Se construyó sobre el caso limpio
Los pilotos se hacen con la versión ordenada del trabajo. La consulta bien escrita, la factura con el formato de siempre, el cliente cuyo nombre se escribe igual en los dos sistemas.
Los casos sucios son donde se van las horas de verdad, y no se los enseñó nadie a quien lo estaba construyendo. Así que el sistema resuelve los casos ordenados, la persona sigue resolviendo a mano los raros y, como para los raros ya está metida en la hoja de cálculo de siempre, hacerlo todo ahí es un cambio de contexto menos.
-
Nadie acordó por adelantado qué significaba que funcionara
Ninguna prueba escrita antes de mover el dinero. Así que en el mes tres no hay forma de zanjar si ha salido bien, y la pregunta la decide quien hable con más seguridad en la reunión.
Es un problema de supervivencia para el proyecto. Un sistema que no se mide solo lo defiende el entusiasmo, y el entusiasmo se apaga en una curva bastante previsible.
-
Lo que producía necesitaba a alguien que lo revisara y no se presupuestó a nadie
Todo lo que escribe, redacta, clasifica o resume necesita una persona que lo lea. Esa persona es un coste real en un calendario real.
Si no se le dio el tiempo, pasa una de dos cosas. O lo producido se queda sin leer y el sistema es más lento que lo de antes, o sale sin leer y una semana bochornosa después todo el mundo deja de usarlo en silencio. La segunda hace más daño, porque además envenena el siguiente intento.
-
Se apoyaba en una sola persona entusiasmada
Alguien lo defendió, se lo aprendió bien, se apañó con sus asperezas y lo mantuvo vivo. Y luego cambió de trabajo, o se fue de vacaciones, o le cayó un trimestre malo.
Una adopción que depende de la atención de una persona dura exactamente lo que dura esa atención. Es la causa individual que más vemos, la más fácil de evitar y la que menos se evita.
Las cinco cosas que evitan cada una
UN REMEDIO POR FALLO LAS CINCO SON DECISIONES, NO COMPRAS
- Nombra al dueño en la sala donde se aprueba el presupuesto. No después, y no "el equipo de operaciones". Una persona, que sepa que es ella, y con tiempo asignado para serlo.
- Mapea primero los casos sucios. Pide los últimos diez ejemplos reales, no una descripción del proceso. La descripción siempre está más ordenada que la realidad, y la diferencia entre las dos es el proyecto.
- Escribe la prueba de apto o no apto antes de mover el dinero, en los términos del negocio, y fírmala. "El noventa por ciento de las consultas normales con acuse de recibo en menos de diez minutos, comprobado durante quince días" es una prueba. "Mejorar la eficiencia" es un deseo.
- Presupuesta la revisión dentro del alcance. No en la tarde libre de alguien. Si la revisión no se puede pagar, el sistema es más pequeño de lo que creías, y es mejor descubrirlo al definir el alcance.
- Forma a más de una persona, sobre su propio trabajo. Dos como mínimo, con sus casos reales y no con un juego de datos de demostración, más una documentación de traspaso que exista el primer día y no cuando se pida.
Ninguna de las cinco es una compra. Las cinco son decisiones que alguien tiene que tomar en voz alta, pronto, cuando todavía salen baratas.
LEÍDO
La incómoda
A veces la respuesta correcta después del mapa es reordenar cómo se trabaja y automatizar menos de lo que esperaba nadie.
Esa conversación es incómoda para el proveedor, porque la factura sale más pequeña, y es incómoda para quien aprobó el presupuesto, porque significa que el problema estaba más cerca de casa de lo que daba a entender la presentación. Y aun así suele ser la respuesta correcta.
Un proceso malo hecho más rápido es un proceso malo con un coste de mantenimiento pegado. Si una tarea tarda cuatro horas porque se hace dos veces, en dos sitios, por dos personas que no saben la una de la otra, no hay sistema que arregle eso. Solo hace más rápidas las dos copias.
Lo decimos en nuestra propia página de método.
Cuatro señales, en el mes dos, de que el tuyo se está parando
Lo útil de todo lo anterior es que se ve pronto, si sabes dónde mirar. Ninguna de estas necesita un panel de control.
La hoja de cálculo de siempre sigue abierta. No como archivo. Abierta, en la segunda pantalla de alguien, y editándose. Es la señal más clara que existe, y suele verse semanas antes de que nadie diga nada.
Hay un apaño y tiene nombre propio. Cuando quienes hacen el trabajo han desarrollado un saber compartido sobre cómo esquivar una parte del sistema, esa parte no se va a arreglar: se va a esquivar para siempre.
Sale un informe que no lee nadie. Pregúntale al destinatario qué ponía en el último. Si no sabe decirlo, el informe es decorado, y el informe decorativo suele estar encima de un sistema que tampoco mira nadie.
Nadie ha pedido un cambio en seis semanas. Esta es la contraintuitiva y es la más fuerte. Un sistema que se usa de verdad a diario genera peticiones, quejas e ideas pequeñas, todo el rato. El silencio no es conformidad. El silencio es que nadie lo está tocando.
Si dos de esas cuatro son ciertas, tienes alrededor de un mes antes de que salga más a cuenta abandonar el sistema que revivirlo. Merece la pena dedicarle una semana ahora mismo, y esa semana no tiene por qué implicar al proveedor original.
Qué hacemos nosotros al respecto, ya que somos quienes escribimos esto
Nuestro método está montado alrededor de este modo de fallo y no alrededor del desarrollo, y está publicado entero para que puedas exigírnoslo o copiarlo.
La versión corta. Cada fase de pago tiene una prueba de apto o no apto escrita y firmada antes de que esa fase empiece. La formación y los treinta días de acompañamiento están dentro del alcance, no vendidos como extra. La documentación de traspaso se entrega por defecto el día de la puesta en marcha, no a petición, para que no dependas de nosotros para entender tu propio sistema. Y el mapa del proceso se hace con quienes hacen el trabajo, no solo con quien firma.
Lo que no te vamos a dar es una cifra de facturación, de visitas o de clientes potenciales. En tu mercado no hay una referencia contra la que prometer eso, y prometerlo igualmente es una forma bien documentada de perder al cliente en el cuarto mes.
Lee el método, no el discurso
Si tienes un sistema que se está quedando callado, las cuatro señales de arriba merecen una hora esta semana. Si estás a punto de encargar uno, los cinco remedios merecen que los discutas antes de firmar nada, con quien vaya a construirlo.
Seis fases, plazos reales, lo que necesitamos de ti, los riesgos que ya podemos nombrar y qué pasa cuando una fase de pago no supera su prueba. Si después de leerlo prefieres hablar, reserva una llamada.
Sigue por aquí
- Nuestro método, completo, con las salidas de cada fase de pago y las cuatro cosas que no vamos a hacer.
- Dos idiomas, un buzón, un ejemplo trabajado de decidir el proceso antes de comprar el software.
- El índice del blog, con las tres líneas y las preguntas que todavía no hemos contestado.
- Contacto, para reservar una conversación o escribir un mensaje corto.