25 de agosto de 2026 · Pedro Aldea
Antes de automatizar un proceso, mide dónde se atasca
Un filtro práctico para elegir el primer flujo que merece automatización, separar reglas de criterio y saber quién lo operará después.
El primer proceso que conviene automatizar no es el que más ruido hace. Es el que puedes describir, medir y entregar al equipo sin esconder sus excepciones. Antes de hablar de modelos, responde tres preguntas: qué decisión se repite, qué entrada la dispara y qué error no puedes permitirte.
Este checklist sirve para decidirlo antes de construir nada. No es una auditoría completa ni una promesa de ROI. Es un filtro para que una conversación de IA termine en un flujo medible, mantenible y útil para el equipo.
1. ¿Qué decisión se repite y quién la toma hoy?
Escribe la decisión en una frase, con sujeto y verbo: “el equipo de compras decide si esta factura necesita revisión”. Si no puedes nombrar la decisión, todavía tienes un problema amplio, no un caso de uso.
Anota también quién la toma, qué información consulta y qué ocurre después. Una IA no debe sustituir una decisión difusa; debe ayudar con una decisión que ya existe.
2. ¿Qué entrada concreta dispara el flujo?
Elige una entrada observable: una factura, un albarán, una fila del ERP, una licitación o una petición interna. Guarda una muestra representativa y separa los casos normales de las excepciones.
Si cada persona recibe una entrada distinta o la interpreta con reglas diferentes, el primer trabajo no es añadir IA. Es definir qué cuenta como entrada y qué campos importan.
3. ¿Qué parte es regla y qué parte necesita criterio?
Marca cada paso como regla, búsqueda o criterio. Las reglas deberían automatizarse sin modelo. La búsqueda puede resolverse con datos y enlaces. La IA solo merece entrar donde haya variación real y el equipo pueda revisar el resultado.
Esta separación evita llamar “agente” a un script, un chatbot o una automatización determinista. También deja claro dónde debe escalar el sistema cuando no está seguro.
4. ¿Qué significa acertar y qué error es inaceptable?
Define una métrica sencilla antes del piloto: tiempo por caso, porcentaje de casos que llegan completos, número de revisiones o tiempo hasta la decisión. Define también el límite: qué errores obligan a parar, quién los revisa y cómo se corrige el dato.
Sin esta pareja —resultado esperado y error intolerable— solo puedes decir que la demo “parece funcionar”.
5. ¿Dónde queda la prueba de cada decisión?
Cada salida debe guardar la entrada, la decisión, la evidencia consultada, la confianza y la persona que intervino. La trazabilidad no es un extra de compliance: es la forma de mejorar el flujo sin discutir opiniones.
En Zero Ops usamos sistemas en producción y dejamos la capacidad dentro del equipo. El proof point operativo vigente es de 5 sistemas en producción, no una colección de demos. El número no sustituye al contexto del flujo, pero sí fija el estándar: producción, evidencia y transferencia.
6. ¿Qué puede mantener el equipo cuando nos vamos?
Lista las tareas de mantenimiento: corregir una regla, revisar una excepción, actualizar una fuente y medir el resultado. Si todas dependen del proveedor, no has activado una capacidad; has comprado dependencia.
El primer flujo correcto es el que el equipo puede entender, revisar y operar con una guía clara.
7. ¿Qué eliminarías antes de automatizar?
Antes de construir, elimina pasos que nadie puede defender, estandariza los datos y simplifica los handoffs. Solo después automatiza lo determinista y reserva la IA para el juicio que queda.
Ese orden complementa el método Zero Friction y evita repetir el problema descrito en por qué fallan los proyectos de IA, sin convertir este checklist en otra explicación general del método.
La decisión al final de la hoja
Al terminar deberías poder escribir una sola línea:
“Vamos a mejorar este flujo, con esta entrada, esta decisión, esta métrica, este límite y este dueño.”
Si no puedes escribirla, la siguiente acción no es construir. Es observar el proceso una semana y volver a medir.