Falhas na Implementação de ERP: Causas e Prevenção

As implementações de ERP (Enterprise Resource Planning) falham com muito mais frequência do que a maioria das organizações espera. A resposta mais direta: a maior parte das falhas não tem origem no próprio software, mas sim numa gestão da mudança deficiente, numa formação inadequada, num planeamento fraco e no pressuposto errado de que implementar nova tecnologia produz automaticamente a adoção por parte dos utilizadores. Compreender os padrões subjacentes ao fracasso na implementação de ERP pode poupar a uma organização anos de perturbação e dezenas de milhões de euros.

Investigações citadas por analistas do setor mostram que mais de 70% das implementações de ERP não conseguem cumprir o caso de negócio original. Os prejuízos financeiros acumulam-se rapidamente: perdas iniciais no projeto, perturbação operacional, custos de mitigação e danos reputacionais. As empresas identificam frequentemente as causas de um retorno sobre o investimento em software negativo apenas depois de os danos estarem feitos.

"Muitos projetos falham porque os recursos são canalizados para o próprio projeto, negligenciando os colaboradores, como milhões atirados pela janela fora."
Guillaume Koch, Althea (entrevista a líder de mudança)

Este artigo examina o custo real do fracasso no ERP, três dos casos de estudo de alto perfil mais instrutivos - incluindo o fracasso do ERP da Nike, o fracasso da implementação do ERP da Hershey e o fracasso do ERP da Revlon - e um quadro prático para evitar os mesmos erros na sua organização.

Qual é o custo real do fracasso na implementação de um ERP?

O fracasso na implementação de um ERP não é um acontecimento isolado. Desenvolve-se ao longo do tempo, nas rubricas orçamentais, no moral dos colaboradores e nas relações com os clientes. As consequências distribuem-se por cinco categorias que cada organização deve mapear antes de um projeto ter início.

O tempo perdido raramente é recuperado

As empresas perdem tipicamente vários anos a identificar, mitigar e resolver as causas raiz da falha. A recuperação exige uma reformulação quase completa da abordagem original de implementação de ERP, abrangendo a gestão da mudança, a estratégia de formação e a governação do projeto, para garantir que os mesmos erros não se repetem.

As perdas financeiras vão além do orçamento do projeto

As perdas financeiras relacionadas com o ERP assumem muitas formas: perda de vendas, abandono de clientes, pressão dos acionistas, quedas no preço das ações, perturbação da cadeia de abastecimento e litígios. Estas são distintas de, e muitas vezes superiores a, o excesso de custos do orçamento original do projeto.

Os custos de mitigação são sempre superiores aos custos de prevenção

Quando as organizações reduzem atalhos na gestão da mudança ou na formação para reduzir custos, o preço de resolver os problemas daí resultantes excede consistentemente o que uma preparação adequada teria custado. As despesas de mitigação incluem honorários de consultoria, software de substituição, custos legais e os encargos operacionais necessários para repor a produtividade normal.

A insatisfação dos colaboradores agrava o problema

Um projeto de ERP falhado raramente fica confinado ao departamento de TI. A fraca adoção do software gera frustração digital, resistência dos colaboradores a mudanças futuras e uma experiência de utilizador no local de trabalho prejudicial. Estes custos culturais persistem muito depois de os problemas técnicos serem resolvidos.

A insatisfação dos clientes é o dano mais visível

A perturbação no cumprimento de encomendas, a escassez de produtos e a cobertura negativa na imprensa traduzem-se diretamente em desconfiança por parte dos clientes e, em casos graves, no seu abandono. Os três estudos de caso apresentados abaixo ilustram exatamente como isto se desenvolve.

Três estudos de caso de falhas de implementação de ERP de grande visibilidade

Estes três exemplos representam algumas das falhas de ERP mais amplamente analisadas de que há registo. Cada um deles demonstra um padrão distinto de fatores críticos de falha que as organizações podem utilizar como lista de verificação do que devem evitar.

1. Falha na implementação do ERP da Nike: sete anos e 500 milhões de dólares para recuperar

A falha do ERP da Nike é um dos exemplos mais citados de uma falha de planeamento de recursos empresariais na história dos negócios, e começou com uma decisão que parecia razoável no papel.

