No todo proceso repetitivo merece automatizarse, y no toda automatización requiere desarrollo a la medida. Esta guía ofrece un criterio de selección basado en retorno real.
El criterio de selección
La pregunta correcta no es «¿puede automatizarse este proceso?» — casi siempre puede — sino «¿debe automatizarse?». Cuatro condiciones determinan si un proceso es buen candidato.
Frecuencia y volumen suficientes. Una tarea que se ejecuta dos veces al año no justifica el costo de construir y mantener una automatización, por tediosa que sea.
Reglas estables y explícitas. Si la decisión depende de criterio profesional que varía con el contexto, la automatización producirá errores sistemáticos en lugar de errores ocasionales.
Entradas estructuradas. Datos que llegan en formato consistente son automatizables; datos que llegan como texto libre en correos requieren una capa de interpretación que cambia el alcance del proyecto.
Costo del error acotado. Un proceso donde un error automatizado se propaga sin detección requiere controles adicionales que deben contemplarse en el diseño.
Tres enfoques con costos muy distintos
El error más costoso que observamos es adoptar RPA sobre interfaz gráfica cuando existía una API disponible. La automatización que simula la interacción de un usuario con una pantalla se rompe cada vez que esa pantalla cambia, y el mantenimiento termina consumiendo el ahorro que justificaba el proyecto.
Cómo estimar el retorno
El cálculo honesto incorpora tres elementos que con frecuencia se omiten: el costo de construcción, el costo de mantenimiento anual (que no es cero, y suele estimarse entre el quince y el veinticinco por ciento del costo inicial), y el costo de los errores que el proceso manual produce hoy y que rara vez está cuantificado.
Ese tercer elemento suele ser el más significativo. Un proceso manual de conciliación que consume ocho horas semanales y produce errores que se detectan un mes después tiene un costo real muy superior a las horas invertidas.
Un ejemplo concreto
La auditoría de seguridad de una red de sitios institucionales es un caso donde las cuatro condiciones se cumplen con claridad: alta frecuencia (debe ser diaria para ser útil), reglas explícitas (versión instalada frente a versión vulnerable conocida), entradas estructuradas (respuestas de sistema, no interpretación) y costo del error alto pero acotado.
En nuestra implementación para una red de catorce sitios institucionales, una rutina diaria de verificación redujo el tiempo de detección de vulnerabilidades de quince días a cuatro horas, eliminando cerca del ochenta por ciento del trabajo manual de supervisión que antes recaía sobre el equipo de tecnología.