El IoT en la logística

En esencia, el Internet de las cosas en el ámbito de la logística describe la integración de objetos físicos en sistemas informáticos, de modo que dichos objetos intercambien datos de forma autónoma a través de redes y, de este modo, resulten útiles para los procesos operativos. En concreto, esto significa que: los paquetes llevan etiquetas de identificación, los contenedores están equipados con sensores de temperatura, los vehículos comunican su ubicación a través de módulos GPS, los sistemas de almacenamiento proporcionan información sobre su ocupación o estado operativo, y las estaciones de medición situadas en la zona de expedición registran automáticamente el peso y el volumen en cada paso. Todos estos objetos físicos generan eventos que pueden aprovecharse digitalmente, sin que sea necesaria la intervención manual de una persona ni la transmisión de datos.

Lo que une a estos objetos es una lógica común: un estado físico, una identidad o un movimiento se transforma en una señal digital que se transmite a través de una red a un sistema superior. Sin embargo, los objetos en sí mismos no son homogéneos: un contenedor frigorífico, una carretilla elevadora y una estación de embalaje tienen requisitos muy diferentes en cuanto a sensores y conectividad. Lo que los une en el Internet de las cosas es el principio: la realidad física se puede representar de forma continua y automatizada en los procesos de almacenamiento, transporte y gestión de pedidos. De este modo, se crea una representación digital de los procesos reales que sirve de base para los registros contables, las decisiones de gestión y el control de procesos.

En el ámbito de los dispositivos conectados se pueden distinguir tres conceptos que, aunque se complementan entre sí, se centran en aspectos diferentes. El Internet de las cosas general abarca todo tipo de objetos conectados, desde dispositivos para el hogar inteligente hasta wearables y sensores industriales. En un primer momento, se limita a describir el principio: los objetos físicos se comunican digitalmente y generan datos que pueden procesarse posteriormente en los sistemas.

El Internet industrial de las cosas, o IIoT, hace referencia a la vertiente industrial de este enfoque. En este caso, el foco se centra en entornos de producción, almacenamiento e intralogística, con requisitos de robustez, disponibilidad, seguridad de los procesos y una estrecha integración con los sistemas operativos. Por lo tanto, cuando se utiliza tecnología conectada en un contexto industrial para representar de forma estable y cercana al sistema los flujos de materiales, el estado de las instalaciones o los traspasos logísticos, se habla, en términos técnicos, de IIoT.

El AIoT se basa en ello, pero complementa la infraestructura conectada con componentes adicionales de inteligencia artificial. Así, los dispositivos y sistemas no solo recopilan datos, sino que estos se interpretan posteriormente mediante modelos de reconocimiento de patrones, previsiones o detección de anomalías. En el contexto logístico, esto puede significar que a partir de los datos de los sensores no solo se genera un informe de estado, sino también una predicción sobre cuellos de botella, averías o desviaciones. El AIoT en la logística representa, por tanto, la combinación de la base de datos del IoT o del IIoT con la inteligencia artificial.

En cada objeto conectado, el flujo de datos comienza con un evento concreto: un sensor de temperatura registra una variación, una etiqueta RFID pasa por la puerta de un almacén, un módulo GPS comunica una nueva posición o una báscula en la zona de embalaje registra un peso. Estos eventos se producen localmente en el propio objeto —en algunos casos de forma continua, en otros provocados por un movimiento o un cambio de estado—. Por sí solos carecen de significado; solo su transmisión estructurada los convierte en información de proceso aprovechable.

El transporte de estos datos brutos corre a cargo de las pasarelas o las redes móviles. Las pasarelas actúan como enlace entre los sensores o las redes inalámbricas locales y los sistemas de nube o de TI de nivel superior: recogen las señales, las procesan y las transmiten en un formato utilizable. En la práctica de los almacenes, pueden ser puntos de acceso Wi-Fi locales, pasarelas LoRaWAN o módulos de telefonía móvil compatibles con NB-IoT, dependiendo de los alcances, los volúmenes de datos y los presupuestos energéticos que requiera cada aplicación.