Contexto. Em 2000, a Nike estava a acelerar a sua expansão global e precisava de modernizar a sua cadeia de abastecimento. A empresa comprometeu aproximadamente 400 milhões de dólares num projeto de transformação digital de ERP destinado a substituir um sistema legado obsoleto, melhorar a previsão da procura e aumentar a quota de mercado. Os componentes principais incluíam um novo sistema ERP SAP e software de gestão da cadeia de abastecimento da i2 Technology.

Porque falhou o sistema ERP da Nike. O erro crítico foi implementar o software de planeamento da procura da i2 Technology em paralelo com o ERP legado existente, em vez de o integrar corretamente com a plataforma SAP que estava a ser adotada. Os dois sistemas operavam com formatos de dados e regras de negócio diferentes. Ligá-los exigiu uma personalização complexa que introduziu erros de previsão quase de imediato. O sistema começou a gerar sinais de procura imprecisos: a encomendar em excesso alguns produtos e a encomendar a menos outros. A cadeia de abastecimento da Nike, já sobrecarregada por uma crescente presença global, não conseguiu absorver os erros.

O custo do fracasso do ERP da Nike. O impacto financeiro imediato foi de cerca de 100 milhões de dólares em vendas perdidas. O preço das ações da Nike caiu aproximadamente 20% após a divulgação dos problemas na cadeia de fornecimento, e a empresa enfrentou ações coletivas relacionadas com encomendas não cumpridas. A recuperação total do fracasso do Nike i2 exigiu aproximadamente sete anos adicionais e um investimento estimado de 500 milhões de dólares. A Nike concluiu finalmente a implementação do SAP ERP em 2004, mas o custo total da primeira tentativa falhada superou em muito o orçamento inicial do projeto.

A lição do caso de estudo de implementação do ERP da Nike. Apressar a integração entre sistemas incompatíveis cria falhas de integridade de dados que se propagam rapidamente por toda a cadeia de operações de fornecimento. Objetivos irrealistas e prazos comprimidos são consistentemente identificados como fatores críticos de falha na implementação de ERP.

2. Falha na implementação do ERP da Hershey: encurtar os testes no pior momento possível

A falha na implementação do ERP da Hershey é um exemplo clássico de como as decisões de calendarização podem fazer colapsar um projeto tecnológico de outra forma sólido no momento da entrada em produção.

Contexto. No final da década de 1990, a Hershey Foods Corporation lançou um grande projeto de ERP no valor de aproximadamente 112 milhões de dólares, envolvendo o SAP R/3, o software de cadeia de fornecimento Manugistics e o software CRM da Siebel Systems. O âmbito era ambicioso, mas o prazo original de 48 meses foi posteriormente comprimido para 30 meses.

Por que razão o ERP da Hershey falhou. De acordo com a análise do caso documentado, a falha na implementação do ERP da Hershey resultou de dois erros críticos: encurtar as fases de testes e selecionar uma data de entrada em produção irrealista. A empresa optou por entrar em produção no verão de 1999, imediatamente antes da época alta de confeitaria do Halloween e do Natal. Quando o sistema entrou em produção, não tinha sido adequadamente testado com volumes de produção reais. O processamento de encomendas entrou em colapso e o sistema de gestão de armazém não conseguiu gerir o pico de procura.

O custo do fracasso do ERP da Hershey. A Hershey não conseguiu satisfazer aproximadamente 100 milhões de dólares em encomendas de produtos de confeitaria durante a sua época de vendas mais crítica. A empresa registou uma queda de 19% nos lucros trimestrais e uma redução de 8% nas vendas líquidas no terceiro trimestre de 1999. Os retalhistas que não conseguiram obter produtos da Hershey transferiram o espaço em prateleira para concorrentes, sendo que parte dessa quota de mercado nunca regressou.

A lição do caso de estudo da Hershey. Nenhuma data de entrada em produção de um ERP deve ser vinculada a um período de pico de negócio, a menos que os testes tenham sido concluídos em condições de carga realistas. A compressão de prazos para cumprir datas arbitrárias é um dos fatores de sucesso e falha mais consistentes na análise de implementações de ERP.

3. Falha do ERP da Revlon: ações judiciais de investidores e 64 milhões de dólares em expedições não cumpridas

A falha do ERP da Revlon demonstra como uma má planificação ao nível da governação do projeto pode destruir simultaneamente a capacidade operacional e a confiança dos investidores.

