Cuándo no conviene automatizar un proceso

Automatizar una tarea no decide si esa tarea tiene sentido. Sólo cambia quién la hace. Antes de invertir en un sistema, conviene observar un caso real de principio a fin.

No hace falta empezar por una auditoría enorme. Basta con sentarse junto a la persona que hace el trabajo y seguir un pedido, una factura o una solicitud completa. Anota dónde nace el dato, dónde se vuelve a escribir y quién resuelve lo que llega incompleto.

Primero pregunta si se puede dejar de hacer

Ese informe que alguien prepara cada lunes puede no tener lector. Una copia de datos puede existir porque una persona la pidió hace años y nadie la retiró. Si el resultado no sirve para decidir ni para cumplir una obligación identificada, revisa la necesidad antes de automatizarlo.

Eliminar un paso inútil suele ser mejor que hacerlo más rápido. La decisión tiene que tomarla quien conoce la operación, no el proveedor por su cuenta.

Si no hay una regla, todavía no hay proceso

«Depende» no es un error. Puede significar que falta escribir una regla o que el trabajo exige criterio profesional.

Recoge tres casos habituales y uno que salió mal. Pregunta qué los diferencia y quién tiene autoridad para decidir. Si dos personas resuelven el mismo caso de forma distinta, esa discrepancia no desaparece al conectarlas con software.

Primero se acuerda cómo debe hacerse. Después se automatiza la parte estable y se deja una salida explícita para las excepciones.

No todo lo que se repite compensa

Una tarea de pocos minutos que ocurre dos veces al año puede no justificar desarrollar y mantener una integración. Otra aparentemente pequeña puede repetirse tantas veces que interrumpa el trabajo de todo un equipo.

Compara el tiempo que consume hoy con el coste completo del cambio: preparación, pruebas, licencias, mantenimiento y revisión de errores. No uses sólo el tiempo de la ejecución ideal. Incluye lo que sucede cuando falta un dato o cambia un programa.

Sin responsable, el error se queda esperando

Toda automatización necesita una persona que reciba los avisos y sepa qué hacer. Si un pedido no entra, ¿quién lo ve? ¿Puede reintentarlo sin duplicarlo? ¿Cómo sabe que se ha resuelto?

No se trata de vigilar a la plantilla. Se trata de que un fallo del sistema no se convierta en una promesa incumplida al cliente.

Una decisión pequeña y comprobable

Antes de encender nada, deja por escrito:

• La tarea concreta y el resultado esperado.
• Qué entradas se aceptan y cuáles necesitan revisión.
• La persona responsable de las excepciones.
• Qué se medirá antes y después, con el mismo criterio.
• Cómo se vuelve al procedimiento anterior si la prueba falla.

Si esto todavía no puede describirse, el siguiente trabajo no es programar. Es ordenar el proceso.

El diagnóstico inicial sirve para decidir precisamente eso: qué tocar primero y qué conviene dejar quieto.