Saca hoy la lista de excepciones de tu operación antes de volver a hablar de automatizar. No me refiero al diagrama del proceso. Me refiero a la libreta, al WhatsApp, a los pendientes que tu equipo resolvió ayer sin registrar en ningún lado.
Hazlo antes de terminar de leer esto: pide los últimos veinte casos que se salieron del camino normal y anota quién los resolvió, en cuánto tiempo y con qué información. Si no puedes juntar veinte, ya tienes el diagnóstico. No te falta tecnología. Te falta ver el trabajo real.
Automatizar algo que no se entiende no lo arregla: lo vuelve más rápido y más difícil de corregir. Y lo que casi nunca se entiende no es el camino feliz. Es la excepción. Yo no apruebo un piloto por cómo trata el caso normal. Lo apruebo por cómo trata el caso que se atora.
1. El camino feliz no es el proceso, es el folleto
Todo manual describe un proceso lineal. Todo piso real opera con interrupciones. Cliente que manda el dato mal, proveedor que llega tarde, autorización que no aparece, sistema que se cae a las seis de la tarde. Eso no es ruido. Eso es el proceso.
Cuando me hablan de inteligencia artificial para negocios, pregunto lo mismo: ¿qué pasa cuando no pasa lo previsto? Si la respuesta es “eso lo ve fulano”, entonces fulano es el proceso. Lo demás es decoración.
Lo escribí en mis Notas de campo y lo repito porque se olvida: el trabajo no vive en el diagrama. Vive en quien desatora. Si esa persona se va de vacaciones, el diagrama no sirve.
2. Pregunta quién desatora y con qué criterio
Hay una pregunta que hago en planta y en oficina y que incomoda siempre: cuando esto se atora, ¿quién decide? No qué dice el procedimiento. Quién decide de verdad, a qué hora, con qué datos.
Normalmente aparecen dos o tres nombres. Son los mismos que contestan el teléfono que nadie más contesta. Esos nombres sostienen la operación y casi nunca aparecen en la presentación del piloto. Error grave.
Lo vi en un negocio de bienestar y estilo de vida que quería automatizar citas y seguimientos. El camino feliz era perfecto: reserva, recordatorio, pago. La excepción era el negocio: clienta que llega tarde, que cambia de tratamiento a mitad de sesión, que pregunta por una contraindicación y necesita que le responda una persona, no una plantilla. Quien resolvía eso era la recepcionista con criterio, no el software. Sin mapear sus decisiones, automatizar era romper la confianza que vendía el servicio.
En una obra con varias instalaciones para obra industrial conviviendo en el mismo pasillo pasa igual. El plano dice una secuencia. El frente dice otra: falta material, se detiene una maniobra por seguridad, entra otro contratista. Quien reordena el día es el sobrestante. Lo entiendes en cuanto miras aquí cómo se cruzan los oficios en una sola jornada y cuántas decisiones se toman fuera de oficina.
Si tu diagnóstico de procesos no nombra a esas personas ni anota sus criterios, no es diagnóstico. Es inventario de buenas intenciones.
3. Diseña la salida antes de diseñar la entrada
Todo proveedor te diseña la entrada: cómo entra el dato, cómo entra el cliente, cómo entra la solicitud. Casi nadie diseña la salida. Qué hace el sistema cuando no sabe qué hacer.
Yo pido tres cosas antes de hablar de modelo, de herramienta o de prompt:
- Lista de excepciones reales. Las últimas veinte, con fecha. No las teóricas. Las que dolieron.
- Dueño de cada excepción. Nombre y apellido. No rol. No “el área”. Persona.
- Tiempo e información para resolver. Cuánto tardó y qué necesitó ver para decidir.
Sin eso, cualquier estrategia de inteligencia artificial es adivinanza. Con eso, a veces descubres que no necesitas IA. Necesitas una regla clara, un teléfono que sí se conteste o un formato que no pida dos veces el mismo dato.
Lo conté en el piloto que funcionó en la demostración: en demo todo entra limpio. En operación todo entra sucio. El piloto muere en la primera semana de excepciones que nadie diseñó.
4. La automatización que sobrevive es la que sabe rendirse
Un buen sistema automático sabe cuándo no debe decidir. Se rinde rápido, avisa bien y entrega el caso masticado a un humano. Un mal sistema insiste. Inventa. Retrasa el aviso. Esconde el error hasta que ya cuesta caro.
Por eso pido que la ruta de escape esté escrita antes que el flujo principal. ¿A dónde va el caso atorado? ¿Con qué contexto llega? ¿Qué puede hacer el humano que el sistema no hizo? Si eso no está definido, el humano recibe basura y le echa la culpa a la herramienta. Y tiene razón.
Soy Margot Duek y paro proyectos por esto. No porque la tecnología falle. Porque nadie quiso mirar las excepciones. Medir el camino feliz es fácil. Sostener el día malo es el trabajo.
Vuelve a tu lista de veinte. Si más de la mitad las resolvió la misma persona de memoria, no tienes un proceso automatizable. Tienes una dependencia. Documenta su criterio primero. Automatiza después. O no automatices.