IT de la cadena de suministro sin soberanía de datos

Los sistemas logísticos informan del estado sin que se hayan aclarado la titularidad y la calidad de los datos a lo largo de la cadena de suministro. Para el CIO y el CDO, esto se convierte en una cuestión de control y responsabilidad que va más allá de las interfaces e implica a proveedores y 3PL. Quien controla los datos de estado también gestiona los riesgos operativos, la capacidad de auditoría y la fiabilidad de los procesos de planificación y previsión.

RelacionadoReglamento de Datos de la UE: garantizar la soberanía sobre los datos y los procesos  /  La geopolítica fragmenta las cadenas de suministro: los CIO bajo presión

Dónde se rompe la soberanía sobre los datos en la cadena de suministro

La soberanía sobre los datos se rompe donde la titularidad y la responsabilidad del sistema divergen. El remitente gestiona el pedido, el transportista el estado del transporte, el almacén el inventario y el destinatario la recepción de mercancías. Cada uno genera estados, a menudo sin una definición común sobre quién gestiona el conjunto de datos principal ni quién puede aprobar correcciones.

Las brechas surgen en los puntos de entrega entre sistemas propios y ajenos. Tan pronto como un 3PL, un transportista o un portal de proveedores establece un estado, la información abandona el ámbito de control propio. Entonces, el departamento de TI observa eventos relevantes desde el punto de vista operativo, pero cuya procedencia, lógica de modificación y normas de eliminación quedan fuera de su gobernanza.

Sin una titularidad clara, surge un control paralelo. Los departamentos crean listas en Excel, canales de mensajería y vistas de seguimiento paralelas, porque el sistema principal no refleja el estado de manera fiable. El resultado es una doble verdad: el ERP muestra un estado, la logística opera con otro y la contabilidad calcula con un tercero.

Datos maestros, datos de eventos y límites del sistema

TI y las áreas especializadas deben considerar los datos maestros y los datos de eventos por separado. Los datos maestros de materiales, socios, ubicaciones y envases forman el marco de referencia estable. Los datos de eventos describen movimientos y cambios de estado a lo largo de la cadena. Quien mezcle ambos sin límites de dominio claros convierte las correcciones de estado en problemas de datos maestros y viceversa.

Los límites del sistema rara vez coinciden con las responsabilidades organizativas. Un sistema de gestión de almacenes puede llevar el control de inventario, mientras que los eventos de transporte y seguimiento provienen de portales de transportistas y el pedido permanece en el ERP. Sin un modelo de objetos canónico para envíos, unidades de manipulación y hitos, queda sin definir qué sistema establece el estado principal en caso de conflicto.

Los estándares sectoriales para eventos de cadena de suministro facilitan la interoperabilidad, pero no reemplazan la propiedad. El estándar GS1 EPCIS 2.0 (Electronic Product Code Information Services, ratificado en junio de 2022) define eventos de visibilidad con las dimensiones Qué, Cuándo, Dónde, Por qué y Cómo, así como tipos de eventos como ObjectEvent, AggregationEvent, TransformationEvent, TransactionEvent y AssociationEvent. El vocabulario empresarial básico (CBV) 2.0, que lo acompaña, proporciona valores uniformes para pasos comerciales y disposiciones. La directriz de implementación EPCIS y CBV 2.0 de GS1 (marzo de 2023) separa claramente los datos de eventos de visibilidad de los datos maestros y las transacciones. Quienes utilicen modelos de eventos cercanos a EPCIS ganarán comparabilidad entre socios. Queda por definir quién verifica la calidad de los eventos, quién descarta duplicados y quién inicia el proceso de corrección en caso de estados contradictorios.

Las integraciones suelen fracasar por suposiciones implícitas sobre marcas de tiempo, zonas horarias, códigos de ubicación y códigos de estado. Un «entregado» de un transportista no es lo mismo que una recepción contabilizada en el ERP. Sin reglas de mapeo y propiedad semántica, cualquier indicación de estado se convierte en una cuestión de interpretación en lugar de una base de control.

Contratos: ¿Quién responde por los datos de estado incorrectos?

Los datos de estado incorrectos abren una laguna contractual y afectan por igual a compras, legal y TI. Los acuerdos de nivel de servicio suelen regular plazos, ventanas de recogida y casos de daños, pero rara vez la calidad y vinculación de los mensajes de estado. Cuando un sistema notifica «entregado» y la mercancía falta, surge inmediatamente la cuestión de responsabilidad, prueba y obligación de corrección.

Los contratos con proveedores y operadores logísticos 3PL necesitan una cláusula de datos con roles definidos. Deben especificarse el sistema principal por objeto, campos obligatorios, frecuencia de actualización, plazos de corrección y vías de escalado. También son relevantes el almacenamiento, los derechos de información y la obligación de registrar los cambios de estado con causa y marca de tiempo de manera trazable.

