En logística, ningún sistema funciona aislado. Un solo envío pasa por el ERP donde se crea el pedido, el TMS que planifica el transporte, el WMS que gobierna el almacén, el portal del transportista y el escáner en la mano de un operario. Si esos sistemas no hablan entre sí automáticamente, alguien reteclea datos a mano, y cada uno de esos puntos de contacto es un retraso, un error y un coste. Para un director de TI, la integración ha dejado de ser un proyecto secundario para convertirse en la base de la operación.
Por nuestra experiencia, lo difícil no es conectar dos sistemas para una demo, sino mantener vivas decenas de esas conexiones bajo carga, ante fallos y con una lista de socios que cambia constantemente. Aquí no tenemos un caso de éxito logístico que agitar, pero sí tenemos ingenieros que llevan años construyendo integraciones de sistemas - en proyectos industriales y embebidos, y allí donde conectamos sistemas de clase empresarial con proveedores externos. Esa competencia la traemos a la logística.
¿Por qué la logística es una red de integraciones y no un único sistema?
Porque en logística el valor se crea en las costuras. La mercancía se mueve entre un expedidor, un transportista, un almacén y un destinatario, y en paralelo tiene que moverse también su rastro digital: estado, documentos, posición, prueba de entrega - y cada participante usa su propio sistema, su formato de datos y su ritmo de trabajo.
Un único sistema gigante no resuelve eso. En su lugar, construyes una capa de integración que traduce mensajes entre mundos, mantiene los eventos en orden y se asegura de que un estado del portal de un transportista llegue al TMS, y de ahí al ERP y al cliente. Esa capa decide si una empresa ve su operación en tiempo real o se entera de los problemas demasiado tarde.
¿Qué es el EDI y cómo organizar las integraciones con los socios?
El EDI sigue siendo la forma más extendida de intercambiar documentos estructurados entre socios logísticos: pedidos, avisos de expedición, confirmaciones de entrega, facturas. El detalle es que «EDI» no es un estándar, sino una familia de estándares y variantes que hay que conciliar.
En la práctica, la integración EDI se reduce para nosotros a un puñado de tareas recurrentes:
- mapeo de formatos - traducir EDIFACT, ANSI X12 o ficheros específicos del sector al modelo de datos del cliente y de vuelta,
- transporte de mensajes - gestionar los canales AS2, SFTP o VAN que los socios usan realmente para enviar ficheros,
- validación y gestión de errores - capturar mensajes incompletos o no conformes antes de que lleguen al fondo del sistema,
- alta de nuevos socios - añadir otra contraparte rápido, sin reescribir toda la lógica desde cero.
Los mapeos tienen que seguir siendo fáciles de mantener, porque los socios se multiplican y sus formatos difieren en detalles pequeños pero dolorosos.
¿Cómo conectar ERP y TMS para que planificación y facturación cuadren?
El ERP y el TMS son los dos corazones de una empresa logística. En el ERP viven los pedidos, las contrapartes y las liquidaciones, mientras el TMS planifica rutas, asigna transportistas y sigue la ejecución. Si esos dos no están sincronizados, el planificador trabaja con datos distintos que contabilidad, y el cliente recibe una factura que no cuadra con lo que le llegó.
Para nosotros, la integración TMS/ERP significa diseñar un flujo coherente de eventos: un pedido del ERP alimenta la planificación en el TMS, y el trabajo realizado, sus costes y sus confirmaciones vuelven al ERP para liquidarlo. Mantenemos una única fuente de verdad por objeto, para que una dirección, un peso o un número de pedido no lleven vida propia en tres sitios. Normalmente eso significa una capa intermedia ligera en lugar de un enlace punto a punto rígido, porque así cambiar un sistema no derriba toda la integración.
¿Cómo aprovechar las APIs de transportistas y los marketplaces logísticos?
Hoy la mayoría de los transportistas y plataformas exponen APIs de transportista modernas y no solo EDI. Eso abre opciones, pero multiplica las conexiones que hay que mantener. A través de estas interfaces solemos montar:
- tarificación y contratación de transporte en tiempo real con varios transportistas a la vez,
- generación de etiquetas y documentos de transporte sin entrar a mano en los portales,
- seguimiento y trazabilidad de envíos mediante webhooks y consulta de estados,
- marketplaces y bolsas de carga, donde la oferta y la demanda de transporte se encuentran de forma dinámica.
El reto aquí no es una API concreta, sino su diversidad - distintos límites de peticiones, distinta autenticación, el mismo estado significando cosas diferentes. Por eso diseñamos un modelo común de transportista y enchufamos a él las nuevas integraciones, en lugar de escribir cada una desde cero.
¿Cómo conectar dispositivos, escáneres y sensores con los sistemas?
La integración no se detiene en los sistemas de TI, porque la logística ocurre en el mundo físico. Los escáneres de códigos de barras, los terminales móviles, las impresoras de etiquetas, las básculas, los arcos RFID y los sensores a bordo generan un flujo de eventos que tiene que llegar al WMS y al TMS en el momento adecuado.
Aquí es donde nuestra experiencia embebida e industrial rinde, porque la integración de dispositivos juega con otras reglas que la de aplicaciones: redes inestables en la nave, protocolos específicos del hardware y el hecho de que un dispositivo no va a esperar al servidor. Construimos una capa que recoge esos eventos localmente, los almacena en búfer cuando cae la conectividad y los reenvía a los sistemas centrales cuando vuelve el enlace.
¿Cómo hacer fiables las integraciones: idempotencia, reintentos, colas?
Esta es la diferencia entre una integración que funciona en una demo y otra en la que puedes confiar en producción. En logística, los mensajes se pierden, las redes se caen y el mismo estado puede llegar dos veces - una integración sin preparar muestra entonces envíos duplicados o pierde pruebas de entrega. Por eso las diseñamos en torno a unos cuantos principios de resiliencia:
- idempotencia - el mismo mensaje recibido dos veces produce un efecto, no dos,
- colas y brokers - los eventos pasan por una cola que suaviza el tráfico y no pierde mensajes en un pico de carga,
- reintentos con back-off - una llamada fallida se reintenta en intervalos crecientes, no se machaca una vez por segundo,
- una dead-letter queue - lo que no se puede procesar aterriza en un sitio aparte para analizarlo en lugar de desaparecer,
- monitorización y alertas - el equipo ve que algo está atascado antes de que llame el cliente.
¿Qué competencias aportamos a las integraciones logísticas?
Para las integraciones damos forma al equipo según la arquitectura concreta, no «por si acaso». En proyectos así solemos cubrir:
- un arquitecto de integración que diseña los flujos, el modelo de datos y la capa intermedia,
- desarrolladores de backend que construyen las conexiones, las APIs y la lógica de mapeo,
- especialistas en EDI que conocen la realidad de EDIFACT, X12 y el transporte de ficheros,
- ingenieros DevOps que levantan las colas, la monitorización y los despliegues.
Así no aprendemos integración a costa del cliente - entramos con personas que ya han conectado sistemas de clase empresarial con proveedores externos.
¿Cómo lo hacemos en RITS?
Lo hacemos como partner nearshore desde Polonia que añade competencia exactamente donde falta. No fingimos tener un despliegue logístico ya hecho en la estantería - en su lugar aportamos ingenieros con experiencia real en integraciones de sistemas y proyectos industriales, personas capaces de asumir EDI, APIs de transportistas y dispositivos en un mismo proyecto.
Lo más habitual es que trabajemos como software a medida, cuando la capa de integración hay que construirla desde cero, o como refuerzo de equipo, cuando el cliente tiene su propio equipo y necesita completar rápido una competencia que le falta. Expusimos las diferencias entre estos modelos en nuestro artículo sobre modelos de colaboración en TI.
¿Por dónde empezar a integrar sistemas logísticos?
Empieza por mapear un flujo, el más importante - por ejemplo, desde un pedido en el ERP, pasando por la planificación en el TMS, hasta un estado del transportista y una confirmación para el cliente. Ese único flujo muestra qué sistemas hay que conectar, qué formatos están en juego y dónde se reintroducen datos hoy a mano - y define el alcance de la primera etapa, la arquitectura de la capa de integración y los roles que necesitas. Más socios y transportistas vienen después, sobre una base que ya funciona.
¿Conectas sistemas logísticos - EDI, TMS, ERP y APIs de transportistas? Hablemos; ajustaremos un equipo y una arquitectura de integración a tu operación.