Contexto. Na sequência da aquisição da Elizabeth Arden em 2016, a Revlon iniciou uma grande implementação do SAP HANA destinada a integrar o planeamento, o aprovisionamento, a produção e a distribuição em toda uma operação global recentemente alargada.

Por que razão o projeto ERP da Revlon falhou. A Revlon não conseguiu concluir o seu relatório financeiro anual devido a problemas de implementação. O sistema não conseguia registar nem contabilizar com precisão o inventário, o que significava que a empresa não era capaz de fabricar as quantidades corretas de produtos nem de satisfazer as encomendas dos clientes. A integração do negócio pós-aquisição acrescentou uma complexidade que o plano do projeto não tinha abordado de forma adequada.

O custo do fracasso do ERP da Revlon. A Revlon registou uma queda de 6,9% no preço das ações nas 24 horas seguintes à divulgação pública da notícia. A empresa não conseguiu satisfazer aproximadamente 64 milhões de dólares em expedições de produtos e gastou mais 53,6 milhões de dólares na tentativa de restabelecer os níveis de serviço ao cliente. Os investidores intentaram ações coletivas, um desfecho raro que ilustra a gravidade com que uma falha de ERP pode abalar a confiança das partes interessadas. A Revlon não conseguiu recuperar as vendas perdidas, e os relatórios indicam que a atenção da gestão foi substancialmente desviada pela crise em curso.

A lição do caso de estudo da Revlon. A integração de ERP pós-aquisição exige planeamento adicional de âmbito e governação. A implementação de um novo sistema sem controlos adequados sobre a qualidade dos dados de inventário cria falhas operacionais imediatas com consequências financeiras em cascata.

Outros exemplos notáveis de falhas de ERP

A Nike, a Hershey e a Revlon estão entre os casos mais documentados, mas não são casos isolados. Uma análise dos exemplos de falhas de ERP ao longo das últimas três décadas revela padrões consistentes.

A falha na implementação do SAP pela Lidl é particularmente instrutiva para a análise de falhas de implementação SAP. A Lidl tinha desenvolvido mais de 90 soluções proprietárias internas ao longo do tempo. Quando tentou consolidá-las num único sistema SAP HANA, a empresa procurou personalizar o software para replicar os seus processos existentes em vez de adaptar os seus processos ao modelo ERP padrão. O sistema SAP registava o inventário a preços de venda a retalho; a Lidl operava com preços de compra. Em vez de se alinhar com o padrão SAP, a equipa enveredou por uma personalização extensiva que gerou uma dívida técnica crescente. Após sete anos e aproximadamente 580 milhões de dólares investidos, a Lidl abandonou o projeto e regressou ao seu sistema de gestão de inventário original.

O caso Lidl é uma ilustração direta de um fator de falha crítico: tratar uma implementação ERP como um exercício de configuração de software em vez de um programa de mudança organizacional.

Quais são os fatores de falha críticos na implementação de ERP?

Nos estudos de caso acima e no conjunto mais alargado de investigação sobre falhas de ERP, várias causas de raiz surgem repetidamente. Estes são os desafios de adoção digital que transformam um projeto ERP de um ativo empresarial numa responsabilidade.

Falta de objetivos claros e âmbito realista

Os projetos que começam sem metas mensuráveis e um âmbito bem definido expandem-se frequentemente durante a execução, um fenómeno conhecido como deriva de âmbito. Sem objetivos claros, não existe nenhum mecanismo para avaliar se a implementação está no bom caminho ou para priorizar decisões quando são necessárias contrapartidas.

Prazos comprimidos ou irrealistas

Tanto as falhas de ERP da Hershey como da Nike envolveram prazos que não permitiram tempo adequado para testes. Reduzir as fases de teste para cumprir um prazo é consistentemente apontado como uma das decisões de maior risco em qualquer projeto ERP de grande escala.

Gestão da mudança inadequada

A gestão da mudança não é um exercício de comunicação. É o processo estruturado de preparar a organização, os seus líderes e os seus utilizadores finais para trabalharem de uma forma fundamentalmente diferente. A falha na implementação do SAP pela Lidl é o exemplo mais claro: sete anos de trabalho técnico colapsaram em parte porque o lado organizacional da mudança nunca foi adequadamente gerido.

