Un cambio de ETA no merece alerta hasta que cambia una decisión

El monitoreo de embarques crea control operativo solo cuando un cambio de estado se convierte en alerta por modificar una decisión, una promesa o una acción, mientras las actualizaciones duplicadas quedan correlacionadas sin volver a interrumpir al equipo. Mostrar cada ETA recibida produce una actividad visible, pero obliga a operadores a reconstruir contexto, discriminar repeticiones y decidir quién actúa.

Evento, condición y alerta son objetos distintos

Un evento afirma que algo ocurrió o fue observado por una fuente. Una condición compara el estado nuevo con plan, promesa o política. Una alerta asigna una acción, un dueño y un reloj porque la condición requiere intervención.

Separarlos permite conservar toda la historia sin convertirla en ruido. Un cambio de ETA puede actualizar la línea de tiempo; solo abre o modifica una alerta si cruza una regla de accionabilidad.

Normalice antes de decidir

GS1 EPCIS estructura datos de visibilidad alrededor de qué, cuándo, dónde, por qué y cómo, con vocabulario de contexto de negocio. IATA ONE Record propone un modelo de datos compartido y APIs para carga aérea, con la fuente como dueña de sus datos. La documentación de DCSA Track and Trace estandariza eventos para seguimiento de contenedores.

No son un catálogo único de alertas. Sí ofrecen una base para conservar identidad, tipo de evento, ubicación, tiempo y fuente antes de aplicar políticas internas.

Un sobre normalizado debería incluir event_id, source, shipment_ref, equipment_or_piece_ref, event_type, event_time, observed_at, location, source_status, payload_version y supersedes. Conserve el mensaje original como artefacto protegido cuando sea necesario.

Contrato mínimo de alerta

Campo	Propósito
alert_id y shipment_id	identidad estable de trabajo
event_fingerprint	correlación y deduplicación
source_refs	eventos y versiones que sostienen la condición
previous_state/current_state	cambio evaluado
plan_ref y promise_ref	expectativa contra la cual se compara
deviation_type	ETA, hito, ruta, documentación o custodia
actionability_class	informar, observar, actuar o escalar
consequence	qué decisión o promesa está expuesta
owner y due_at	responsable y reloj
suppression_key/policy	por qué no se crea otra interrupción
status y resolution_code	abierta, reconocida, resuelta, reabierta
outcome_ref	confirmación de acción y resultado

severity sin consequence es decorativa. Una etiqueta “alta” debe explicar qué ventana, compromiso o control está en riesgo y qué autoridad puede responder.

Cuatro clases de accionabilidad

Informar: el evento completa historia pero no cambia una decisión. Observar: existe desviación, aunque todavía no cruza el punto de acción; se reevalúa con el siguiente evento o vencimiento. Actuar: hay una tarea definida, como solicitar documento, cambiar cita o avisar a un receptor. Escalar: la acción normal no puede proteger la consecuencia y una autoridad debe decidir.

La clase depende del objeto y la promesa, no solo de minutos de diferencia. Un mismo cambio puede ser informativo para carga sin compromiso inmediato y accionable para una conexión cercana. Evite umbrales universales.

Deduplicar sin borrar evidencia

Calcule un fingerprint con fuente, identificador del objeto, tipo, tiempo efectivo y versión o identificador del evento. Si llega el mismo evento, añada observación técnica sin crear otra alerta. Si una fuente corrige el evento, use supersedes y vuelva a evaluar.

Para actualizaciones sucesivas de la misma condición, use suppression_key basado en embarque, desviación y acción. La alerta abierta recibe nueva evidencia, actualiza estado y conserva todas las versiones. Solo reinterrumpa cuando:

• cambia la clase de accionabilidad o consecuencia;
• aparece una fuente contradictoria relevante;
• vence la acción asignada;
• la nueva evidencia invalida la resolución;
• la política de escalamiento exige otra autoridad.

