Por que tantos projetos de ERP não dão certo?

S

em método, a decisão vira aposta. E aposta com software de missão crítica custa caro.

⏱️ Leitura: aproximadamente 10 minutos

Escolher um ERP é uma das decisões mais importantes que uma empresa pode tomar.

O sistema vai estar no financeiro, nas vendas, nas compras, no estoque, na produção, no fiscal, nos indicadores e, principalmente, nas decisões que a gestão toma todos os dias.

Mesmo assim, ainda vejo muitas empresas conduzindo essa escolha de uma forma que considero perigosa: começam pelas demonstrações dos fornecedores, comparam algumas propostas comerciais e tentam decidir qual sistema “parece melhor”.

O problema é que ERP não deveria ser escolhido pela apresentação que impressionou mais o comitê.

Deveria ser escolhido com base em requisitos, evidências, custo total, riscos e, principalmente, na capacidade de atender aos objetivos do negócio.

Existe um dado da Gartner que merece atenção de qualquer empresa que esteja pensando em trocar ou implementar um ERP: mais de 70% das iniciativas de ERP implementadas recentemente não deverão atingir plenamente seus objetivos de negócio originais até 2027. A Gartner aponta, entre os fatores relacionados a esse cenário, abordagens excessivamente centradas em tecnologia, com pouco envolvimento dos stakeholders e pouco alinhamento com a estratégia da empresa. Gartner — What IT Leaders Must Do to Avoid Disappointing ERP Initiatives

Esse dado muda a pergunta.

Talvez o problema não seja simplesmente “por que projetos de ERP fracassam?”

Talvez devêssemos perguntar:

“Por que tantas empresas começam um projeto de ERP sem definir claramente o que precisam alcançar com ele?”

O problema começa antes da implantação

Quando falamos em projetos de ERP que atrasam, ultrapassam custos ou não entregam o resultado esperado, é comum colocar a culpa na implementação.

“O fornecedor não entregou.”

“A equipe não se adaptou.”

“O sistema era mais complexo do que imaginávamos.”

“Houve muitas customizações.”

Tudo isso pode acontecer.

Mas existe uma pergunta anterior que poucas empresas fazem:

Será que o problema começou quando o projeto foi implantado ou quando o ERP foi escolhido?

Na minha experiência, muitas vezes a resposta está na segunda opção.

Uma seleção mal estruturada cria problemas que só aparecem meses depois, quando o contrato já foi assinado, o projeto já começou e mudar de direção ficou muito mais caro.

A própria literatura sobre implementação de ERP mostra que o sucesso desses projetos depende de fatores que vão muito além da tecnologia, envolvendo planejamento, gestão, processos, pessoas, mudança organizacional e alinhamento entre o sistema e o negócio.

Por isso, não basta escolher um bom software. É preciso escolher o software certo para aquela empresa, dentro de um processo de decisão bem conduzido.

Mais de 70% das iniciativas de ERP podem não atingir seus objetivos de negócio

Existe um ponto da análise da Gartner que considero especialmente importante.

Segundo a consultoria, mais de 70% das iniciativas de ERP implementadas recentemente não deverão atingir plenamente seus objetivos de negócio originais até 2027.

A Gartner relaciona esse cenário, entre outros fatores, a abordagens centradas excessivamente na tecnologia, com baixo envolvimento dos stakeholders e pouco alinhamento entre o projeto de ERP e a estratégia corporativa.

Isso é fundamental.

Porque uma empresa não investe em um ERP simplesmente para trocar um sistema por outro.

Ela investe para melhorar processos, aumentar eficiência, ganhar previsibilidade, reduzir riscos, integrar informações e tomar decisões melhores.

Se o projeto entrega um novo software, mas não entrega os objetivos que justificaram o investimento, podemos realmente chamar isso de sucesso?

O ERP não pode ser um projeto isolado da estratégia

Eu vejo esse como um dos maiores riscos de uma seleção de ERP.

A empresa começa discutindo funcionalidades:

“Esse sistema tem esse módulo?”

“Tem esse dashboard?”

“Tem integração com determinado sistema?”

“Tem aplicativo?”

“Tem inteligência artificial?”

Todas essas perguntas são importantes.

Mas existe uma pergunta anterior:

“Quais objetivos de negócio queremos alcançar com esse ERP?”