Formação insuficiente dos utilizadores e baixa adoção

Os sistemas ERP são apenas tão eficazes quanto a exatidão e consistência dos dados neles inseridos. Se os utilizadores finais não forem adequadamente formados antes do arranque, ou se a formação ocorrer demasiado cedo e for esquecida no dia do lançamento, o sistema produz resultados pouco fiáveis desde o primeiro dia.

"Demorou três ou quatro meses, e tivemos de garantir que a formação acontecia antes do arranque, mas não demasiado antes, para que as pessoas não se esquecessem. Inevitavelmente houve dificuldades no lançamento: as pessoas tinham esquecido como realizar determinada operação."
Elder Mathias, DSI, Aftral (podcast CIO Pioneers)

Este é precisamente o cenário que transforma um sistema tecnicamente sólido numa implementação ERP falhada. O apoio à formação contínua e em contexto, disponível no momento da necessidade, é uma abordagem mais fiável do que um programa de formação pontual antes do lançamento.

Má planificação da integração

A falha na implementação ERP da Nike é o caso de referência aqui. Executar dois sistemas com diferentes padrões de dados em paralelo cria problemas de integridade de dados que se amplificam em todos os processos interligados. A arquitetura de integração deve ser definida e testada antes de qualquer sistema entrar em funcionamento.

Personalizar o software para corresponder a processos legados

As plataformas ERP padrão incorporam as melhores práticas do setor. Personalizar extensivamente o software para corresponder aos processos organizacionais existentes, como fez a Lidl, introduz complexidade técnica que dificulta futuras atualizações e cria sistemas difíceis de suportar. A melhor abordagem é adaptar os processos ao modelo padrão do ERP, limitando a personalização a requisitos genuinamente únicos.

Patrocínio executivo fraco e governação pouco clara

Quando a liderança sénior não está ativamente envolvida, a tomada de decisões fica bloqueada, os conflitos de recursos ficam por resolver e o projeto perde prioridade organizacional. O patrocínio executivo é consistentemente identificado como um fator de sucesso nas implementações de ERP que cumprem os seus objetivos de negócio.

Parceiro de implementação errado ou composição inadequada da equipa interna

O fracasso da implementação SAP da MillerCoors é frequentemente citado como exemplo de seleção de um parceiro de implementação sem experiência relevante suficiente. O custo de substituir um parceiro a meio do projeto, ou de desenvolver capacidade interna após o arranque, é substancialmente mais elevado do que o custo de uma avaliação adequada do parceiro no início.

10 passos para evitar o fracasso na implementação de ERP

Os padrões identificados nestes casos de insucesso apontam para um quadro prático de prevenção. Qualquer organização que esteja a planear ou a executar um projeto de ERP pode utilizar estes passos para reduzir o risco.

1. Escolha um software adequado aos seus processos de negócio reais. Selecione a melhor opção para o seu modelo operacional, não o nome mais proeminente do mercado. Avalie até que ponto o sistema padrão corresponde aos seus processos antes de se comprometer com personalizações.
2. Selecione parceiros de implementação com base na experiência relevante. Verifique se o seu parceiro tem experiência específica com a plataforma escolhida, o seu setor de atividade e projetos de escala e complexidade comparáveis.
3. Clarifique os papéis e responsabilidades de cada interveniente. Defina a responsabilização a nível executivo, de gestão de projeto e de utilizador final antes do início do projeto. A ambiguidade na titularidade é um caminho direto para decisões bloqueadas.
4. Defina explicitamente o âmbito, o orçamento, o calendário e os parâmetros de gestão de risco. Um plano de projeto realista que contemple tempo para testes, formação e contingência tem mais probabilidades de sucesso do que um calendário agressivo que não deixa margem para problemas.
5. Construa um programa estruturado de gestão da mudança. Isto implica comunicar o propósito e os benefícios da mudança a toda a organização, envolver os resistentes desde cedo e dotar os líderes das ferramentas necessárias para apoiar as suas equipas durante a transição. Envolver competências em gestão da mudança, sejam internas ou externas, desde as fases iniciais do projeto é um fator de sucesso documentado.
6. Realize a formação perto do arranque e torne-a contínua. Como o caso Aftral acima ilustra, a formação ministrada demasiado cedo é esquecida na altura do lançamento. Realize a formação nas semanas anteriores ao arranque e complemente-a com orientação na própria aplicação, a que os utilizadores possam aceder no momento em que precisam.
7. Estabeleça um processo de gestão de risco com vias de escalada claras. Identifique os momentos de maior risco no calendário de implementação, em especial os pontos de integração de sistemas e o arranque, e defina antecipadamente como os problemas serão escalados e resolvidos.
8. Não reduza os testes para cumprir um prazo. O fracasso da implementação ERP da Hershey é a evidência mais clara de que entrar em produção sem testes adequados durante um período de pico de negócio é uma decisão com consequências catastróficas. Se os testes não estiverem concluídos, adie a data de arranque.
9. Implemente implementações em grande escala de forma incremental. Uma abordagem faseada ou baseada em projetos-piloto cria a oportunidade de identificar problemas numa escala menor, ajustar a estratégia e reforçar a confiança organizacional antes da implementação completa.
10. Afete recursos dedicados à otimização pós-arranque. A data de arranque não é o fim do projeto. Reserve orçamento e tempo de pessoal para o período de estabilização, que tipicamente envolve a resolução de problemas de qualidade de dados, o apoio aos utilizadores e a otimização de fluxos de trabalho.

