Desenvolvimento ABAP: quando customizar o SAP e quando não

Toda implementação SAP chega ao mesmo momento: o processo da empresa não cabe no padrão da ferramenta, e alguém pergunta se dá para desenvolver.

Quase sempre dá. A pergunta certa é se deve.

O custo real de uma customização

O preço do desenvolvimento é a menor parte do custo total. O que vem depois:

Todo upgrade precisa testá-la. Cada objeto customizado entra no escopo de teste de regressão de toda aplicação de Support Package e de toda mudança de release. Para sempre.

Toda nota SAP precisa considerá-la. Uma nota que altera um objeto padrão modificado exige análise de impacto e, às vezes, reimplementação da customização.

Ela precisa de documentação viva. Sem especificação atualizada, daqui a três anos ninguém saberá por que aquele código existe — e ninguém terá coragem de removê-lo.

Ela entra no inventário de migração. Quando chegar a hora de migrar para uma nova plataforma, cada customização será um item a analisar, adaptar ou descartar.

Multiplique isso por algumas centenas de objetos e você tem o retrato de um ambiente SAP antigo: caro de manter, arriscado de atualizar e difícil de migrar.

Os critérios de decisão

Antes de aprovar um desenvolvimento, percorra esta sequência:

1. O padrão realmente não atende?

Uma parcela relevante dos pedidos de customização vem de desconhecimento do padrão. A transação existe, o campo existe, a configuração existe — mas ninguém sabia. Este é o motivo pelo qual os workshops de fit-to-standard precisam de consultor experiente no módulo, não apenas de alguém anotando requisitos.

2. O processo precisa ser assim mesmo?

Frequentemente a exigência vem de um jeito de trabalhar que ninguém questiona há anos. "Sempre fizemos assim" não é requisito de negócio. Se a diferença entre o processo atual e o padrão SAP não tem justificativa de negócio, a decisão certa é mudar o processo.

3. A diferença é competitiva ou é histórica?

Este é o critério decisivo. Se o processo é o que diferencia sua empresa no mercado — uma regra de precificação própria, um modelo logístico específico — a customização se justifica. Se ele é apenas o resultado de decisões acumuladas ao longo do tempo, ela não se justifica.

4. Existe alternativa fora do núcleo?

Extensões que rodam fora do núcleo do ERP, integrações e aplicações complementares permitem atender à necessidade sem modificar o sistema central. É a lógica do clean core: manter o núcleo o mais próximo possível do padrão e resolver a especificidade na periferia. Ambiente com núcleo limpo é substancialmente mais barato de atualizar e migrar.

Quando a customização se justifica

Não se trata de nunca desenvolver. Casos legítimos:

• Exigência legal ou fiscal não coberta pelo padrão — comum no Brasil
• Diferencial competitivo real de processo
• Integração com sistema específico do seu negócio
• Relatório gerencial que o padrão não entrega e que direciona decisão
• Melhoria de usabilidade com ganho mensurável em volume alto de operação

Boas práticas que reduzem o passivo

Quando a decisão é desenvolver, algumas práticas reduzem muito o custo futuro:

Use os pontos de extensão previstos. BAdIs, user exits e enhancement points existem justamente para permitir customização sem modificar o objeto padrão. Modificar objeto padrão diretamente é a decisão que mais dor causa em upgrade.

Namespace próprio e consistente. Objetos customizados devem ser inequivocamente identificáveis. Padrão de nomenclatura definido no início do projeto, não improvisado por desenvolvedor.

ATC como parte da esteira. As verificações do ABAP Test Cockpit precisam rodar antes do transporte, não como auditoria ocasional.

ABAP OO em vez de procedural. Código orientado a objeto é mais testável e mais fácil de manter. Programa de mil linhas em fluxo único é passivo desde o primeiro dia.

Documentação junto com o código. Especificação funcional e técnica atualizadas fazem parte do entregável. Não são etapa posterior — são condição de aceite.

Revisão por par obrigatória. Nenhum objeto vai para transporte sem revisão de outro desenvolvedor. É a prática de melhor custo-benefício em qualquer time de desenvolvimento.

Uma prática que vale ouro

Faça um inventário anual dos objetos customizados com indicação de uso real — quando cada um foi executado pela última vez e por quantos usuários.

O resultado costuma surpreender: uma parcela relevante do que existe no ambiente não é executada há muito tempo. Cada um desses objetos é custo de teste em todo upgrade, sem nenhum benefício correspondente.

Remover objeto morto é o trabalho de manutenção com melhor retorno em ambiente SAP, e quase ninguém faz — porque não gera valor visível, só reduz risco invisível.

Se a sua empresa está avaliando migração para S/4HANA, esse inventário deixa de ser boa prática e vira pré-requisito. Escrevemos sobre isso em migração de SAP ECC para S/4HANA.