Arquitectura de TI y escalabilidad del SGA

Cada vez son más las empresas que confían al departamento de TI el liderazgo de los proyectos de SGA. Las decisiones sobre la arquitectura del SGA determinan las posibilidades a largo plazo. Merecen toda esa atención.

Sin embargo, esas decisiones rara vez se toman de forma deliberada. Se heredan de proyectos anteriores, vienen implícitas por la elección de herramientas o se descubren durante la implementación. Para entonces, cualquier corrección resulta costosa.

La arquitectura del SGA y su escalabilidad definen cómo se conectan tus sistemas, quién es responsable de qué y qué puede absorber tu configuración cuando cambia la estrategia. Su diseño sigue tres pasos.

  1. Trazar la arquitectura ideal sin hacer concesiones con las limitaciones actuales
  2. Identificar la función natural de cada sistema
  3. Planificar una trayectoria realista, paso a paso

Se abre nuevo canal. Se pone en marcha un centro nuevo. Llega la automatización. En la nube o local. Iniciativa de IA. Cada uno de ellos pone a prueba la escalabilidad de tu arquitectura. ¿Es capaz de adaptarse al cambio o se colapsa bajo presión?

El software de SGA es un componente de esa arquitectura. Lo que puede hacer depende de la claridad en las fases iniciales. De lo que gestiona el ERP. De dónde reside la información veraz sobre las existencias. De cómo se conecta la automatización. Sin esa claridad, el SGA hereda problemas que no puede resolver.

Diseñar la arquitectura que se ajusta a tu SGA

Una empresa minorista tiene previsto abrir un canal de e-commerce. El departamento de cadena de suministro sabe lo que se avecina. Nuevos flujos. Envíos de paquetes pequeños. Variabilidad en los picos.

El departamento de TI se enfrenta a su propia versión de ese debate. ¿Deberían separarse o combinarse los flujos B2B y B2C? ¿El SGA actual es capaz de gestionar ambos o se necesitan dos instancias? ¿Qué hay del transporte de paquetes pequeños? Y, en el futuro, si la empresa vende a través de marketplaces, ¿necesitarás un OMS?

El método comienza por trazar la arquitectura ideal. Sin hacer concesiones con respecto a las limitaciones actuales. ¿Cómo debería ser el objetivo si pudieras empezar de cero?

Entonces proyectas ese objetivo con una trayectoria realista. Modernización paso a paso. No una utopía. Una secuencia de medidas que reduce la brecha entre el estado actual y el estado objetivo.

El objetivo es sencillo. Una estructura de TI preparada para apoyar la estrategia empresarial. El crecimiento mediante adquisiciones implica una rápida integración de nuevas entidades. El aumento del volumen implica absorber un 30 % más sin inversión en infraestructura. El modelo omnicanal implica que el B2B y el B2C coexistan sin necesidad de rehacer el trabajo.

Si no puedes plasmar ese objetivo en una sola diapositiva, es que no lo tienes.

Cada sistema desempeña una tarea:

El ERP gestiona las transacciones y el aspecto económico. El OMS gestiona la promesa de la entrada de pedidos. El TMS gestiona la ejecución del transporte. El SGA gestiona la ejecución en el almacén y la veracidad de las existencias.

Algunas empresas cuentan con los cuatro. Otros tienen dos. No es lo que importa.

Lo que importa es saber dónde termina uno y dónde empieza el siguiente. En el límite entre el ERP y el SGA se aborda cómo trazar esa línea para la ejecución del almacén.

Cada herramienta supera ligeramente su cometido esencial. Es lo que se da en llamar la regla del 1 %. Toleras un pequeño solapamiento con cada herramienta vecina para evitar comprar otra. El transporte del expedidor se sitúa entre el SGA y el TMS. Algunos proveedores de SGA han incorporado esa función en su producto. Otros dan por sentado que un TMS se encarga de ello. Ambas opciones funcionan, siempre y cuando el límite sea explícito.

El problema es el solapamiento no controlado.

Un sitio web empieza a gestionar las existencias porque la integración del SGA llevaba demasiado tiempo. Ahora, la información veraz sobre las existencias reside en tres sitios distintos. El mantenimiento y la generación se suman al caos. Eso es lo que se conoce como «TI en la sombra».

Describe qué hace cada herramienta de tu arquitectura. Y qué no hace. Si no has hecho ese trabajo, no sabrás de qué es responsable el SGA y qué debe quedar fuera.

Del objetivo a una trayectoria realista

La arquitectura ideal es un objetivo. No es un plan que se ejecute el lunes por la mañana.

