Em quase toda implantação de ERP chega o momento em que alguém diz: "no sistema antigo era assim". A frase é legítima, porque ninguém quer perder algo que funciona. Mas é também o ponto de partida da maioria das customizações que, anos depois, vão travar uma atualização de release. Implantar bem o Protheus passa por uma regra simples de enunciar e difícil de sustentar: padrão primeiro, processo sempre.

Por que customização é um custo recorrente

A TOTVS lança uma nova release do Protheus por ano, normalmente em outubro, e cada release conta com 20 meses de manutenção padrão. A release 12.1.2410, por exemplo, saiu do suporte padrão em 30 de junho de 2026. A partir dessa data, pacotes de correção e alterações legais só continuam chegando para quem contrata a garantia estendida.

Na prática, atualizar a release não é uma escolha eventual, é um compromisso de calendário. E toda atualização exige responder à mesma pergunta: o que foi customizado continua funcionando?

Especialistas em migração apontam as customizações em ADVPL como o ponto mais sensível desse processo. Os casos mais comuns de quebra envolvem pontos de entrada descontinuados, rotinas automáticas cuja estrutura mudou, conflitos de campos no dicionário, regras fiscais em TES antigas e telas customizadas. E há um agravante: quando a empresa faz o inventário completo, costuma encontrar de três a cinco vezes mais customização do que estimava.

Cada customização, portanto, não é um custo único de implantação. É uma parcela que volta a cada release.

Foque no processo antes de abrir o sistema

O erro mais caro de uma implantação é discutir tela antes de discutir processo. Antes de qualquer configuração, vale mapear cada fluxo relevante: quem executa, em que ordem, com quais aprovações e, principalmente, quais exceções acontecem de verdade. Sem esse mapa, qualquer pedido de customização é opinião, e opinião não tem critério para ser recusada.

O mapeamento também revela algo que costuma surpreender: parte do processo atual existe apenas para compensar limitações do sistema antigo. Replicar esse comportamento no Protheus é carregar um problema que já não existe.

Rode o padrão com o processo real

Com o processo mapeado, o passo seguinte é executá-lo no Protheus padrão, em ambiente de homologação, com casos reais da empresa. Não demonstração genérica: pedidos, notas, títulos e lançamentos iguais aos do dia a dia, incluindo devoluções, cancelamentos e exceções.

É nesse teste que muita "falta de funcionalidade" se revela como parâmetro não configurado, cadastro incompleto ou regra de negócio que o sistema já oferece.

Esgote a parametrização antes do código

O Protheus é altamente parametrizável. Parâmetros de sistema, tipos de entrada e saída, regras fiscais, configurações de cadastro e rotinas de aprovação resolvem uma parte grande das necessidades que chegam como pedido de desenvolvimento. Parametrização acompanha a release; código precisa ser revalidado a cada uma.

Critérios para aprovar uma customização

Quando o padrão e a parametrização realmente não atendem, a customização é legítima. Mas precisa passar por um filtro claro:

  • Exigência legal ou fiscal que o padrão não cobre para o seu caso.
  • Diferencial competitivo real, algo que a empresa faz melhor que o mercado e que o sistema precisa sustentar.
  • Volume ou ganho operacional que pague não só o desenvolvimento, mas a manutenção a cada release.

Hábito do sistema anterior não entra nessa lista. A pergunta que resume o critério é: é o processo que precisa disso, ou é o costume?

Quando customizar, faça do jeito que sobrevive à próxima release

  • Use os caminhos previstos, como pontos de entrada e extensões documentadas pela TOTVS.
  • Mantenha um catálogo de customizações com dono, motivo, data e processo atendido. Na próxima atualização, esse catálogo encurta semanas de diagnóstico.
  • Documente no momento da decisão, não na véspera do go-live.
  • Revise periodicamente: customizações que perderam o motivo devem ser desligadas.

Segure novas customizações até o terceiro fechamento

Nos primeiros meses após o go-live, a pressão por ajustes é alta. Parte dela é legítima; outra parte é curva de aprendizado. Uma boa prática é congelar novas customizações até o terceiro fechamento contábil e fiscal completo, salvo exigência legal ou impedimento operacional. O que parece lacuna no primeiro mês muitas vezes é falta de treino no primeiro mês.

Conclusão

Implantar pelo padrão não é engessar a empresa. É reservar o investimento em desenvolvimento para o que realmente diferencia o negócio e manter o restante leve o bastante para acompanhar cada release sem sustos. Processo primeiro, parametrização depois, código só quando o processo provar que precisa.

Com 21 anos como parceira TOTVS e mais de 150 implantações, a ELR Solutions conduz projetos com essa lógica. Se a sua empresa está implantando o Protheus ou vai atualizar a release e quer entender quanto da customização atual ainda faz sentido, fale com a nossa equipe.