Casi todos los proyectos que reviso llegan con la misma pregunta: qué modelo conviene. Casi ninguno trae contestada la anterior: qué hace exactamente el proceso que se quiere automatizar. Las dos preguntas no pesan lo mismo. La primera se resuelve en una tarde. La segunda decide si el proyecto sirve.
Un proceso mal entendido no se arregla con software. Se acelera. Un error que ocurría doce veces al día pasa a ocurrir mil doscientas, con la ventaja adicional de que ya nadie lo revisa porque «está automatizado».
Estas son las cinco señales que uso para saber si un proceso está entendido o solamente contado. Ninguna necesita tecnología para detectarse y todas se ven en una semana de trabajo. Son la parte aburrida de cualquier estrategia de inteligencia artificial y también la única que predice el resultado.
1. Nadie sabe cuánto tarda hoy
Pregunto cuánto tiempo toma el proceso completo. Si la respuesta es un rango —«depende, entre dos horas y dos días»— no es una respuesta: es una confesión. Un rango de veinticuatro veces no describe un proceso. Describe dos o tres procesos distintos que comparten nombre.
Sin ese número no hay comparación posible después. El proyecto se termina evaluando con la frase «se siente más rápido», que es exactamente el criterio que permite a un piloto sobrevivir un año entero sin producir nada. Medir tiempos y cuellos de botella antes de tocar nada no lo inventó la inteligencia artificial: es lo que la consultoría de procesos lleva décadas haciendo con cronómetro y libreta, y el formato de ese ejercicio está documentado aquí desde mucho antes de que existieran los modelos de lenguaje.
La medición no tiene que ser fina. Tiene que existir.
2. El diagrama que dibujan no es el que ejecutan
Pido el diagrama del proceso. Casi siempre existe, casi siempre es de hace tres años y casi siempre está limpio: cajas, flechas, ninguna vuelta atrás. Luego me siento junto a quien lo ejecuta y cuento los pasos reales. Nunca coinciden. La distancia entre los dos dibujos es el tamaño del problema.
Donde más claro lo he visto es en la operación de una tienda en línea. En el papel el pedido entra, se cobra, se surte y se entrega. En la realidad hay un paso donde alguien revisa a mano si el inventario del almacén coincide con el del sitio, y ese paso no aparece en ningún diagrama porque nació como un parche de una tarde. Antes de medir cualquier cosa en una operación de comercio electrónico hay que entender el vocabulario del canal —carrito abandonado, surtido, devolución, contracargo—, que está explicado aquí con más orden del que yo le voy a dar en un párrafo. Sin ese vocabulario uno mide lo que entiende, no lo que pasa.
3. Las excepciones no están contadas
«El noventa por ciento de los casos son iguales.» Es la frase más cara de todas. Nadie la ha contado nunca; es una impresión. Y cuando por fin se cuenta, el noventa suele ser sesenta.
Importa porque el diez por ciento restante es el que se come el presupuesto. El caso simple lo resuelve cualquier cosa. El caso raro exige reglas, revisión humana y una ruta de escape, y ahí es donde el proyecto se vuelve caro. Un piloto que solo probó con casos limpios no probó nada: probó que la parte fácil es fácil.
Le pido a alguien que lleve una libreta dos semanas y anote cada vez que tuvo que salirse del camino. Dos semanas de libreta valen más que un mes de reuniones.
4. El proceso tiene participantes, no dueño
Pregunto quién decide cuando el proceso falla. Si contestan tres personas distintas, o si contestan «lo vemos entre todos», el proyecto ya tiene escrita su causa de muerte. Un sistema automático necesita alguien que apruebe cambios, que acepte los errores y que tenga autoridad para apagarlo. Sin ese nombre, cada ajuste se convierte en una negociación entre cuatro áreas y el ajuste no se hace.
No es un problema técnico y por eso se ignora tanto. La inteligencia artificial para negocios fracasa en organigramas mucho más seguido que en modelos. Es lo mismo que conté en El piloto que funcionó en la demostración: el sistema andaba bien; lo que no había era quién se hiciera cargo el día que dejara de andar.
5. Nadie escribió qué significaría fracasar
La última señal es la más fácil de revisar y la que más se salta. Antes de arrancar pregunto una sola cosa: ¿con qué resultado, a los seis meses, decidiríamos apagar esto? Si no hay respuesta, no hay proyecto. Hay una apuesta con presupuesto.
Un criterio de fracaso escrito antes de empezar protege a todos, a mí incluida. Evita la conversación incómoda de la evaluación final, porque la evaluación ya estaba pactada desde el día uno. Y obliga a poner un número donde normalmente hay entusiasmo.
Qué hacer si aparecen tres de las cinco
Si tres de estas señales están presentes, el proyecto no está listo para elegir tecnología. Está listo para un diagnóstico de procesos, que dura semanas y no meses, cuesta una fracción de lo otro y a veces termina en la conclusión más barata posible: que el proceso no necesitaba automatizarse, necesitaba dejar de tener tres dueños y un paso de más.
Es la parte del trabajo que a nadie le gusta pagar porque no se ve. También es la única que evita pagar dos veces. Lo que voy anotando de estos casos lo dejo en notas de campo, y el resumen de cómo trabajo está en la portada de este sitio.