Los eventos entrantes llegan finalmente a una plataforma en la nube, a un sistema periférico o directamente a una interfaz WMS o ERP. Allí, el software se encarga de la recepción, el almacenamiento y el análisis de los datos: los eventos se vinculan con los datos maestros, se comparan con los valores límite y se sintetizan en información de estado, alarmas o registros automáticos. Así, una señal de temperatura sin procesar se convierte en un incumplimiento documentado de los valores límite; y un escaneo RFID se convierte en un registro de entrada de mercancías. Este flujo de datos continuo —desde el sensor hasta el sistema operativo— es el requisito técnico básico para que los datos del IoT controlen realmente los procesos y no se limiten a generar valores de medición.

Quien, durante el funcionamiento, quiera saber dónde se encuentra en ese momento un portacarga, cuál es el nivel de ocupación de un almacén intermedio o si un contenedor de la zona de refrigeración respeta los límites de temperatura permitidos, sin un sistema de registro automatizado de datos tendrá que depender de información manual o de actualizaciones del sistema con retraso. El registro en red cubre esta laguna de información al hacer visibles, prácticamente en tiempo real, los stocks, los movimientos de material y los parámetros de estado —no como un análisis a posteriori, sino como una visión continua de la situación durante el funcionamiento operativo—.

En concreto, los sensores de temperatura, humedad o vibraciones proporcionan datos continuos sobre el estado de las zonas sensibles del almacén o de los medios de transporte, mientras que los sensores de nivel supervisan automáticamente el grado de ocupación de las estanterías dinámicas o de los contenedores de material a granel. Los puntos de identificación situados en las puertas del almacén o en las líneas de transporte registran los movimientos de mercancías en el momento en que se producen, sin que sea necesario realizar ningún registro manual. El resultado es una visión actualizada de toda la actividad del almacén: desde la cantidad de existencias y la ubicación de cada uno de los soportes de carga hasta las desviaciones críticas en el estado que requieren una reacción inmediata.

La ventaja operativa se manifiesta especialmente en la reducción del tiempo dedicado a la búsqueda, la espera y la coordinación: cuando los sistemas actualizan de forma autónoma las posiciones de stock y los datos de estado, se eliminan las consultas que consumen tiempo entre turnos, departamentos o socios del sistema. Las decisiones sobre reabastecimiento, traslados o intervenciones relacionadas con la calidad pueden tomarse basándose en información actualizada, y no en el último estado del inventario o en una estimación introducida manualmente.

Un envío pasa por varias etapas del proceso, desde la recepción de mercancías hasta la entrega, pasando por el almacenamiento, la manipulación y el transporte, etapas de las que a menudo se encargan diferentes sistemas, actores o unidades de la empresa. Sin un registro digital continuo, se producen lagunas de información en estos puntos de transición: solo mediante consultas manuales o notificaciones de estado tardías es posible averiguar quién se ha hecho cargo del envío, cuándo ha salido de un almacén o si todavía se encuentra en tránsito. Los eventos de identificación y estado interconectados cierran estas lagunas en cada etapa relevante, por ejemplo, mediante el registro por RFID en los controles de acceso, los mensajes GPS de los medios de transporte o los eventos de sensores en los puntos de transbordo.

Para que esta información siga siendo comparable y evaluable más allá de los límites de los sistemas, se necesita un modelo de datos común. EPCIS —el estándar para los Servicios de Información de Códigos Electrónicos de Productos (Electronic Product Code Information Services), gestionado por GS1— define precisamente este modelo de eventos: describe qué ha ocurrido con un objeto, cuándo y dónde tuvo lugar el evento y en qué contexto empresarial. Sobre esta base, los eventos de estado procedentes de diferentes fuentes de datos pueden combinarse, independientemente del fabricante, y sintetizarse en un historial de envíos coherente, lo que constituye una base sólida para el seguimiento y la localización, los albaranes de entrega y el control de procesos entre sistemas a lo largo de toda la cadena de suministro.

