Parametrizar, customizar ou integrar: 4 caminhos para adaptar o ERP à empresa

Quando o ERP não faz algo do jeito que a empresa trabalha, existem quatro caminhos: ajustar o processo ao padrão do sistema, parametrizar (usar as opções de configuração que o próprio sistema oferece), customizar (encomendar desenvolvimento que altera ou estende o sistema) ou integrar outro sistema especializado. Em ordem de custo e risco, costuma valer tentar nessa sequência: primeiro processo e parâmetro, depois integração, e customização só quando a necessidade for um diferencial real do negócio e não houver outra saída. A seguir, cada caminho é comparado pelos mesmos critérios, e a última seção indica o mais adequado para cada perfil de empresa.

A pergunta que vem antes de qualquer caminho

Antes de escolher como adaptar o sistema, a empresa precisa responder por que o processo atual é do jeito que é. Muitas exigências levadas ao fornecedor são hábitos herdados de planilhas ou do sistema anterior, e não necessidades do negócio. “O pedido precisa ter este campo porque sempre teve” é diferente de “o cliente exige esta informação na nota”.

Uma forma prática de separar as duas coisas é perguntar, para cada exigência, o que acontece se ela não for atendida. Se a resposta for “a equipe vai estranhar no começo”, é hábito. Se for “perdemos o contrato com o maior cliente” ou “a nota sai sem um dado obrigatório para aquela operação”, é necessidade. Só as necessidades justificam os caminhos mais caros.

Os critérios da comparação

Os quatro caminhos são avaliados pelos mesmos cinco critérios:

• Custo inicial: o que se gasta para colocar a adaptação de pé.
• Custo de manutenção: o que se gasta para mantê-la funcionando ao longo dos anos.
• Risco nas atualizações: a chance de a adaptação quebrar quando o fornecedor lança uma nova versão, inclusive as atualizações fiscais, que costumam ser frequentes no Brasil.
• Prazo: quanto tempo leva para ficar pronta.
• Dependência: de quem a empresa passa a depender para mudar ou corrigir a adaptação.

Caminho 1: ajustar o processo ao padrão do sistema

Ajustar o processo significa mudar a forma de trabalhar para seguir o fluxo que o ERP já oferece. É o caminho mais barato e o de menor risco, e por isso deveria ser sempre o primeiro avaliado.

O fluxo padrão de um ERP costuma refletir a forma como muitas empresas fazem a mesma tarefa. Quando a empresa diverge desse padrão sem um motivo de negócio, quase sempre a divergência é o problema. Um exemplo hipotético: uma distribuidora aprova pedidos por mensagem com o gerente antes de digitá-los no sistema. O ERP oferece bloqueio por alçada de desconto, com fila de aprovação dentro do próprio pedido. Adotar a fila elimina uma etapa paralela e deixa o histórico registrado no sistema.

• Custo inicial: baixo, concentrado em treinamento e em revisar procedimentos internos.
• Custo de manutenção: praticamente nenhum.
• Risco nas atualizações: nenhum, porque nada no sistema foi alterado.
• Prazo: curto no sistema, mas a mudança de hábito leva algumas semanas.
• Dependência: só da própria equipe.

Limite: não serve quando o processo atual é um diferencial competitivo ou uma exigência de cliente, contrato ou legislação.

Caminho 2: parametrizar

Parametrizar é configurar o sistema usando as opções que ele já traz: campos obrigatórios, regras fiscais por operação, tabelas de preço, fluxos de aprovação, campos adicionais no cadastro, modelos de relatório. Não há código novo; o comportamento muda dentro do que o fornecedor previu.

Boa parte do que as empresas chamam de “personalização” é, na verdade, parametrização. Por isso, vale pedir ao fornecedor, para cada necessidade, uma resposta explícita: isso se resolve com parâmetro ou exige desenvolvimento? Muitas exigências que parecem pedir customização são atendidas por uma combinação de campos adicionais e regras já existentes.

