A maioria das empresas que usam SAP há mais de cinco anos tem a mesma resposta quando perguntada sobre o volume de objetos Z no ambiente: ‘temos bastante, mas não sabemos exatamente quanto’. Essa falta de visibilidade não é apenas um problema técnico. É um risco financeiro que cresce silenciosamente a cada novo desenvolvimento, cada nova customização e cada nova integração criada fora do padrão SAP.
Com o fim do suporte mainstream ao SAP ECC previsto para 2027, o momento de fazer esse cálculo não pode mais ser adiado. Empresas que chegarem ao processo de migração para S/4HANA sem saber o que têm de Z, onde está e o que cada objeto faz vão descobrir o preço tarde demais, já dentro do projeto.
Este artigo explica o que é o código Z no contexto SAP, por que ele acumula, qual o custo real que ele representa hoje e como fazer o diagnóstico antes que a conta chegue maior.
O que é código Z no SAP e por que ele se acumula
Código Z é o termo usado para designar qualquer desenvolvimento realizado fora do padrão SAP: programas, relatórios, funções, tabelas e integrações criadas diretamente no ambiente, geralmente para atender a um requisito que o padrão não cobria ou que foi interpretado assim pela equipe de projeto.
Em ambientes SAP com mais de dez anos de operação, é comum encontrar centenas ou até milhares de objetos Z. A maior parte deles foi criada com uma boa razão à época. O problema não é a existência da customização, mas o que acontece depois: falta de documentação, falta de rastreabilidade, falta de análise sobre se aquela funcionalidade ainda é necessária e falta de critério para decidir o que manter, o que migrar e o que desativar.
O resultado típico: um ambiente onde 60% a 80% do orçamento SAP vai para manutenção do que já existe, deixando menos de 20% disponível para inovação. Esse dado não é exceção. É o padrão que a QAMetrik encontra na maioria dos assessments de ambiente SAP realizados.
Cada objeto Z criado sem governança vira custo recorrente: alguém precisa mantê-lo, testá-lo a cada mudança, garantir que não conflita com outros objetos e validar que ainda funciona após atualizações. Isso se repete indefinidamente.
Para entender como a classificação das extensões SAP funciona hoje e qual o impacto no Clean Core, vale ler: Modelo A-B-C-D da SAP: Como Classificar Suas Extensões e Reduzir Risco em Atualizações.
O custo real: o que está escondido na conta do código Z
Quando gestores de TI estimam o impacto do código Z, a tendência é pensar apenas no custo de migração. Mas o custo começa muito antes disso.
Custo de manutenção contínua. Cada objeto Z precisa ser validado e eventualmente ajustado sempre que há uma atualização no ambiente, uma mudança de processo ou uma nova integração. Sem automação e sem governança, isso é feito manualmente, demanda horas de profissionais especializados e gera retrabalho constante. É o que transforma TI em gargalo operacional no dia a dia.
Custo de incidentes causados por dependências opacas. Boa parte dos dumps e erros que chegam em produção sem origem clara tem relação direta com objetos Z que ninguém mapeou completamente. Um programa Z que acessa tabelas standard de forma não homologada, uma integração customizada que não foi atualizada após uma mudança no processo, um relatório Z que trava o batch. O custo de cada incidente desse tipo vai muito além da hora técnica: envolve impacto operacional, comunicação de crise com o negócio e tempo de recuperação.
Custo de migração para S/4HANA. Aqui o impacto fica mais visível. Projetos de migração em ambientes com alto volume de objetos Z descontrolados têm, em média, 30% a 50% do orçamento total consumido apenas com análise e adequação de código legado. Objetos Z incompatíveis com o modelo de dados do S/4HANA precisam ser reescritos, migrados para SAP BTP como extensões certificadas ou simplesmente descontinuados. Cada um desses caminhos tem um custo, e quanto mais tarde esse mapeamento acontece, mais caro fica.
Empresas que chegam a um projeto S/4HANA sem inventário de objetos Z costumam descobrir que o escopo real do projeto é entre 30% e 50% maior do que o estimado inicialmente.
Custo de compliance e auditoria. Em setores como indústria alimentícia, farmacêutico, mineração e distribuição, o código Z sem rastreabilidade é um risco direto de conformidade. Quem mudou, quando, por quê e com qual evidência de teste? Se não há resposta clara para isso, a auditoria pode apontar não conformidade. Para saber como estruturar rastreabilidade de mudanças no ambiente SAP, veja: Gestão de Mudanças (GMUD) no SAP: Como proteger operação, manter Clean Core e acelerar evolução.
Por que 2027 não é prazo distante
O fim do suporte mainstream ao SAP ECC em 2027 é amplamente divulgado. O que ainda não é amplamente compreendido é o que isso significa na prática para projetos que ainda não começaram.
Um projeto de migração para S/4HANA em ambientes de médio porte, com volume relevante de customizações, leva em média de 18 a 36 meses para ser concluído com segurança. Isso significa que empresas que ainda não iniciaram o diagnóstico estão, na melhor das hipóteses, chegando ao limite do prazo com margem zero para imprevistos.
E os imprevistos sempre aparecem. Quase sempre na forma de objetos Z que ninguém sabia que existiam, de integrações customizadas sem documentação e de dependências que só se revelam durante o processo de conversão.
A janela para fazer o diagnóstico de forma estruturada, priorizar o que precisa ser resolvido e planejar a migração com segurança está se fechando. Quem começa agora ainda tem tempo de conduzir o processo com controle. Quem espera mais vai ter que tomar decisões sob pressão.
Para entender em detalhe como preparar o ambiente SAP ECC para a migração sem perder estabilidade operacional, leia: Como preparar o SAP ECC para migrar ao S/4HANA sem perder estabilidade.
O que um diagnóstico de código Z precisa revelar
Fazer o inventário de objetos Z não é simplesmente contar quantos existem. Um diagnóstico útil precisa responder a perguntas específicas que vão orientar as decisões seguintes.
- Quantos objetos Z existem e em quais módulos estão concentrados?
- Quais objetos acessam tabelas standard de forma não homologada pela SAP?
- Quais são compatíveis com S/4HANA e quais precisam de reescrita ou migração para BTP?
- Quais objetos ainda são utilizados ativamente e quais podem ser desativados?
- Existe documentação técnica associada a cada objeto? Quem é o responsável?
- Quais objetos participam de processos críticos como faturamento, supply chain e fechamento contábil?
Com essas respostas em mãos, é possível priorizar o que atacar primeiro: os objetos de alto risco que afetam processos críticos ou que criam bloqueio direto para a migração. Sem esse mapeamento, qualquer estimativa de projeto S/4HANA é especulação.
O Clean Core começa exatamente aqui: saber o que existe, entender o que cada coisa faz e ter critério para decidir o que manter, o que mover e o que descartar. Para aprofundar o conceito e entender por que Clean Core deixou de ser opcional, leia: Clean Core no SAP: o que significa de verdade, por que virou prioridade e como começar sem travar a operação.
Como começar: diagnóstico antes de qualquer decisão de migração
O erro mais comum que empresas cometem ao iniciar um projeto S/4HANA é ir direto para as decisões de arquitetura e licenciamento antes de entender o estado real do ambiente atual. A consequência é escopo incorreto, orçamento subestimado e cronograma que se estende inevitavelmente.
O caminho correto começa com um diagnóstico objetivo do ambiente: inventário de objetos Z, análise de compatibilidade com S/4HANA, mapeamento de processos críticos afetados e identificação dos pontos de maior risco. Com esse diagnóstico, a empresa tem base concreta para tomar as decisões seguintes com clareza.
O QAAssessment da QAMetrik foi desenvolvido especificamente para essa etapa. Realiza o inventário de objetos Z, conduz a análise de ampliações com potencial de impacto na migração, avalia a aderência ao Clean Core e entrega um roadmap priorizado por risco e valor, orientado a dados e não a percepções.
Se você quer saber quanto o seu código Z realmente custa e o que é necessário fazer antes de 2027, o ponto de partida é esse diagnóstico. Converse com nosso time e entenda o que é possível planejar ainda neste ciclo.
Checklist: sinais de que o seu ambiente SAP precisa de diagnóstico agora
- Você não sabe ao certo quantos objetos Z existem no ambiente
- Boa parte do orçamento SAP vai para manutenção do que já existe, não para inovação
- Transportes quebram produção com frequência e a origem nem sempre é clara
- O time técnico tem medo de mexer em determinados programas Z porque ‘não se sabe o que pode quebrar’
- Não existe inventário atualizado de customizações com documentação associada
- O projeto S/4HANA ainda não tem data definida e o prazo de 2027 está próximo
Se você marcou três ou mais itens, o diagnóstico não pode esperar. Acesse o Checklist SAP: Guia de Prontidão e entenda em que nível de maturidade o seu ambiente está hoje.