Contexto

A Saga Moto Yamaha é uma grande concessionária Yamaha em Goiânia. Como a maioria das concessionárias do Brasil, opera em cima de um ERP/DMS (Dealer Management System) que é o coração do negócio: estoque, vendas, pós-venda, oficina, peças, financeiro, tudo passa por ali.

A ProdMan foi chamada por uma dor que parecia específica. A liderança queria usar dados pra apoiar decisão. Dashboards, indicadores, visão de negócio. O briefing era sobre analytics.

Começamos por onde se começa: entender de onde vêm os dados. Foi aí que o problema real apareceu.

Você é chamado pra resolver uma dor. Se fizer bem o trabalho, encontra a dor de verdade. E é essa que precisa ser resolvida.

O diagnóstico que mudou o projeto

O ERP da Saga tinha sido construído por uma empresa local que estava fechando as portas. Em pouco tempo, o sistema que rodava a operação inteira ficaria sem suporte, sem evolução, sem qualquer chance de atender demandas que o negócio já vinha pedindo.

Era uma dor dupla. O ERP atual já estava parado no tempo, com várias necessidades do negócio não atendidas, e a gestão vinha postergando o debate de migração pra olhar depois. Mas o depois tinha chegado. A empresa dona do sistema ia desaparecer, e a Saga ficaria sozinha com uma tecnologia congelada.

Trocar ERP não é decisão simples. Envolve operação inteira, equipe, fornecedores, integrações, processos construídos ao longo de anos. Por isso vinha sendo adiada. Mas adiar mais não era opção.

Ficar no problema de dados e fingir que o ERP não era o problema real teria sido fazer a coisa errada bonitinha. A ProdMan reabriu a conversa com a liderança e reposicionou o escopo: o projeto de dados entrava pra fila depois. O que precisava acontecer primeiro era o mapeamento completo da operação e a preparação da migração de sistema.

A abordagem em três frentes

O trabalho foi estruturado em três frentes que avançaram em paralelo, com prioridades definidas junto à liderança.

Frente 1: cotação e seleção do novo DMS

Avaliação de soluções modernas de mercado que atendessem os requisitos reais da Saga. Análise de fornecedores, capacidade técnica do produto, saúde financeira da empresa por trás (pra evitar exatamente a armadilha do ERP anterior), custo total de propriedade e aderência aos processos da concessionária. Entrou no critério de seleção a capacidade nativa de dar confiabilidade, amarração entre dados, etapas e relatórios, endereçando já a dor original de analytics que tinha aberto o projeto. A liderança recebeu uma escolha fundamentada, com prós e contras explícitos, não uma recomendação empurrada por marketing de fabricante.

Frente 2: mapeamento completo dos processos

Entrevistas em profundidade com gestores de todas as áreas: vendas, pós-venda, oficina, peças, administrativo, financeiro, TI. Mapeamento end-to-end de cada processo, fluxogramas detalhados, regras de negócio documentadas, exceções identificadas, integrações com outros sistemas desenhadas. O tipo de diagnóstico que uma concessionária raramente para pra fazer, e que vira base obrigatória pra qualquer migração de sistema funcionar sem perder a operação no meio do caminho.

Frente 3: especificação para a equipe de implementação

Tudo o que foi mapeado virou estrutura em Jira. Organização criada, backlog construído, escopos descritos, regras e requisitos documentados em nível de task. O entregável final foi um pacote de implementação completo, pronto pra ser usado pela equipe técnica do novo DMS quando a Saga decidisse executar a virada.

Resultados principais
  • Problema real diagnosticado antes que virasse incêndio: o ERP estava com prazo de morte, não só desatualizado
  • Documentação completa dos processos da operação, material que antes não existia em lugar nenhum
  • Novo DMS selecionado com critério técnico rigoroso, já resolvendo na fonte a dor original de analytics e confiabilidade de dados
  • Pacote de requisitos estruturado em Jira, pronto pra handoff direto com a equipe de implementação do novo DMS
  • Autonomia preservada: a Saga escolheu o timing da migração considerando o próprio ciclo fiscal, sem ficar dependente de consultoria externa pra executar

Por que esse case importa

Esse é o case que prova o posicionamento da ProdMan em formato concreto. Não é case de IA. Não foi vendido pra ser case de IA. Foi vendido pra resolver uma dor de negócio, e a dor de negócio mudou ao longo do diagnóstico. Quando isso acontece, o consultor honesto reposiciona o escopo. Não fica empurrando a solução que já estava combinada só pra bater meta de entrega.

A parte difícil de consultoria em operação de verdade não é executar. É enxergar. A Saga tinha uma dor declarada e uma dor real, e essas duas coisas estavam em níveis diferentes. O trabalho começou resolvendo a que estava declarada e terminou entregando um plano pra resolver a que estava na raiz.

Quando a ProdMan saiu, a Saga ficou com capacidade instalada pra executar a migração no timing certo, com fornecedor escolhido com critério e requisitos completos em mão. E com uma solução muito mais elegante do que a contratação inicial previa: a dor de analytics que abriu o projeto já ficou endereçada no próprio DMS escolhido. Dois coelhos, uma cajadada. Isso é consultoria que respeita a operação que já funciona e devolve autonomia, não dependência.

Case anterior
← AUVP Capital
Voltar
Todos os cases →