• Custo inicial: baixo a moderado, quase sempre em horas de consultoria de implantação.
• Custo de manutenção: baixo, desde que alguém registre o que foi configurado e por quê.
• Risco nas atualizações: baixo, porque os parâmetros fazem parte do produto e são preservados nas novas versões.
• Prazo: de horas a poucos dias por item.
• Dependência: moderada; com treinamento, um usuário-chave interno consegue manter boa parte dos parâmetros.

Um exemplo hipotético: uma empresa de manutenção predial quer que o pedido de serviço registre o número do contrato do cliente e que esse número saia nas observações da nota. O primeiro orçamento recebido fala em desenvolvimento. Uma segunda conversa mostra que o ERP aceita um campo adicional no cadastro do cliente e um modelo de observação da nota que puxa esse campo automaticamente. O que seria customização vira duas configurações, sem código e sem risco nas atualizações.

Erro comum: parametrizar sem documentar. Dois anos depois, ninguém sabe por que determinado campo é obrigatório ou por que uma regra fiscal tem uma exceção. Uma planilha simples com parâmetro, valor, motivo e data resolve.

Caminho 3: customizar

Customizar é desenvolver algo que o sistema não faz: uma tela nova, uma regra de cálculo própria, um relatório com lógica específica, uma alteração em rotina existente. Pode ser feito pelo fornecedor, por um parceiro ou por um desenvolvedor da empresa, dependendo do que o sistema permite.

Há duas formas de customização com riscos bem diferentes:

• Extensão: o desenvolvimento fica numa camada separada, usando pontos de extensão que o fornecedor documenta e mantém. O núcleo do sistema continua intacto.
• Alteração do núcleo: o código original é modificado. Cada atualização do fornecedor pode desfazer ou quebrar a mudança, e a empresa passa a precisar testar e refazer a customização a cada versão.

Em sistemas oferecidos como serviço na nuvem, a alteração do núcleo geralmente nem é possível; a customização, quando existe, é por extensão. Em sistemas instalados no servidor da empresa, as duas formas costumam ser possíveis, e a tentação de alterar o núcleo é maior.

• Custo inicial: alto, proporcional às horas de desenvolvimento e teste.
• Custo de manutenção: contínuo; cada nova versão do ERP exige revalidar a customização.
• Risco nas atualizações: moderado na extensão, alto na alteração do núcleo.
• Prazo: semanas ou meses, somando especificação, desenvolvimento e testes.
• Dependência: alta, de quem desenvolveu. Se o desenvolvedor sair ou o parceiro encerrar o contrato, a empresa pode ficar com um código que ninguém entende.

Um exemplo hipotético de efeito colateral: uma empresa altera a rotina de cálculo de comissão para atender uma regra própria. Meses depois, uma atualização fiscal obriga a instalar a versão nova do ERP, que substitui a rotina alterada. A comissão do mês sai pelo cálculo padrão, e a diferença só é percebida quando os vendedores reclamam. A correção exige refazer a customização às pressas. Contratos de suporte costumam tratar de forma diferente o que é padrão e o que foi customizado.

Caminho 4: integrar outro sistema

Integrar é manter o ERP no papel dele e ligar a ele um sistema especializado para a parte que o ERP não cobre bem: uma loja virtual, um sistema de ponto de venda, uma ferramenta de roteirização de entregas, um sistema de produção específico do setor. Os dois trocam dados por meio de uma interface de integração, normalmente uma API, ou por arquivos.

O ponto central da integração é definir qual sistema é a fonte de cada dado. Se o cadastro de produtos nasce no ERP e é enviado à loja virtual, alterações de preço feitas direto na loja vão ser sobrescritas na próxima sincronização. Essa regra precisa estar escrita antes de a integração entrar em produção.

