Integración de sistemas
Conectar el ERP con el almacén y el transporte: las cuatro formas, y lo que cada una deja fuera
Casi todas las distribuidoras tienen ya alguna forma de integración entre sus sistemas, y casi todas siguen teniendo pedidos parados. Esta página explica por qué pasan las dos cosas a la vez: qué sincroniza de verdad cada forma de conectar, qué se queda fuera y qué ocurre cuando una integración falla por la mitad.
¿Qué significa de verdad que mi ERP y mi almacén «estén integrados»?
Significa que copian datos de uno a otro, y casi nunca significa nada más. Una integración normal mueve maestros y documentos —artículos, stock, pedidos, albaranes— en un sentido o en los dos, con una periodicidad. Lo que no hace, salvo que alguien lo haya construido a mano, es decidir qué pasa cuando el dato no llega o llega mal: eso se queda sin dueño, y es exactamente donde viven las incidencias.
Por eso conviene separar dos preguntas que suelen ir juntas y no son la misma. «¿Están conectados?» es una pregunta de infraestructura y la responde sistemas. «¿Se cierra el trabajo sin que nadie lo empuje?» es una pregunta de operaciones, y en la mayoría de las empresas la respuesta es no aunque la primera sea sí.
¿Cuáles son las cuatro formas de conectar el ERP con el almacén, y qué deja fuera cada una?
Son cuatro, se pueden mezclar y casi todas las distribuidoras tienen al menos dos conviviendo. La columna que importa no es la primera: es la de «qué deja fuera», porque ahí está lo que vas a seguir haciendo a mano después de pagar la integración.
Ninguna de las cuatro está mal elegida: cada una es correcta para lo que sabe hacer. El problema aparece al asumir que, por tenerlas, el trabajo se cierra solo.
| Forma | Qué sincroniza bien | Qué deja fuera | Quién lo mantiene |
|---|---|---|---|
| Ficheros: CSV, Excel o FTP por lotes | Maestros y volúmenes grandes que no necesitan ir al minuto | Todo lo que pase entre dos pasadas. Un fichero que no llega no avisa: se nota al día siguiente, en forma de descuadre | Nadie de forma explícita, hasta que falla |
| Conector nativo del proveedor | El camino feliz entre esas dos aplicaciones concretas, y suele ir bien | Lo que el proveedor no contempló: tu circuito de parciales, tus rappels, tu forma de gestionar abonos. Y los estados intermedios, que no siempre viajan | El proveedor, dentro de su alcance |
| Plataforma de flujos con un integrador | Empezar rápido y barato, y automatizar pasos concretos con pocas condiciones | La memoria del trabajo. Un flujo que falla a mitad no sabe qué hizo antes, así que la recuperación vuelve a ser manual | Quien lo montó, que muchas veces ya no está |
| Desarrollo a medida | Exactamente tu proceso, incluidas las excepciones que tú quieras cubrir | Las excepciones que no se previeron al escribirlo, y que aparecen cuando cambia una tarifa, un transportista o un cliente grande | Tu equipo o tu proveedor, para siempre |
¿Por qué sigo teniendo pedidos parados si mis sistemas ya están integrados?
Porque una integración transporta datos y no resuelve excepciones, y son dos trabajos distintos. Cuando el dato llega correcto, la integración hace su trabajo y no te enteras. Cuando el dato no llega, llega tarde o llega en contradicción con otro, la integración no tiene criterio para decidir: no sabe si ese pedido puede servirse parcial, si ese cliente admite ese retraso o si ese abono se puede emitir sin preguntar. Así que no hace nada, y lo que no hace nadie acaba haciéndolo una persona. Son siempre los mismos casos, y están enumerados en los siete sitios donde se queda parado un pedido.
Dicho con números de tu operación: si el 95 % de tus pedidos pasa limpio por la integración, el 5 % restante es lo que ocupa a tu equipo el día entero. La integración resolvió el volumen, y el coste nunca estuvo en el volumen: estaba en la cola. Si tus incidencias están sobre todo en pedidos bloqueados o en la franja de factura de proveedor, puedes poner cifras a lo que te cuestan al año; la cadena completa del pedido se mide en el diagnóstico operativo, con los datos de tu operación. Y el caso concreto de una tienda conectada a un ERP está contado entero, con las limitaciones documentadas del fabricante, en qué se sincroniza de verdad entre Holded y Shopify.
¿Qué pasa cuando una integración falla a la mitad?
Que queda un trabajo a medias que nadie tiene registrado como pendiente. Este es el modo de fallo más caro y el peor documentado, porque no produce un error visible: produce dos sistemas afirmando cosas distintas sobre el mismo pedido. El almacén dice que se preparó y el ERP no tiene la confirmación; o la factura se generó y el albarán firmado no llegó nunca.
Lo que haría falta para que eso no se quedara parado no es una integración más fiable: es que algo llevara la cuenta del trabajo, no la del mensaje — que supiera que este pedido concreto empezó un proceso hace tres días, que el segundo paso falló, qué se intentó ya y quién tiene que decidir si no se resuelve hoy. Un flujo que solo transporta mensajes no puede saber eso, porque para él cada ejecución empieza de cero. El motor que sostendría esa cuenta está en construcción con las primeras distribuidoras; esta sección está en condicional por ese motivo.
¿Necesito tener API en todos mis sistemas para conectarlos?
No en todos, y esa es una de las primeras cosas que hay que mirar antes de prometer nada. Los sistemas de una distribuidora se reparten casi siempre en tres grupos: los que tienen API moderna y documentada, los que solo permiten intercambio por ficheros o por base de datos, y los que únicamente dejan leer —un portal de transportista, un buzón de correo, un PDF—. Con los tres se puede trabajar, pero no se puede prometer lo mismo con los tres, y cualquiera que lo prometa antes de mirarlo no lo ha mirado.
Por eso el primer paso es inventariar qué se puede leer y qué se puede escribir de verdad en cada sistema, antes de diseñar nada. De ahí sale la diferencia entre lo que se puede cerrar entero y lo que, como mucho, se puede dejar preparado para que una persona lo confirme en diez segundos en vez de en veinte minutos. Y una cosa es lo que un sistema permite técnicamente y otra lo que decides permitirle: eso se decide aparte, y está en hasta dónde puede escribir un agente en cada sistema.
¿Tengo que cambiar mi ERP o mi sistema de almacén?
No, y si alguien te propone empezar por ahí, está resolviendo su problema y no el tuyo. El ERP se queda, el sistema de almacén se queda y el transportista se queda: son las aplicaciones donde vive tu operación y donde tu equipo sabe trabajar. Sustituir cualquiera de las tres es un proyecto de un año que ocupa exactamente al mismo equipo que hoy persigue los pedidos.
Lo que cambiaría no es qué aplicaciones tienes, sino que el trabajo que hoy se pierde entre ellas pasara a tener dueño, plazo y registro. Y la pregunta que viene justo después de esta —«¿y qué va a poder tocar ese sistema dentro de mi ERP?»— tiene su propia página: qué permisos se abren, quién los decide y qué queda registrado.
Preguntas frecuentes
¿Cómo se conecta un ERP con un sistema de gestión de almacén?
Hay cuatro formas y se usan a menudo combinadas: intercambio de ficheros por lotes (CSV, Excel o FTP), el conector nativo que publique uno de los dos proveedores, una plataforma de flujos montada por un integrador, y desarrollo a medida contra las API de ambos. La elección depende menos de la tecnología que de dos cosas: con qué frecuencia necesitas el dato actualizado y quién se va a hacer cargo cuando la conexión falle, que es la pregunta que se suele dejar sin responder.
¿Integrar el ERP con el almacén elimina las incidencias de pedidos?
Reduce las que nacen de teclear dos veces el mismo dato, y no elimina las que nacen de una excepción. Una integración mueve información entre sistemas, pero no tiene criterio para decidir si un pedido se puede servir parcial, si un cliente admite un retraso o si un abono se puede emitir sin preguntar. Por eso es habitual tener los sistemas integrados y seguir teniendo un equipo dedicado a perseguir la cola de casos que se salen del camino previsto.
¿Qué pasa si uno de mis sistemas no tiene API?
Se puede trabajar igualmente, pero con un alcance distinto y conviene decirlo antes de empezar. Cuando un sistema solo permite leer —un portal de transportista, un buzón de correo, un PDF— se puede detectar la incidencia y preparar la resolución, pero no ejecutarla dentro de ese sistema: alguien tiene que dar el último clic. La diferencia entre lo que se cierra entero y lo que se deja preparado sale del inventario técnico, que es lo primero que se hace y antes de prometer nada.
¿Cuánto tarda en conectarse un ERP con el almacén y el transporte?
Varía tanto según el estado de las API y la limpieza de los maestros que cualquier plazo dado antes de mirarlo es una cifra inventada. Lo que sí se puede acotar pronto es el alcance: en dos sesiones se sabe qué sistemas tocan un pedido, qué se puede leer y escribir en cada uno, y cuál de las incidencias habituales conviene atacar primero. Ese orden importa más que la velocidad, porque empezar por la incidencia equivocada consume el presupuesto de paciencia de la organización.
¿Qué diferencia hay entre una plataforma de integración y una capa de operaciones con IA?
Una plataforma de integración te da herramientas para construir tus propios flujos, y el resultado depende de que alguien de tu casa se convierta en integrador y se mantenga. Una capa de operaciones con IA se ocuparía del trabajo completo: detectar la incidencia, reunir el contexto de los sistemas implicados, resolverla dentro de las reglas que fija el cliente y pedir una decisión solo cuando hace falta. La diferencia práctica estaría en qué se entrega: en un caso, flujos que mantener; en el otro, casos cerrados. Decimos «estaría» a propósito: ese motor se está construyendo con las primeras distribuidoras y hoy no se puede comprar.
El inventario técnico va antes que cualquier promesa
Antes de conectar nada hay que saber qué se puede leer y qué se puede escribir de verdad en cada uno de tus sistemas. Eso es la primera sesión del diagnóstico operativo, y no necesita acceso a tus sistemas ni ninguna credencial: se hace hablando con quien los usa y con quien los mantiene.
Sale con un número —cuántas horas al mes se van hoy entre aplicaciones— y con el orden en que conviene atacarlas. Si no llegan a 40 horas al mes, te lo decimos por escrito y ahí se acaba.
Pedir el diagnóstico operativo