En logística, la métrica decisiva es cuánto dura una excepción
Por Equipo Quantum Developers
Resumir:
El tablero que presume miles de contenedores rastreados puede seguir siendo operacionalmente inútil. La tesis de este artículo es verificable: un sistema de monitoreo crea valor cuando reduce el tiempo entre la primera evidencia de una desviación y una acción con dueño, no cuando solo aumenta el número de embarques visibles. Para comprobarlo no hace falta atribuir ahorros imaginarios; basta medir si una excepción importante fue detectada, asignada, decidida y cerrada antes de que perdiera utilidad.
La visibilidad es un medio. Una ETA que cambia y nadie califica no es control. Una alerta enviada a diez personas sin responsable tampoco. El objeto de diseño debe ser un reloj de excepción que conecte eventos, contexto y autoridad.
Primero normalice qué ocurrió y cuándo
Los eventos logísticos provienen de navieras, terminales, transportistas, sensores y registros internos. Si cada fuente expresa hitos con nombres y tiempos distintos, el reloj empieza en puntos incompatibles. DCSA explica que su estándar Track & Trace usa modelos, definiciones y APIs interoperables para intercambiar eventos de la travesía del contenedor y mejorar el manejo de excepciones (DCSA Track & Trace). Esa normalización no resuelve la operación por sí sola, pero hace comparable la evidencia.
GS1 EPCIS estructura un evento alrededor de qué ocurrió, cuándo, dónde y por qué; su estándar incluye eventTime, recordTime, ubicación y paso de negocio (GS1 EPCIS 2.0.1). La guía de implementación aclara una diferencia crucial: eventTime representa el momento del evento, mientras recordTime indica cuándo llegó al repositorio (guía EPCIS y CBV). La distancia entre ambos permite distinguir una operación tardía de una notificación tardía.
Un registro mínimo debe conservar: identificador del embarque, tipo de evento normalizado, tiempo observado, tiempo recibido, fuente, ubicación, hito previsto relacionado, calidad de evidencia y versión del esquema. Sobrescribir la ETA anterior destruye la historia que explica la excepción; almacene revisiones como eventos.
El reloj de excepción
Propongo seis marcas. Es un modelo operativo, no un estándar externo:
- T0 — expectativa: momento o ventana prevista para un hito.
- T1 — evidencia: primera observación que contradice o pone en riesgo la expectativa.
- T2 — calificación: el sistema determina tipo, severidad y posible impacto.
- T3 — aceptación: un responsable reconoce el caso.
- T4 — decisión: se selecciona una acción o se documenta por qué no actuar.
- T5 — cierre: se confirma resultado, nueva expectativa y evidencia final.
De estas marcas salen cuatro métricas que no deben mezclarse: latencia de detección T2−T1, latencia de asignación T3−T2, latencia de decisión T4−T3 y tiempo de cierre T5−T4. También conviene vigilar T1−T0 cuando la excepción solo puede conocerse después del hito esperado. Cada intervalo señala un problema diferente: datos, clasificación, capacidad del equipo o ejecución.
No defina un único SLA para toda alerta. Una variación sin acción posible puede archivarse como contexto; una conexión en riesgo con alternativa disponible requiere otro reloj. La severidad debe combinar consecuencia, ventana restante, confianza de la evidencia y reversibilidad de la respuesta.
Contrato de excepción y propiedad
Cada clase de excepción necesita un contrato:
| Campo | Pregunta que responde |
|---|---|
| reason_code | ¿Qué condición se incumplió? |
| evidence_event | ¿Qué evento inició el reloj? |
| severity | ¿Qué consecuencia y ventana existen? |
| case_owner | ¿Quién coordina hasta el cierre? |
| decision_authority | ¿Quién puede cambiar ruta, costo o compromiso? |
| next_action | ¿Qué paso concreto sigue? |
| due_at | ¿Cuándo debe decidirse? |
| status | ¿Nueva, aceptada, decidida, bloqueada o cerrada? |
| closure_evidence | ¿Qué demuestra el resultado? |
Separe roles. El dueño de señal corrige integraciones y calidad; el dueño de caso mantiene contexto y presión temporal; la autoridad de decisión acepta costo o compromiso; el dueño del dato resuelve semántica. Una bandeja compartida sin esta separación convierte todos los retrasos en “falta de seguimiento”.
Ejemplo ilustrativo
Suponga un transbordo con una ventana de conexión definida por la operación. Llega un evento de descarga más tarde que la expectativa y, después, una ETA revisada para el siguiente tramo. El sistema vincula ambos al mismo objeto embarque, abre CONNECTION_AT_RISK y conserva tiempos observado y recibido.
Si existe una alternativa autorizada y queda ventana para solicitarla, la severidad sube y el caso se asigna al coordinador. Si no existe acción posible, el evento informa al cliente pero no compite en la cola de decisiones. Esta diferencia evita que una gran cantidad de alertas informativas o duplicadas oculte los pocos casos accionables. Los valores de la ventana y de severidad deben provenir de la política de la empresa; no son universales.
Cómo instrumentarlo en Quantum
En un entorno como Quantum Automation Center, el objeto embarque puede unir eventos con el estado de la automatización, una línea de tiempo, artefactos y logs. Shipment Monitor puede presentar la vista operativa, mientras el plano de control conserva quién ejecutó cada paso y qué evidencia produjo.
Una pantalla útil no empieza por un contador total. Empieza por excepciones abiertas ordenadas por tiempo restante para decidir, muestra la edad de cada fase y permite filtrar por responsable, razón y fuente. La analítica debe separar cobertura de datos, calidad de eventos y desempeño de respuesta. Así una mejora de ingestión no se confunde con una mejora de operación.
El contrapunto: sin cobertura tampoco hay reloj
Contar contenedores no es una métrica de resultado, pero la cobertura sí es un requisito. Si faltan eventos de una naviera o un puerto, la latencia observada puede parecer excelente porque los casos nunca se abren. Antes de premiar tiempos rápidos, publique el denominador: embarques esperados, embarques con eventos suficientes, fuentes tardías y periodos sin señal.
Además, no todo retraso necesita intervención. Forzar una acción sobre cada desviación aumenta ruido y puede empeorar decisiones. El contrato debe permitir NO_ACTION_OBSERVE con motivo y revisión posterior.
Cuándo no usar este enfoque
No construya un reloj detallado si no puede establecer hitos confiables, si los eventos carecen de identidad común o si nadie tiene autoridad para actuar. Empiece corrigiendo fuentes y responsabilidades. Tampoco lo use para penalizar equipos cuando el retraso depende de un tercero y no existe alternativa; mida por separado información, decisión y resultado.
La pregunta ejecutiva correcta no es “¿cuántos contenedores vemos?”. Es “¿qué excepción accionable lleva más tiempo sin decisión, quién la posee y qué evidencia falta?”. Cuando el sistema responde eso de forma consistente, la visibilidad empieza a convertirse en control.
