Microsoft Fabric para indústrias: quando faz sentido centralizar os dados da operação?

O Microsoft Fabric faz sentido para uma indústria quando três condições aparecem juntas: os dados da operação estão espalhados em várias fontes que precisam ser cruzadas com frequência (ERP, MES, qualidade, manutenção, sensores e as planilhas de cada fábrica); o volume de dados ou de consultas já não cabe com folga em relatórios do Power BI que importam tudo direto das fontes; e existe alguém, na equipe ou em um parceiro, para cuidar da capacidade, dos custos e da governança depois da implantação. Quando a empresa tem um ERP só, poucos relatórios e um time pequeno, o Power BI com licenças Pro e um banco de dados bem modelado costuma resolver por bem menos. O Fabric não é uma ferramenta de relatório mais cara. É uma plataforma de dados, e só se paga quando a empresa precisa de uma.

Que problema o Fabric resolve em uma indústria?

Em uma fábrica típica, cada sistema guarda um pedaço da história. O ERP sabe o que foi comprado, produzido e faturado. O MES registra ordens, apontamentos e paradas. O sistema de qualidade tem as inspeções e as não conformidades, e a manutenção tem as ordens de serviço. Sensores e historiadores de processo geram milhões de leituras por dia, e as planilhas cobrem o que nenhum sistema registra. Perguntas como o custo real de uma ordem de produção, a perda de OEE causada por falta de material ou a relação entre o lote de um fornecedor e o refugo exigem juntar pelo menos três dessas fontes, com histórico. É nesse cruzamento que um ambiente central se justifica: cada fonte é copiada uma vez para o OneLake, tratada em camadas e reaproveitada por todos os relatórios, em vez de cada relatório do Power BI buscar e transformar os mesmos dados por conta própria.

Quando o Fabric faz sentido?

• Muitas fontes para cruzar: três ou mais sistemas combinados com frequência, inclusive de fábricas com ERPs ou versões diferentes.
• Histórico que a origem não guarda: fotografias diárias de estoque, carteira e programação que o sistema de origem sobrescreve a cada movimento.
• Dados de máquina e sensores: leituras em alta frequência para monitorar processo e paradas, um volume que não cabe em planilha nem em um modelo importado do Power BI.
• Atualizações pesadas: modelos do Power BI que levam horas para atualizar, ou batem no limite de tamanho, porque cada um refaz as mesmas transformações.
• Ambiente Microsoft já em uso: empresa que usa Microsoft 365, Entra ID e Power BI ganha com o controle de acesso unificado.
• Muitos leitores de relatório: centenas de pessoas que só consultam painéis, situação em que a capacidade F64 pode substituir licenças individuais, como mostra o exemplo mais abaixo.

Quando ainda não vale a pena?

• Uma fonte e poucos relatórios: um ERP, uma dúzia de painéis e atualização diária cabem no Power BI Pro, com ou sem um banco intermediário.
• Cadastros desorganizados: se o cadastro de materiais e a estrutura de produto estão inconsistentes, centralizar só leva o problema para um lugar mais caro. O saneamento vem antes.
• Ninguém para operar: uma capacidade precisa de alguém que acompanhe o consumo, ajuste horários de carga e controle quem cria o quê. Sem esse dono, o custo cresce sem que ninguém perceba.
• Plataforma de dados funcionando: se a empresa já tem um data warehouse em outra nuvem que atende bem, migrar só por migrar raramente compensa. O Power BI continua lendo de lá.

Quanto custa o Fabric na prática?

O custo tem quatro partes, e a capacidade é só a mais visível. Os valores de referência abaixo vêm da página oficial de preços do Microsoft Fabric, em dólar e para regiões dos Estados Unidos, consultada em outubro de 2026. Na região Brasil o preço por hora é outro, e o valor final depende do câmbio e do contrato com a Microsoft ou com o revendedor.

• Capacidade: cobrada por unidade de capacidade por hora. Na referência americana, cerca de US$ 0,18 por CU-hora no pagamento por uso, o que dá aproximadamente US$ 263 por mês para uma F2 ligada o tempo todo e US$ 8.410 para uma F64. A reserva anual reduz o valor em cerca de 40%, mas é paga mesmo com a capacidade ociosa.
• Armazenamento no OneLake: cobrado por GB por mês, separado da capacidade, e continua sendo cobrado com a capacidade pausada. Para dados de ERP costuma ser a menor parcela. Para dados de sensores, nem sempre.
• Licenças do Power BI: quem cria e publica relatórios precisa de Power BI Pro (US$ 14 por usuário por mês na tabela pública) em qualquer tamanho de capacidade. Quem só visualiza também precisa de Pro em capacidades menores que a F64. A partir da F64, leitores com licença gratuita e papel de visualizador no workspace abrem os relatórios, conforme a documentação de licenças do Microsoft Fabric.
• Pessoas: engenharia de dados para montar as cargas e as camadas, e alguém para acompanhar o consumo pelo aplicativo de métricas de capacidade. É o item mais esquecido nos orçamentos e o que mais pesa no primeiro ano.

