Como estruturar um data warehouse para supply chain

O dado de logística está espalhado e ninguém confia nele#

Em operação logística, o dado nasce fragmentado. O status de um pedido vive no ERP, a posição física do estoque vive no WMS, o frete e a rota vivem no TMS, e a transportadora manda o rastreio por planilha ou API própria. Quando alguém pergunta "qual foi o custo real de servir o cliente X no último trimestre", a resposta depende de cruzar sistemas que não se falam. É exatamente esse problema que um data warehouse supply chain bem estruturado resolve: consolidar pedido, embarque, estoque e frete em um modelo único, consistente e auditável, para que a pergunta de negócio tenha uma resposta só, e não três.

Este artigo é sobre como estruturar esse warehouse na prática. Não é sobre comprar ferramenta, é sobre modelagem, camadas e integração. Vou usar o Microsoft Fabric e o OneLake como plataforma de referência, porque é onde a maioria dos nossos clientes de logística já está, mas os princípios de modelagem valem para qualquer stack.

Modelagem dimensional é o que separa relatório de análise#

A tentação de time técnico iniciante é replicar as tabelas do sistema de origem dentro do warehouse. É um erro. O modelo transacional do ERP foi desenhado para gravar rápido, não para responder pergunta analítica. Se você joga isso direto no Power BI, o resultado é um modelo lento, cheio de junções e impossível de explicar para a área de negócio.

O padrão correto é o esquema estrela: tabelas fato no centro, cercadas por dimensões. Na logística, as fatos representam os eventos que você quer medir, e as dimensões representam o contexto que descreve esses eventos.

As quatro fatos que sustentam quase toda análise de supply chain são:

• Fato de pedido: uma linha por item de pedido, com quantidade, valor, data de emissão, data prometida e data atendida. É a base para nível de serviço e OTIF.
• Fato de embarque: uma linha por evento de expedição, ligando pedido, rota e transportadora, com data de coleta, data de entrega e status.
• Fato de estoque: um snapshot periódico por SKU e por local, com saldo, custo e idade do estoque. É uma fato de foto, não de transação.
• Fato de frete: uma linha por conhecimento de transporte, com valor do frete, peso, cubagem e componentes de custo.

As dimensões que amarram tudo:

Dimensão	Chaves e atributos principais	Origem típica
Produto	SKU, descrição, categoria, peso, volume, curva ABC	ERP e WMS
Cliente	código, nome, segmento, região, canal	ERP e CRM
Rota	origem, destino, distância, modal, zona de entrega	TMS
Transportadora	código, nome, tipo de contrato, prazo acordado	TMS e ERP
Local	centro de distribuição, doca, endereço de armazenagem	WMS
Calendário	data, semana, mês, trimestre, dia útil	gerada

Um detalhe que dá muito retorno: trate as dimensões de produto e cliente como dimensões de mudança lenta, ou SCD. Se o cliente troca de segmento comercial no meio do ano, você precisa decidir se a análise histórica deve enxergar o segmento antigo ou o atual. Sem essa decisão explícita, o número do passado muda sozinho e ninguém entende por quê. Escrevemos mais sobre boas práticas de modelo em modelagem DAX e boas práticas no Power BI.

A granularidade define o que você pode e não pode medir#

A pergunta mais importante ao desenhar uma fato é: o que representa uma linha desta tabela? Se a fato de pedido tem uma linha por item, você consegue analisar por produto. Se tem uma linha por pedido, perdeu essa capacidade para sempre. A regra prática é modelar a fato no menor grão possível que a origem entregue, porque agregar depois é fácil, e desagregar é impossível.

Isso também explica por que estoque merece uma fato separada. Estoque não é um evento, é um estado. Você fotografa o saldo em intervalos regulares, diário ou semanal, e cada foto é uma linha. Misturar isso com movimentação transacional é confundir dois conceitos diferentes de medição.

As camadas medalhão organizam o caos entre origem e consumo#

