Visión general
El Control Tower de NexLog OS es la capa de decisión de la plataforma. Consume el event ledger (businessEvents) de WMS, TMS, OMS, YMS, Customs, ESG y Finanzas, aplica el exception engine a los desvíos, activa playbooks versionados y expone un digital twin para simulación what-if.
Es un control tower que actúa, no un panel que agrega KPIs: observa, decide, actúa y aprende sobre el mismo núcleo de eventos y datos canónicos, sin ETL.
Capacidades
Las ocho capacidades que forman la capa de decisión.
Executive Cockpit
KPIs consolidados de WMS, TMS, OMS, YMS, ESG y Finanzas, con drill-down por tenant, canal y región.
Exception engine
Motor de excepciones que detecta desvíos, activa playbooks y escala a una persona cuando es necesario.
Playbooks
Reglas versionadas que automatizan decisiones, con historial, rollback y auditoría completa a través del event ledger.
Digital twin
Réplica digital de la red logística, de los activos y de los pedidos, que refleja el estado real y permite la simulación what-if.
Network design
Optimización de la red: CDs, rutas, cross-dock, modal shift y relación costo-servicio.
Capacity planning
Planificación de capacidad por ventana, muelle, CD, ruta y recursos humanos.
Peak readiness
Prueba de estrés y plan de contingencia para Black Friday, Navidad y promociones masivas.
GenAI operativa
Asistente que redacta playbooks, explica excepciones en lenguaje natural, resume paneles para la dirección y sugiere ajustes de parámetros bajo supervisión.
Ciclo de decisión
Un control tower necesita observar, decidir, actuar y aprender. En NexLog OS, cada etapa tiene un componente propio.
| Etapa | Componente | Qué sucede |
|---|---|---|
| Observar | Event ledger (businessEvents) | Recibe los eventos canónicos de todos los módulos, correlacionados por correlationId y causationId. |
| Decidir | Exception engine | Detecta desvíos y elige el playbook aplicable. |
| Actuar | Playbooks | Automatizan la decisión o escalan al gestor, que aprueba o rechaza. |
| Aprender | Event ledger y GenAI | Cada decisión queda registrada en el ledger como evento auditable; la GenAI aprende sobre el estado transaccional. |
Fuentes de datos
El Control Tower lee las colecciones canónicas de cada módulo directamente del MongoDB operativo, sin un data warehouse separado para la operación.
| Módulo | Colecciones | Se usa para |
|---|---|---|
| WMS | movements, inventoryCounts | Exactitud de inventario y productividad. |
| TMS | shipments | OTD y seguimiento del tránsito. |
| OMS | orders | Completitud del pedido (order completeness). |
| YMS | dockSchedules | Capacidad y ocupación de muelles. |
| Customs | tradeDeclarations | Estado de las declaraciones y bloqueos del Denied Party Check. |
| ESG | carbonEntries | CO2e por región en el service footprint. |
| Finanzas | costAllocations, billing | Cost-to-serve por pedido. |
KPIs consolidados
OTIF unificado
Métrica consolidada de OTD (TMS), completitud del pedido (OMS) y exactitud de inventario (WMS).
Cost-to-serve
Costo total por pedido, prorrateado en costAllocations y billing.
Service footprint
Cobertura geográfica con tiempo de atención, cost-to-serve y CO2e por región.
Roles y gobernanza
El acceso sigue la autorización ABAC y los roles multi-tenant de la plataforma (enum en UPPER_SNAKE_CASE).
| Rol | Alcance | En el Control Tower |
|---|---|---|
TENANT_OWNER | Tenant | Ejecutivo dueño de la cuenta, con control total sobre el tenant. |
TENANT_ADMIN | Tenant | Administra usuarios, planes e integraciones. |
MANAGER | Módulo | Gestor operativo: aprueba excepciones y playbooks. |
OPERATOR | Módulo | Ejecuta las tareas de WMS, TMS y YMS generadas por las decisiones. |
VIEWER | Lectura | Solo lectura, para analistas y auditores. |
Gobernanza de playbooks y GenAI
Los playbooks son versionados, con historial y rollback. Cada sugerencia de la GenAI registra prompt, modelo y auditoría, y el usuario la aprueba o rechaza antes de cualquier cambio.
El Control Tower como capa de decisión de un supply chain OS
Los dashboards no son control towers
Muchas empresas llaman control tower a lo que, en la práctica, es un panel que agrega KPIs. Un control tower real necesita observar, decidir, actuar y aprender.
En NexLog OS, consume el event ledger (businessEvents) de todos los módulos, aplica el exception engine a los desvíos, escala playbooks versionados y expone el digital twin para simulación what-if. OTIF unificado, cost-to-serve y service footprint quedan en el mismo panel, sin ETL.
Digital twin y what-if sobre el estado real
Con el MDM unificado y el event ledger central, las simulaciones se ejecutan sobre el estado real del negocio. Network design prueba escenarios de nueva red, capacity planning dimensiona muelles, rutas y CDs antes del pico y peak readiness valida la operación frente a los picos esperados.
Así, capacity planning pasa a ser un ejercicio continuo, y no anual.
GenAI aplicada a la cadena de suministro
La GenAI de NexLog OS actúa como copiloto: sugiere playbooks, explica excepciones en lenguaje natural, resume paneles para la dirección y ajusta parámetros bajo supervisión.
Como vive en el mismo núcleo de eventos y datos canónicos, no necesita un data lake paralelo: aprende sobre el estado transaccional, con gobernanza y trazabilidad nativas.