Para muchos equipos de IT en empresas importadoras, el miedo no es el ERP nuevo. Es todo lo que cuelga de él: el Excel puente que alguien actualiza cada mañana, las cargas a mano desde el TMS y los datos de aduanas que se vuelven a teclear. Por eso, cuando se habla de integración ERP en importación, la pregunta real no es qué conector comprar, sino cómo conseguir que cada dato entre una sola vez y llegue donde tiene que llegar sin abrir un frente más de mantenimiento.

Este artículo explica qué es la integración ERP aplicada a una empresa que importa, por qué las integraciones improvisadas acaban siempre en la mesa de IT y qué criterios usar para ordenar los flujos de datos, sobre todo cuando hay un cambio de ERP en marcha.

Qué es la integración ERP (y por qué en importación es distinta)

La integración ERP es la conexión del ERP con el resto de sistemas de la empresa para que compartan datos de forma automática: pedidos, facturas, proveedores, stock o costes. En la teoría general suele ilustrarse con el CRM o la tienda online. En una empresa importadora el mapa es más complicado, porque buena parte de los datos que el ERP necesita no nacen dentro de la empresa.

Llegan en documentos de terceros: la factura comercial del proveedor, el BL de la naviera, el aviso de llegada del transitario, la factura del transporte con sus recargos o el DUA que devuelve el agente de aduanas. Cada uno tiene su formato y su ritmo, y casi ninguno encaja directamente en el modelo de datos del ERP. Integrar el ERP en importación significa, por tanto, resolver dos problemas a la vez: conectar sistemas entre sí (ERP, TMS, CRM, sistema de despacho) y convertir documentos externos en datos estructurados que esos sistemas puedan consumir.

Las integraciones que nadie diseñó

Cuando ese segundo problema no se resuelve, la empresa lo resuelve sola, con lo que tiene a mano. Así nacen las integraciones que no aparecen en ningún diagrama de arquitectura, pero que sostienen la operación diaria. Las más habituales en importadoras son tres:

• El Excel puente: una hoja compartida donde Compras o Logística cruza pedido, factura del proveedor y coste del transporte antes de pasarlo al ERP.
• Las cargas a mano desde el TMS: exportaciones a CSV que alguien limpia, reordena e importa en el ERP cada semana, o directamente datos que se copian de una pantalla a otra.
• El retecleo de aduanas: los datos del DUA (valor en aduana, aranceles, IVA de importación) que llegan en PDF y se vuelven a introducir para imputar costes y cuadrar la contabilidad.

Ninguna de estas soluciones es un error de quien la montó. Son la respuesta razonable a una necesidad real que el sistema no cubría. El problema es lo que pasa después, cuando la solución provisional lleva tres años en producción.

Por qué cada integración improvisada acaba en la mesa de IT

Una integración improvisada no tiene dueño claro, pero sí tiene un responsable de facto cuando falla: el equipo de sistemas. Y falla con más frecuencia de la que parece, porque está construida sobre supuestos frágiles. Una columna que cambia de posición en la exportación del TMS, una macro que deja de funcionar tras una actualización de Office o la persona que sabía cómo funcionaba la hoja que se va de vacaciones.

Además, estas integraciones no dejan rastro. Si un coste de importación está mal imputado en el ERP, es muy difícil saber si el error vino del documento original, de la transcripción o de una fórmula. Sin trazabilidad, cada incidencia se convierte en una investigación manual, y cada investigación consume horas de IT que no estaban planificadas.

El resultado es un patrón conocido: el equipo de sistemas dedica cada vez más tiempo a mantener conexiones que nunca diseñó, y cada nueva necesidad del negocio (un proveedor nuevo, una ruta nueva, un cambio de transitario) añade otro parche a la pila.

El cambio de ERP: la ventana para ordenar los flujos

Los proyectos de cambio de ERP suelen centrarse en el propio ERP: migración de maestros, parametrización, formación. Lo que cuelga de él se deja para el final, y ahí aparece el riesgo. Si el ERP nuevo se conecta replicando las mismas cargas manuales y el mismo Excel puente, la empresa habrá cambiado de sistema sin cambiar el problema, y además tendrá que reconstruir integraciones frágiles sobre una plataforma que todavía no conoce bien.

Por eso el cambio de ERP es el mejor momento para hacer inventario de flujos. Basta con responder tres preguntas para cada dato que entra en el ERP: de dónde viene, quién lo transforma y cuántas veces se teclea. Si la respuesta a la última es “más de una”, ahí hay una integración pendiente de diseñar.

Métodos de integración ERP: de punto a punto a una capa de datos

No hay un único método correcto: cada uno resuelve un tipo de flujo y tiene un coste de mantenimiento distinto. Los más comunes en el entorno de una empresa importadora son estos:

