ERP padrão ou customizado: quando configurar ou programar

Em algum ponto da maioria das implementações de ERP, um workshop chega a um momento em que o sistema padrão faz algo de forma diferente daquela como o negócio o faz atualmente, e alguém pergunta, com toda a razão, se é possível alterá-lo para corresponder. A resposta é quase sempre sim — os ERP modernos são flexíveis e um desenvolvedor competente consegue fazer com que o sistema faça praticamente tudo. A pergunta que vale a pena fazer não é se é possível fazê-lo. É a que se está a comprometer ao fazê-lo.

Uma customização não é um custo pontual. É um custo recorrente: tem de ser novamente testada em cada atualização, tem de ser compreendida por cada novo membro da equipa, tem de ser documentada ou torna-se um mistério, e tem de ser mantida durante todo o tempo em que o sistema estiver em uso. As empresas mid-market que acumulam customizações sem um quadro coerente para decidir entre elas acabam com uma instância de ERP que é caro tocar, lenta de atualizar e, na prática, única — algo que soa a flexibilidade e funciona como fragilidade.

Este artigo apresenta um quadro para tomar essa decisão de forma coerente, porque as decisões individuais são normalmente razoáveis e o agregado normalmente não é.

Por que isto importa

O custo direto de uma customização é visível no momento da construção e fácil de orçamentar. Os custos que se acumulam depois são os que verdadeiramente determinam se valeu a pena.

Cada customização aumenta o âmbito dos testes em cada atualização futura — as notas de lançamento do fabricante não sabem nada do seu script, pelo que alguém tem de o verificar manualmente, sempre. Cada customização é um pedaço de conhecimento institucional que vive com quem a construiu, e as empresas mid-market não retêm essa pessoa indefinidamente; quando sai, a customização torna-se ou uma caixa negra ou uma reconstrução. E cada customização dificulta o trabalho do próximo partner de implementação, porque passa a dar apoio a um sistema que diverge daquele em que se formou e daquele que a própria documentação do fabricante descreve.

Existe um efeito cumulativo específico do ERP: uma instância fortemente customizada torna-se progressivamente mais difícil de alterar, exatamente no momento em que o negócio mais precisa que mude, porque a dívida de customização acumula-se mais depressa em empresas em crescimento e em evolução — precisamente aquelas para quem a flexibilidade mais importa.

Num relance: o quadro de decisão

A última linha é a disciplina que mais importa e a que mais frequentemente é omitida. Deveria exigir-se que todos os pedidos de customização lhe respondam de forma explícita e por escrito, antes da aprovação.

O que funciona e sobre o que ser honesto

O que funciona:

Exigir uma resposta escrita a "o que se quebra se não fizermos isto". Não uma preferência, uma consequência. "A equipa do armazém acha o ecrã de picking padrão menos conveniente" é uma preferência. "Não podemos faturar legalmente segundo os requisitos espanhóis sem este campo" é uma consequência. Tornar esta distinção explícita e exigi-la por escrito transforma a conversa de defesa de posições em evidência.

Um registo de customizações, revisto periodicamente. Cada customização registada com o seu responsável, a sua justificação de negócio e uma data de revisão. A maioria das empresas mid-market não tem tal registo, o que significa que ninguém consegue responder "por que é que o sistema faz isto" para uma parte significativa daquilo que foi construído, e ninguém volta a questionar se a justificação continua a ser válida.

Preferir a configuração ao scripting, e o scripting à modificação do núcleo. Estas opções acarretam custos de manutenção diferentes e riscos de atualização diferentes. Uma alteração de configuração é normalmente segura entre atualizações. Um script precisa de testes. Uma modificação do núcleo é a categoria de maior risco e deveria exigir o limiar de justificação mais elevado.

Isolar aquilo que tem de ser customizado. Quando a customização se justifica genuinamente, construa-a como uma adição discreta, bem documentada e fracamente acoplada, em vez de a incorporar na configuração do núcleo. Isto reduz materialmente o custo da próxima atualização e o custo de a remover mais tarde, caso a justificação deixe de se sustentar.

Rever as customizações antigas, e não apenas filtrar as novas. Uma justificação que era correta há três anos pode não o ser agora — a regulamentação pode ter mudado, o diferenciador competitivo pode ter-se tornado requisito mínimo de mercado, a equipa que precisava do contorno pode ter saído. A revisão periódica deteta isto; a maioria das empresas nunca olha para trás.

Sobre o que ser honesto:

Recusar um pedido de customização é uma conversa mais difícil do que aprová-lo. Quem pede tem normalmente uma frustração genuína e imediata, e "adote o processo padrão" pode soar a desvalorização, mesmo quando é a resposta certa. Isto é uma competência de governação e de comunicação tanto como técnica, e exige alguém com poder de decisão disposto a ter a conversa incómoda.

Alguma customização é genuinamente necessária, e recusar toda ela é o seu próprio modo de falha. Os requisitos legais, os diferenciadores competitivos genuínos e as necessidades de integração são categorias reais. O objetivo é um quadro coerente e defensável, não uma recusa generalizada.

O quadro exige alguém com autoridade para dizer não. Sem uma pessoa com poder de decisão efetivo — o mesmo requisito discutido nos padrões de falha das implementações de NetSuite noutro artigo desta série — este quadro é um documento que ninguém segue, porque cada pedido individual encontrará um defensor e nenhum pedido encontrará um avaliador coerente.

