O quão "tempo real" é o tempo real? Níveis de latência de dados e alertas de limite para o BI de armazéns

Nosso BI é em tempo real? Quase todos os gerentes de TI de armazéns já receberam essa pergunta do chefe. E o primeiro instinto de quase todos é respondê-la como uma pergunta tecnológica: conseguimos atualizar a cada segundo? Precisamos de processamento de streams?

Com base nos meus anos acompanhando projetos de digitalização de armazéns, essa pergunta na verdade não é tecnológica. Trata-se de cadência de decisões: decisões de negócio diferentes toleram níveis completamente diferentes de latência de dados. Usar dados em nível de segundos para uma decisão T+1 é desperdício; usar dados T+1 para uma decisão em nível de segundos é um acidente. O que o chefe entende por "tempo real", na maioria dos casos, não é tempo real em nenhum sentido físico.

Consideremos duas histórias que realmente aconteceram.

História um: um atraso de 20 minutos que "perdeu" um lote de pedidos urgentes (2024, um armazém 3PL no leste da China). Essa instalação preparava pedidos para uma marca de cosméticos: 8,000 pedidos por dia, 30,000 durante os picos promocionais. Seu painel de BI extraía dados de pedidos do OMS a cada 20 minutos. Na manhã do festival de compras "618", a marca lançou um lote urgente de pedidos de pagamento final que precisavam ser enviados no mesmo dia. A operação acompanhava o número de "pedidos pendentes de expedição" no painel. Ele permanecia estável em torno de 400, tudo parecia bem. Na realidade, o atraso no OMS já havia subido para 1,400: a extração de BI havia congelado às 9:40 a.m., e as três extrações seguintes falharam porque o banco de dados do OMS estava bloqueado. Mas o painel não mostrava nenhum alerta de anomalia, então o número simplesmente ficou ali, congelado. Às 11 a.m., quando alguém percebeu, o horário limite da transportadora já havia passado. Quase 900 pedidos perderam o envio no mesmo dia, e a marca deduziu 15% da taxa de serviço daquele mês. A descoberta real: o problema não era a latência de 20 minutos em si. Era que ninguém sabia que a latência havia ultrapassado seu limite: o painel não exibia nenhum carimbo de "dados atualizados às", então os operadores assumiam que cada número que viam era a verdade atual.

História dois: $60,000 gastos em processamento de streams em tempo real que ninguém assistia (2023, um armazém próprio de e-commerce no sul da China). Depois de visitar a "cabine digital" de uma empresa líder, o chefe exigiu que seu próprio BI fosse "em tempo real em nível de segundos". A equipe de TI passou quatro meses e mais de $60,000 reconstruindo o data warehouse T+1 em uma arquitetura de streaming com Kafka + Flink. Os números na tela grande atualizavam a cada cinco segundos. Quando visitei seis meses depois, perguntei ao supervisor de operações com que frequência olhavam a tela em tempo real. A resposta: "Todos os dias durante a primeira semana. Depois percebemos que os números pulando não nos ajudavam a fazer nada, então paramos. Ainda usamos o resumo da manhã em Excel". A razão era simples: o ritmo de decisões do armazém é por ondas: as ondas de picking são liberadas a cada duas horas, o reabastecimento é revisado diariamente, as escalas de mão de obra são definidas no dia anterior. A atualização a cada cinco segundos agregava zero valor, e os números piscando ainda criavam a falsa impressão de que os dados eram "instáveis".

Ambas as histórias apontam para a mesma conclusão: a latência de dados é um parâmetro de negócio a ser gerenciado em níveis, não uma métrica técnica onde menor é sempre melhor. A base para a estratificação deve ser "para qual decisão este dado é usado", não "quão rápido a tecnologia pode ir".

Um framework de quatro níveis de latência de dados para o BI de armazéns

Com base na sensibilidade temporal das decisões, a latência de dados do BI de armazéns divide-se em quatro níveis, cada um mapeado para diferentes tipos de decisão, abordagens técnicas e níveis de custo:

Este é um julgamento contraintuitivo que vale a pena declarar explicitamente: para mais de 90% dos armazéns, o nível de minutos é o teto prático do "tempo real": ir além, para os segundos, tem retorno sobre investimento negativo. Por quê? Porque o armazém físico em si não opera em nível de segundos. Um picker leva três minutos para caminhar da prateleira à estação de embalagem; uma empilhadeira leva quinze minutos para completar um ciclo de reabastecimento; uma onda leva de uma a duas horas da liberação à conclusão. Dados que superam o mundo físico em uma ordem de magnitude não têm nenhuma decisão para consumir esse "realismo" extra. Essa é a lição dos $60,000 da história dois.

Então, como um armazém deve definir seus próprios níveis de latência? Recomendo um framework de três etapas:

