RPA, low-code o código a medida: elegir con un proceso concreto

Quieres pasar pedidos de un programa a otro. Antes de comparar herramientas, yo miraría cómo deja salir y entrar los datos cada aplicación. Una API documentada, una exportación de archivos y una pantalla son puntos de partida distintos.

RPA, low-code y desarrollo a medida tampoco son tres cajas separadas. Una plataforma visual puede llamar a una API, ejecutar código y utilizar un robot de escritorio en el mismo proceso. La decisión consiste en escoger las piezas que puedas operar y mantener.

Tres soluciones para la misma exportación

Uso un escenario hipotético: cada semana necesitas extraer un listado de pedidos y añadirlo a un registro interno. No se emiten facturas ni se confirma stock en este paso.

Si el programa solo ofrece una pantalla y un botón de exportación, un robot RPA podría abrirlo, seleccionar el periodo y descargar el archivo. No lo descartaría por principio. La documentación de Microsoft explica que los flujos de escritorio pueden identificar elementos con selectores, sin depender de coordenadas absolutas. También contempla selectores alternativos y basados en texto. Mover un botón no implica necesariamente que todo robot falle.

Aun así, probaría cambios de sesión, ventanas inesperadas y actualizaciones de la aplicación. Si no encuentra el archivo correcto, debe detenerse. Para una exportación semanal que una persona revisa antes de importar, puede ser una opción razonable.

Si existe un conector compatible, una herramienta low-code puede recoger los pedidos y escribirlos en el registro. Resulta útil cuando su equipo puede entender el flujo y ajustar reglas sencillas. Revisaría si el conector admite todos los campos, cómo pagina los resultados y qué sucede al alcanzar límites de uso. El coste depende del plan concreto; no asumiría que siempre se cobra por usuario ni que siempre aumenta igual.

Si hay una API pero el proceso exige reglas que el conector no cubre, el código a medida permite expresarlas directamente. A cambio, alguien debe documentarlo, probarlo y actualizarlo. La API también puede cambiar, limitar peticiones o retirarse: escribir código propio no elimina las dependencias.

Comparar el mantenimiento, además de la puesta en marcha

Pediría para las tres opciones el mismo alcance: volumen de pedidos, campos, frecuencia, tratamiento de duplicados y respuesta a fallos. Sin eso, un presupuesto para copiar datos y otro para conciliarlos parecen comparables aunque resuelvan trabajos distintos.

Opción	Qué verificaría en la prueba	Trabajo posterior que presupuestaría
RPA sobre pantalla	Exportación correcta con distintas sesiones	Actualizaciones de interfaz y entorno de escritorio
Conector low-code	Campos, límites y recuperación de errores	Cambios de conector, plan y reglas
Código con API	Respuestas incompletas, duplicados y reintentos	Versiones de API, pruebas y soporte

Para un proceso crítico, exigiría controles de datos, registros, recuperación y una persona responsable cualquiera que sea la herramienta. El nombre del método no acredita esos controles.

También pediría cómo exportar el flujo o el código, dónde queda la documentación y qué necesita otra persona para mantenerlo. La posibilidad de cambiar de proveedor se comprueba con esa entrega, no con una promesa de independencia.

Mi elección partiría del acceso disponible y del coste total de mantener un resultado correcto. Para este listado semanal, una solución sencilla revisada puede bastar. Si después debe confirmar pedidos sin intervención, habrá que volver a evaluar el riesgo y el alcance.