Ter o modelo dimensional pronto no papel não basta. Entre o sistema de origem e o dashboard existe um caminho de transformação, e a arquitetura medalhão é a forma de organizar esse caminho em três camadas. No Microsoft Fabric, cada camada vive como tabelas Delta no OneLake, que é o armazenamento único da plataforma.

Camada	O que contém	Transformação aplicada
Bronze	cópia bruta e fiel da origem, sem tratamento	ingestão, nada mais
Prata	dados limpos, tipados, deduplicados e conformados	qualidade e padronização
Ouro	modelo dimensional pronto para consumo	fatos e dimensões, regras de negócio

A camada bronze recebe os dados exatamente como saem do TMS, do WMS e do ERP. A regra aqui é não transformar nada. Se a origem manda uma data em formato ruim, ela chega ruim no bronze. O motivo é auditoria: quando o número do dashboard diverge do sistema, você precisa de um ponto onde o dado é idêntico à fonte para provar onde a divergência nasceu.

A camada prata é onde a qualidade acontece. Aqui você padroniza tipos, resolve duplicidade, trata nulo, e concilia chaves entre sistemas. O grande trabalho da prata em logística é a conformidade: o SKU do WMS e o SKU do ERP precisam virar a mesma chave, o código de transportadora do TMS precisa bater com o cadastro do ERP. Sem isso, a junção na camada ouro simplesmente não fecha.

A camada ouro entrega as fatos e dimensões modeladas na seção anterior, já com as regras de negócio aplicadas. É esta camada que o Power BI consome. Nada de negócio deveria estar calculado antes da ouro, e nada de dado bruto deveria vazar para o consumo direto.

Se você quer entender a plataforma por baixo dessa arquitetura, vale a leitura de o que é o Microsoft Fabric e se vale a pena em 2026.

Direct Lake muda a conta de performance#

Um ponto técnico que importa para logística, onde as fatos crescem rápido: no Fabric, o modo Direct Lake permite que o Power BI leia as tabelas Delta direto do OneLake, sem importar os dados para dentro do modelo e sem consultar a origem em tempo real como faz o DirectQuery. Na prática, você ganha a performance próxima do modo Import sem pagar o custo de duplicar e recarregar tudo a cada refresh.

Vale lembrar como o motor por trás disso funciona. O VertiPaq, o motor colunar do Power BI, comprime cada coluna de acordo com a cardinalidade dela. Coluna com poucos valores distintos comprime muito, coluna com valores únicos comprime mal. Isso tem consequência direta na sua modelagem: evite trazer para a camada ouro chaves de altíssima cardinalidade que você não vai usar, como identificadores técnicos ou timestamps ao segundo, porque eles incham o modelo sem entregar análise. Modelar bem é, em boa parte, uma disciplina de não trazer o que não serve.

O consumo no Fabric é medido em Capacity Units, e a capacidade é contratada em SKUs que vão de F2 a F2048, além dos SKUs Premium clássicos de P1 a P5. Quanto mais pesado o refresh e a consulta, mais unidades você queima. Modelo enxuto não é só elegância técnica, é economia de capacidade.

A integração TMS, WMS e ERP é o trabalho de verdade#

Desenhar o modelo é a parte intelectual. Conectar as origens é a parte que consome o cronograma. Cada um desses sistemas tem uma personalidade de integração diferente.

• ERP: costuma ser a fonte mais estável e com melhor acesso, seja por banco, view ou API. É de onde vêm pedido, cliente, produto e a espinha financeira.
• WMS: gera muito evento de movimentação e o saldo de estoque. O volume é alto e o desafio é a frequência de atualização, porque estoque desatualizado engana decisão.
• TMS: traz rota, frete e status de entrega. Aqui mora a maior dor de padronização, porque cada transportadora reporta de um jeito, e integrar rastreamento externo raramente é trivial.