Una ventana de tiempo fija por sí sola es insuficiente. Puede ocultar un cambio material dentro de la ventana o generar ruido al terminarla aunque nada haya cambiado.

Ejemplo ilustrativo: ETA que se mueve varias veces

Este escenario es ilustrativo. Un transportista publica una ETA posterior y el motor determina que todavía no afecta la cita de recepción. La condición queda en observar, sin interrupción. Otra actualización repite el mismo evento y se deduplica.

Después, una corrección cruza la ventana de la cita. La política abre una alerta “reprogramar recepción”, asigna al coordinador y enlaza los tres eventos. Una actualización adicional mueve la ETA, pero la acción sigue siendo la misma; la alerta se actualiza sin crear otra. Cuando el almacén confirma una nueva cita, outcome_ref cierra. Si una fuente posterior devuelve la ETA original pero la cita ya cambió, el sistema no borra historia: evalúa si hay que restaurar o mantener.

El operador ve una unidad de trabajo con contexto, no cuatro mensajes desconectados.

Fuentes discordantes y confianza operacional

No promedie ETAs de fuentes diferentes. Conserve autoridad por tipo de evento, procedencia y observed_at. Una fuente puede ser autoritativa para un hito físico y otra para una reserva. Si discrepan, abra una condición de conflicto con evidencia; no invente una certeza.

La confianza útil describe completitud y procedencia, no una puntuación opaca. “Evento del transportista sin ubicación” orienta mejor una acción que “confianza media”.

Métricas para un sistema que ayuda

Mida eventos recibidos, eventos deduplicados, condiciones abiertas, alertas por clase, tiempo hasta dueño, antigüedad de acciones, escalaciones, reaperturas y cierres con outcome_ref. Revise alertas sin acción y acciones creadas sin cambio de consecuencia.

No convierta “alertas evitadas” en ahorro sin observar trabajo real. Una supresión es útil si conserva evidencia y reduce interrupción redundante; puede ser peligrosa si baja una cifra ocultando casos.

Cómo representarlo en Quantum

En Quantum Automation Center, el embarque funciona como objeto de negocio. La línea de tiempo conserva eventos; artefactos y logs enlazan evidencia; ejecuciones muestran normalización y evaluación; permisos y aprobaciones asignan autoridad; analíticas separan eventos, condiciones, alertas y resultados. La documentación de objetos de negocio conecta estado y operación.

El agente puede resumir evidencia y proponer acción. La política decide si abre, actualiza, suprime o escala; el humano conserva decisiones sensibles.

El contrapunto: suprimir también puede ocultar

Suprimir alertas puede esconder deterioro o fuentes discordantes; la supresión debe ser una regla versionada, conservar cada evento y reabrir cuando cambien consecuencia, evidencia o acción requerida. Audite casos suprimidos y permita que el operador inspeccione la cadena.

Un equipo puede preferir más sensibilidad durante un cambio de proveedor. La política debe ser ajustable por población y vigencia, no una constante escondida.

Cuándo no automatizar alertas

No lo haga cuando las fuentes carecen de identidad y tiempo confiables, el proceso es demasiado esporádico para definir responsables o una señal de seguridad exige notificación independiente sin supresión. Primero establezca el contrato de eventos y el procedimiento humano.

Tampoco automatice una promesa que nadie posee. Si no existe acción, dueño o autoridad, una alerta solo redistribuye ansiedad.

La prueba del contrato

Tome una alerta y responda: qué evento la abrió, qué promesa cambió, por qué era accionable, quién recibió la tarea, qué actualizaciones se suprimieron, qué evidencia reabrió o cerró y qué resultado siguió. Si el sistema solo muestra “ETA cambió”, hay seguimiento; todavía no hay control de alertas.

Sources

• GS1 EPCIS and Core Business Vocabulary — gs1.org
• IATA ONE Record — iata.org
• DCSA Track and Trace Standard Documentation — dcsa.org