Alta
8,9%
dos pedidos foram cancelados, 3× a meta
R$ 2,10 Mi em vendas que o cliente já tinha decidido fazer.
← Todos os projetos
📁 Projeto 01 · ⭐ Case principal· Engenharia analítica
Onde a Amplo Varejo está perdendo faturamento?
Construí uma rede varejista inteira em dados (do banco de dados ao dashboard) para responder essa pergunta com números e transformar a resposta num plano de ação para a diretoria.
- Meu papel
- Tudo, de ponta a ponta
- Dados
- Sintéticos, 10,7 mil pedidos
- Ferramentas
- Python · SQL · Power BI
- Entrega
- Dashboard + plano de ação
R$ 1,7 a 3,3 Mi recuperáveis em 90 dias 💰
Maior perda8,9%de pedidos cancelados (3× a meta)
⚡ Em 30 segundos
O problema
A diretoria fechou 2025 abaixo da meta, com pedidos cancelados e estoque parado, sem saber qual perda atacar primeiro.
O que eu fiz
Criei o simulador, o banco e o Data Warehouse, construí o dashboard e testei as causas com estatística.
O que descobri
3 frentes de perda. A maior é o cancelamento, e ele é igual em todas as lojas: o problema é de processo.
O que recomendei
Começar pelos cancelamentos: custa pouco, o retorno começa em 30 dias e vale até R$ 1,39 Mi.
1O desafio
Uma empresa que sabia que perdia dinheiro, mas não onde
A Amplo Varejo é uma rede fictícia com 54 lojas nos 27 estados. Em 2025 ela ficou abaixo da meta, cancelou quase 1 em cada 11 pedidos e acumulou estoque. Cada área tinha uma explicação diferente, e ninguém conseguia dizer quanto cada problema custava.
95,5%da meta de faturamento atingida
957pedidos cancelados no ano
R$ 4,56 Miparados em estoque
"O cancelamento está concentrado em alguma região?"
"Quais lojas puxam o resultado para baixo?"
"Quanto dinheiro está parado no estoque, e em quê?"
🎯 Perguntas que guiaram a análise2A construção
Antes de analisar, construí a empresa
Em vez de baixar uma base pronta, criei os dados com regras de negócio reais. Assim pratiquei tudo o que vem antes do gráfico: definir regras, gerar, validar, modelar e carregar.
Regras e requisitos
Problema, regras de negócio e 25 requisitos escritos antes do código.
DocumentaçãoSimulador em Python
Vendas diárias com sazonalidade, Black Friday, Natal e eventos regionais.
PythonPandasBanco e Data Warehouse
15 tabelas operacionais reorganizadas em estrela para análise.
MySQLSQLDashboard e análise
114 medidas DAX e um relatório que conta a história.
Power BIDAX
Quer o lado técnico (código, SQL, DAX e decisões)? Leia o README no GitHub →
3O dashboard
Desenhado como uma conversa com a diretoria
A resposta aparece antes de qualquer gráfico. Depois, cada seção prova uma parte dela e termina numa decisão.
1234- 1A perguntaEscrita em cima, para ninguém se perder.
- 2A respostaUm texto em DAX que se reescreve com os filtros.
- 3O dinheiro em jogoAs 3 perdas lado a lado, com a prioridade.
- 4Os indicadoresComparados com a meta, não soltos.
Rolando a página
📌 Título que conclui"A taxa é 8,9%, 3× a meta" em vez de "Taxa por mês".
🎨 Cor só para destacarVermelho é problema, azul é destaque, o resto é neutro.
🧭 Uma página, uma históriaContexto → achados → decisão, em rolagem.
✍️ Protótipo antesDesenhado e aprovado em HTML, depois levado ao Power BI.
4Os achados
Três perdas, com valor e endereço
Média
35 de 54
lojas abaixo da meta, com gap de R$ 1,64 Mi
19 lojas concentram 82% do gap: dá para agir de forma dirigida.
Média
R$ 1,56 Mi
em estoque acima de 3 meses de venda
Metade do excesso está em só 10 produtos caros.
🔄 A virada da história
A hipótese que eu tinha estava errada
Imaginei que os cancelamentos vinham de falta de produto. Mas havia estoque em todas as lojas. Testei se a taxa mudava entre regiões, meses, lojas e categorias com o teste qui-quadrado: nenhuma diferença relevante.
Conclusão: o cancelamento é igual em todo lugar, então o problema está no processo do pedido, não numa loja. Isso mudou a recomendação.
Diferença entre grupos (p-valor)
Abaixo da linha amarela (0,05) haveria diferença real
Região0,12
Mês0,38
Loja0,64
Categoria0,94
5A decisão
Da análise a um plano que a diretoria consegue aprovar
Cada recomendação segue o mesmo caminho, do número até o gatilho de revisão:
- Fato
- Interpretação
- Causas
- Validação
- Ação
- Resultado
- Acompanhamento
Recomendação
Começar pelos cancelamentos: é a maior perda, a primeira ação custa pouco e o retorno começa em 30 dias.
As três frentes juntas podem recuperar de R$ 1,7 a 3,3 Mi em até 90 dias.
1Alta
Cancelamentos
Registrar o motivo, auditar o fluxo do pedido e corrigir a causa nº 1.
R$ 0,69 a 1,39 MiOperações + TI · 90 dias
2Média
Estoque excedente
Transferir entre lojas, pausar compras e promover os 10 itens.
R$ 0,63 a 1,09 Miem caixa · Estoque + Compras · 60 dias
3Média
Lojas abaixo da meta
Diagnóstico individual das 19 lojas abaixo de 90% da meta.
R$ 0,40 a 0,80 MiGestão de lojas · 90 dias
6Bastidores
O que deu errado, e como corrigi
Revisei o projeto inteiro antes de publicar e encontrei erros meus. Corrigir e documentar foi parte do trabalho.
Metas fora de escala
A meta era sorteada numa faixa pensada para outro volume de dados. Quase todas as lojas apareciam "abaixo da meta".
✓ Agora a meta nasce da venda real de cada região
Simulação não reprodutível
Cada execução gerava números diferentes, e o dashboard não batia com os arquivos publicados.
✓ Semente fixa: mesma execução, mesmos dados
5 medidas DAX erradas
A taxa usava o denominador errado e a receita somava pedidos cancelados.
✓ Todos os números conferidos em Python, fora do Power BI
🧪 Quando a ferramenta não deixou
O Power BI não reproduzia o protótipo. Então escrevi um gerador.
O layout virou imagem de fundo e cada visual é posicionado por código, exatamente onde o protótipo manda. O relatório ficou fiel ao design e pode ser regenerado em segundos.
O que aprendi: conferir os números fora da ferramenta antes de confiar no gráfico. ✍️
Explore o projeto
Veja tudo por dentro
ZIP de 3 MB com o projeto do Power BI e os dados já incluídos. Extraia a pasta e abra amplo_varejo.pbip no Power BI Desktop (gratuito).
Próximo projeto · 02
Quem vende mais nem sempre vende melhor
Análise de 96 mil pedidos do e-commerce Olist.
Ver a apresentação