Si bien la transparencia en tiempo real y el seguimiento de envíos tienen un impacto operativo inmediato, el beneficio estratégico más profundo de la recopilación de datos interconectada radica en una base de datos sólida que proporciona un fundamento firme para la gestión y la mejora continua. Los datos que proceden directa y automáticamente del proceso en curso —es decir, que no se han registrado manualmente, ni se han agregado a posteriori ni se han reconstruido a partir de registros del sistema— constituyen la base para establecer prioridades operativas basadas en el estado real de los procesos y no en hipótesis de planificación que, posiblemente, ya hayan quedado obsoletas desde hace horas.

En lo que respecta a la detección de cuellos de botella, esto significa que: en lugar de esperar a que lleguen avisos de escalación desde la planta, los cuellos de botella críticos —por ejemplo, en las zonas de preparación de pedidos, en las líneas de transporte o en la puesta a disposición de mercancías— pueden detectarse tan pronto como cambian en tiempo real parámetros relevantes como los tiempos de tramitación, la ocupación de los almacenes intermedios o los retrasos en la tramitación. De este modo, la gestión operativa gana en capacidad de reacción y precisión. Lo mismo se aplica al control de reabastecimiento: si las fuentes de datos proporcionan de forma continua los niveles de existencias y las tasas de consumo, las órdenes de reabastecimiento pueden activarse con antelación y basándose en reglas, en lugar de depender de lecturas manuales de inventario o de notificaciones procedentes de la preparación de pedidos.

A largo plazo, el registro continuo genera un conjunto de datos que proporciona una base sólida para la mejora sistemática de los procesos: las desviaciones pueden relacionarse con contextos de proceso reales, los conjuntos de reglas pueden perfeccionarse basándose en parámetros de proceso medidos en lugar de estimados, y las etapas de automatización se asientan sobre una base de información válida.

En la práctica, la conectividad supone un compromiso: no es posible maximizar al mismo tiempo el alcance, el consumo energético, el volumen de datos y la latencia. NB-IoT resulta adecuado cuando se deben transmitir pequeñas cantidades de datos a través de grandes áreas en la red móvil, por ejemplo, en el caso de puntos de sensores distribuidos o contenedores móviles con notificaciones de estado esporádicas. Su punto fuerte radica en su funcionamiento energéticamente eficiente y en la buena cobertura territorial, no en las altas velocidades de transmisión de datos.

LoRaWAN resulta interesante cuando las empresas desean gestionar su propia red de largo alcance o, deliberadamente, no quieren depender de la red móvil pública. Es adecuado para aplicaciones con paquetes de datos pequeños, larga duración de la batería y una frecuencia de transmisión manejable. Sus limitaciones se ponen de manifiesto cuando se requieren tiempos de respuesta muy cortos o grandes volúmenes de datos.

El 5G se dirige a un perfil diferente: altas velocidades de transmisión de datos, baja latencia y muchos dispositivos conectados simultáneamente. Esto es relevante para aplicaciones industriales más exigentes, como los sistemas basados en imágenes o la robótica móvil con control de gestión preciso. Para datos de sensores sencillos, el 5G resultaría a menudo excesivo. Por lo tanto, la elección correcta no se deriva del estándar más moderno, sino del perfil de carga concreto de la aplicación.

La cuestión de si optar por la nube o el borde es, ante todo, una cuestión de lógica de toma de decisiones. Si un valor debe comprobarse de forma inmediata a nivel local, ya sea porque un retraso supondría un riesgo o porque la conexión a Internet no está disponible en todo momento, ese procesamiento debe realizarse en el borde de la red. Esto se aplica, por ejemplo, a las comprobaciones de valores límite en las que el tiempo es un factor crítico, a las reacciones de las máquinas locales o a situaciones en las que el funcionamiento debe continuar incluso en caso de fallos de conexión.