Como as plataformas de adoção digital abordam o fator humano no insucesso do ERP

O tema mais persistente em todos os estudos de caso de insucesso de ERP é que o fracasso tecnológico é quase sempre um fracasso humano. Os utilizadores que não compreendem o sistema, não confiam nele ou recorrem a soluções alternativas comprometem a qualidade dos dados de que todo o sistema depende.

Uma DAP (Plataforma de Adoção Digital) responde diretamente a este desafio, incorporando orientação estruturada dentro da própria aplicação ERP. Em vez de depender de que os colaboradores se lembrem de formações em sala realizadas semanas antes, uma DAP fornece instruções passo a passo, dicas contextuais e ajuda a pedido no momento exato em que o utilizador está a executar uma tarefa no sistema. Esta abordagem reduz o intervalo entre o arranque e a plena competência dos utilizadores, que é o período em que ocorre a maioria dos erros de dados e falhas de processo.

A Lemon Learning é uma plataforma de adoção digital criada para apoiar implementações de ERP em plataformas como SAP, Oracle, Microsoft Dynamics e Infor. Ao sobrepor formação e suporte na aplicação ao ERP, a Lemon Learning permite às organizações manter a proficiência dos utilizadores não apenas no arranque, mas ao longo de todo o ciclo de vida do sistema, incluindo atualizações e alterações de processos.

Para as organizações que gerem a dimensão de mudança organizacional de um projeto de ERP, a página de soluções de gestão da mudança descreve como uma plataforma de adoção digital apoia lançamentos estruturados, reduz a resistência e acelera o tempo de aquisição de competências pelos utilizadores finais.

Pode também explorar o guia mais abrangente sobre plataforma de adoção digital ou consultar os estudos de caso de clientes da Lemon Learning para ver como as organizações utilizaram a orientação em aplicação para melhorar os resultados de adoção de ERP.

Principais conclusões: o que todas as organizações devem aprender com as falhas na implementação de ERP

A falha na implementação de ERP não é principalmente um problema tecnológico. É um problema de planeamento, governação e gestão da mudança. A falha de ERP da Nike, a falha na implementação de ERP da Hershey, a falha de ERP da Revlon e a falha SAP da Lidl tiveram perfis técnicos diferentes, mas partilharam as mesmas causas subjacentes: prazos comprimidos, investimento insuficiente em formação e gestão da mudança, fraco planeamento de integração e atenção insuficiente à forma como os utilizadores reais iriam interagir com o sistema desde o primeiro dia.

As organizações que têm sucesso com as implementações de ERP tratam a tecnologia como um componente de uma transformação organizacional mais ampla. Investem na gestão da mudança desde as fases mais iniciais do projeto, testam exaustivamente antes de entrar em funcionamento e proporcionam apoio de formação contínua que não termina no dia em que o sistema é lançado.

Se a sua organização está a planear uma implementação de ERP ou a trabalhar em desafios num projeto existente, os passos e as estruturas acima representam as lições consolidadas das falhas de ERP mais dispendiosas registadas. O custo de as aplicar antes da entrada em funcionamento é uma fração do custo de as aprender posteriormente.