Como conectar o Power BI ao TOTVS Protheus sem travar o ERP

A pergunta aparece em toda primeira reunião: "se eu ligar o Power BI direto na base do Protheus, vou derrubar o sistema?"

A resposta honesta é: depende inteiramente de como você conecta. Existem três caminhos, e a diferença entre eles não é técnica-para-técnico: é a diferença entre o faturamento rodar normalmente às 10h da manhã ou a operação inteira reclamar de lentidão.

O problema de fundo

A base do Protheus é modelada para transação, não para análise. Ela foi desenhada para gravar um pedido rapidamente, não para responder "qual foi a margem por produto nos últimos 24 meses".

Quando você faz uma pergunta analítica direto nas tabelas transacionais, o banco precisa varrer volumes grandes de linhas. Isso compete pelos mesmos recursos que a operação está usando para faturar. Não é que a conexão seja perigosa em si. O problema é a consulta errada no momento errado.

Caminho 1: DirectQuery direto na base

O Power BI envia uma consulta SQL ao banco a cada interação do usuário. Cada clique num filtro é uma nova consulta.

Quando funciona: volumes pequenos, poucos usuários simultâneos, necessidade real de dado ao vivo.

Por que costuma dar errado: dez pessoas abrindo o mesmo dashboard às 9h da manhã geram dezenas de consultas pesadas simultâneas contra a base de produção. O ERP fica lento e a culpa recai sobre o BI, corretamente nesse caso.

Há ainda um detalhe que pega muita gente: em DirectQuery, boa parte da modelagem em DAX é traduzida para SQL em tempo de execução. Medidas que parecem inofensivas no Power BI Desktop viram consultas custosas em produção.

Caminho 2: Importação com janela agendada

O Power BI copia os dados para o próprio modelo em memória, em horários definidos. Durante o dia, os usuários consultam essa cópia, e a base do ERP não é tocada.

Quando funciona: praticamente todos os casos de indicador de gestão. Margem, faturamento, curva ABC, aderência ao plano: nada disso muda de significado por ser de ontem à noite.

O cuidado necessário: a janela de carga precisa cair em horário de baixa concorrência, e a extração deve trazer só as colunas que o modelo usa. SELECT * numa tabela de movimentação é a forma mais rápida de transformar uma carga noturna em incidente.

Na prática, é o caminho que recomendamos para a grande maioria dos projetos.

Caminho 3: Camada intermediária

Uma base analítica separada recebe os dados do Protheus e serve o Power BI. É o modelo de data warehouse.

Quando compensa: quando há mais de uma fonte (Protheus + CRM + mídia paga), quando o histórico precisa ir além do que o ERP guarda, ou quando várias áreas consomem os mesmos dados e você não quer replicar a mesma regra de negócio em cada relatório.

O custo: é mais infraestrutura e mais projeto. Não é o ponto de partida de quem está construindo o primeiro dashboard. É para onde a maioria migra quando o BI vira parte da rotina.

O que decide a escolha

Três perguntas resolvem quase todos os casos:

Com que atraso a informação ainda é útil? Se a resposta for "o dado de ontem serve", importação resolve.
Quantas fontes entram? Mais de uma, e a camada intermediária começa a se pagar.
Quantas pessoas vão consumir simultaneamente? Quanto mais usuários, menos DirectQuery.

Um detalhe que vale mais que a escolha da arquitetura

Independente do caminho, o acesso ao ERP deve ser feito com usuário exclusivo e somente leitura. Não é só questão de segurança, é rastreabilidade. Quando aparecer uma consulta pesada no monitoramento do banco, você precisa saber em segundos se ela veio do BI ou da operação.

Parece burocrático. É o tipo de decisão de cinco minutos que evita uma reunião de duas horas seis meses depois.

Trabalha com Protheus, Datasul, RM ou Logix e quer avaliar qual arquitetura faz sentido no seu cenário? Fale com a gente. O diagnóstico inicial não tem custo.