Sair do Excel para BI: quando a planilha vira gargalo
Por Alexandre Pereira · · 5 min de leitura
Quando você abre a pasta compartilhada e encontra cinco versões do mesmo relatório — "vendas_final.xlsx", "vendas_final_v2.xlsx", "vendas_REAL_agora_vai.xlsx" — é sinal de que a planilha deixou de ser ferramenta e virou problema. Sair do Excel para BI não é modismo: é sobrevivência operacional. Uma distribuidora capixaba com 120 funcionários chegou ao ponto de ter três analistas recalculando margem porque cada um usava fórmula diferente, com critérios de rateio que ninguém mais lembrava de onde vieram.
O Excel nasceu para análise pontual, não para governança de dados. Quando a empresa cresce, a planilha vira legado técnico: arquivos pesados, fórmulas aninhadas que travam, macros que param de funcionar após atualização do Office. E o pior: ninguém confia no número porque ninguém sabe de onde ele veio.
Por que a planilha quebra quando a PME cresce?
O primeiro sinal é estrutural: você tem cinco ou mais planilhas que deveriam estar sincronizadas mas vivem com versões conflitantes. O segundo é técnico: alguém abriu uma fórmula e viu quatro níveis de PROCV aninhado com SE e E lógico — e desistiu de entender. O terceiro é humano: só uma pessoa sabe mexer naquele arquivo, e se ela sair de férias a diretoria fica cega.
Uma rede varejista em Vitória rodava fechamento mensal em Excel conectado ao TOTVS via exportação manual. Três analistas gastavam 14 horas por mês só conferindo se os totais batiam entre as abas. Quando migraram para um data warehouse leve (Supabase) + dashboard em GFloow Analytics, o fechamento caiu para 2 horas — e com rastreabilidade: cada número aponta pro registro-fonte no ERP.
O problema não é o Excel em si, mas a arquitetura. Planilha não foi feita pra ser banco de dados multiusuário, versionado, com auditoria e refresh automático. Quando você tenta forçar isso, paga o preço em retrabalho, erro e risco.
Qual o caminho prático para migrar sem parar a operação?
Passo 1: catalogar fontes. Liste todas as planilhas críticas (as que alimentam decisão semanal) e mapeie de onde vêm os dados — TOTVS, Senior, Sankhya, CSV de transportadora, nota fiscal escaneada. Esse inventário revela redundâncias: muitas vezes três planilhas puxam do mesmo lugar, mas com filtros diferentes aplicados manualmente.
Passo 2: escolher data warehouse leve. Para PME, Supabase (PostgreSQL gerenciado, free até 500 MB) ou BigQuery (Google, free até 10 GB processados/mês) resolvem 80% dos casos. A ideia não é construir um data lake corporativo — é ter um lugar único, SQL, onde os dados brutos ficam antes de virarem dashboard.
Passo 3: migrar um dashboard por mês. Comece pelo mais doloroso: o relatório que trava toda segunda-feira, ou o fechamento que consome dois dias. Monte a pipeline (extração do ERP → warehouse → BI) e rode em paralelo com a planilha por 30 dias. Quando bater três fechamentos consecutivos sem divergência, congele a planilha antiga — renomeie pra "_LEGADO_nao_usar.xlsx" e tire permissão de edição.
Passo 4: governança mínima. Documente onde cada métrica é calculada (ex: "Margem Bruta = (Receita − CMV) / Receita, CMV vem da view `sankhya.custo_medio`"). Isso evita que daqui a seis meses alguém crie outra planilha "porque não confiava no dashboard".
Uma metalúrgica em Serra economizou 6 horas por semana por analista depois de migrar os três dashboards críticos (vendas, estoque, inadimplência). O ganho não foi só tempo: foi confiança. Reunião de diretoria deixou de ser "qual planilha está certa?" e virou "o que fazer com esse desvio de 12% na Região Sul?".
Quanto tempo leva e o que não dá pra evitar?
Conta de padaria: um dashboard médio (3-5 gráficos, 2-3 filtros, 1-2 tabelas) leva de 16 a 24 horas pra estruturar — se os dados já estiverem limpos no ERP. Se precisar tratar inconsistência (cliente cadastrado três vezes com CNPJ diferente, nota sem centro de custo), some 40% no prazo. O trabalho sujo não é montar o gráfico: é arrumar a bagunça que a planilha escondia.
O que não dá pra evitar: a primeira migração vai expor problemas de cadastro que estavam invisíveis. Quando você consolida tudo num banco SQL, a duplicidade e a falta de padrão gritam. Isso é bom — significa que você está curando o dado na origem, não empurrando a sujeira pra frente.
Quem quer começar pode partir de um piloto de 30 dias: escolhe o dashboard mais crítico, monta a pipeline, roda em paralelo. Se funcionar, escala. Se travar, ajusta. O importante é não tentar migrar tudo de uma vez — isso paralisa a operação e frustra o time.