Um ERP mal implementado não se nota no dia do arranque: nota-se seis meses depois, quando a equipa mantém uma folha de cálculo paralela porque o sistema “não serve para o nosso caso”. A essa altura já se pagou a licença, a consultoria e a migração, e voltar atrás custa mais do que continuar.
Quase todos os projetos que descarrilam fazem-no pelas mesmas razões, e nenhuma delas é técnica. Estas são as dez falhas que mais se repetem e como detetá-las a tempo.
Em resumo: as implementações de ERP raramente falham por causa do software. Falham por âmbito mal definido, dados de origem sujos, excesso de personalização, ausência de um responsável interno com poder de decisão e formação deixada para o fim. São problemas de gestão, e todos são evitáveis.
1. Começar sem ter mapeado os processos
É o erro de origem do qual nascem quase todos os outros. Compra-se o ERP e só depois se descobre como a empresa trabalha realmente, normalmente a meio da configuração.
O processo documentado e o processo real quase nunca coincidem. A pessoa da administração aplica há oito anos uma exceção que não está escrita em lado nenhum e que afinal representa 30% das encomendas.
Como evitá-lo: dedique as primeiras semanas a documentar o fluxo real — não o do manual — da encomenda ao recebimento e da compra ao pagamento. Sente-se com quem o executa todos os dias, não apenas com quem o dirige. É esse mapa que depois permite decidir com critério o que se normaliza e o que se respeita.
2. Definir o âmbito como uma lista de desejos
Quando se pergunta a cada departamento do que precisa, saem duzentos requisitos e todos são “imprescindíveis”. O resultado é um projeto que não cabe no orçamento e que se corta a meio do caminho, quase sempre por onde mais dói.
Como evitá-lo: classifique cada requisito em três caixas: bloqueia a operação, poupa tempo mensurável e seria bom ter. A primeira caixa entra na fase 1, a segunda prioriza-se por horas poupadas por mês, e a terceira revê-se seis meses após o arranque. Muitos desses requisitos caem sozinhos assim que se vê o sistema a funcionar.
3. Migrar dados sujos
É a causa número um de atrasos, e a mais subestimada. Ninguém quer reconhecer que a ficha de clientes tem duplicados, referências obsoletas e campos preenchidos à mão com critérios diferentes conforme o ano.
Um ERP não corrige isso: herda-o e amplifica-o, porque agora esse dado alimenta a contabilidade, o armazém e a faturação ao mesmo tempo.
Como evitá-lo: audite os dados antes de assinar o calendário. Conte duplicados, lacunas e valores fora de intervalo em clientes, artigos e fornecedores. Limpe na origem e aproveite para arquivar o que já não se usa: migrar quinze anos de histórico que ninguém consulta encarece o projeto sem trazer nada. O nosso guia sobre migrar de Excel para um ERP entra no detalhe desta fase.
4. Personalizar tudo desde o primeiro dia
A personalização é viciante porque na reunião parece sempre razoável. O problema aparece na primeira atualização do produto, quando é preciso rever cada desenvolvimento à medida um a um.
Cada personalização paga-se três vezes: ao construí-la, ao mantê-la e em cada atualização.
Como evitá-lo: aplique a regra de partida de adaptar o processo ao standard, e personalizar apenas quando esse processo for uma verdadeira vantagem competitiva. Se a sua forma de calcular os custos de produção é o que o distingue, personalize-a. Se é o formato da guia de remessa, adapte-se. Um teste útil: pergunte o que aconteceria se esse processo fosse feito como o faz o resto do setor. Se a resposta for “nada de grave”, não o personalize.
5. Não colocar um responsável interno com poder de decisão
O projeto precisa de alguém de casa que decida quando dois departamentos discordam sobre como deve funcionar um fluxo. Se essa figura não existe, cada decisão escala para a direção e o calendário enche-se de esperas.
A falha associada é igualmente frequente: nomear essa pessoa e não a aliviar de trabalho. Um projeto de ERP consome tempo real, e quem o lidera com o dia já cheio acaba a atender o urgente e a adiar o importante.
Como evitá-lo: nomeie um responsável com autoridade sobre processos e atribua-lhe uma percentagem explícita do seu horário. Que esteja escrito, não subentendido.
6. Deixar a formação para o fim
É o corte fácil quando o orçamento aperta: reduz-se a formação a uma sessão de duas horas na semana anterior ao arranque. Depois a equipa aprende à medida que avança, cada um à sua maneira, e consolidam-se formas erradas de usar o sistema que depois custa muito corrigir.
Como evitá-lo: forme por função e não por módulo — a cada pessoa aquilo que vai usar —, faça-o com dados reais da empresa e agende uma segunda sessão duas ou três semanas depois do arranque, que é quando surgem as perguntas a sério. Reserve esse orçamento desde o início e proteja-o.
7. Escolher o arranque big bang sem necessidade
Arrancar todos os módulos e todas as instalações no mesmo dia é tentador porque parece mais limpo. Também significa que qualquer problema aparece ao mesmo tempo em todas as frentes e com a empresa inteira a olhar.
Como evitá-lo: em organizações pequenas com processos homogéneos, o big bang é assumível. Em estruturas multiempresa, multipaís ou com produção, arranque por fases: primeiro um módulo ou uma instalação, estabiliza-se, e replica-se o que se aprendeu. Alarga o calendário e reduz muitíssimo o risco.
8. Confundir o go-live com o fim do projeto
No dia do arranque o sistema funciona, mas a organização ainda não. As primeiras semanas concentram incidentes, dúvidas e ajustes, e é precisamente quando a equipa de implementação costuma desmobilizar-se.
Como evitá-lo: planeie uma fase de estabilização com suporte reforçado e um canal único onde a equipa possa perguntar sem fricção. Meça incidentes por semana: se não descem, algo do desenho não encaixa na operação real e convém revê-lo antes que o uso de atalhos se torne normal.
9. Não integrar o ERP com o que já funciona
Um ERP que não fala com a loja online, o CRM ou o POS transforma alguém da equipa numa ponte humana que copia dados de um sistema para outro. Esse trabalho não aparece em nenhum orçamento e, no entanto, paga-se todos os meses.
Como evitá-lo: identifique desde o início os pontos de contacto entre sistemas e trate-os como parte do âmbito, não como um extra. Confirme que o ERP tem API documentada e verifique que as integrações que lhe prometem já existem e funcionam num cliente real. Nós fizemos este trabalho tanto sobre produto standard — por exemplo integrando o Odoo — como construindo a camada à medida quando o standard não chegava.
10. Medir o sucesso pelo cumprimento do calendário
Entregar dentro do prazo um sistema que ninguém usa não é um sucesso. No entanto, o calendário é a única coisa que muitos comités medem, porque é o mais fácil de olhar.
Como evitá-lo: defina dois ou três indicadores de negócio antes de começar e meça-os aos três e aos seis meses. Por exemplo: dias de fecho contabilístico, tempo entre a encomenda e a guia de remessa, percentagem de encomendas com incidente. Se o ERP funciona, esses números mexem-se. Se não se mexem, tem um problema mesmo que o projeto tenha sido entregue a horas.
Sinais de alerta durante o projeto
Quatro sintomas que antecipam problemas com semanas de antecedência:
| Sinal | O que costuma indicar |
|---|---|
| As reuniões de acompanhamento esvaziam-se | A organização deixou de sentir o projeto como seu |
| Aparecem folhas de cálculo paralelas nos testes | O sistema não cobre um fluxo real e ninguém o disse |
| Todas as decisões escalam para a direção | Falta um responsável com poder real |
| A lista de personalizações cresce todas as semanas | O âmbito não foi verdadeiramente fechado |
Como o abordamos nós
Na Soamee começamos sempre pelo mapa de processos e pela auditoria de dados, antes de falar de módulos. E dizemos que não quando aquilo de que o cliente precisa é um produto standard bem configurado em vez de um desenvolvimento: se a sua operação encaixa no que já existe no mercado, o comparativo entre Odoo, SAP e Sage para PMEs é melhor ponto de partida do que qualquer proposta nossa.
O desenvolvimento à medida faz sentido quando o processo que o diferencia não cabe no produto standard, e o sinal é concreto: horas de pessoal dedicadas todos os meses a acertar à mão aquilo que o sistema não sabe fazer. Quando esse custo supera o de o construir bem, a decisão já está tomada.
Tem uma implementação a decorrer que não acaba de arrancar, ou está prestes a começar uma? Conte-nos o caso e damos-lhe uma leitura honesta de por onde se está a torcer.