A resposta deveria orientar todo o processo de seleção.

Se o objetivo é aumentar a previsibilidade financeira, os requisitos precisam refletir isso.

Se o problema é falta de integração entre vendas, estoque e financeiro, isso precisa estar claramente representado nos critérios de avaliação.

Se a empresa está crescendo e precisa ganhar escala sem aumentar a complexidade operacional na mesma proporção, o ERP precisa ser avaliado também pela capacidade de sustentar esse crescimento.

É essa conexão entre estratégia, processos e tecnologia que muitas seleções deixam de fazer.

1. A demonstração comercial não é um diagnóstico

Uma demonstração de ERP pode ser excelente.

O fornecedor mostra dashboards bonitos, processos integrados, automações, inteligência artificial, aplicativos, relatórios e dezenas de funcionalidades.

Tudo parece funcionar perfeitamente.

Mas existe um problema:

a demonstração foi preparada para vender.

Ela não necessariamente foi construída para responder às perguntas mais importantes para a sua empresa.

Por exemplo:

• O sistema atende aos processos críticos do meu negócio?
• Quais requisitos são atendidos nativamente?
• Quais dependem de configuração?
• Quais exigem customização?
• Quais integrações serão necessárias?
• Quais funcionalidades estão disponíveis na versão contratada?
• Quanto custará manter essas soluções ao longo dos anos?
• Quais riscos existem na implantação?
• O fornecedor tem experiência no meu segmento?
• Como será o suporte depois do go-live?

Quando essas perguntas não são estruturadas antes das demonstrações, cada fornecedor apresenta aquilo que considera seu ponto forte.

E a empresa acaba comparando apresentações, não soluções.

Isso não é uma seleção de ERP. É uma disputa de apresentações comerciais.

2. O fornecedor conhece o produto. A empresa precisa conhecer o problema.

Existe outra mudança de mentalidade que considero fundamental.

Quando a seleção começa pela demonstração, a empresa passa a enxergar o próprio negócio através daquilo que cada software oferece.

O fornecedor mostra seus diferenciais.

Apresenta seus módulos.

Demonstra seus dashboards.

Mostra automações.

Fala sobre inteligência artificial.

E tudo isso pode ser relevante.

Mas a pergunta deveria ser outra:

“Como essa solução contribui para resolver os problemas que realmente importam para a nossa empresa?”

Essa mudança parece simples, mas altera completamente a qualidade da decisão.

Em vez de adaptar a necessidade da empresa àquilo que o software apresenta, a organização passa a avaliar os softwares a partir de suas próprias necessidades e objetivos.

Primeiro o negócio.

Depois os requisitos.

Depois os fornecedores.

Depois o custo e o risco.

E só então a decisão.

3. Planilhas demais também podem virar um problema

Outro cenário que encontro com frequência é o oposto.

A empresa tenta ser extremamente criteriosa.

Cria uma planilha enorme.

Coloca centenas de requisitos.

Envia perguntas para vários fornecedores.

Recebe documentos, propostas, anexos, apresentações e respostas.

Depois passa semanas — às vezes meses — tentando consolidar tudo.

O problema não é usar uma planilha.

O problema é quando não existe um padrão de avaliação por trás dela.

Se cada fornecedor interpreta uma pergunta de maneira diferente, a comparação perde qualidade.

Se um requisito tem peso 5 para uma área e peso 10 para outra, a decisão fica inconsistente.

Se uma resposta está em uma apresentação, outra em uma proposta e outra em uma conversa com o vendedor, a rastreabilidade desaparece.

E, no final, alguém precisa dizer:

“Eu acho que esse ERP é melhor.”

É nesse momento que uma decisão que deveria ser baseada em evidências volta a ser baseada em opinião.

4. RFI e RFP existem por um motivo

É aqui que entram duas ferramentas importantes de uma seleção profissional: RFI e RFP.

O RFI, ou Request for Information, ajuda a estruturar a coleta inicial de informações dos fornecedores.

O RFP, ou Request for Proposal, aprofunda a solicitação com base nos requisitos definidos pela empresa.

A grande vantagem é simples:

todos os fornecedores respondem às mesmas perguntas.

Isso cria uma base de comparação.

Em vez de perguntar:

“O que o seu ERP oferece?”

a empresa passa a perguntar:

“Como sua solução atende este requisito específico do meu negócio?”

