RPA vs desarrollo a medida: cuándo conviene cada uno

Hace un par de meses nos sentamos con el gerente de una clínica oncológica que estaba evaluando automatizar el pago de honorarios a profesionales. Su primera pregunta no fue "cuánto cuesta el proyecto". Fue "¿por qué no conectamos directo a la API de Softland en vez de armar un robot?". Buena pregunta. La respuesta no fue "porque RPA es mejor". Fue que esa conexión API directa todavía no estaba confirmada como viable: dependía de que el proveedor Softland habilitara el acceso, algo que en ese momento seguía en veremos.

Esa conversación se repite seguido, con roles invertidos. Hay clientes que llegan convencidos de que necesitan un desarrollo a medida y terminan con un robot corriendo en tres semanas. Y hay clientes que nos piden RPA y terminamos recomendando que lo construyan con su propio equipo de desarrollo.

Qué es cada cosa, sin vueltas

RPA opera sobre la interfaz que ya existe: abre el sistema, hace clic donde haría clic una persona, lee lo que hay en pantalla. No necesita que el sistema tenga una API, y por eso funciona incluso sobre software viejo, sin documentación, o que el proveedor dejó de mantener hace años.

El desarrollo a medida se conecta directamente a la base de datos o a una API. Es más rápido en ejecución, más estable a largo plazo y no depende de que la pantalla no cambie de un día para el otro. El costo de esa estabilidad es que hay que construirlo desde cero, y alguien tiene que mantenerlo con conocimiento de código, no de configuración.

Ninguna de las dos es "la buena". Son herramientas con supuestos distintos.

Cuándo conviene RPA

Tres condiciones suelen inclinar la balanza hacia RPA:

• El sistema fuente no tiene API, o la tiene pero no cubre la funcionalidad puntual que necesitas automatizar. Pasa más seguido de lo que parece, sobre todo en SAP con transacciones viejas o módulos poco usados.
• El proceso necesita salir funcionando en semanas, no en meses, porque hay una persona a punto de irse o un pico estacional encima.
• El equipo que va a operar el robot después no tiene perfil de desarrollador. Configurar un flujo en Rocketbot lo puede hacer alguien de operaciones con una capacitación de un par de días. Modificar código Python en producción, no.

Hay un cuarto punto que pesa más de lo que parece: RPA es reversible. Si el proceso cambia el mes que viene, ajustas el flujo. Si un desarrollo a medida queda mal diseñado desde el inicio, la reescritura sale casi tan cara como el proyecto original.

Cuándo conviene el desarrollo a medida

Acá es donde muchos partners de RPA se quedan callados, porque no les conviene decirlo: si tienes volumen alto (decenas de miles de transacciones diarias) y el sistema sí tiene una API estable, un desarrollo a medida va a ser más rápido en ejecución y más barato de correr a largo plazo. Usar RPA simulando clics de interfaz para ese volumen es poner un martillo donde entra un tornillo.

También conviene el desarrollo propio cuando ya existe un equipo interno con capacidad ociosa y conocimiento del dominio. Pagarle a un tercero para automatizar algo que tu propio equipo puede construir con su tiempo disponible no tiene sentido económico, aunque tarde un poco más en salir.

Y conviene cuando el proceso es el núcleo del negocio, no una tarea de soporte. Si la lógica que estás automatizando es la que te diferencia de la competencia, probablemente no quieras que viva en un flujo que cualquier consultor externo puede abrir y replicar. Ese tipo de lógica suele merecer código propio, versionado, con pruebas automatizadas detrás.

Cómo se combinan RPA y desarrollo a medida en la práctica

En la práctica, la mayoría de los proyectos grandes que hacemos no son puramente uno u otro. Es el patrón que más se repite en los proyectos de SAP que armamos (puedes ver el detalle en qué procesos de SAP se pueden automatizar con RPA): el robot extrae datos de un sistema legado sin API, y la validación y el cálculo de reglas de negocio complejas corre en un script Python embebido en el mismo flujo, que el robot solo invoca. RPA para la parte que necesita simular interfaz humana, código a medida para la parte que necesita precisión y velocidad.

La pregunta correcta casi nunca es "¿RPA o desarrollo?". Es "¿qué parte de este proceso necesita cada cosa?".

Lo que de verdad determina el mantenimiento

El mantenimiento de un robot no depende tanto de la herramienta como de quién lo cuida. Un robot bien construido con monitoreo activo se mantiene con horas puntuales cuando el sistema fuente cambia de pantalla. Un robot sin dueño interno, entregado y olvidado, se rompe en silencio a los pocos meses, y nadie se entera hasta que alguien pregunta por qué el reporte de siempre dejó de llegar.

Con el desarrollo a medida pasa lo mismo, al revés. Si el desarrollador que lo construyó se va de la empresa y no dejó documentación, ese código se vuelve una caja negra que nadie quiere tocar. Ahí no importa si era RPA o Python. El problema es de gobierno del proyecto, no de la tecnología elegida.

Antes de decidir

Antes de asumir que ya sabes cuál necesitas, conviene confirmar tres cosas: si el sistema fuente tiene API real (no "en teoría la tiene", sino si cubre exactamente lo que necesitas tocar), cuál es el volumen diario del proceso, y quién en tu equipo va a quedar a cargo del mantenimiento el día después de la entrega.

Esas tres respuestas suelen decidir más que cualquier comparación técnica.

Preguntas frecuentes

Danilo Toro, fundador de Robotipy, ayuda a empresas medianas y grandes en Chile y Argentina a decidir qué automatizar y con qué herramienta, sin vender de más.