RPA significa Robotic Process Automation: automatización robótica de procesos. El nombre confunde porque no hay ningún robot físico. Lo que hay es un programa que usa tus aplicaciones igual que las usaría una persona: abre el sistema, se autentica, navega a la pantalla correcta, lee lo que hay, aplica reglas y escribe el resultado.
Esa es toda la idea. Su valor no está en la sofisticación técnica, sino en que funciona sobre sistemas que no fueron diseñados para integrarse — que es la situación real de casi cualquier empresa con más de diez años de operación.
RPA frente a integración
Si dos sistemas tienen API y alguien puede desarrollar la integración, la integración suele ser la mejor opción: es más rápida, más estable y no depende de la interfaz. El problema es que esa condición se cumple pocas veces. El sistema legacy no tiene API, el proveedor cobra por el módulo de integración, el portal del cliente no expone nada, o el área de TI tiene la iniciativa en el backlog para el año siguiente.
RPA opera en ese espacio. No compite con la integración: la sustituye mientras no existe, y convive con ella cuando sí existe. Un mismo proceso puede llamar una API para una parte y operar una pantalla para la otra.
Qué hace bien un robot de software
- Procesos con reglas claras y decisiones acotadas.
- Volumen alto de casos parecidos entre sí.
- Tareas que cruzan varios sistemas sin conexión entre ellos.
- Trabajo que se ejecuta en ventanas fijas: cierre, corte diario, nómina.
- Actividades donde la consistencia importa más que el criterio.
Dónde RPA no es la respuesta
Hay casos donde automatizar es la solución equivocada, y decirlo a tiempo ahorra un proyecto entero:
- El proceso está mal diseñado. Automatizar un proceso roto solo lo rompe más rápido.
- El volumen es bajo y la variabilidad alta. Cinco casos al mes, todos distintos, no justifican el esfuerzo.
- La interfaz cambia constantemente. Un robot que se rompe cada semana genera más trabajo del que quita.
- La decisión es genuinamente humana. Si cada caso requiere criterio, el robot puede preparar la información, no resolverla.
Atendido y desatendido
Un proceso desatendido corre solo, por horario o por disparador, sin nadie enfrente. Es el modelo natural para lotes nocturnos y cierres. Un proceso atendido lo lanza una persona desde su equipo cuando lo necesita, normalmente para acelerar una tarea puntual dentro de su propio trabajo.
La mayoría del valor está en lo desatendido, porque es donde el proceso deja de depender de que alguien se acuerde.
Qué hace falta además del robot
Un robot suelto es un script. Lo que convierte RPA en una capacidad de la empresa es la infraestructura alrededor: un orquestador que decide qué corre y cuándo, manejo de excepciones para el caso raro, administración de credenciales, separación de entornos y bitácora de cada ejecución. Sin eso, el primer proceso funciona y el décimo se vuelve inmanejable.
La pregunta útil no es «¿se puede automatizar?». Casi siempre se puede. La pregunta es «¿conviene, y en qué orden?».