Essa mudança parece pequena.

Mas muda completamente a qualidade da decisão.

O objetivo é sair de uma comparação baseada em apresentações e construir uma avaliação baseada em requisitos, evidências e critérios previamente definidos.

5. O menor preço pode ser o ERP mais caro

Outro erro muito comum é olhar apenas para o investimento inicial.

Imagine dois fornecedores.

O primeiro apresenta uma proposta de R$ 500 mil.

O segundo apresenta uma proposta de R$ 650 mil.

À primeira vista, o primeiro parece claramente mais barato.

Mas e se, ao longo de cinco anos, ele exigir:

• Mais customizações;
• Mais integrações;
• Infraestrutura adicional;
• Maior esforço de suporte;
• Mais horas de consultoria;
• Atualizações mais caras;
• Ferramentas complementares;
• Maior esforço interno da equipe?

A comparação muda.

Por isso, uma seleção madura precisa olhar para o TCO — Total Cost of Ownership.

Não apenas:

“Quanto custa contratar?”

Mas:

“Quanto essa decisão vai custar para a empresa ao longo do tempo?”

O TCO permite considerar não apenas o investimento inicial, mas também os custos associados à implantação, licenciamento, infraestrutura, suporte, evolução, integrações e demais componentes necessários para manter a solução funcionando ao longo do tempo.

Porque o ERP mais barato na proposta pode não ser o mais barato para a empresa.

6. Risco também precisa entrar na conta

Existe outro ponto que normalmente fica escondido nas planilhas de comparação: o risco.

Duas soluções podem ter uma aderência parecida e custos semelhantes, mas riscos completamente diferentes.

Por exemplo:

• Dependência de customizações;
• Integrações críticas;
• Dependência de pessoas específicas;
• Maturidade do fornecedor;
• Capacidade de suporte;
• Complexidade de migração de dados;
• Dificuldade de adoção pelos usuários;
• Riscos relacionados ao cronograma;
• Necessidade de infraestrutura adicional.

Se esses riscos não forem registrados, eles continuam existindo.

Só não aparecem na apresentação ao comitê.

Uma matriz de risco ajuda justamente a transformar essas incertezas em algo que pode ser discutido, priorizado e mitigado.

E isso é especialmente importante porque risco não é sinônimo de problema.

Uma solução pode apresentar riscos maiores e ainda assim ser a melhor escolha.

O importante é que o comitê conheça esses riscos antes de decidir.

7. Sem rastreabilidade, a decisão fica vulnerável

Imagine que, seis meses depois da escolha, alguém pergunte:

“Por que escolhemos esse ERP?”

Qual seria a resposta?

“Porque foi o que o diretor gostou mais?”

“Porque o vendedor demonstrou melhor?”

“Porque tinha uma condição comercial interessante?”

“Porque todo mundo achou que era o mais completo?”

Essas respostas podem até explicar uma decisão informal.

Mas não sustentam uma decisão estratégica.

Um comitê precisa conseguir voltar ao processo e enxergar:

• Quais eram os requisitos;
• Quais eram os critérios;
• Como cada fornecedor respondeu;
• Quanto cada solução custava;
• Quais riscos foram identificados;
• Quais premissas foram consideradas;
• Por que uma alternativa foi escolhida em relação às outras.

Isso é rastreabilidade.

E rastreabilidade não serve apenas para auditoria.

Serve para proteger a própria empresa.

Porque decisões importantes precisam sobreviver à troca de pessoas.

8. A seleção começa antes da demonstração

Por tudo isso, eu defendo que uma seleção de ERP bem estruturada precisa começar antes de qualquer fornecedor abrir uma tela do sistema.

Primeiro, a empresa precisa entender seus objetivos.

Depois, mapear os processos críticos.

Definir requisitos.

Priorizar o que realmente importa.

Estabelecer critérios de avaliação.

E somente então levar os fornecedores para uma comparação estruturada.

A demonstração deixa de ser o ponto de partida.

Ela passa a ser uma etapa de validação.

E essa diferença é enorme.

Porque, quando todos os fornecedores respondem aos mesmos requisitos e são avaliados pelos mesmos critérios, a empresa deixa de comparar apresentações comerciais e passa a comparar aderência ao negócio.

