Painéis de Power BI para WMS que não conciliam: métricas, atualização e acesso

O essencial primeiro: quando um painel de Power BI para WMS não corresponde ao seu WMS, a interface geralmente é inocente. Nove vezes em dez, os dois sistemas estão usando definições diferentes para o mesmo número. Corrija definições, momento de atualização e acesso antes de redesenhar um único gráfico. Já recebi essa chamada de resgate três vezes, e em todas o cliente começou culpando o conector e terminou admitindo que ninguém tinha escrito as definições.

Em março de 2025, eu estava concluindo um go-live em um armazém de logística terceirizada perto de Los Angeles, com mais de 40,000 localizações e mais de 6,000 pedidos de saída por dia na alta temporada. O financeiro levou um valor de estoque do Power BI para a operação e a diferença era próxima de uma carga completa de contêiner. Passamos uma tarde verificando os registros da interface, e os registros estavam limpos. A causa real era simples: o estoque disponível no WMS subtraía o estoque alocado mas ainda não separado, enquanto o Power BI somava tudo o que estava fisicamente em mãos. Nenhum número estava errado. A palavra "disponível" simplesmente nunca tinha sido escrita em uma única frase. No mesmo dia surgiu uma segunda diferença: mercadorias devolvidas em uma zona de controle de qualidade contavam como vendáveis no Power BI, enquanto o WMS as retinha. O financeiro achava que havia estoque extra. A operação não o encontrava em lugar nenhum.

Um segundo armazém, um site de comércio eletrônico em Ontário, entrou no ar com painéis pouco antes do pico de 2024. Todas as manhãs às 8h, os pedidos expedidos do dia anterior no Power BI chegavam cerca de 200 pedidos abaixo do WMS. A TI verificou a interface por três dias antes de alguém olhar o limite do calendário. O WMS encerrava o dia no horário do Pacífico. A atualização do Power BI rodava no fuso horário padrão do servidor, de modo que os pedidos do turno da noite ainda não tinham chegado quando a reunião da manhã começou. Nenhum dado foi perdido. Os dois sistemas simplesmente traçavam a linha entre os dias em lugares diferentes.

Quando os números do Power BI para WMS divergem, comece pelas definições

A conciliação começa escrevendo definições, não desenhando gráficos. Cada métrica central precisa de uma frase: o que inclui, o que exclui e o momento exato em que é medida. Estoque disponível, estoque em mãos, quantidade alocada, quantidade em retenção de qualidade e quantidade em trânsito são cinco campos diferentes em um WMS. Fundi-los em um único número de "estoque" no Power BI deixa o painel errado desde o primeiro dia. Meu método de trabalho é uma tabela de aprovação com três colunas: o nome comercial, o campo do WMS e o cálculo do Power BI. Financeiro, operação e TI assinam a mesma tabela antes de qualquer pessoa construir um visual. Essa assinatura importa, porque a próxima discussão se resolve abrindo a tabela, não levantando a voz.

Esta é a parte contraintuitiva: um painel que corresponde ao WMS até a última unidade não é necessariamente um bom painel. Um WMS é um sistema operacional ao vivo cujos números se movem a cada minuto. Um painel é um retrato em um momento no tempo. Perseguir o retrato até que ele iguale o sistema ao vivo significa atualizações e recálculos constantes, e por fim um relatório tão lento que ninguém o abre. Um acordo melhor é uma tolerância combinada: deixe o estoque diferir pela quantidade em trânsito de um turno, e deixe o valor diferir por um ajuste não lançado. Defina primeiro a tolerância, e a conciliação finalmente terá uma linha de chegada.

Momento de atualização: de quem é o relógio que o relatório de Power BI para WMS realmente usa?

Os problemas de atualização dividem-se em três segmentos, e é preciso verificar os três: quando os dados do WMS chegam às tabelas de preparação, quando o Power BI lê essas tabelas e quando a página do relatório é atualizada para o usuário. Se algum segmento parar, o carimbo de data do relatório vai enganá-lo. O caso clássico que continuo vendo é um relatório carimbado às 9h que na verdade mostra os dados das 23h da noite anterior, porque uma extração noturna falhou e ninguém recebeu o alerta. A correção é simples, mas funciona: todo relatório deve mostrar sua hora de dados vigentes, e essa hora deve ser a hora comercial, não a hora do servidor.

Na minha lista de verificação da noite de go-live, a atualização tem apenas quatro verificações: o registro de sucesso da extração, quem recebe o alerta de falha, qual fuso horário define o limite do dia e quem pode pressionar a atualização manual. A atualização manual soa como uma rede de segurança, mas é um risco disfarçado. Uma pessoa atualizando à mão redefine a base de tempo para toda a empresa. Minha regra é que apenas o administrador do relatório pode atualizar manualmente, e cada atualização manual deixa um registro explicando por que aconteceu.

Regras de acesso que mudam os números em silêncio

O acesso é a causa mais traiçoeira, porque nada dá erro. Duas pessoas abrem o mesmo relatório e veem números diferentes, e ambas presumem que os dados estão quebrados. No WMS, o acesso é dividido por cliente, armazém e zona. No Power BI, se o acesso for dividido apenas por departamento, uma pessoa vê o armazém inteiro enquanto outra vê apenas o seu próprio cliente, e a conciliação entre elas é impossível desde o início. Já vi essa armadilha três vezes, e cada vez a discussão sobre dados errados terminou com a descoberta de que um filtro tinha ocultado silenciosamente parte das linhas.

A correção é escrever as regras de acesso na mesma tabela de aprovação. O isolamento por cliente no WMS corresponde à filtragem em nível de linha no Power BI. O isolamento por armazém corresponde aos filtros padrão do relatório. Campos sensíveis devem ser removidos completamente do Power BI, e não deixados no lugar contando com a boa-fé. Outra armadilha merece atenção: juntar tabelas em um relacionamento de um para muitos pode dobrar a contagem de linhas, de modo que o estoque de repente parece inflado. Sempre que um número salta sem motivo comercial, verifique a junção antes de verificar o negócio.

O custo de pular esse trabalho é fácil de contar. Tome uma equipe de operações de 20 pessoas gastando 2 horas cada por semana conciliando relatórios e explicando-os em reuniões. Isso são 2,000 horas por ano discutindo números em vez de resolver exceções e melhorar rotas de separação. Escreva definições, regras de atualização e regras de acesso uma única vez, e a conciliação geralmente cai para menos de meio dia por semana. O que você compra não é um relatório mais bonito. É a hora da reunião semanal que deixa de ser gasta discutindo qual número está certo.

Antes de conectar qualquer coisa, leia o guia de integração de BI para WMS para a forma geral como os dados do WMS são trazidos para o BI, e depois execute as três verificações acima contra essa configuração. Uma interface que funciona é apenas o começo. Um painel conta como funcional quando suas definições também funcionam.

Na noite do go-live, execute esta lista de verificação mais uma vez: cada métrica tem uma definição de uma frase, o limite do dia e o fuso horário estão escritos, as regras de acesso correspondem ao WMS e a hora de dados vigentes é mostrada em hora comercial? Passe nessas quatro verificações antes de publicar, e as chamadas da primeira semana sobre o painel serão cerca de metade do que você temia.

Por Lin Xiao, Consultor de Implementação de WMS

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