En los últimos dos años he entrado en bastantes empresas con el encargo de automatizar algo. En cuatro de ellas la recomendación final fue no hacerlo, y en tres se aceptó. Esas conversaciones tienen un patrón, y contarlo ahorra dinero a más gente que cualquier tutorial.

No es una entrada contra la IA. Es una entrada sobre el orden: primero el proceso, después la herramienta. Cuando se invierte, la herramienta amplifica el desorden.

Caso 1: el criterio que vivía en una persona

Una distribuidora quería automatizar la aprobación de pedidos con condiciones especiales. Lo hacía una persona con dieciocho años en la casa, y lo hacía bien. El problema apareció en la primera sesión: cuando le pedí que explicara cómo decidía, la respuesta fue «depende del cliente».

Estuvimos dos sesiones sacando reglas. Salieron once, y en cuanto las revisamos con casos reales del último trimestre, siete tenían excepciones que dependían de conversaciones que no estaban escritas en ningún sitio. No es que el criterio fuera irracional: es que era relacional. Un modelo puede imitar la forma de esas decisiones, pero no tiene acceso a lo que las sostiene.

Lo que recomendé: escribir el criterio durante seis meses, cada vez que se decidiera algo, en dos líneas. No para automatizar, sino porque esa persona se jubila en tres años y ahí sí había un riesgo real. Automatizar, más tarde y sólo la parte que resultara estable.

«Si quien hace la tarea no sabe explicar cómo decide, no tienes un proyecto de automatización: tienes un proyecto de documentación.»

Caso 2: el volumen no daba

Un estudio de arquitectura quería un agente para redactar las memorias de calidades. Es una tarea repetitiva, con estructura clara y bastante mecánica. Cumplía todo, menos lo importante: hacían nueve al año.

Con nueve al año, el ahorro potencial eran unas doce horas anuales. El montaje, entre veinte y treinta, más el mantenimiento y el coste de que nadie recordara cómo funcionaba de una vez a la siguiente. Lo que hicimos fue mucho más aburrido y mucho mejor: una plantilla con los bloques fijos ya escritos y una lista de comprobación. Dos horas de trabajo, seis horas ahorradas al año, cero mantenimiento.

SEÑAL

UMBRAL QUE USO

Repeticiones

Al menos veinte al mes para que se note

Tiempo por repetición

Diez minutos o más, o interrumpe otra cosa

Ahorro anual estimado

Cinco veces el coste de mantenimiento

Personas afectadas

Dos o más; si es una sola, empieza por la plantilla

Caso 3: el error salía directo al cliente

Una clínica quería que un agente respondiera consultas de pacientes sobre tratamientos y precios. Aquí el problema no era técnico: era que un error no se revierte. Una respuesta equivocada sobre un tratamiento es un problema sanitario y legal, y llega al paciente antes de que nadie la vea.

Se puede montar con revisión humana previa, y así lo planteé. Al calcular el tiempo de esa revisión salió que revisar cada respuesta costaba casi lo mismo que escribirla, con el añadido de que revisar textos ajenos plausibles cansa más y detecta peor. Lo que sí montamos: un buscador interno para que el personal encontrara la información correcta en segundos. La persona sigue respondiendo; sólo dejó de buscar.

PREGUNTA QUE FILTRA >Si esta respuesta sale mal y llega al cliente sin que nadie la lea, ¿qué pasa? Si la respuesta incluye la palabra «reclamación», «sanción» o «alta médica», el agente no va delante: va detrás de una persona.

Caso 4: el proceso estaba roto antes

Una empresa de servicios quería automatizar el seguimiento de presupuestos porque se les caían oportunidades. Al mirarlo, el problema no era el seguimiento: era que los presupuestos tardaban once días en salir. Automatizar el recordatorio habría servido para perseguir con más eficiencia unas oportunidades ya frías.

Trabajamos sobre los once días. Resultó que ocho eran esperar la validación de una persona que recibía la petición por correo entre cuarenta mensajes diarios. Un formulario y un aviso diario agrupado bajaron el plazo a tres días. Después, el seguimiento automático sí tenía sentido, y se montó cuatro meses más tarde.

«Automatizar un proceso roto es pagar por hacer lo mismo mal, sólo que más rápido y con menos testigos.»

Cómo detectarlo antes de firmar

Cinco preguntas. Si dos se responden mal, el proyecto no está listo; no significa que no se haga nunca, significa que hay trabajo previo.

  1. ¿Quien hace la tarea puede explicar cómo decide, con reglas y excepciones escritas?
  2. ¿Ocurre al menos veinte veces al mes con la misma forma?
  3. ¿Un error se detecta y se corrige antes de llegar al cliente?
  4. ¿El proceso funciona hoy razonablemente bien cuando lo hace una persona con tiempo?
  5. ¿Hay alguien con nombre y apellido que va a mantenerlo dentro de seis meses?

La quinta es la que más proyectos ha frenado en mis presupuestos, y la que menos aparece en las propuestas ajenas.