Visão geral
O Control Tower do NexLog OS é a camada de decisão da plataforma. Ele consome o event ledger (businessEvents) de WMS, TMS, OMS, YMS, Customs, ESG e Financeiro, aplica o exception engine sobre os desvios, aciona playbooks versionados e expõe um digital twin para simulação what-if.
É um control tower que atua, não um painel agregador de KPIs: observa, decide, aciona e aprende no mesmo núcleo de eventos e dados canônicos, sem ETL.
Capacidades
As oito capacidades que formam a camada de decisão.
Executive Cockpit
KPIs consolidados de WMS, TMS, OMS, YMS, ESG e Financeiro, com drill-down por tenant, canal e região.
Exception engine
Motor de exceções que detecta desvios, aciona playbooks e escala para uma pessoa quando necessário.
Playbooks
Regras versionadas que automatizam decisões, com histórico, rollback e auditoria completa pelo event ledger.
Digital twin
Réplica digital da rede logística, dos ativos e dos pedidos, que reflete o estado real e permite simulação what-if.
Network design
Otimização de malha: CDs, rotas, cross-dock, modal shift e relação custo-serviço.
Capacity planning
Planejamento de capacidade por janela, doca, CD, rota e recurso humano.
Peak readiness
Stress test e plano de contingência para Black Friday, Natal e promoções massivas.
GenAI operacional
Assistente que redige playbooks, explica exceções em linguagem natural, resume painéis para a liderança e sugere ajustes de parâmetros sob supervisão.
Ciclo de decisão
Um control tower precisa observar, decidir, acionar e aprender. No NexLog OS, cada etapa tem um componente próprio.
| Etapa | Componente | O que acontece |
|---|---|---|
| Observar | Event ledger (businessEvents) | Recebe os eventos canônicos de todos os módulos, correlacionados por correlationId e causationId. |
| Decidir | Exception engine | Detecta desvios e escolhe o playbook aplicável. |
| Acionar | Playbooks | Automatizam a decisão ou escalam para o gestor, que aprova ou rejeita. |
| Aprender | Event ledger e GenAI | Cada decisão fica registrada no ledger como evento auditável; a GenAI aprende sobre o estado transacional. |
Fontes de dados
O Control Tower lê as collections canônicas de cada módulo direto do MongoDB operacional, sem data warehouse separado para a operação.
| Módulo | Collections | Usa para |
|---|---|---|
| WMS | movements, inventoryCounts | Acurácia de estoque e produtividade. |
| TMS | shipments | OTD e acompanhamento do trânsito. |
| OMS | orders | Completude de pedido (order completeness). |
| YMS | dockSchedules | Capacidade e ocupação de docas. |
| Customs | tradeDeclarations | Status das declarações e bloqueios do Denied Party Check. |
| ESG | carbonEntries | CO2e por região no service footprint. |
| Financeiro | costAllocations, billing | Cost-to-serve por pedido. |
KPIs consolidados
OTIF unificado
Métrica consolidada de OTD (TMS), completude de pedido (OMS) e acurácia de estoque (WMS).
Cost-to-serve
Custo total por pedido, com rateio em costAllocations e billing.
Service footprint
Cobertura geográfica com tempo de atendimento, cost-to-serve e CO2e por região.
Papéis e governança
O acesso segue a autorização ABAC e os papéis multi-tenant da plataforma (enum em UPPER_SNAKE_CASE).
| Papel | Escopo | No Control Tower |
|---|---|---|
TENANT_OWNER | Tenant | Executivo dono da conta, com controle total no tenant. |
TENANT_ADMIN | Tenant | Administra usuários, planos e integrações. |
MANAGER | Módulo | Gestor operacional: aprova exceções e playbooks. |
OPERATOR | Módulo | Executa as tarefas de WMS, TMS e YMS geradas pelas decisões. |
VIEWER | Leitura | Somente leitura, para analistas e auditores. |
Governança de playbooks e GenAI
Playbooks são versionados, com histórico e rollback. Cada sugestão da GenAI registra prompt, modelo e auditoria, e o usuário aprova ou rejeita antes de qualquer mudança.
Control Tower como camada de decisão de um supply chain OS
Dashboards não são control towers
Muitas empresas chamam de control tower o que, na prática, é um painel agregador de KPIs. Um control tower real precisa observar, decidir, acionar e aprender.
No NexLog OS, ele consome o event ledger (businessEvents) de todos os módulos, aplica o exception engine sobre desvios, escala playbooks versionados e expõe o digital twin para simulação what-if. OTIF unificado, cost-to-serve e service footprint ficam no mesmo painel, sem ETL.
Digital twin e what-if sobre o estado real
Com o MDM unificado e o event ledger central, as simulações rodam sobre o estado real do negócio. Network design testa cenários de nova malha, capacity planning dimensiona docas, rotas e CDs antes do pico e peak readiness valida a operação contra os picos esperados.
Com isso, capacity planning vira um exercício contínuo, e não anual.
GenAI aplicada a supply chain
A GenAI do NexLog OS atua como copiloto: sugere playbooks, explica exceções em linguagem natural, resume painéis para a liderança e ajusta parâmetros sob supervisão.
Como vive no mesmo núcleo de eventos e dados canônicos, ela não precisa de data lake paralelo: aprende sobre o estado transacional, com governança e rastreabilidade nativas.