La automatización se aprueba una vez que el SGA está en funcionamiento. 12 meses después, o en ocasiones 36. Para entonces, la arquitectura de SGA ya está definida, los límites de integración están establecidos y el modelo de coordinación nunca se ha probado con el equipamiento que no existía durante la selección.
Todas las presentaciones de los proveedores de SGA dicen que están «listos para la automatización». La compatibilidad con las API garantiza la conectividad. El hecho de haber realizado integraciones anteriores con Exotec o AutoStore demuestra que el proyecto ha cumplido su cometido. Ninguna de las dos cosas demuestra que el SGA pueda asumir la próxima inversión en equipamiento sin tener que rediseñar las interfaces.
Un SGA está listo para la automatización cuando se pueden verificar tres aspectos. En este documento se explica cuáles son, en qué aspectos los proveedores simplifican en exceso y cómo comprobarlos antes de firmar.
Qué significa listo para la automatización en un contexto de selección
Límites claros del sistema: SGA frente a SCA frente a integrador
Tres sistemas, tres tareas.
| System | Función | Decide |
| SGA | Coordinación de tareas | Qué se selecciona, en qué orden y con qué prioridad |
| SCA | Control del equipamiento | Velocidad de la cinta transportadora, envío de robots, asignación de ruta de las clasificadoras |
| Integrador | Capa de conexión | Mapping de datos, conversión de protocolos, supervisión de las interfaces |
Sobre el papel, parece sencillo. En la práctica es un poco caótico.
Un patrón habitual: el SGA envía una tarea, el SCA reinterpreta la prioridad en función del estado del equipamiento, y el integrador subsana la deficiencia con una lógica personalizada que nadie ha documentado. Tres sistemas, ningún responsable del conflicto.
Los proveedores de automatización, como Exotec y AutoStore, aplican límites estrictos al equipamiento.
La parte de SGA de ese límite merece el mismo rigor. Si no puedes trazarlo en un solo diagrama durante la evaluación de proveedores, es que aún no existe. Inclúyelo como requisito en tu pliego de condiciones para el SGA.
Integración de equipamiento agnóstico
El SGA se selecciona ahora. Los robots se seleccionarán de aquí a 18 meses.
Quizá cintas transportadoras. Quizá lanzaderas goods-to-person.
Quizá un proveedor que aún no existe.
El mercado de la automatización de almacenes ha incorporado más proveedores de equipamiento viables en los últimos cinco años que en los quince anteriores (Interact Analysis, 2024). Eso significa que están llegando al mismo tiempo al almacén más protocolos, más modelos de eventos y más patrones de interfaz.
Un SGA estrechamente vinculado al modelo de integración de un solo proveedor convierte esa diversidad en una limitación. La próxima decisión sobre equipamiento deja de ser gratuita.
Modelo de interacción basado en eventos
Aquí es donde se interrumpe, en una fase demasiado temprana, la mayor parte de las evaluaciones.
La sincronización de los lotes significa que el SGA y el equipamiento de automatización se comunican según un horario establecido. Cada pocos segundos, a veces cada pocos minutos. Entre ciclos, el almacén funciona a ciegas.
Imagina una tarde en periodo de máxima actividad. Un atasco en la cinta transportadora bloquea la línea 3. En un modelo por lotes, el SGA no lo sabe hasta pasados 30 segundos. Durante esos 30 segundos, sigue enviando pickings a la línea 3. Los operarios llegan, esperan y apilan las cajas en el suelo. En origen, se congestiona la clasificadora. Y en destino, ahora hay tres horas límite de transportista que corren el riesgo de no cumplirse.
Para cuando se activa el siguiente ciclo de sincronización, el problema se ha extendido a dos zonas y un supervisor, radio en mano, está intentado reasignar las rutas manualmente.
En un modelo basado en eventos, la señal de atasco llega de inmediato al SGA. Las selecciones se reordenan en las líneas 1 y 2 antes de que el primer operario llegue al punto de bloqueo. La clasificador ajusta la prioridad de entrada. Las horas límite se mantienen según lo previsto.
Tres criterios que deben tenerse en cuenta durante la selección:
- Documentación sobre límites: diagrama formal de la arquitectura que muestra las zonas del SGA, el SCA y el integrador
- Filosofía de integración: conectores abiertos, sin dependencia de un único proveedor de equipamiento
- Modelo de procesamiento de eventos: gestión de eventos en tiempo real frente a sincronización por lotes
Cuando los proveedores simplifican en exceso la preparación para la automatización
«Disponemos de API»
Las API confirman que dos sistemas puedan intercambiar datos. No dicen nada sobre lo que sucede cuando ese intercambio falla en condiciones de carga.
¿Quién es responsable de la lógica de coordinación que se ejecuta entre dos sistemas?
¿Qué ocurre cuando una tarea falla a media ejecución?
¿Qué sistema reacciona primero cuando se produce un atasco en una cinta transportadora y es necesario resecuenciar las tareas de picking?
La API no da respuesta a nada de esto. La documentación sobre la arquitectura del proveedor debería.
«Nos hemos integrado con Exotec» (o AutoStore o Dematic o Geek+, etc.)
Un proyecto anterior ejecutado con éxito demuestra una cosa: que esa integración concreta cumplió su cometido para ese cliente y en esas condiciones.
No demuestra que la arquitectura sea reutilizable.
Es posible que el próximo proveedor de automatización utilice protocolos, modelos de eventos y requisitos de latencia distintos. Si la integración anterior se elaboró como proyecto personalizado, la siguiente comienza desde cero.
La pregunta clave no es si el vendedor ya lo ha hecho antes. Es si la capa de interfaz resiste tras un cambio de proveedor. No te conformes con una llamada para recabar referencias. Solicita un diagrama de la arquitectura que muestre cómo se adapta la misma integración a un proveedor de equipamiento distinto.
«El middleware se encarga de ello»
En ocasiones, lo hace. El problema es quién es el responsable.
El middleware suele situarse entre el SGA y el equipamiento de automatización, y actúa como capa de integración gestionada por un tercero. O por nadie en concreto. Supervisión, SLA de latencia, asignación de rutas para las excepciones, rutas de escalado. Estas responsabilidades existen independientemente de que alguien las haya asumido o no.
Cuando la latencia de la coordinación se dispara en los periodos de máxima actividad, el proveedor del SGA apunta al middleware. El proveedor de middleware señala el equipamiento. El proveedor de equipamiento apunta al SGA. Nadie se hace responsable del problema. Y almacén tiene que asumir el coste.
Debes aclarar tres cosas antes de firmar:
- ¿Quién supervisa el rendimiento del middleware?
- ¿Quién es responsable del SLA de latencia de coordinación?
- ¿A quién se debe llamar a las 2 de la madrugada cuando se estropea?
El principio de responsabilidad compartida nula
La integración de la automatización implica al menos a cuatro partes:
- El proveedor del SGA
- El proveedor de automatización
- El integrador
- El departamento de TI interno
Cada uno hace su aportación a la coordinación. Ninguno de ellos es el responsable de forma natural.
Esa carencia resulta conveniente a la hora de negociar el contrato. Cuatro partes que comparten un compromiso y buena voluntad mutua. Entonces, algo falla en el momento de mayor demanda y tres proveedores organizan una videoconferencia para determinar quién tiene el problema. Se tardan días en resolver la situación. El almacén tiene que asumirlo.
Una zona de fallo, un responsable que rinde cuentas
| Tarea | Proveedor de SGA | Proveedor de automatización | Integrador | Departamento de TI | Cadena de suministro |
| Definición de la lógica de coordinación | A | C | R | C | I |
| Supervisión de la interfaz | R | C | A | C | I |
| SLA sobre latencia | A | R | C | C | I |
| Diseño del flujo de trabajo de excepciones | R | C | A | C | I |
A = Rinde cuentas. R = Es responsable. C = Se le consulta I = Se le informa
Una regla: cada fila contiene exactamente una A. Sin excepciones. No hay ninguna celda con rendición de cuentas compartida.
Si no puedes rellenar esta tabla con nombres concretos durante la evaluación de los proveedores, la capa de coordinación no tiene un responsable. Es un riesgo que asumes desde el primer día.
Siete preguntas que revelan el grado de preparación para la automatización
La tabla RACI del apartado anterior define las áreas de rendición de cuentas. Estas siete preguntas sirven para comprobar si un proveedor es capaz de rellenar esas áreas con nombres y pruebas.
La lógica es secuencial. Cada respuesta da pie a la siguiente. No hay cortes bruscos, pero sí señales claras que indican cuándo es necesario profundizar en la evaluación.
Empieza por la arquitectura.
| N.º | Pregunta | Señal clara |
| Pregunta 1 | ¿Están documentados formalmente los límites entre el SGA, el SCA y el integrador? | El resultado entregable en materia de arquitectura se compartió durante la evaluación, no se prometió que se implementaría. |
| Pregunta 2 | ¿Quién es el responsable de la lógica de coordinación? | Una entidad designada. No «la comparten los equipos». |
Si las preguntas 1 y 2 dan lugar a respuestas vagas o evasivas, es prematuro formular el resto de las preguntas. La conversación pasa de ser una evaluación del producto a saber si existe compromiso con su arquitectura.
A continuación, toca probar la resiliencia.
| N.º | Pregunta | Señal clara |
| Pregunta 3 | ¿Se puede cambiar de proveedor de automatización sin tener que volver a crear interfaces? | Prueba de reutilización de la interfaz entre al menos dos proveedores de equipamiento. |
| Pregunta 4 | ¿Cómo se comprueba la simultaneidad en condiciones de carga máxima? | Resultados de simulaciones de carga, no afirmaciones sobre capacidad teórica. |
| Pregunta 5 | ¿Qué ocurre cuando se producen picos de latencia durante las operaciones mecanizadas? | Lógica de contingencia documentada. Deterioro gradual, no intervención manual. |
A continuación, valida la gobernanza.
| N.º | Pregunta | Señal clara |
| Pregunta 6 | Is middleware internal or partner-managed? | Clear ownership, budgeted monitoring, documented SLA. |
| Pregunta 7 | Who signs the orchestration SLA? | One signature. Contractual clarity on accountability. |
Estas preguntas deben incluirse en demos basadas en casos prácticos, no en guías sobre ergonomía. Simula casos prácticos excepcionales. Evita la senda amable.
La coordinadora como criterio de selección
La coordinación está relacionada con otras decisiones que se toman durante la evaluación del SGA. No debe confundirse con ninguna de ellas.
La rapidez con la que las actualizaciones de automatización llegan al almacén dependen del modelo de despliegue en la nube o local del SGA.
Lo que las prestaciones de IA en el SGA pueden ofrecer depende de la calidad de los datos de eventos que la capa de coordinación les aporta.
La arquitectura define la estructura. El despliegue define la velocidad. La IA define la inteligencia. La coordinación define si alguno de ellos resiste una carga mecanizada.
Preguntas frecuentes
¿Deberíamos evaluar el grado de preparación para la automatización si no hay planes de automatización hasta dentro de más de tres años?
Sí. Las decisiones sobre la arquitectura que se toman durante la selección de un SGA son difíciles de revertir. Un SGA seleccionado hoy sin tener en cuenta su grado de preparación para la automatización impone tener que optar de aquí a tres años por una costosa adaptación de la integración sobre la marcha o por un cambio anticipado de plataforma.
¿Un SGA existente puede para convertirse en un sistema listo para la automatización?
Depende del enfoque en cuanto a la arquitectura. Un SGA modular que prioriza las API y basado en eventos puede evolucionar hasta alcanzar la madurez en materia de coordinación. Es probable que un sistema monolítico basado en lotes requiera un rediseño de la arquitectura para poder integrar cualquier capa de automatización significativa.
¿Siempre necesitamos middleware?
No siempre. Algunas plataformas de SGA gestionan la coordinación de forma nativa. Cuando existe un middleware, la responsabilidad debe estar claramente definida: quién lo supervisa, quién es responsable del SLA y quién se encarga de escalar el problema en caso de fallo.
¿Quién debe estar presente en la evaluación del grado de preparación de la automatización?
Los departamentos de cadena de suministro, de TI y el responsable de automatización, si lo hay. El departamento de cadena de suministro es responsable de la necesidad operativa. El departamento de TI es responsable de la arquitectura. El responsable de automatización es responsable de las restricciones de equipamiento. Si falta alguno, surgen puntos ciegos que afloran durante la implementación en forma de cambios en el alcance no presupuestados. Si la automatización aún no tiene un responsable interno, eso también es una señal.