Cómo integrar RPA con tu ERP: SAP, Finnegans y sistemas legacy

El robot de creación de materiales que estamos por cerrar para una empresa de arriendo y gestión de flota de vehículos entra a SAP dos veces al día, a las 12:00 y a las 15:30. Cada corrida hace tres cosas distintas: lee un correo con el pedido, arma una planilla maestra aplicando las reglas de jerarquía del repuesto, y recién ahí genera los archivos que se cargan en SAP por lote. En el medio hay una pausa deliberada: el proceso se detiene y espera que un analista revise la planilla antes de que la carga llegue a producción.

Ese robot no "usa RPA para integrarse con SAP" como si fuera una sola técnica. Combina tres formas distintas de hablar con el ERP en el mismo flujo. Ese es el tema real detrás de la pregunta "¿cómo integro RPA con mi ERP?": no hay una respuesta única, hay que elegir el camino correcto para cada tramo del proceso, y esa elección cambia según qué sistema tengas del otro lado.

Los tres caminos para que un robot hable con tu ERP

El más conocido es la interfaz gráfica: el robot abre el ERP con un usuario propio y hace clic, escribe y navega igual que una persona. Es el camino universal, funciona con cualquier sistema que tenga pantalla, y es el único disponible cuando no existe otra puerta.

El segundo es la llamada directa a una función del sistema, sin pasar por ninguna pantalla. En SAP esto tiene nombre y forma: BAPI, RFC, IDoc. El robot le pide un dato o le entrega uno a través de esa función, y el ERP responde sin que nadie vea una ventana abrirse. Es más rápido y no depende de que el layout de una pantalla siga igual el mes que viene.

El tercero es la carga masiva por archivo, que en SAP se llama LSMW y en otros sistemas tiene su propio nombre. El robot no interactúa con nada en vivo: prepara un archivo con el formato exacto que el ERP espera, se lo entrega a una transacción de carga, y esa transacción hace el trabajo de escribir cientos o miles de registros de una sola vez. Es la opción cuando el volumen es alto y las reglas están cerradas.

El bot de materiales que abre este artículo usa los tres: interfaz para leer el correo y armar la planilla, y carga masiva para el volumen final. En otro proyecto de ventas que tenemos en producción, el robot navega la pantalla para armar el documento comercial pero trae los datos del cliente con una BAPI hecha a medida, porque tipearlos a mano introducía errores de dígito que la BAPI no comete. Elegir uno solo de los tres caminos porque es "el estándar" suele dejar plata sobre la mesa.

SAP tiene puertas que otros ERP no tienen

Acá hay algo que conviene decir sin vueltas: SAP es, de los ERP grandes, el que más caminos alternativos a la interfaz ofrece. Años de BAPIs documentadas, una comunidad enorme y clientes dispuestos a pagar por esa capa de integración hicieron que ese ecosistema exista.

Finnegans, como la mayoría de los ERP pensados para el mercado local o de tamaño medio, no llega con ese mismo nivel de API pública. Ahí el camino casi siempre es la interfaz: el robot abre el sistema web o de escritorio y opera como lo haría un usuario, porque no hay una BAPI equivalente esperando del otro lado. Eso lo define el sistema, no el robot, y conviene saberlo antes de prometerle al cliente una integración "por API" que ese ERP simplemente no ofrece.

También nos tocó el otro extremo: un sistema central que corre sobre mainframe, sin interfaz web ni pantalla moderna, solo una terminal verde y negra que habla el protocolo TN3270. Ahí el robot tiene un solo camino disponible: conectarse directo por ese mismo protocolo, carácter por carácter, porque no existe ni una API que llamar ni un botón que hacer clic en un navegador. Ese proyecto todavía está en desarrollo, así que no doy más detalle del cliente, pero sirve para el punto: antes de diseñar la integración hay que mirar qué sistema tienes en frente, y no asumir que todos los ERP se parecen a SAP.

Elegir el camino correcto es una decisión de plata, no de preferencia técnica

Una integración por BAPI o API, cuando existe, casi siempre gana en velocidad y en robustez frente a cambios de pantalla. Pero construirla toma tiempo de desarrollo especializado que no todos los proyectos justifican, y en varios ERP medianos directamente no está disponible. La interfaz gráfica se construye más rápido y no depende de que exista documentación técnica del sistema, pero es más frágil ante una actualización que mueva un campo de lugar.

La carga masiva es la más eficiente quirúrgicamente para volumen, pero solo sirve para el tramo del proceso donde los datos ya están validados y listos. Nadie carga por LSMW un dato que todavía puede tener un error, porque un objeto de carga masiva que falla a mitad de camino con 2.000 registros es un problema mucho más grande que uno que falla con un solo registro en pantalla.

La decisión correcta casi nunca es "cuál de los tres es mejor" sino qué parte del proceso necesita cada uno. Sobre cómo se documenta esa clase de decisión antes de que el desarrollo arranque, ya escribimos en cómo documentar un proceso antes de automatizarlo.

Lo que rompe una integración con el ERP

El gobierno del acceso tumba más integraciones que un error de código. Usar una cuenta compartida o genérica del ERP para el robot suele frenar el proyecto en la revisión de seguridad, sobre todo en empresas con auditoría seria. Lo que funciona es un usuario dedicado al robot con un rol acotado a las pocas transacciones o funciones que de verdad usa.

El segundo motivo es el timing en las cargas masivas: un objeto LSMW mal configurado corta la carga si un parámetro (por ejemplo, el número máximo de registros esperados) queda más chico que el volumen real. Es un error que no avisa con una alarma, avisa con la mitad de los datos cargados y nadie enterándose hasta el día siguiente.

El tercero es asumir que una BAPI resuelve todo. Una BAPI valida los datos que le llegan según sus propias reglas, y si el dato de origen está mal (un cliente que no existe en la tabla de equivalencias, un código de material sin mapear) la BAPI simplemente rechaza la llamada. El robot necesita un camino para esos rechazos, no solo para el camino feliz.

Cuándo no conviene meter el robot en el ERP todavía

Si tu empresa tiene planificado un cambio de ERP en los próximos meses, construir una integración profunda con el sistema actual es, la mayoría de las veces, tiempo que se va a tirar. Conviene esperar al sistema nuevo o, si el proceso es urgente, resolverlo con la interfaz gráfica más simple posible, sabiendo que es una solución puente.

Tampoco tiene sentido invertir en una integración por API para un proceso que se ejecuta pocas veces al mes. El desarrollo de una BAPI a medida se paga con volumen; si el volumen no está, la interfaz gráfica, aunque sea más lenta por ejecución, sale más barata en total.

Preguntas frecuentes

¿Tienes un proceso que hoy vive atado a tu ERP y no sabes por dónde conviene automatizarlo? Escríbenos y lo evaluamos juntos. Si todavía estás decidiendo qué automatizar primero, te sirve qué procesos de SAP se pueden automatizar con RPA y RPA vs desarrollo a medida: cuándo conviene cada uno.