En una empresa de distribución con varias sedes, el problema rara vez aparece en un único sitio. Un pedido llega al buzón comercial, alguien tiene que identificar a qué cliente y delegación corresponde, el equipo de esa sede necesita trabajar contra el mismo ERP que el resto y, después, dirección necesita comparar ventas, compras y stock sobre una base común. Si cada sede está conectada de una manera distinta, el firewall se ha configurado sin criterio común o la extracción del ERP compite con la operación diaria, la tecnología acaba marcando el ritmo del negocio. En Congelados Herbania, la arquitectura se puede contar como un recorrido: proteger los accesos con Fortinet y segmentación por VLAN; unir las sedes mediante túneles IPsec permanentes; leer Oracle/SIGES en solo lectura con cargas incrementales horarias; y colocar una aplicación de IA sobre Amazon Bedrock para leer facturas, albaranes y pedidos. El objetivo no es sumar tres proyectos, sino que el documento que entra por correo termine convertido en trabajo útil dentro de la misma operación.
Tener varias sedes no es, en sí mismo, un problema técnico. Lo es cuando cada una resuelve lo mismo de forma distinta y la empresa deja de tener una única versión de su operación.
Un cliente pide por correo a una delegación, otro llama a la central y un tercero confirma con el comercial que lo visita. El pedido es el mismo objeto de negocio, pero entra por puertas distintas. Con las facturas de proveedor ocurre igual: llegan en PDF al buzón de administración, en papel al almacén que recibe la mercancía o grapadas al albarán que firma el transportista. Si cada puerta de entrada tiene su propio circuito, la empresa acaba conviviendo con tantas versiones del mismo pedido como sedes tiene, y la conciliación posterior se convierte en un trabajo manual permanente.
La respuesta no es unificarlo todo. Lo que debe quedar unido es la lógica de negocio: un único ERP, un único maestro de clientes y artículos, un único criterio de precios y de coste. Lo que debe quedar separado es el riesgo: el tráfico de un almacén no tiene por qué ver la red de administración, y un portátil conectado desde fuera no debería alcanzar los mismos sistemas que un puesto de oficina. Unir la operación y separar la red son decisiones complementarias, no contradictorias.
Antes de hablar de ERP hay que hablar de red, porque todo lo demás se apoya sobre ella. El perímetro se sostiene sobre un parque Fortinet multi-modelo repartido entre sedes de distintas islas y de la península, con el mismo criterio de configuración en todas: es el trabajo que describimos en firewall perimetral y redes multisede.
Multi-modelo significa que no todas las sedes tienen el mismo equipo, y no tendría sentido que lo tuvieran: una delegación pequeña no necesita el mismo cortafuegos que la central. Lo que sí es común es el criterio. Cada sede se segmenta en VLAN según la función del tráfico —puestos de oficina, almacén, dispositivos de red, acceso de invitados— y las políticas se escriben entre funciones, no entre máquinas sueltas. Así, una regla se entiende leyendo su nombre: qué función habla con qué función y para qué.
Esa disciplina tiene un efecto muy práctico el día que hay que cambiar algo. Cuando una sede incorpora un sistema nuevo, no hay que reconstruir el cortafuegos: hay que decidir a qué función pertenece, y heredará las políticas de esa función. Y cuando algo va mal, la segmentación limita el alcance: un equipo comprometido en el almacén no alcanza por defecto los puestos de administración ni la red de gestión.
Con el perímetro resuelto queda lo que convierte varias sedes en una sola empresa: que todas trabajen contra el mismo ERP sin tener que exponerlo a internet.
La topología es hub-and-spoke: cada delegación mantiene un túnel IPsec permanente contra el nodo central, donde reside el ERP. Permanente quiere decir que no depende de que nadie lo levante; está establecido y se renegocia solo. Para el usuario de una sede, el ERP se comporta como si estuviera en la sala de al lado: no hay un procedimiento distinto por estar en otra isla.
Esta forma de conectar tiene una consecuencia que suele pasarse por alto: el ERP no necesita publicarse en internet. No hay un puerto abierto hacia el exterior ni una pasarela adicional que mantener parcheada. El acceso llega por el túnel o no llega, y el control vuelve a ser el mismo cortafuegos que ya gobierna la red de cada sede.
Los túneles entre sedes resuelven las oficinas, pero no a quien trabaja desde un hotel, desde casa de un cliente o entre visitas. Para eso hay un acceso remoto por VPN con una propuesta criptográfica cerrada y confidencialidad persistente, de modo que comprometer una clave de sesión no permita descifrar las anteriores. Es una conexión distinta de la que une las sedes, con sus propias políticas, y por eso se trata también como una red distinta dentro del cortafuegos.
Oracle/SIGES es el sistema donde viven las compras, las ventas, la facturación y el stock. Que todas las sedes trabajen contra él es el objetivo; el riesgo es que ese mismo sistema tenga que atender además a quien quiere analizarlo. Ese reparto es el que explicamos en detalle en la integración de Oracle SIGES con Power BI.
La extracción se hace en solo lectura. El proceso analítico no escribe en el ERP, no bloquea tablas y no puede alterar un dato operativo: su permiso no se lo consiente. Y no se lee todo cada vez. Airflow orquesta cargas incrementales que recogen cada hora los movimientos nuevos, lo que mantiene el volumen por ejecución en una fracción de lo que supondría una copia completa y evita que la extracción compita con la operación diaria. Conviene decirlo con precisión: la información se actualiza cada hora, no en tiempo real, y para las decisiones que se toman con ella es suficiente.
El cálculo que más atención exige es el precio medio ponderado. SIGES lo actualiza de forma automática por artículo y por lote en cada entrada de mercancía, y mientras las compras son compras el resultado es fiable. Se distorsiona en tres situaciones conocidas: devoluciones de cliente que vuelven al stock valoradas a precio de venta, regularizaciones de inventario y descuentos retroactivos que cambian el coste de una compra ya registrada. Saber que esas tres cosas existen es lo que permite tratarlas en la capa analítica, en vez de descubrirlas el día que el margen no cuadra.
Hasta aquí, la arquitectura permite que una persona de cualquier sede trabaje contra el ERP. La siguiente limitación es de otra naturaleza: esa persona sigue teniendo que teclear a mano lo que llega escrito en un documento.
La aplicación de IA lee facturas, albaranes, presupuestos, pedidos y abonos sin una plantilla por proveedor. Esa es la diferencia con los sistemas clásicos de captura: no hay que enseñarle dónde está cada campo en el formato de cada emisor, porque no trabaja por posición sino por comprensión del documento. Un proveedor nuevo no obliga a configurar nada.
De cada documento extrae quién lo emite y a quién va dirigido, con su CIF; de qué tipo de documento se trata; su número y su fecha; y después, línea a línea, la referencia, la descripción, la cantidad, la unidad, el precio, la base, el IVA y el total. El resultado es el documento convertido en datos comparables, que es exactamente lo que antes alguien copiaba a mano.
El pedido tiene un recorrido propio, y es el único flujo que se escribe solo en el ERP. La aplicación lee el buzón comercial mediante Microsoft Graph, identifica de qué cliente viene y a qué delegación corresponde, reconoce los productos solicitados contra el catálogo —aunque el cliente los llame como los llama él y no como los llama el ERP—, vuelca el pedido estructurado en Oracle/SIGES y contesta desde el mismo buzón comercial. El correo deja de ser una bandeja de entrada y pasa a ser una puerta de entrada operativa.
Hay una decisión de diseño que condiciona todo lo anterior: la IA no sustituye el proceso, se ejecuta encima de él. El ERP sigue siendo el ERP y el circuito de aprobación sigue siendo el que era; lo que cambia es quién hace la lectura. Así planteamos las aplicaciones de IA documental.
El modelo que lee los documentos es Claude Sonnet 4.5, invocado a través de Amazon Bedrock, y el detalle importante es dónde: en la cuenta cloud del propio cliente. Los documentos no salen hacia una plataforma de terceros; la aplicación llama al modelo desde la infraestructura de la empresa, con sus permisos y su registro de actividad.
Técnicamente, la lectura es directa sobre el documento. No hay una fase previa de OCR que convierta la imagen en texto y de la que dependan todos los errores posteriores: el modelo interpreta el documento tal cual, y eso incluye corregir la orientación cuando alguien ha escaneado una factura girada o del revés. Es una diferencia pequeña en la descripción y grande en la práctica: buena parte de los fallos de los sistemas de captura clásicos nace en ese escalón entre la imagen y el texto.
De las salidas conviene repetir el límite: el volcado automático al ERP está confirmado para los pedidos. El resto de documentos se entrega estructurado para que lo use el proceso que ya existía.
Con la operación resuelta queda la última pregunta, la de dirección: comparar ventas, compras y stock entre sedes sobre una base común. Esa capa es la que tratamos en almacén analítico y Power BI.
Los movimientos que Airflow extrae del ERP se depositan en un almacén analítico construido sobre PostgreSQL gestionado en AWS Aurora o sobre Snowflake, según el caso, y encima se montan los cuadros de mando en Power BI. La razón de que ese almacén esté separado del ERP no es estética: una consulta analítica pesada lanzada contra la base operativa la ralentiza para todo el mundo, y quien lo paga es la sede que está facturando en ese momento. Separándolos, el análisis puede ser todo lo exigente que necesite sin que nadie en un almacén note que alguien está mirando un informe.
Una arquitectura se juzga por cómo se comporta cuando algo falla. Las configuraciones de los cortafuegos están versionadas, de modo que un cambio se puede comparar con el anterior y revertir sin reconstruir nada de memoria. En los equipos hay EDR/XDR con Wazuh, que vigila comportamiento y no solo ficheros conocidos, y centraliza los eventos de todas las sedes en un mismo sitio.
La identidad y la colaboración se apoyan en Microsoft 365 con Teams y Entra ID, y en Google Workspace donde corresponde, con el mismo criterio de acceso en ambos. Y el correo —que es por donde entra el pedido y también por donde entra el fraude— tiene SPF, DKIM y DMARC configurados en el dominio, que es lo que impide que un tercero escriba en nombre de la empresa. Son controles poco vistosos. Son los que marcan la diferencia el día malo.
Revisamos cómo están conectadas hoy, qué entra por correo y qué podría dejar de teclearse. Sin importar qué ERP uses.
HablemosFAQ
Hablemos
Cuéntanos tu proyecto y te proponemos la solución más adecuada sin compromiso.