As customizações herdadas são mais difíceis de remover do que as novas são de prevenir. Depois de um processo ter sido construído em torno de uma customização, removê-la tem um custo de gestão da mudança independente do seu custo técnico. Este é um argumento a favor do rigor no momento da criação, já que a prevenção é muito mais barata do que uma remoção posterior.

Isto não é uma decisão pontual. Um quadro aplicado uma única vez na implementação e depois abandonado produz a mesma acumulação que pretendia evitar. Tem de ser um processo de governação permanente, com um responsável, durante toda a vida do sistema.

Síntese do quadro de decisão: aplicá-lo na prática

A tabela acima é o quadro. Na prática, aplique-o como um processo permanente:

1. Todos os pedidos de customização entram num registo antes de qualquer desenvolvimento começar, com quem pede obrigado a responder por escrito à pergunta da justificação.

2. Uma pessoa nomeada com poder de decisão avalia contra o quadro, não um comité — veja o artigo sobre implementação de NetSuite desta série para entender por que isto importa em geral.

3. As customizações aprovadas são construídas de forma isolada e documentada, com um responsável e uma data de revisão registados.

4. O registo é revisto num intervalo fixo — anualmente é razoável para a maioria das empresas mid-market — e a justificação de cada entrada é novamente testada face às circunstâncias atuais, e não apenas face à aprovação original.

5. Os pedidos recusados também são registados, com a alternativa de processo padrão documentada, para que o mesmo pedido não ressurja sem memória institucional do motivo da recusa.

Custo e esforço indicativos

Peça um orçamento para uma auditoria de customizações delimitada à sua instância atual.

Perguntas frequentes

Como adaptamos este quadro a um sistema que já tem anos de customização não documentada?
Comece pelo registo — inventarie o que existe, mesmo que inicialmente sem justificação completa, porque o inventário por si só já tem valor. Priorize a revisão por aquilo que é mais arriscado de atualizar ou menos compreendido, em vez de tentar justificar tudo de uma vez.

Que proporção de pedidos de customização devemos esperar recusar?
Não existe um número universal que valha a pena citar, e tratar a taxa de recusa como um objetivo distorce o processo — a meta é um quadro coerente aplicado com honestidade, não uma quota. Na nossa experiência, um quadro aplicado com verdadeiro rigor recusa uma minoria significativa de pedidos que, de outro modo, teriam sido aprovados por omissão, mas isto varia enormemente de empresa para empresa e de setor para setor.

Este quadro aplica-se da mesma forma à customização de relatórios e à customização de processos?
O princípio é o mesmo, mas o perfil de risco difere — um relatório personalizado é geralmente de menor risco do que uma alteração à lógica transacional do núcleo, porque não afeta a forma como as transações são processadas, apenas a forma como são apresentadas. Pese a sua avaliação em conformidade; o limiar para a customização de um relatório pode razoavelmente ser mais baixo do que para a customização de um fluxo de trabalho.

Quem deve ser a pessoa com poder de decisão neste quadro?
A mesma pessoa com autoridade sobre as decisões transversais de desenho do ERP em geral — veja o artigo sobre implementação desta série. Se essa pessoa não existir, estabelecer esse papel é um pré-requisito para que este quadro funcione de alguma forma.

Qual é a relação disto com uma implementação de NetSuite em concreto?
É a disciplina de governação contínua que evita o padrão de falha da "customização como resposta por omissão a todas as lacunas" discutido no artigo sobre implementação. Esse artigo aborda-o durante um projeto; este aborda-o como disciplina operacional permanente depois.

Fecho — Próximos passos

As decisões de customização são tomadas uma a uma, por pessoas diferentes, sob pressão de tempo, e o agregado raramente é aquilo que alguém pretendia. Um quadro coerente — aplicado por uma pessoa nomeada com poder de decisão, exigindo uma justificação escrita e revisto periodicamente — não elimina a customização. Garante que aquilo que existe está lá porque merecia o seu lugar, e que alguém notaria se deixasse de o merecer.

Se quiser saber em que ponto está hoje: tente construir o registo de customizações da sua instância atual. O exercício em si — descobrir o que foi construído, por quem e por que motivo — é normalmente a tarde mais informativa ao alcance de uma equipa que se pergunta por que motivo o seu sistema se tornou caro de alterar.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora de NetSuite que serve clientes mid-market em toda a Ibéria. Especializa-se em ligar sistemas CRM e ERP para fluxos order-to-cash sem atritos, construindo pipelines automatizados de gestão de encomendas que eliminam a introdução manual de dados entre as equipas de vendas e de finanças. Como partner oficial de implementação da Stacksync, Bruno desenha e implementa agentes de IA em plataformas de integração para tratar do encaminhamento de exceções, do processamento de documentos e da reconciliação — transformando fluxos de encomendas fragmentados em sistemas fiáveis que se monitorizam a si próprios.

LinkedIn: https://www.linkedin.com/in/brunogd

Fontes

Os URL são a nível de editor e devem ser verificados antes da publicação.

• Oracle NetSuite, documentação de customização e SuiteScript — https://docs.oracle.com/en/cloud/saas/netsuite/
• Panorama Consulting Group, ERP Report anual — dados sobre customização e custo total de propriedade — https://www.panorama-consulting.com
• Experiência de projetos da Atypical Tech, implementações de NetSuite no mid-market da Ibéria