É nesse momento que RFI, RFP, TCO e análise de riscos deixam de ser apenas ferramentas de compras ou TI e passam a fazer parte de uma governança de decisão.

O fracasso não começa necessariamente no go-live

Quando um projeto de ERP dá errado, é muito comum olhar para a fase de implantação.

Mas talvez devêssemos voltar algumas etapas.

A empresa definiu corretamente seus objetivos?

Entendeu quais problemas precisava resolver?

Definiu seus requisitos?

Comparou os fornecedores usando os mesmos critérios?

Entendeu o custo total?

Mapeou os riscos?

Documentou as premissas?

Conseguiu explicar por que escolheu aquela solução?

Se a resposta for “não” para várias dessas perguntas, talvez o problema do projeto tenha começado muito antes da implantação.

É justamente por isso que a escolha do ERP precisa ser tratada como uma decisão estratégica.

O projeto não começa quando o fornecedor inicia a implantação. O projeto começa quando a empresa decide o que espera alcançar.

Método não elimina o risco. Ele torna o risco visível.

Nenhum método consegue garantir que um projeto de ERP será perfeito.

ERP envolve pessoas, processos, dados, tecnologia, fornecedores e mudanças organizacionais.

Sempre haverá imprevistos.

Mas existe uma diferença enorme entre assumir um risco conscientemente e descobrir o risco depois de assinar o contrato.

Método serve para isso.

Para transformar opinião em critério.

Para transformar proposta em comparação.

Para transformar custo inicial em visão de TCO.

Para transformar incerteza em risco documentado.

E para transformar uma decisão difícil em uma decisão que pode ser explicada.

No fim, é isso que eu acredito que uma empresa deveria buscar ao escolher um ERP:

não a solução que parece melhor durante uma demonstração, mas a solução que apresenta a melhor combinação entre aderência ao negócio, custo, risco e capacidade de entregar os objetivos estratégicos definidos pela empresa.

Porque software de missão crítica não deveria ser escolhido no feeling.

Deveria ser escolhido com método.

Como transformar a seleção de ERP em um processo de decisão

Eu costumo organizar uma seleção estruturada em cinco grandes etapas:

1. Diagnóstico

Entender os processos atuais, problemas, objetivos e prioridades da empresa.

2. Requisitos

Transformar as necessidades do negócio em requisitos claros e priorizados.

3. RFI e RFP

Enviar perguntas estruturadas aos fornecedores e receber respostas comparáveis.

4. TCO e riscos

Avaliar o custo total da decisão e os riscos técnicos, comerciais e operacionais.

5. Decisão

Consolidar as informações em uma visão executiva que permita ao comitê decidir com base em evidências.

Essa estrutura ajuda a transformar a seleção de ERP em um processo de decisão estruturado, em vez de uma sequência de apresentações comerciais.

Quer estruturar a próxima seleção de ERP da sua empresa?

Eu criei o Decision Hub justamente para ajudar empresas a conduzir esse processo de forma estruturada, com requisitos, RFI, RFP, TCO, matriz de risco e painel executivo.

A ideia é substituir planilhas dispersas e decisões baseadas em percepção por um processo com método, comparação e rastreabilidade.

Se a sua empresa está avaliando um novo ERP, vale a pena começar pela pergunta certa:

O que precisamos alcançar com essa decisão?

Depois disso, fica muito mais fácil entender qual tecnologia realmente faz sentido.

👉  Conheça o Decision Hub

Antes de escolher o ERP, escolha como você vai tomar essa decisão.

Referências

GARTNER. – O que líderes de TI devem fazer para evitar decepcionar iniciativas de ERP. Disponível em: Gartner — What IT Leaders Must Do to Avoid Disappointing ERP Initiatives.

SAP — Metodologia estruturada de implementação do SAP Business One. Disponível em: Utilização da metodologia do projeto de implementação

Leia também

1. Desafios de implementar o SAP Business One e como solucioná-los.

Desafios de implementar o SAP Business One e como solucioná-los — SPS Group

2. Quando e por que implantar um sistema ERP?

Quando e por que implantar um sistema ERP? — SPS Group

3. Como Fazer um Levantamento de Necessidades para Implementação de um ERP

Como Fazer um Levantamento de Necessidades para Implementação de um ERP

4. Toda empresa toma decisões. Poucas têm um método para decidir.

Toda empresa toma decisões. Poucas têm um método para decidir.