• Custo inicial: moderado; inclui o sistema especializado e o trabalho de ligar os dois.
• Custo de manutenção: moderado; integrações precisam de monitoramento, porque falhas de envio nem sempre aparecem para o usuário.
• Risco nas atualizações: moderado; se um dos lados muda a interface, a integração precisa de ajuste.
• Prazo: de dias, quando existe um conector pronto entre os dois sistemas, a semanas, quando a integração é desenvolvida do zero.
• Dependência: dividida entre dois fornecedores, o que pode gerar dúvida sobre quem resolve um problema que está “no meio”.

Como descrever a necessidade antes de escolher o caminho

A escolha entre os quatro caminhos depende de a necessidade estar descrita com precisão. Pedidos vagos, como “o sistema precisa controlar os contratos”, recebem respostas vagas e orçamentos que não se comparam. Uma descrição útil responde a seis perguntas:

1. Situação: em que momento do processo a necessidade aparece (no pedido, na entrada da nota, no fechamento do mês).
2. Regra: o que o sistema deve fazer, com um exemplo de entrada e de resultado esperado.
3. Exceções: os casos em que a regra não vale.
4. Quem usa: quais funções executam ou consultam aquilo.
5. Frequência: quantas vezes por dia, semana ou mês a situação acontece.
6. Consequência: o que acontece se a necessidade não for atendida.

As duas últimas respostas costumam decidir a questão. Uma situação que ocorre duas vezes por mês, sem consequência para cliente ou fisco, raramente justifica desenvolvimento: um procedimento manual documentado resolve. Já uma regra aplicada em centenas de pedidos por dia, cujo erro gera prejuízo, merece ser avaliada até o caminho da customização, se os anteriores não resolverem.

A mesma descrição deve ser enviada a quem vai orçar. Com ela, o fornecedor consegue dizer se a necessidade se resolve com parâmetro, e a empresa consegue comparar propostas que respondem à mesma pergunta.

Os quatro caminhos lado a lado

O custo de manutenção pesa mais do que parece porque se repete. Num exemplo hipotético, uma customização que consome 60 horas para ficar pronta e 8 horas de revisão a cada atualização do sistema, com quatro atualizações relevantes por ano, soma 32 horas anuais só para continuar funcionando. Em três anos, a manutenção supera em horas o próprio desenvolvimento.

A tabela mostra por que a ordem sugerida no início faz sentido: cada caminho à direita resolve casos que o anterior não resolve, mas cobra mais ao longo do tempo. Na fase de avaliação de um ERP novo, a mesma tabela serve para outra pergunta: quantas das necessidades da empresa caem nas duas colunas da esquerda? Se a maioria cair em customização, talvez aquele sistema não seja o mais adequado para o negócio.

Qual caminho escolher conforme o perfil da empresa

Empresa pequena com processos pouco formalizados: ajustar o processo e parametrizar resolvem quase tudo. Customizar nesse estágio costuma congelar hábitos que ainda nem estavam maduros. A recomendação é evitar qualquer desenvolvimento no primeiro ano de uso e anotar as necessidades que aparecerem, para decidir com mais informação depois.

Empresa em crescimento, com um canal ou operação muito específica: integração tende a ser o melhor caminho para a parte especializada, como vendas pela internet ou logística, mantendo o ERP no padrão para financeiro, fiscal e estoque. Exija do fornecedor da integração a definição escrita da fonte de cada dado.

Empresa com um processo que é diferencial competitivo: uma regra de precificação própria ou um fluxo de produção particular podem justificar customização. Nesse caso, prefira extensão a alteração do núcleo, exija documentação técnica e inclua no contrato quem mantém o desenvolvimento a cada atualização.

Empresa que já tem muitas customizações: antes de criar mais uma, faça um inventário das existentes e pergunte quais ainda são usadas e quais poderiam virar parâmetro nas versões atuais do sistema. Reduzir customizações antigas costuma diminuir o custo de cada atualização futura.

Em qualquer perfil, a regra prática é a mesma: registrar cada adaptação com o caminho escolhido, o motivo e o responsável. Esse registro é o que permite, anos depois, revisar as decisões sem depender da memória de quem estava lá.