• Intercambio de ficheros (CSV, XML, EDI): sencillo y muy extendido con transitarios y navieras, pero sensible a cualquier cambio de formato y con poca visibilidad cuando falla.
• Conexiones por API punto a punto: robustas para un par de sistemas, pero cada nueva conexión multiplica los puntos de mantenimiento.
• Middleware o plataformas de integración genéricas: ordenan las conexiones en un solo lugar, aunque no resuelven por sí solas la lectura de documentos logísticos ni conocen la lógica de un BL o un DUA.
• Una capa de datos especializada en logística: combina la extracción de datos de documentos con la conexión nativa a ERP, TMS y CRM, de modo que el dato llega validado y con su origen registrado.

Para un equipo de IT, el criterio decisivo no suele ser la tecnología, sino cuántas piezas tendrá que mantener y quién responderá cuando un dato llegue mal. Cuantas menos piezas sueltas y más trazabilidad, menos frentes abiertos.

Un ejemplo: el coste de una importación desde Asia

Pensemos en una importadora de componentes que recibe varios contenedores al mes desde Asia. Antes de ordenar sus flujos, el proceso de cada importación funciona así: el pedido vive en el ERP; la factura comercial llega por email y alguien de Compras la cruza con el pedido en un Excel; el transitario manda el aviso de llegada y la factura del flete, que Logística introduce a mano en el TMS; y cuando el agente de aduanas devuelve el DUA, Administración teclea en el ERP el valor en aduana, los aranceles y el IVA de importación para calcular el coste real de la mercancía. El mismo envío pasa por tres personas y cuatro transcripciones, y el coste unitario no está disponible hasta semanas después.

Con una capa de datos conectada, los documentos se leen al llegar, los datos se validan contra el pedido y las tarifas, y se cargan en el ERP y el TMS sin retecleo. Las personas revisan solo las excepciones: una factura que no cuadra con el pedido o un recargo que no estaba en la tarifa. IT deja de mantener la hoja puente y las cargas semanales, y gana algo que antes no tenía: un registro de qué dato vino de qué documento y cuándo.

Más de 10 integraciones nativas con ERP, TMS y CRM, e implantación en 8-10 semanas.

Trazabilidad y aduanas: por qué el dato tiene que venir limpio desde el origen

En importación, la calidad del dato no es solo una cuestión de eficiencia. El Código Aduanero de la Unión (Reglamento UE 952/2013) establece en su artículo 6 que el intercambio de información entre operadores y autoridades aduaneras se hace por medios electrónicos. Y quien presenta una declaración responde de que los datos sean exactos y completos.

Para una empresa que actúa como importador de registro, eso significa que un error de transcripción entre la factura comercial, el sistema de despacho y el ERP no es un problema interno: puede acabar en una declaración incorrecta. Integrar bien no consiste solo en ahorrar horas, sino en poder demostrar de dónde sale cada dato. Si quieres profundizar en este documento, lo explicamos en nuestra guía sobre el DUA en aduanas.

Qué preguntar antes de conectar un sistema más

Antes de aprobar una integración nueva, sea durante un cambio de ERP o para cubrir una necesidad puntual, conviene que IT pueda responder a cinco preguntas:

1. ¿Sustituye o alimenta? Una herramienta que obliga a migrar datos o a cambiar procesos del ERP abre un proyecto; una que lo alimenta con datos limpios se suma a lo que ya funciona.
2. ¿Es nativa o depende de desarrollos a medida? Los conectores nativos se actualizan con el producto; los scripts propios se quedan con quien los escribió.
3. ¿Deja rastro? Cada dato debería poder rastrearse hasta el documento y el momento en que entró.
4. ¿Qué pasa cuando falla? Una integración madura avisa y separa la excepción; una improvisada falla en silencio.
5. ¿Quién la mantiene? Si la respuesta es “nosotros, a mano”, el coste real está en esa respuesta.

Si varias respuestas no son claras, la integración probablemente acabará siendo otro Excel puente con mejor aspecto.

Integrar sin abrir frentes nuevos

La buena integración ERP no se nota: los datos llegan, cuadran y se pueden rastrear. Para conseguirlo en importación no hace falta sustituir el ERP ni montar una arquitectura nueva, sino eliminar los puntos donde el dato se teclea más de una vez. Es la misma idea que recorre la digitalización logística y la automatización de facturas: empezar por el flujo con más volumen y más errores, medir y ampliar.

K-Plug parte de ese principio: no sustituye tu ERP, lo alimenta con datos limpios y trazables. Se conecta de forma nativa con tu ERP, TMS o CRM para que cada dato entre una sola vez y llegue donde tiene que llegar.

Puntos clave

• En importación, la integración ERP implica conectar sistemas y convertir documentos de terceros (facturas, BL, DUA) en datos estructurados.
• El Excel puente, las cargas manuales desde el TMS y el retecleo de aduanas son integraciones que nadie diseñó y que acaba manteniendo IT.
• El cambio de ERP es el mejor momento para inventariar los flujos de datos y eliminar los puntos donde un dato se teclea más de una vez.
• Antes de conectar otro sistema, comprueba si alimenta o sustituye al ERP, si es nativo, si deja rastro y quién lo mantiene.