Las plataformas centrales despliegan todo su potencial cuando hay que agregar datos de distintas ubicaciones, archivarlos históricamente o compartirlos con socios. Quien desee reunir en una única vista varios almacenes, procesos de transporte y partes externas, necesita un nivel superior para el análisis, la elaboración de informes y la gestión de interfaces. Allí también se crean las condiciones necesarias para evaluaciones posteriores y modelos basados en la inteligencia artificial.

A la hora de la integración de sistemas, lo que cuenta en última instancia no es tanto la ubicación de almacenamiento como la interoperabilidad técnica. Un evento debe estar procesado de tal manera que los sistemas WMS, ERP o los sistemas especializados puedan trabajar con él. Por eso, no solo la infraestructura, sino también la calidad de las interfaces, las API y los modelos de eventos determinan el beneficio real.

Para que los datos procedentes de distintos dispositivos, fabricantes y estaciones de proceso sean compatibles entre sí, se necesitan estructuras comunes. EPCIS es el punto de referencia central para los datos de trazabilidad y de eventos a lo largo de las cadenas de procesos logísticos. El estándar, mantenido por GS1, describe qué ha ocurrido con un objeto, cuándo y dónde tuvo lugar el evento y en qué contexto empresarial se inscribe. Precisamente en las cadenas de suministro distribuidas, esto es más importante que los mensajes individuales propietarios, ya que solo así se crea un historial de eventos continuo que trasciende los límites de la empresa.

Con EPCIS 2.0, este modelo se ha abierto aún más a las arquitecturas modernas: los datos de los sensores se pueden representar mejor, y JSON-LD y OpenAPI facilitan la integración técnica. Para las empresas, esto significa sobre todo una cosa: quien utilice desde el principio un modelo de eventos estandarizado reducirá el esfuerzo posterior en ampliaciones, integraciones con socios y cambios de sistema.

Para los flujos de datos de intralogística y transporte en el ámbito de los vehículos móviles y la robótica, VDA 5050 es un estándar de interfaz relevante. Describe la comunicación entre el sistema de control y los vehículos de distintos fabricantes, creando así una base de integración común cuando se deben integrar diferentes sistemas FTS, AGV o AMR en el mismo flujo de materiales. Desde el punto de vista terminológico, conviene establecer una diferenciación clara: los FTS o AGV clásicos suelen seguir en mayor medida lógicas de desplazamiento predefinidas, mientras que los AMR pueden calcular sus rutas en función de la situación. La norma VDA 5050 no hace que estos sistemas sean funcionalmente idénticos, pero facilita su conexión estandarizada.

La tecnología de sensores resulta adecuada cuando lo decisivo no es la identidad de un objeto, sino su estado medible. La selección se basa en cuatro criterios prácticos: ¿qué magnitud de medición se necesita?, ¿con qué frecuencia debe registrarse?, ¿qué estabilidad debe mantener la precisión de la medición a lo largo del tiempo? y ¿cómo se alimenta el dispositivo? Los requisitos para una cadena de frío son distintos a los de un sensor de nivel en una estantería o de un sistema de pesaje en una línea de transporte.

La elección se vuelve crítica cuando las condiciones ambientales influyen en la medición. Los sensores de temperatura deben adaptarse al rango de medición; los sensores de humedad envejecen de forma diferente según el entorno de uso; los sensores de vibraciones necesitan un disparador adecuado; y los sensores de peso pueden verse alterados por el montaje, la suciedad o la tensión mecánica previa. A esto se suma la necesidad de calibración: quien utilice los datos para la facturación, el control de calidad o la documentación de valores límite, a menudo no puede confiar en una medición aproximada de tendencias.

