Todas las empresas que utilizan un ERP cuentan con prestaciones de almacén en algún lugar del sistema. Un módulo de existencias. Una pestaña de logística. A veces, incluso una función denominada «SGA».
Así que la pregunta surge pronto: ¿me basta con mi ERP?
Para una gestión básica del almacén, sí. Para una ejecución logística real, rara vez. Son tres los aspectos que distinguen un software de SGA específico de un módulo de ERP: La competencia experta operativa, la agnosticidad del sistema y el grado de preparación para la automatización.
En el caso de la mayor parte de las operaciones que superan un cierto umbral de complejidad, la respuesta no es ni una cosa ni la otra. Son ambas, con una límite claro entre ellas.
Este documento te ayuda a trazar esa línea. De qué es responsable cada sistema, dónde se conectan, dónde no, y cómo reconocer el momento en que tu ERP deja de ser suficiente.
¿Qué hace realmente un ERP en el almacén?
Los sistemas ERP se crearon para gestionar un negocio, no un almacén. SAP, Oracle, Microsoft Dynamics, Sage, Infor. Todos incluyen módulos de gestión de las existencias. Algunos incluso los denominan SGA. Se encargan de lo básico: órdenes de compra, recepción de mercancías, valoración de las existencias e inventario de forma agregada.
Tiene su utilidad. Conecta el departamento de compras con el financiero, ofrece visibilidad sobre lo que hay en existencias y lo que se debe reponer. Para un almacén con flujos sencillos, volúmenes estables y un equipo reducido, puede ser suficiente.
No obstante, un ERP piensa en términos de transacciones. Llega un pedido. Merman las existencias. Se emite una factura. Se trata de un proceso secuencial y financiero.
Lo que ocurre entre el pedido y el envío, la realidad física sobre cómo se mueven las mercancías dentro del almacén, no es lo para lo que un ERP se ha diseñado. Puede registrar que se ha recibido un palet. No decide dónde debe ir ese palet en función de la rotación, el espacio disponible y el plan de salidas del día siguiente.
Esa distinción parece insignificante cuando las operaciones son de pequeña envergadura. Se convierte en algo estructural cuando crecen.
¿Qué hace un SGA que un ERP no puede hacer?
Un SGA ejecuta el gesto logístico (ya sabes a qué me refiero).
No es una metáfora. El movimiento físico real, la decisión sobre la secuenciación y la gestión de las excepciones que se producen cientos de veces por hora en el almacén.
Tomemos un ejemplo concreto. Un cliente exige que los palets no superen 1,50 m de altura. Esa regla se configura una sola vez en el SGA. A partir de ese momento, se guía automáticamente a cada operario que prepara ese palet. No hay que leer ninguna hoja de instrucciones. No hay que confiar en la experiencia. La herramienta se encarga de aplicar la restricción y el operario ni siquiera se da cuenta.
Ahora imagínate esto a escala de todo un almacén. Ubicaciones de almacenamiento asignadas según la rotación y el espacio disponible. Rutas de picking optimizadas según la carga de trabajo y la prioridad. Reaprovisionamiento activado antes de que se produzca una rotura de existencias, no después. Secuenciación de las tareas ajustada cuando falta personal.
Todo ello ejecutándose en segundo plano.
El ERP envía el pedido. Es el «mandante». El SGA decide cómo ejecutarlo con el menor número de movimientos, en el mejor momento y con el menor número de interrupciones. Cuando algo falla (una ubicación estropeada, un palé perdido), el operario señala la excepción directamente en el SGA. El encargado del almacén lo revisa más tarde. Todo lo demás sigue su curso.
Los profesionales lo denominan «gestión por excepciones». El sistema funciona de forma autónoma. Los humanos solo intervienen cuando se produce un fallo. Los módulos ERP no se han diseñado para funcionar así.
¿Cuándo ya no basta con un módulo ERP?
Cinco operarios en un almacén estable, ejecutando los mismos flujos todos los días. El ERP se encarga de ello. Las reglas las albergan las personas en su cabeza. Todo el mundo sabe dónde van las cosas, cómo gestionar las excepciones y cuáles son las prioridades.
Entonces, la actividad empieza a crecer.
10 operarios. 20, 50, 100… Los empleados temporales que llegan para la temporada de máxima actividad y no tienen esos conocimientos. Un nuevo cliente con normas de embalaje distintas. Un canal que no existía hace seis meses.
El módulo del ERP sigue funcionando. Pero ya no es suficiente. Una vez que el equipo supera los diez operarios, las reglas que albergan las personas en su cabeza se convierten en un riesgo con cada pico de actividad, cada nuevo empleado contratado y cada cambio de turno.
Cuando tu proceso depende de que alguien conozca la respuesta correcta en lugar de que el sistema la aplique, cada nuevo empleado contratado, cada pico de actividad y cada cambio se convierten en un riesgo.
El punto de inflexión rara vez es un solo evento:
- Un volumen que hace insostenible la coordinación manual
- Una complejidad que supera las opciones de configuración;
- Una automatización que requiere coordinación en tiempo real;
La mayoría de las empresas se dan cuenta demasiado tarde.
El ERP «más o menos funciona» el tiempo suficiente como para retrasar la decisión. Detectar a tiempo las señales de obsolescencia del SGA es lo que evita que ese retraso se convierta en una crisis de migración.
¿Cómo funcionan juntos el ERP y el SGA en la práctica?
La teoría es sencilla. La ejecución es donde la cosa se pone interesante.
- Pedido del cliente: el ERP lo transmite. El SGA realiza el picking del pedido, lo embala, lo envía y lo confirma. El ERP activa la facturación.
- Reaprovisionamiento de existencias: el SGA señala una SKU con pocas existencias. El ERP ajusta el aprovisionamiento o realiza un pedido al proveedor.
- Suministro a producción: el SGA entrega los componentes a la línea de producción en el momento adecuado. El ERP realiza un seguimiento del consumo.
El patrón se repite en todos los flujos.
Los datos van y vienen, pero cada sistema es la fuente de verdad de su propio ámbito. El ERP sabe qué se ha pedido y facturado. El SGA sabe dónde se encuentra físicamente cada artículo en este preciso momento, hasta el nivel de ubicación.
Esto funciona cuando hay tres aspectos bien definidos: Qué sistema contiene los datos maestros. Qué desencadena el intercambio de datos. Y con qué rapidez debe producirse ese intercambio.
Estas son decisiones relacionadas con la arquitectura y la escalabilidad del SGA. Cuando no están claramente definidas, ambos sistemas acaban haciendo parte del trabajo del otro. La fuente de información real sobre las existencias reside en tres lugares. Las soluciones provisionales se multiplican. Nadie se hace responsable de los límites.
SAP, Oracle, Microsoft Dynamics: ¿sus módulos de SGA pueden estar a la altura?
Depende de lo que se les pida que hagan.
SAP, Oracle y Microsoft Dynamics incluyen módulos de gestión de almacén. Algunos son más avanzados que otros. SAP EWM, por ejemplo, gestiona casos complejos y se integra perfectamente con S/4HANA.
Para operaciones estables con una complejidad de ejecución moderada, estos módulos pueden funcionar.
El límite aparece cuando el almacén necesita una gran capacidad de configuración a escala de operario, una secuenciación autónoma de las tareas o una automatización que evolucione independientemente del ciclo de actualización del ERP.
Lo hemos constatado de primera mano. En un proyecto de una empresa minorista con varios centros, el equipo de ERP comenzó seis meses antes que el equipo de SGA. Diseñaron los flujos del almacén basándose en la lógica transaccional. Cuando se incorporaron los especialistas en ejecución, la mayoría de esas asunciones tuvieron que revisarse. Los equipos de ERP modelan datos. Los almacenes mueven palets. La brecha entre ambos es donde las asunciones hacen aguas.
Se trata de una brecha estructural. Las plataformas que dan prioridad al ERP desarrollan la ejecución del almacén como un módulo. Un software de SGA de primera categoría se crea al revés. La ejecución es el producto. Todo lo demás está al servicio de ella.
Cómo evaluar si necesitas un SGA específico
Un punto de partida sencillo: cuatro preguntas. Respóndelas en orden. Detente cuando tengas claro el camino a seguir.
¿Tu almacén gestiona más de una lógica de ejecución de pedidos? Varios clientes, varios canales, devoluciones mezcladas con envíos salientes o normas de envío diferentes según el tipo de pedido.
Sí → necesitas un SGA.
No → siguiente pregunta.
¿Tus operarios confían en la experiencia y no en el sistema para tomar decisiones? Dónde almacenar un palet, qué picking se debe realizar a continuación, cómo gestionar una excepción. Si la respuesta la albergan las personas en su cabeza, no está en la herramienta.
Sí → necesitas un SGA.
No → siguiente pregunta.
¿Se ha implementado la automatización o está prevista en los próximos 18 meses? Cintas transportadoras, robótica, goods-to-person. Si el SGA debe coordinar el equipamiento.
Sí → necesitas un SGA
No → siguiente pregunta.
¿Vas a abrir un nuevo centro, canal o nuevo mercado el próximo año?
Si la respuesta es sí → evalúa el SGA ahora. Migrar más adelante sale más caro que hacerlo hoy.
Si has respondido «no» a las cuatro preguntas, es probable que tu módulo de ERP siga siendo suficiente. Por ahora.
Este marco contextual ofrece una orientación. No sustituye a una evaluación adecuada.
Procesos logísticos, panorama de integración, hoja de ruta de crecimiento, capacidad informática interna. Todo ello requiere tiempo y un análisis estructurado que va más allá de cuatro preguntas. Trabajar con consultores de la cadena de suministro o integradores experimentados en esta fase ayuda a hacer aflorar las limitaciones que ningún árbol de decisión puede captar.
¿Qué viene después de la decisión entre un ERP o un SGA?
Una vez que queda claro el límite, las siguientes preguntas surgen rápidamente.
Un SGA específico solo cumple su cometido si la arquitectura de TI y la escalabilidad del SGA subyacentes pueden hacer frente a lo que venga después. Sistema en la nube o local, dependencia de un proveedor o agnosticidad, grado de preparación para la automatización. Se trata de decisiones estructurales que se acumulan a lo largo de la vida útil de la plataforma.
Las conversaciones sobre el presupuesto también se plantean pronto. La brecha entre el coste del software de SGA y el coste total de propiedad es el punto en el que se desmoronan la mayor parte de las justificaciones comerciales. Un módulo de ERP parece más barato en el momento de la firma. Rara vez sigue siendo más barato al tercer año.
La selección en sí misma sigue un método. La mayoría de los fracasos se deben a que el proceso de selección del SGA se ha llevado a cabo en el orden incorrecto, no a que se eligiera al proveedor equivocado.