Toda segunda-feira de manhã, durante dois anos, eu abria quatro planilhas Excel diferentes, copiava dados manualmente, recalculava KPIs que já tinham sido calculados na semana anterior, formatava tudo em um relatório PDF e enviava para oito pessoas. O processo todo levava cerca de duas horas e meia.
Multiplique isso por 104 semanas. São 260 horas da minha vida profissional gastas fazendo exatamente a mesma coisa. Repetidamente. Sem nenhum valor agregado além de consolidar informação que já existia em algum lugar.
Foi quando percebi: eu estava trabalhando para o processo. O processo não estava trabalhando para mim.
O momento de virada
A percepção não veio de um treinamento ou de um livro. Veio de uma frustração específica. Em uma semana, me pediram para gerar o mesmo relatório com um recorte diferente — por região geográfica, em vez de por linha de produto.
Com a estrutura que eu tinha, isso significava refazer tudo do zero. Mais duas horas.
Sentado ali, olhando para as planilhas, pensei: "Esse dado já existe em algum lugar. Por que estou recriando manualmente algo que o sistema já calculou?"
Essa pergunta mudou minha maneira de trabalhar.
Por que dados industriais são especialmente difíceis
Antes de falar sobre a solução, preciso contextualizar o problema. Dados industriais têm características que tornam a análise particularmente desafiadora:
Fragmentação de sistemas. Em ambientes industriais, é comum ter um ERP para finanças, um MES para produção, um sistema de qualidade separado, um CRM para vendas — todos com estruturas de dados diferentes, atualizados em frequências diferentes, com nomenclaturas que parecem ter sido criadas por equipes que nunca se falaram.
Dados em tempo real versus dados históricos. Alguns KPIs precisam ser monitorados ao vivo (temperatura de processo, taxa de rejeição em linha). Outros fazem sentido apenas como tendência histórica. Misturar os dois no mesmo relatório estático é problemático.
O analista como gargalo. Quando os dados só existem em forma de relatório, a organização inteira depende da disponibilidade de uma pessoa para gerar insights. Isso cria um gargalo absurdo e transforma analistas em operadores de copiar-e-colar.
A implementação: do zero ao dashboard
Quando decidi resolver o problema de verdade, comecei com o óbvio: aprendi Power BI. Não o nível básico de "inserir gráfico de pizza". O nível de entender como o modelo de dados funciona, como construir DAX eficiente, como estruturar relacionamentos entre tabelas.
Fase 1: Mapear as fontes
Passei uma semana apenas mapeando de onde vinha cada dado que eu colocava no relatório. Descobri que:
- Três das quatro planilhas eram alimentadas a partir do mesmo sistema
- Dois campos que eu calculava manualmente já existiam como campos nativos no ERP
- Uma das "fontes de dados" era, na verdade, um resumo de outro relatório — que por sua vez era um resumo de outro dado
A cadeia de transformações manuais tinha criado uma espécie de "telefone sem fio" de dados. Cada passo introduzia possibilidade de erro.
Fase 2: Conectar diretamente
Em vez de exportar para Excel e depois consolidar, conectei o Power BI diretamente às fontes. Isso eliminou o intermediário e garantiu que o relatório sempre mostrasse os dados mais recentes, atualizados automaticamente.
Fase 3: Construir o modelo semântico
Aqui está a parte que a maioria das pessoas pula e depois se arrepende: antes de criar qualquer visual, defini o modelo de dados. Quais tabelas se relacionam com quais? Em que granularidade? Quais métricas são calculadas versus armazenadas?
Um modelo bem construído é como uma fundação bem feita: você não a vê, mas tudo que você constrói em cima depende dela.
Fase 4: Criar visuals que respondem perguntas
O erro clássico de quem começa com BI é criar dashboards cheios de gráficos que mostram dados mas não respondem perguntas. Um bom dashboard começa pela pergunta: "O que as pessoas precisam saber para tomar uma decisão?"
No meu caso, as perguntas centrais eram:
- Nossa produção está dentro do planejado?
- Onde estão os gargalos?
- Qual é a tendência das últimas 12 semanas?
Cada visual do dashboard responde a uma dessas perguntas, e só uma.
O resultado
O relatório de segunda-feira que levava 2h30 passou para... 10 minutos. E esses 10 minutos são apenas para eu revisar se algum dado está estranho — o próprio Power BI já fez todo o resto.
Mas o benefício maior não foi o tempo economizado. Foi a democratização do acesso à informação. Com o dashboard publicado e compartilhado, qualquer membro da equipe pode verificar os números em tempo real, sem depender de mim. As reuniões de alinhamento ficaram mais rápidas porque todo mundo chega já sabendo o que os dados mostram.
O que aprendi sobre dados na prática
Dados sujos são a regra, não a exceção. Prepare-se para gastar 70% do tempo de qualquer projeto de dados limpando e transformando — não analisando.
Automatizar processo errado é pior que processo manual. Antes de automatizar, questione se o processo precisa existir. Às vezes a solução é eliminar, não otimizar.
O relatório que ninguém lê é melhor que nenhum relatório? Não. É pior. Porque ocupa tempo de quem produz e cria falsa sensação de governança. Se um relatório não está gerando nenhuma decisão, ele não deveria existir.
Tecnologia resolve metade do problema. A outra metade é cultural. Convencer a liderança a confiar nos dados ao vivo em vez de esperar o relatório semanal levou mais tempo do que construir o dashboard.
Se você ainda está copiando e colando dados entre planilhas toda semana, não é um problema de ferramenta. É um problema de prioridade. A tecnologia para resolver isso é acessível e, em muitos casos, já está incluída na licença de software que sua empresa paga.
A pergunta é: você quer continuar trabalhando para o processo, ou quer que o processo trabalhe para você?
Diego Badelli é Engenheiro de P&D na Furukawa Electric LatAm. Certificado em Google Data Analytics e Microsoft Power BI, combina engenharia industrial com análise de dados em projetos de inovação.