También es decisiva la relación entre el intervalo de medición y el consumo energético. Un sensor que envía un valor cada pocas horas se gestiona de forma muy diferente a un dispositivo que mide cada segundo o que reacciona permanentemente a los eventos. En la práctica, esto significa que los sensores son muy útiles cuando se trata de supervisar magnitudes de estado definidas; sin embargo, resultan menos adecuados cuando lo principal es el reconocimiento de objetos, la localización en interiores o la autorización de procesos.

La RFID y la NFC son, sobre todo, mecanismos de identificación y recopilación de datos en las soluciones de IoT. Se utilizan para reconocer objetos sin necesidad de introducción manual de datos y, a menudo, también sin contacto visual directo, y para procesar digitalmente la identidad registrada. La tecnología NFC resulta adecuada para el ámbito de proximidad controlada: las distancias típicas se sitúan en el rango de los centímetros, por ejemplo, para el registro individual, la autenticación de dispositivos o interacciones activadas de forma deliberada. La tecnología RFID abarca escenarios más amplios, desde el registro específico de contenedores individuales hasta el registro en grupo de varias etiquetas en una puerta.

A la hora de elegir, la distinción entre registro individual, registro en grupo y rango cercano controlado es más importante que la mera denominación de la tecnología. La RFID de baja frecuencia (LF) y de alta frecuencia (HF) suelen funcionar en el rango cercano y resultan robustas allí donde no se necesitan grandes alcances. La RFID UHF, en el rango de 860-960 MHz, es la opción habitual para lectores de puertas, el registro de pilas o palés y la lectura simultánea de varias etiquetas. Pero ahí es precisamente donde residen sus límites: la RFID no es una herramienta para la localización interior precisa ni ofrece una garantía fiable de alcances fijos.

Las distancias de lectura son siempre solo rangos típicos. Dependen expresamente del tipo de etiqueta, la potencia del lector, la disposición de la antena, el entorno, el material, la situación de instalación y la cantidad de datos que se vayan a transmitir. El metal, los líquidos, los lugares de montaje desfavorables u objetos muy próximos entre sí pueden alterar significativamente el resultado. Para los proyectos, esto significa que la tecnología RFID no debe seleccionarse en función del alcance indicado en el catálogo, sino que debe probarse en el entorno real del proceso.

Los localizadores GPS son el componente típico de las arquitecturas del IoT para la obtención de datos de localización en el sector del transporte. Se utilizan sobre todo en aquellos casos en los que los vehículos, las cajas móviles, los contenedores u otros activos móviles se desplazan fuera del almacén y es necesario conocer su ubicación sin necesidad de infraestructura local. Por lo tanto, su principal ventaja radica en la determinación autónoma de la posición a grandes distancias.

El GPS se vuelve crítico siempre que no hay visión despejada del cielo. En naves industriales, bajo cubiertas, en aparcamientos subterráneos o en zonas de terminales con construcciones muy densas, la calidad de la localización disminuye considerablemente o se interrumpe por completo. Por ello, el GPS no es adecuado para la localización interior precisa. Quien desee registrar movimientos dentro de un edificio, o incluso a nivel de estanterías y puestos de trabajo, necesita otros métodos, como la UWB, la localización basada en wifi o la identificación por zonas mediante RFID.

La idoneidad depende además de la frecuencia con la que se necesiten las posiciones y del grado de autonomía con el que deba funcionar el dispositivo. Un localizador de activos que solo tiene que enviar unos pocos mensajes de estado al día plantea requisitos distintos en cuanto a batería, intervalo de transmisión y geovallas que un localizador de vehículos con telemetría de alta frecuencia. El GPS es muy eficaz para el seguimiento en exteriores a gran escala, pero no para una precisión sin fisuras en cualquier contexto espacial.