Duas características mudam a conta. A capacidade contratada por uso pode ser pausada, por exemplo fora da janela de cargas, e deixa de cobrar processamento enquanto está parada. O consumo acumulado é lançado na fatura no momento da pausa, e os relatórios ficam indisponíveis até a retomada. Além disso, o espelhamento (mirroring) de bancos como SQL Server e Azure SQL replica os dados no OneLake sem consumir a capacidade, com armazenamento gratuito proporcional ao tamanho contratado: 1 TB por CU, ou 64 TB em uma F64. Para indústrias com ERP em SQL Server, isso reduz bastante o trabalho e o custo da primeira carga.

Como isso fica em números?

Para tornar a comparação concreta, imagine uma indústria criada só para este artigo, sem relação com qualquer cliente ou projeto da Insight Pro. Ela tem três fábricas, ERP em SQL Server, MES em duas plantas e planilhas de qualidade. São 25 pessoas que criam ou editam relatórios e 180 que só consultam. Os preços são os de referência em dólar citados acima, com reserva anual (cerca de US$ 78 por CU por mês) e sem impostos.

• Hoje, só Power BI Pro: 205 licenças de US$ 14 somam US$ 2.870 por mês, e as cargas pesadas rodam em um servidor local que já está no limite.
• Opção A, F8 com Pro para todos: a F8 reservada custa cerca de US$ 625 por mês e assume a ingestão, o lakehouse e os modelos. Com as 205 licenças Pro, o total fica em torno de US$ 3.495 por mês.
• Opção B, F64 com Pro só para quem cria: a F64 reservada custa cerca de US$ 5.000 por mês. Somando 25 licenças Pro (US$ 350), o total chega a US$ 5.350 por mês, e os 180 leitores deixam de precisar de licença paga.

Para essa empresa, a opção A custa cerca de US$ 1.860 a menos por mês. O ponto de virada aparece quando o número de leitores passa de aproximadamente 310: a partir daí, cada leitor novo custa US$ 14 na opção A e nada na opção B. A F64 só se paga pelo licenciamento quando a empresa leva os painéis a supervisores, líderes de turno e equipes de chão de fábrica em grande número, ou quando a carga de dados de fato precisa de 64 unidades de capacidade. Comprar F64 por padrão, só porque é o tamanho mais citado, é um erro comum. O inverso também acontece: uma F2 escolhida para economizar fica sobrecarregada, entra em limitação (throttling) e atrasa cargas e relatórios. O tamanho certo sai de um teste com as cargas reais, acompanhado pelo aplicativo de métricas de capacidade.

Como começar sem transformar o projeto em uma migração gigante?

1. 1.Escolher um caso de uso com dono: por exemplo, custo por ordem de produção ou perdas de OEE por causa. Um problema de negócio, e não "migrar tudo para o Fabric".
2. 2.Testar pequeno: usar o período de avaliação do Fabric ou uma capacidade pequena por uso, levar as fontes desse caso, medir o consumo das cargas e dos relatórios e pausar a capacidade fora do horário.
3. 3.Trazer as fontes sem reescrever o que funciona: espelhamento para bancos compatíveis, pipelines para os demais e atalhos (shortcuts) do OneLake para dados que já estão em outro armazenamento em nuvem.
4. 4.Organizar em camadas: dado bruto como veio, dado limpo e padronizado, e dado pronto para o negócio, com a regra de cada indicador escrita uma vez só.
5. 5.Ligar o Power BI à camada final: modelos semânticos em modo Direct Lake leem as tabelas do OneLake sem importar e atualizar tudo de novo.
6. 6.Definir a governança antes de abrir para todos: quem pode criar workspaces, quem responde por cada carga, alertas de consumo e regra de pausa.
7. 7.Fechar o tamanho e a reserva depois de medir: só com dois ou três meses de consumo real, e com a conta de licenças feita como no exemplo acima.

Quais erros encarecem a adoção?

• Levar os problemas de origem junto: número que não bate no ERP continua não batendo no Fabric. Antes de centralizar, vale entender por que os números do Power BI não batem com o ERP.
• Capacidade disputada: um notebook mal escrito ou uma atualização fora de hora consome a capacidade e deixa lentos os painéis da diretoria. Separar cargas de produção e de experimentação, em capacidades ou horários diferentes, evita a disputa.
• Copiar tudo sem critério: trazer todas as tabelas do ERP "para o caso de precisar" aumenta armazenamento, tempo de carga e confusão, sem responder pergunta nenhuma.
• Reservar antes de medir: contratar um ano de F64 antes de conhecer o consumo real trava um custo que pode ser o dobro do necessário.
• Plataforma sem dono: sem alguém que acompanhe consumo e custos, o ambiente cresce como uma pasta compartilhada sem regra.

Se a sua indústria já sente o limite do Power BI ligado direto às fontes, ou está avaliando o Fabric por indicação da Microsoft ou de um revendedor, a pergunta certa é se a operação precisa de uma plataforma de dados agora e de que tamanho. No diagnóstico gratuito de arquitetura de dados da Insight Pro, parte do serviço de Engenharia de Dados, levantamos as suas fontes (ERP, MES, qualidade, manutenção, sensores e planilhas), o volume e a frequência de atualização de cada uma, os relatórios existentes e quantas pessoas criam e consultam, e comparamos o custo de três caminhos: manter o Power BI Pro com um banco intermediário, adotar uma capacidade pequena do Fabric ou ir direto para a F64. A avaliação termina com a estimativa de custo de cada opção e a recomendação de por onde começar, mesmo quando a conclusão é não adotar o Fabric agora.