Os erros na implementação de ERP que mais custam caro são erros de execução: decisões de calendário, de dados e de teste que parecem detalhe no cronograma e viram problema no primeiro dia de uso. Os dez abaixo aparecem com frequência em projetos de pequenas e médias empresas. Para cada um, o que acontece quando ele é cometido e como evitar, separando o que é responsabilidade do fornecedor do que é decisão da empresa.
1. Começar sem escopo escrito da primeira fase
Sem uma lista fechada do que entra na primeira fase, cada reunião acrescenta um pedido: um relatório novo, uma integração a mais, um módulo que "já que estamos fazendo" pode entrar junto. O prazo cresce sem que ninguém tenha decidido isso.
O efeito colateral é pior que o atraso: com o escopo aberto, nenhuma área sabe quando sua parte está pronta, e o teste final nunca começa porque sempre falta configurar algo.
Como evitar: escreva em uma página os módulos, processos e integrações da primeira fase, e o que fica para depois. Todo pedido novo vai para a lista da fase seguinte, a menos que o responsável pelo projeto decida trocar algo de lugar, com impacto no prazo registrado.
2. Marcar a virada no fechamento do mês ou na alta temporada
A data da virada costuma ser escolhida pela conveniência do calendário do projeto, e não da operação. Virar o sistema na semana do fechamento contábil ou no mês de maior movimento junta a curva de aprendizado com o período de menos tempo para corrigir erros.
Como evitar: escolha um período de movimento menor, longe do fechamento e de datas fiscais importantes, e com as pessoas-chave sem férias marcadas. O início de mês tem uma vantagem adicional: os saldos de abertura coincidem com um fechamento já conferido.
Exemplo hipotético: uma loja de materiais que vende o dobro em novembro e dezembro marca a virada para o começo de novembro, para "aproveitar o ano". Com fila no balcão e equipe aprendendo telas novas, os pedidos voltam para o papel. A mesma virada em agosto teria dado três meses de prática antes do pico.
3. Migrar saldos sem conferência assinada
Saldos de estoque, títulos em aberto e saldos bancários entram no ERP como ponto de partida. Se ninguém confere e confirma esses números, qualquer diferença descoberta depois vira discussão sobre se o erro veio da migração ou da operação.
Como evitar: para cada tipo de saldo, um responsável da área compara o total do sistema antigo com o total do ERP e assina a conferência. Exemplo hipotético: contas a receber com R$ 84.300 no sistema antigo e R$ 84.300 no ERP, conferido por cliente na amostra dos vinte maiores. O roteiro completo está em como migrar cadastros e saldos para um ERP novo.
4. Testar cada módulo isoladamente e pular o teste de ponta a ponta
O financeiro testa o contas a pagar, o fiscal testa a emissão de nota, o estoque testa as movimentações. Tudo funciona. Na primeira semana real, o pedido de venda gera a nota, mas o título sai com vencimento errado, porque a condição de pagamento nunca foi testada passando por todos os módulos.
Como evitar: monte roteiros que atravessem os módulos: do pedido de compra ao pagamento, do pedido de venda ao recebimento conciliado, da devolução ao estorno do título. Execute com dados reais da empresa no ambiente de teste e registre cada diferença encontrada.
Uma diferença só sai da lista quando é corrigida e testada de novo pelo mesmo roteiro. Corrigir o parâmetro e seguir em frente sem repetir o teste é a forma mais comum de levar o mesmo erro para a produção, só que agora com outro sintoma.
5. Deixar o cadastro fiscal dos produtos para a véspera
NCM, CFOP, situação tributária e demais dados fiscais dependem de definição do contador e levam tempo para revisar em centenas de produtos. Deixados para a última semana, são preenchidos às pressas, e as primeiras notas são rejeitadas ou saem com tributação errada.
Como evitar: comece a revisão fiscal dos cadastros junto com a limpeza dos dados, no início do projeto. Teste a emissão em ambiente de homologação com os produtos de maior venda antes da virada.
Uma forma de priorizar: ordene os produtos pelo faturamento dos últimos doze meses e revise primeiro os que respondem pela maior parte das vendas. Os itens de baixo giro podem ser revisados em seguida, mas sem ficar para depois da virada.
6. Liberar acesso de administrador para todo mundo
Na pressa de fazer o sistema funcionar, todos os usuários recebem acesso total "por enquanto". O provisório fica permanente, parâmetros são alterados sem saber o efeito e ninguém consegue dizer quem mudou o quê.
Como evitar: defina os perfis de acesso por função antes da virada, mesmo que simples, e deixe o acesso de administrador com uma ou duas pessoas. Ajustar um perfil restrito é rápido; descobrir depois quem alterou um parâmetro crítico não é.
Exemplo do efeito: um usuário muda o parâmetro que permite estoque negativo para conseguir faturar um pedido urgente. O pedido sai, mas a partir daí o sistema aceita vender o que não existe, e as divergências de saldo aparecem semanas depois, sem pista da origem.
7. Deixar as integrações para depois da virada
Integração com o banco, com a loja virtual ou com o sistema da contabilidade parece um complemento. Sem ela, a equipe passa a digitar no ERP o que antes chegava automaticamente, e a primeira impressão do sistema novo é de mais trabalho.
Como evitar: classifique cada integração como necessária para a virada ou não. As que alimentam a rotina diária, como pedidos da loja e extratos bancários, entram no teste de ponta a ponta. As demais podem esperar, mas com data marcada.
8. Desligar o sistema antigo sem exportar o histórico
Com a virada feita, o contrato do sistema antigo é encerrado para economizar. Meses depois, aparece a necessidade de consultar uma nota antiga, o histórico de compras de um cliente ou um documento pedido pela contabilidade, e os dados não estão mais acessíveis.
Como evitar: antes de desligar, exporte em formato aberto os dados que não foram migrados e guarde os arquivos fiscais pelo prazo que o contador indicar. Defina quem pode consultar esse acervo e onde ele fica.
9. Não acompanhar a adoção nas primeiras semanas
Depois da virada, o projeto passa a ser medido por chamados ao suporte. Mas uma equipe que voltou para a planilha não abre chamado. Quando o problema aparece no fechamento, já são semanas de trabalho por fora.
Como evitar: acompanhe indicadores simples de uso: pedidos lançados no momento da venda, baixas feitas pela conciliação, notas emitidas pelo sistema. Quando a equipe resiste, a causa costuma estar nas telas e no treinamento, como mostra layout do ERP e resistência da equipe.
10. Encerrar o projeto no dia da virada
A virada é tratada como o fim do projeto: o consultor sai, o responsável interno volta para as funções antigas e os ajustes pendentes ficam sem dono. Os problemas de configuração que só aparecem com volume real se acumulam.
Como evitar: planeje uma fase de estabilização de trinta a sessenta dias, com o responsável interno ainda dedicado, uma lista de pendências priorizada e uma revisão no primeiro fechamento mensal feito no ERP. O projeto termina quando o primeiro fechamento sai do sistema sem planilhas de apoio.
Por trás de vários desses erros estão expectativas que se formam antes do projeto começar, como achar que o fornecedor implanta sozinho ou que um paralelo longo traz segurança. Essas crenças estão em desafios na implementação de ERP e as crenças que atrapalham o projeto.