Otro caso de uso claro del IoT en la logística es la cadena de frío o la monitorización de condiciones. El problema inicial es aquí evidente: los daños no suelen producirse en un único punto de traspaso, sino como consecuencia de una evolución del estado que pasa desapercibida a lo largo del tiempo. Por lo tanto, el dato necesario no es solo un valor de medición puntual, sino una secuencia de valores de temperatura, humedad o vibraciones en relación con el objeto, el periodo de tiempo y el contexto del proceso.

Para la integración hay dos aspectos decisivos: en primer lugar, los valores límite o los patrones deben definirse técnicamente para que, a partir de una serie de mediciones, se pueda obtener un aviso útil. En segundo lugar, es necesaria una asignación clara al encargo, al lote, al contenedor o al medio de transporte. Sin este contexto, incluso un sistema de sensores técnicamente impecable carece de utilidad operativa.

La ventaja inicial suele ser evidente de inmediato: una reacción más rápida ante las desviaciones y una mayor capacidad de justificación ante clientes, socios o auditorías. Los escollos suelen residir en el montaje de los sensores, en el intervalo de medición y en unos valores límite mal establecidos. Quien solo quiera documentar necesita una configuración diferente a la de alguien que deba intervenir activamente para evitar daños.

La zona de embalaje es la opción más rentable para muchas empresas medianas, ya que el problema inicial es muy concreto: los pesos y las dimensiones se registran manualmente, se estiman o solo se verifican tras recibir la confirmación de los transportistas. El dato necesario es inequívoco: el peso y el volumen exactos de cada envío en el momento del embalaje. Es precisamente ahí donde se generan los valores relevantes para el transporte, se toman las decisiones de verificación y, a menudo, surge la última oportunidad de realizar correcciones antes del envío.

El registro automático del peso y el volumen en la zona de embalaje constituye, por tanto, un caso de uso específico del IoT: una estación de medición conectada genera datos de proceso directamente en el lugar de origen y los transmite sin interrupciones a los sistemas posteriores. Un medidor de volumen conectado a la red o una estación de medición combinada transmite los valores al software de envíos, al ERP, al WMS o a las reglas de control. Los primeros beneficios se aprecian rápidamente: datos de envío más fiables, menos introducciones manuales, detección temprana de incumplimientos de los valores límite y una base más sólida para la facturación y la gestión de reclamaciones. Además, la medición puede retroalimentar continuamente el registro de datos maestros cuando sea necesario validar datos reales de embalaje o de artículos.

El escollo habitual en este caso no radica tanto en la idea de la medición como en la disciplina del proceso: sin una asignación clara entre el paquete, el pedido y el sistema de destino, ni siquiera los valores de medición precisos aportan un beneficio operativo fiable.

En la zona de embalaje se aprecia especialmente bien lo que puede aportar una fuente de datos de IoT integrada en el proceso en las pymes. Cuando el peso y el volumen se registran automáticamente durante el embalaje, se genera un evento precisamente en el momento en que los datos de envío cobran relevancia técnica. Esto distingue este tipo de registro de datos de las correcciones a posteriori realizadas por los transportistas o de las nuevas mediciones manuales en caso de reclamación.

En este contexto,PackageHERO® puede considerarse un ejemplo de este tipo de arquitectura: no como un dispositivo de medición aislado, sino como una fuente de datos estructurados de volumen y peso dentro del proceso de embalaje en curso. La ventaja radica no tanto en el valor individual como en la disponibilidad fiable de esta información para la comprobación del envío, la validación de datos y los procesos posteriores de contabilización o autorización.

Esta orientación práctica resulta especialmente interesante para aquellas empresas que desean abordar el tema de forma pragmática. La estación de embalaje está claramente delimitada espacialmente, los datos son de relevancia comercial inmediata y el impacto puede evaluarse con relativa rapidez. De este modo, queda patente cómo un punto de medición concreto puede convertirse en un componente sólido de una arquitectura de IoT más amplia.