La responsabilidad solo entra en juego si los errores son medibles y atribuibles. Sin métricas de calidad acordadas, «estado incorrecto» sigue siendo una cuestión de opinión. Los modelos de contrato preparados específicamente para la calidad de los datos de estado en alianzas logísticas son difíciles de encontrar en las asociaciones sectoriales. Para orientar la responsabilidad y el uso de datos, sirven como referencia las condiciones contractuales modelo no vinculantes (Model Contractual Terms) de la Comisión Europea sobre el Reglamento de Datos en el proyecto de recomendación de noviembre de 2025, entre otros, para la cesión voluntaria de datos entre empresas. No obstante, los socios deben definir en el SLA y las cláusulas de datos las métricas de calidad para eventos incorrectos, actualizaciones tardías y estados contradictorios, adaptadas a cada caso.

Desde el punto de vista legal y operativo, la carga de la prueba y el acceso al sistema suelen separarse. El cliente asume el riesgo de control, mientras que el socio conserva los datos brutos. Por ello, el CIO y el CDO deben aclarar con compras y legal qué derechos sobre los datos entran en vigor en caso de incidencia y quién obtiene acceso de auditoría a los historiales de eventos.

Requisitos mínimos para la arquitectura de integración

La arquitectura de integración debe garantizar la propiedad técnica y hacer más que simplemente proporcionar interfaces. Como mínimo, se requieren un modelo de dominio canónico para pedido, envío, inventario y evento, así como un sistema de registro claro para cada objeto. Esto incluye idempotencia, trazabilidad y la posibilidad de registrar correcciones de estado como nuevos eventos en lugar de sobrescripciones silenciosas.

Las conexiones con socios necesitan contratos de interfaz vinculantes. Las especificaciones de API o EDI deben definir códigos de estado, atributos obligatorios, códigos de error y lógica de repetición. La directriz de implementación GS1 sobre EPCIS y CBV (versión 2.0, marzo de 2023) describe cómo los sistemas de visibilidad se integran en entornos IT típicos, qué modelos de coreografía controlan el intercambio de eventos y qué pasos de validación garantizan la interoperabilidad. La recomendación VDA 4998 (junio de 2021) complementa los procesos EDI establecidos con un modelo de datos y APIs REST para el seguimiento y localización (Track & Trace) en la cadena de suministro automotriz. Sin versionado y procesos de aceptación, cada integración con socios sigue siendo un caso especial.

La observabilidad forma parte del equipamiento mínimo. Los eventos deben ser verificables en cuanto a completitud, orden, latencia y contradicciones. Las alertas no deben activarse únicamente cuando el cliente reclame. Un monitor de integración que muestre hitos faltantes y saltos de estado es, al mismo tiempo, una herramienta de control y una garantía de responsabilidad.

La clasificación de datos y la protección de acceso son parte de la arquitectura y deben diseñarse desde el principio. Los datos de estado suelen contener información sobre socios, cantidades y ubicaciones con implicaciones críticas en términos de competencia y cumplimiento normativo. El rol, el propósito y la protocolización deben definirse antes del lanzamiento de la interfaz.

Conjunto de KPI que compras e IT deben compartir

La gestión solo funciona si compras e IT comparten las mismas métricas. Los valores de disponibilidad puramente técnicos no bastan, ni tampoco la puntualidad de entrega comercial por sí sola. Se necesita un conjunto común que incluya calidad de datos, impacto en el proceso y cumplimiento contractual.

A nivel de datos, cuentan la completitud de los campos obligatorios, el porcentaje de estados contradictorios, la tasa de correcciones y la latencia de eventos hasta su visibilidad en el sistema principal. A nivel de procesos, cuentan la planificabilidad de las entradas de mercancías, el trabajo manual adicional y los casos de escalación por lagunas en los estados. A nivel contractual, cuentan el cumplimiento de las obligaciones de actualización y los tiempos demostrables de corrección por parte de los socios.

La gobernanza debe garantizar la propiedad en el día a día. Un comité conjunto formado por IT, compras, logística y legal establece umbrales, decide sobre la aprobación de socios y evalúa los errores recurrentes en los datos como un riesgo para el proveedor. La calidad de los estados se convierte así en parte de la evaluación de socios y de la hoja de ruta de integración.

Para el CIO y el CDO, la consecuencia es clara: la IT de la cadena de suministro sin soberanía sobre los datos sigue siendo una visibilidad costosa sin capacidad de gestión. Quien no gestione la propiedad, los contratos, los estándares mínimos de arquitectura y los KPI compartidos como un programa único, financiará integraciones que solo informan estados y dejan responsabilidades sin definir.

Preguntas frecuentes

Fuente de la imagen: Generada por IA (julio 2026)

Traducido del original en alemán con inteligencia artificial. La versión alemana es la de referencia.