Etapa 1: listar cada decisão. Anote todas as decisões que dependem de dados de BI: liberação de ondas, interceptação de exceções, realocação de mão de obra, gatilhos de reabastecimento, avaliações de desempenho, liquidação financeira, e para cada uma anote "até quando o dado precisa estar visível".

Etapa 2: trabalhar para trás a partir da cadência de decisões. Uma regra prática útil: a latência dos dados de suporte deve ficar entre um quarto e metade da frequência de decisão, reservando tempo para a janela de "ver dados, analisar, agir".

Etapa 3: atribuir tecnologia por nível. Apenas os cenários que genuinamente precisam de segundos recebem processamento de streams; todo o resto usa abordagens em lote mais baratas. Em um armazém típico, não mais que cinco métricas precisam realmente de latência em nível de segundos (status de equipamentos, temperatura, segurança contra incêndio, docas, estado do sorter).

Alertas de limite: a configuração que importa mais que a própria latência

A verdadeira lição da história um não foi "a latência de 20 minutos é lenta demais", foi "a violação de latência não avisou ninguém". Uma vez definidos os níveis de latência, a segunda tarefa é configurar alertas de limite de latência para cada nível: quando a latência real excede o máximo permitido do nível, o sistema deve avisar proativamente alguém.

Um manual prático:

1. Definir um SLA por fonte de dados: por exemplo, "dados de pedidos do OMS, nível de minutos, limite de latência 30 minutos". Escreva na documentação, não apenas na cabeça do engenheiro de ETL.
2. Forçar um carimbo de "dados às" em cada painel. A proteção mais barata e eficaz que existe: cada painel e relatório deve carregar um carimbo de "Dados às HH:MM". Um operador que vê "Dados às 9:40" às 11:00 ficará naturalmente desconfiado. O acidente da história um muito provavelmente não teria acontecido com esse carimbo no lugar.
3. Escalar pela severidade da violação: violação ×1 → avisar a operação de TI, nova tentativa automática; ×2 → alertar o supervisor de operações, exibir um banner de "dados atrasados"; interrupção total (três falhas consecutivas) → chamar o gerente do armazém, esmaecer automaticamente o painel com um rótulo de "dados vencidos".
4. Colocar a própria latência no BI. Construir um painel de "saúde dos dados" que acompanhe a latência real versus o SLA por fonte. A equipe de dados também precisa ser governada por dados.

Uma compensação aqui merece discussão: limites de alerta muito apertados afogarão a operação em falsos alarmes; muito frouxos, são decoração. Os jobs de ETL de armazéns são inerentemente instáveis: bloqueios de tabelas no sistema de origem, microquedas de rede, atrasos do agendador, então violações ocasionais de 10–20% do limite são normais. Limites desenhados muito apertados geram dezenas de alertas diários, os operadores começam a ignorar todos eles, e o incidente real passa despercebido. Um ponto de partida pragmático: limite = latência histórica P95 × 1.5. Primeiro faça os alertas serem genuinamente respeitados, depois aperte gradualmente.

Para onde isso vai: dois julgamentos de tendência

Primeiro, o "tempo real" está evoluindo de uma métrica técnica para uma cláusula de SLA. Segundo a pesquisa de dados e analytics da Gartner de 2024, a "SLA-ificação" dos pipelines de dados é uma tendência estabelecida: as partes interessadas agora perguntam "qual é o SLA de latência, e quem responde por uma violação". Os compromissos dos 3PL com as marcas estão começando a incluir cláusulas como "latência de dados de estoque abaixo de 30 minutos". Armazéns que conseguem articular seus níveis de latência e SLAs têm vantagem na conquista de clientes.

Segundo, as decisões orientadas por IA estão criando novas demandas na estratificação de latência. Mais armazéns agora usam algoritmos para sugestões de reabastecimento, otimização de ondas e previsão de mão de obra. A latência dos dados de entrada de um modelo determina diretamente a vida útil de sua saída: um modelo de reabastecimento alimentado com dados T+1 pode ficar obsoleto em duas horas em um dia de promoção. Então, antes de adotar IA, faça uma pergunta: em que nível está a latência de entrada do modelo? Muitos projetos de IA de baixo desempenho têm sua causa raiz não nos algoritmos, mas em um descompasso entre a latência de dados e a cadência de decisões: a mesma lógica da lição dos $60,000 na história dois.

Voltando à pergunta inicial: "Nosso BI é em tempo real?" Uma boa resposta não é sim nem não: é uma tabela: quais métricas estão no nível de segundos, quais decisões o nível de minutos cobre, quais relatórios são T+1, e se o SLA de latência e os alertas de violação de cada nível estão configurados.

Uma pergunta aberta para encerrar: o painel do seu armazém carrega aquela pequena linha de "Dados às"? Se não, aqueles números dançantes que você olha todos os dias: você realmente sabe de que hora eles representam a verdade?

Por Dr. Chen, pesquisador de cadeia de suprimentos

Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.