La brecha entre dónde estás y dónde quieres estar es real. Sistemas heredados. Integraciones existentes. Contratos. Equipos. Ciclos presupuestarios. La pregunta es cómo cerrar esa brecha sin caer en dos trampas.

  1. Primera trampa: el big bang. Sustituir todo de una vez. Alto riesgo. Alto coste. Rara vez funciona.
  2. Segunda trampa: esperar al momento perfecto. Nunca llega. La brecha persiste. La arquitectura sigue siendo implícita. Cada nuevo proyecto añade otra capa de soluciones provisionales.

El método consiste en una modernización paso a paso. Cada paso reduce parte de la brecha. Cada paso se justifica por el valor para el negocio, no solo por la liquidación de la deuda técnica.

Sustituyes el SGA. Ese es un paso. Aclaras el límite entre el SGA y el TMS. Ese es otro. Migras a SaaS. Otro. Conectas la automatización. Otro.

El objetivo permanece fijo. La trayectoria se adapta a las limitaciones, los plazos y el presupuesto. Pero siempre sabes hacia dónde te diriges. Esa es la diferencia entre la arquitectura y la improvisación.

Lo que tu arquitectura de TI debe dejar claro

El negocio no espera a que la TI esté lista. Surgirán estas preguntas.

  1. El volumen aumenta un 30 %. ¿Un modelo SaaS o local? Un modelo SaaS implica configuración. La opción local puede suponer una inversión en infraestructura.
  2. Llega la automatización. mecanización, robótica, goods-to-person. ¿Tu SGA es agnóstica con respecto al equipamiento que la empresa aún no ha elegido? ¿O está atado a proveedores específicos?
  3. La empresa pone en marcha una iniciativa de IA. ¿Pueden colaborar tus sistemas? El SGA genera eventos y datos. Lo mismo hace el ERP. Lo mismo hace el TMS. La IA funciona cuando los sistemas intercambian decisiones. No cuando cada herramienta tiene su propia función aislada.
  4. Adquieres una empresa. ¿Con qué rapidez puede el departamento de TI integrar sus operaciones? ¿Se debe desplegar otra instancia del SGA o ampliar la actual?
  5. La empresa abre nuevos canales de venta. Marketplaces, venta directa al consumidor. ¿Necesitas un OMS o las herramientas existentes pueden gestionar la coordinación de canales?

Si puedes responder hoy a estas preguntas, tu arquitectura tiene un objetivo. Si no es así, descubrirás las carencias durante la implementación.

En la nube o local. Preparación para la automatización. Integración de la IA. No se trata de temas independientes. Son los aspectos en los que se pone a prueba tu arquitectura cuando la escalabilidad es importante.

Sistema en la nube frente a un sistema local

Optar por un sistema en la nube o local es hacer una elección sobre cómo llega el cambio al almacén. El modelo SaaS cumple ese cometido de forma continua. El modelo local lo cumple por proyectos. El modelo adecuado depende de tu trayectoria de crecimiento en los próximos 5 a 10 años. Los inconvenientes se manifiestan en cuatro situaciones: picos de volumen, nuevas centros, automatización y ciclos de actualización. SGA en la nube frente a local te ofrece un marco de referencia para tomar una decisión antes de comparar proveedores.

Automatización y agnosticidad

La automatización se aprueba una vez que el SGA está en funcionamiento. En unas ocasiones 12 meses después, y en otras 36 meses después. Para entonces, la arquitectura ya está definida de forma fija y los límites de integración están establecidos. Antes de firmar, se puede comprobar que un SGA está listo para la automatización a partir de tres criterios: unos límites claros del sistema, una integración agnóstica del equipamiento y un modelo de interacción basado en eventos.

La IA en el SGA

Todos los proveedores incluyen la IA en la primera diapositiva de sus presentaciones. Durante el proceso de selección de un SGA, la mayoría de los compradores no tienen forma de distinguir entre un producto listo para producción y un prototipo con un guion de demo. En La IA en el SGA se analizan cinco casos de uso que ya se están aplicando en los almacenes, las preguntas que ponen de manifiesto la madurez real del proveedor y lo que la arquitectura tiene que admitir para que la IA pueda cumplir su cometido.

Dónde encaja esto en tu proceso de implementación del SGA

Este documento ha abordado la arquitectura y la escalabilidad desde el punto de vista del SGA, el departamento de TI y la empresa. Estado del objetivo. Funciones del sistema. Las preguntas que debe responder el departamento de TI. La trayectoria de lo ideal a lo realista.

La arquitectura define lo que un SGA puede hacer. No elige la herramienta.

Si tu arquitectura está bien definida y estás preparado para comparar plataformas, en el mejor SGA se acota el mercado por nivel y caso de uso.

Si sabes lo que necesitas, cómo elegir un SGA te ofrece el método de selección.