A recomendação prática é começar a ingestão pelo ERP, que dá a base de dimensões, e só então plugar WMS e TMS sobre essa base. Tentar integrar os três em paralelo, sem uma dimensão de produto e cliente já conformada, gera retrabalho garantido. Esse tipo de sequenciamento é o que tratamos em um trabalho de engenharia de dados, e a decisão de por onde começar costuma sair de um bom discovery e assessment.

Governança não é burocracia, é o que mantém o número confiável#

Dado de logística cruza informação de cliente, e no Brasil isso significa Lei Geral de Proteção de Dados, a Lei nº 13.709/2018. Endereço de entrega, dados de contato e histórico de compra são dados pessoais. O warehouse precisa nascer com controle de acesso por camada, mascaramento onde couber e trilha de quem acessa o quê.

Além do aspecto legal, governança é o que garante que a definição de OTIF seja a mesma para todas as áreas. Não adianta cada gerente ter sua própria fórmula. A camada ouro deve ser a fonte única dessas definições. Tratamos isso a fundo em governança de dados no Power BI e LGPD e no serviço de governança de dados.

Perguntas frequentes#

Preciso mesmo de um data warehouse ou dá para conectar o Power BI direto nos sistemas?

Para um dashboard isolado, conectar direto funciona. Para uma operação de supply chain com múltiplas origens, não. Sem uma camada intermediária que consolide e concilie os sistemas, cada relatório vira uma junção frágil que quebra quando a origem muda. O warehouse existe para dar estabilidade e uma versão única da verdade.

Qual a diferença entre a arquitetura medalhão e um data warehouse tradicional?

O warehouse tradicional já entregava a ideia de camadas de staging e modelo final. A medalhão formaliza isso em bronze, prata e ouro e casa bem com o modelo lakehouse do Fabric, onde tudo vive como tabelas Delta no OneLake. Não é uma tecnologia nova, é uma organização clara de um princípio antigo e bom.

Devo modelar estoque como fato de transação ou de snapshot?

Snapshot. Estoque é um estado, não um evento. Você fotografa o saldo por SKU e local em intervalos regulares, e cada foto vira uma linha da fato. Isso permite analisar cobertura, giro e idade do estoque de forma correta, o que uma modelagem transacional não entrega bem.

Direct Lake substitui o modo Import de vez?

Não em todo caso, mas para fatos grandes de logística ele resolve o dilema clássico entre performance do Import e frescor do DirectQuery. Como ele lê as tabelas Delta direto do OneLake, você tem desempenho alto sem reimportar os dados. Ainda assim, cenários com transformação pesada no modelo podem pedir Import. A escolha depende do caso.

Quanto custa rodar isso no Microsoft Fabric?

O custo é medido em Capacity Units e depende do SKU contratado, que vai de F2 a F2048. Faixas de preço variam por região e por compromisso de reserva, e devem sempre ser confirmadas na tabela oficial da Microsoft. A conta prática é: modelo enxuto e refresh bem planejado consomem menos capacidade, então boa modelagem é economia direta.

Por onde começo se hoje só tenho planilhas e sistemas isolados?

Comece pequeno e pela base. Faça um discovery para mapear origens e definir as perguntas de negócio prioritárias, ingira o ERP primeiro para montar as dimensões, e só depois plugue WMS e TMS. Entregar uma fato de pedido bem modelada já resolve boa parte das dúvidas de nível de serviço antes mesmo do projeto completo.

O warehouse é meio, a decisão é o fim#

Estruturar um data warehouse supply chain não é um projeto de tecnologia, é um projeto de confiança no número. Modelagem dimensional correta, camadas medalhão bem separadas e integração sequenciada de TMS, WMS e ERP são o que transformam dado disperso em decisão de estoque, frete e nível de serviço. A plataforma, no caso o Microsoft Fabric com OneLake e Direct Lake, acelera o caminho, mas quem sustenta o resultado é a disciplina de modelo.

Se a sua operação logística ainda depende de cruzar planilhas para responder pergunta simples, fale com a gente e vamos desenhar a arquitetura certa para o seu contexto.