Un caso de uso típico del IoT en la intralogística son los traspasos poco claros, los tiempos de búsqueda de los soportes de carga y los cuellos de botella detectados con retraso en las puertas, las zonas de almacenamiento temporal o las líneas de transporte. El dato necesario en estos casos rara vez es complejo: por lo general, se trata de que un objeto haya pasado por un punto definido, de que una zona esté ocupada o de que una unidad técnica haya cambiado a un estado relevante. De ello se derivan registros automáticos, información sobre ocupación o avisos de avería para el control operativo.

La integración necesaria está estrechamente vinculada a la lógica del almacén. Un evento en una puerta debe interpretarse correctamente desde el punto de vista técnico en el WMS, la ocupación de una zona de almacenamiento temporal debe ser comprensible en el contexto del flujo de materiales, y los mensajes de estado técnico no deben quedar aislados del sistema de control. Para comprender de forma sólida el marco procesal, resulta útil fijarse en los procesos TUL, ya que el transporte, la manipulación y el almacenamiento proporcionan la estructura técnica para estos eventos.

Los primeros beneficios suelen hacerse evidentes rápidamente: menos consultas, menos esfuerzo de búsqueda y una escalación más temprana en caso de atascos o desvíos erróneos. Un escollo habitual es la delimitación clara de la tecnología de registro. El código de barras es, en primer lugar, AIDC o Auto-ID, y no automáticamente IoT; solo mediante la integración en la red, el procesamiento de eventos y el acoplamiento de sistemas se convierte en un componente de una arquitectura de procesos interconectada.

En el sector del transporte, el problema inicial suele ser el siguiente: los vehículos, las cajas móviles o los contenedores están en ruta, pero su ubicación o estado actuales solo se conocen con retraso. Por ello, el dato central suele ser la posición, complementada con eventos como la apertura de puertas, las desviaciones de temperatura o la entrada en una geozona. Esto resulta especialmente valioso cuando los activos se dejan estacionados sin supervisión o cuando los socios de transporte colaboran en redes distribuidas.

Para la integración, no basta con mostrar las ubicaciones en un mapa. Solo cuando los avisos cercanos a la hora estimada de llegada (ETA), las lógicas de estacionamiento, el tratamiento de excepciones o las alertas de calidad se conectan a los sistemas operativos, se genera un beneficio real para el proceso. Dependiendo de la aplicación, esto afecta a la gestión del transporte, la gestión de patios, el control de calidad o la comunicación con los clientes.

La ventaja inicial radica en una mayor capacidad de planificación y en una reducción de las consultas telefónicas. Por el contrario, los obstáculos típicos son la duración de la batería, la cobertura de radio, los lugares de montaje y la valoración errónea del GPS en entornos cubiertos o cercanos a edificios. Quien necesite un seguimiento en exteriores, aquí está en el lugar adecuado; quien quiera representar con precisión los movimientos dentro de naves, necesitará otros medios.

En la preparación de pedidos, el problema no suele radicar en la falta de existencias, sino en unos procesos mal sincronizados: los pedidos compiten por las mismas zonas, las prioridades cambian con poca antelación y las notificaciones llegan demasiado tarde al sistema. El dato relevante en este caso es el estado actual de procesamiento de una zona, un pedido o un recurso; es decir, no solo si hay mercancía disponible, sino también el nivel de carga que soporta en ese momento una fase del proceso.

Por lo tanto, la integración necesaria se adentra más en el control de pedidos que en el caso de simples eventos de identificación. Las priorizaciones, las rutas, las reservas de trabajo y las escalaciones deben poder reaccionar técnicamente a estas señales en el SGA o en el sistema de control. Una mera visualización de datos sin lógica de control aporta poco en este contexto.

El beneficio inicial se manifiesta en flujos de pedidos más estables, ciclos de coordinación más cortos y un mejor aprovechamiento de los recursos escasos. El escollo típico es la falsa expectativa de lograr un control verdaderamente adaptativo con tan solo unas pocas señales. Precisamente en este ámbito, los beneficios y la complejidad casi siempre aumentan de forma conjunta.