[ Automação ]

Do Excel caótico a um dashboard em tempo real: um caso de transformação

Baqueiro Desarrollo Web ·

TL;DR

  • Uma empresa de logística trabalhava com uma dúzia de ficheiros Excel enviados por email todas as manhãs, com versões contraditórias e decisões tomadas com dados de há várias horas.
  • Ligámos os seus sistemas a uma base de dados central e montámos um dashboard que se atualiza sozinho, sem consolidação manual.
  • Resultado: 4 horas diárias de consolidação eliminadas, dados com menos de 1 hora de atraso e uma fonte única de verdade.

Quando chegámos, a operação funcionava com uma arquitetura de dados a que, sendo generosos, chamaríamos “distribuída”: uma dúzia de folhas de Excel em pastas partilhadas, versões enviadas por email todas as manhãs e uma pessoa que dedicava meio dia, todos os dias, a consolidar tudo num “master” para a direção.

O problema não era a falta de dados. Tinham demasiados e em demasiados sítios. E transformá-los em informação útil levava tanto tempo que, quando o relatório chegava à direção, já era história.

O contexto: logística com dados fragmentados

A empresa geria transporte de mercadorias para clientes B2B. A sua operação incluía:

  • Vários armazéns que introduziam dados em sistemas locais.
  • Uma frota de veículos com folhas de rota em papel e em Excel.
  • Um departamento de manutenção com registos em Access.
  • Faturação num programa de contabilidade desligado das operações.
  • Clientes que perguntavam “onde está a minha carga?” e respostas que demoravam horas a chegar.

O sistema de reporting era este: cada armazém enviava um Excel por email ao responsável pelo reporting às 9h00. Ele consolidava-o à mão, aplicava fórmulas, gerava gráficos e enviava um PDF à direção por volta do meio-dia. Nessa altura, os dados tinham entre 3 e 15 horas.

Os problemas eram previsíveis: versões contraditórias (alguém reencaminha um Excel antigo por engano), erros humanos na consolidação, impossibilidade de aprofundar (porque é que aparece este número? é preciso abrir os Excel originais um a um) e a frustração constante de operar com informação desatualizada.

Análise prévia: perceber antes de construir

Antes de propor qualquer tecnologia, dedicámos 2 semanas a perceber 3 coisas.

Que decisões são tomadas com que dados. A direção queria ver a ocupação dos armazéns, o desempenho das rotas, as incidências e o fluxo de caixa operacional. As operações precisavam de visibilidade em tempo real da carga pendente e dos problemas em curso.

Onde vivem os dados originais. Alguns estavam num software de gestão de armazém com API. Outros continuavam em Excel porque não existia sistema nenhum. E outros nasciam em papel e alguém os passava depois para Excel.

Que passos eram realmente necessários. Muitos passos de consolidação existiam só porque os sistemas não comunicavam entre si, não porque acrescentassem valor. Se um passo só serve para copiar dados de um sítio para outro, é candidato a desaparecer.

A solução: uma arquitetura de dados unificada

Desenhámos um sistema em 3 camadas.

Camada 1: ingestão de dados

  • Ligações por API: os sistemas que já tinham API (o software de armazém e o GPS da frota) foram ligados diretamente. O armazém sincronizava de hora a hora; o GPS, a cada poucos minutos.
  • Carregamento estruturado: para os dados que continuavam em Excel (manutenção), modelos normalizados com validação, carregados na base de dados central. Se faltasse um campo ou uma data não fizesse sentido, o sistema rejeitava-o no momento.
  • Formulários digitais: uma aplicação móvel simples substituiu o papel dos motoristas e alimentava diretamente a base de dados.

Camada 2: base de dados central e processamento

Uma base de dados PostgreSQL onde convergiam todos os dados, com processos automáticos de:

  • Limpeza e normalização (o mesmo cliente aparecia escrito de várias formas consoante a fonte).
  • Cálculos derivados (desempenho por rota, percentagem de ocupação).
  • Histórico (guardar a evolução ao longo do tempo para poder comparar semanas e épocas do ano).

Camada 3: dashboard e reporting

  • Dashboard operacional: Metabase (open source) com os KPI atualizados automaticamente, acessível a partir do navegador e do telemóvel.
  • Alertas automáticos: quando a ocupação de um armazém ultrapassa os 90%, quando uma rota acumula mais de 30 minutos de atraso, etc. Avisos por email e Telegram.
  • Relatórios agendados: envio automático de PDF diários e semanais sem intervenção humana.

Implementação: fases e aprendizagens

Fase 1 (mês 1): resultados rápidos

Ligámos as API existentes e criámos um dashboard básico de ocupação dos armazéns. Valor visível desde o primeiro mês, o que gerou a confiança e o impulso necessários para o que vinha a seguir.

Fase 2 (meses 2 e 3): dados manuais

Substituímos os Excel soltos por formulários estruturados. Foi a parte mais fastidiosa: convencer as operações de que o novo processo era melhor e iterar os formulários até serem realmente cómodos de usar.

