Grupo Boticário
Setembro de 2024 – Abril de 2026 · 1 ano 8 meses
O Produto
O GDEM é a ferramenta interna de planejamento de demanda do Grupo Boticário. Com modelos estatísticos, ela auxilia planejadores a prever a demanda dos SKUs — e essa previsão vai direto para o Supply para orientar a fabricação. Não há margem para erro: uma previsão errada significa ruptura nas prateleiras das franquias.
Contexto & escala
O que fiz
search Discovery de dores
Entrevistas com planejadores para entender o que travava o processo e onde o modelo falhava
list_alt Refinamento com dados
Backlog priorizado junto ao time de Ciência de Dados, com critérios claros de impacto e viabilidade
bar_chart Métricas de sucesso
Definição de KPIs de acurácia (WAPE) e tempo de planejamento como norte para o squad
Frente 1 · Discovery B2B
O GDEM foi construído para o processo padrão da empresa — mas o canal B2B opera com dinâmicas próprias que o produto não suportava. O time de B2B entendia que o GDEM simplesmente "não funcionava para eles". O time do GDEM, por sua vez, não conhecia como o B2B operava. Sem esse entendimento mútuo, qualquer solução seria um tiro no escuro.
5 áreas mapeadas no assessment
Planejadores de Demanda B2B
Usuários diretos do GDEM no canal B2B
Gerentes de Demanda B2B
Stakeholders com visão estratégica do canal
Planejamento Comercial
Área que conecta demanda às metas comerciais
Torre de Controle
Visão operacional e de monitoramento
Dados
Time técnico responsável pelos modelos e infraestrutura
A descoberta central
O gap não era técnico — era conceitual. O B2B tinha um processo de demanda fundamentalmente diferente do canal padrão, e nenhum dos dois lados conhecia bem o outro. A principal entrega do assessment foi criar uma linguagem comum entre os dois mundos e, a partir daí, recortar um MVP viável.
O que foi entregue
map Mapeamento completo
Processo de demanda B2B documentado do início ao fim, com dados de viabilidade
handshake Alinhamento de 5 áreas
Reviews quinzenais até todas as partes chegarem a um entendimento comum
straighten MVP definido
Épicos e histórias quebrados, viabilidade mapeada — pronto para construção
Resultado
Após 10 entrevistas com stakeholders de 5 áreas e 4 reviews quinzenais, o discovery chegou a um MVP bem definido — e a diretoria aprovou o recorte para seguir com o desenvolvimento. A decisão posterior de despriorizar foi de negócio, não de falta de clareza: o produto estava pronto para ser construído, mas outras iniciativas tomaram precedência. Um discovery que gera uma decisão informada é um discovery bem feito.
Frente 2 · PM de Sellout
Como PM do squad de Previsão de Sellout, o maior problema ao entrar não era falta de feature — era uma avalanche de incidentes de dados incorretos. Para 15 planejadores com alta carga operacional, um dado errado significava subir uma previsão incorreta direto para o Supply. Não havia margem para erro.
O diagnóstico
Regras de negócio haviam sido mal alinhadas entre business e tech durante o desenvolvimento. O que estava codado divergia do que os stakeholders esperavam — os cálculos traziam resultados diferentes do previsto. Não era culpa de nenhuma área em específico, mas precisava ser corrigido.
O que foi feito
search Mapeamento regra por regra
Sentou com pessoas-chave da área de demanda e documentou cada lógica de cálculo — caso a caso, modelo a modelo
link Validação com o código
Comparou o que estava implementado com o que foi mapeado, identificando onde os cálculos divergiam da expectativa
bar_chart Priorização e visibilidade
Organizou as incongruiências encontradas, priorizou os ajustes e deu visibilidade clara ao time de negócios
Resultado
−50%
Uma decisão de prioridade
Durante a expansão para a marca Eudora — com data limite definida — o time de negócios trouxe com urgência um problema de performance em múltiplas agendas simultâneas e pediu para paralisar tudo. Em vez de ceder à pressão, sentei com as pessoas-chave e fiz as perguntas certas: quantos incidentes foram abertos por isso? O que causou o problema? Faz sentido atrasar a expansão para resolver isso agora? A resposta foi: nenhum incidente, causa pontual, cenário médio — não crítico. Juntos, chegamos à conclusão de que a expansão era a prioridade. O problema de performance foi resolvido logo depois.
Outras responsabilidades do squad
Assertividade (WAPE)
Monitoramento contínuo da acuácia das previsões geradas pelo modelo de dados
Experiência do planejador
UX dentro do GDEM — o sistema passou a consolidar dados antes espalhados em múltiplas planilhas e bases
Curva C simplificada
Produtos de baixo impacto deixaram de passar pelo processo complexo — o volume do modelo estatístico passou a ser confiado diretamente
Interface com Ciência de Dados
Integração do modelo ao produto e validação dos outputs com o time de dados
Resultados · GDEM
↓ 50% no ciclo
20 dias
ciclo de planejamento
antes: 40 dias
assertividade da previsão
70%
acuácia das previsões
de demanda
↓ incidentes de dados
−50%
redução de incidentes
no squad de Sellout