Lição: a resistência à mudança não era tecnológica, era de hábito. Cada um tinha os “seus” Excel e confiava mais neles do que em qualquer sistema novo. Ganhámos essa confiança ao demonstrar, durante semanas, que o dashboard mostrava exatamente o mesmo que eles viam no seu Excel local.

Fase 3 (meses 3 e 4): aplicação móvel para motoristas

Substituímos as folhas de rota em papel por uma aplicação simples (uma PWA, não uma aplicação nativa, para encurtar prazos e não depender das lojas de aplicações). Permitia marcar entregas, reportar incidências com fotografia e consultar a paragem seguinte.

Esse foi o ponto de viragem. Ter a posição de cada veículo e o estado das entregas em tempo real mudou a operação: o centro de controlo via onde estava cada camião e podia gerir as incidências antes de o cliente ligar.

Fase 4 (mês 5): automatização do reporting

Com os dados a fluir, eliminámos a consolidação manual. A pessoa que dedicava meio dia ao reporting deixou de passar dados de um lado para o outro e passou a analisá-los e a propor melhorias operacionais. Mudança de função, não eliminação do posto de trabalho.

Resultados medidos

6 meses depois de concluída a implementação:

Tempo de reporting: de cerca de 4 horas diárias de consolidação manual para 0. Os relatórios geram-se sozinhos.

Antiguidade dos dados: de entre 3 e 15 horas (consoante a hora do dia) para menos de 1 hora na maioria das métricas, e tempo real na posição da frota.

Erros por versões contraditórias: eliminados. Há uma fonte única de verdade.

Resposta a clientes: de “confirmo-lhe dentro de 1 ou 2 horas” (enquanto alguém procurava nos Excel) para “neste momento vejo que a sua carga está em tal ponto e chega a tal hora”.

Decisões operacionais: capacidade de ver tendências (por exemplo, carga a acumular-se num armazém) e agir antes, em vez de reagir a problemas que já aconteceram.

Retorno: o investimento total em desenvolvimento rondou os 25 000 €. O tempo de consolidação recuperado, somado a menos erros e a respostas mais rápidas, justificou-o em menos de um ano.

O que fizemos bem

  • Começar simples e alargar aos poucos. Não tentámos resolver tudo no primeiro lançamento. Os resultados rápidos deram-nos margem para as fases difíceis.
  • Envolver as operações desde o início. Não foi “tecnologia imposta de cima”, mas sim “uma ferramenta que resolve os problemas que tu já tens”.
  • Manter o Excel onde fazia sentido. Não o substituímos só por substituir. Para análises pontuais e cenários hipotéticos, o Excel continuou disponível, agora alimentado com dados fiáveis.
  • Documentar processos. O novo sistema tinha documentação clara, coisa que o caos de Excel nunca teve. É uma parte que muitos projetos saltam e que sai cara mais à frente.

O que faríamos de forma diferente

  • Mais formação no início. Subestimámos de quanta formação alguns utilizadores não técnicos precisavam. Uma sessão de apresentação não chega: é preciso acompanhamento nas primeiras semanas e um guia curto à mão.
  • Permissões mais granulares desde o início. Tivemos de refazer parte do modelo de permissões quando surgiram necessidades do tipo “este departamento não devia ver esses dados”.
  • Cópias de segurança testadas, não apenas configuradas. Um pequeno incidente de corrupção de dados lembrou-nos que uma cópia automática não vale nada se nunca se testou a sua reposição.

Aplicabilidade a outros casos

Este padrão (dados dispersos, consolidação, dashboard e automatização) serve para muitas empresas:

  • Retalho: consolidar as vendas de vários canais (loja física, loja online, marketplaces).
  • Indústria: ligar máquinas, inventário e planeamento.
  • Serviços: horas das equipas, estado dos projetos e faturação.
  • Marketing: reunir as métricas de várias plataformas num único relatório.

Os detalhes mudam, mas a arquitetura de 3 camadas (ingestão, processamento, visualização) é sólida e replicável. E nem sempre obriga a mudar de sistema: muitas vezes basta ligar o que já existe, como contamos em como automatizar o reporting do teu ERP sem mudar de sistema. Se quiseres identificar primeiro que informação se devia mover sozinha na tua empresa, começa por que dados do teu negócio se deviam atualizar sozinhos.

Conclusão

A transformação não consistiu em “abandonar o Excel”. Consistiu em deixar de usar o Excel para aquilo que o Excel faz mal: ser um sistema de dados multiutilizador e em tempo real. O Excel é magnífico para a análise exploratória; como base de dados operacional é um problema.

O valor real não esteve na tecnologia (PostgreSQL e Metabase são padrão e acessíveis). Esteve em perceber que dados alimentam que decisões e em desenhar fluxos que os liguem sem atrito.

Se a tua empresa vive num labirinto de Excel partilhados por email e suspeitas que há uma forma melhor de trabalhar, provavelmente há. Conta-nos como funciona hoje a tua operação e dizemos-te, com números, o que faria sentido ligar primeiro.

[ Continue a ler ]

Mais ideias para o seu próximo projeto.

[ Vamos falar ]

O seu próximo projeto começa com uma conversa.

Conte-nos o que precisa de resolver. Revemos consigo o âmbito e os próximos passos.

Fale-nos do seu projeto