Parece que a transição do cinturão é inevitável, mas o campeão não vai desistir tão fácil.
Vejo muitas discussões que abrangem apenas os aspectos técnicos deste movimento, principalmente entre colegas de trabalho. Quem trabalha com algo, independentemente da ferramenta, quer sempre atuar na sua melhor versão. A verdade é que se fôssemos considerar apenas o lado técnico, não haveria discussão. Tecnicamente, o ideal é sempre evoluir, escolher a versão mais nova, migrar para o software mais novo.
Porém, neste caso, a decisão não pode ser tomada considerando apenas os aspectos técnicos. Existem muitas variáveis nessa equação e a definição de algumas delas não está apenas nas mãos dos gestores de TI. Essa decisão deve ocorrer principalmente nas camadas de Diretoria e C-levels, com todos os dados históricos e projeções futuras em mãos. Não estou dizendo que é fácil, mas é necessário.
A Canibalização Estratégica
No mundo dos negócios, o movimento da SAP ao lançar o S/4HANA e definir a data de fim do suporte para o ECC tem um nome bem claro: Canibalização Planejada de Produtos, que na prática é uma coexistência estratégica de gerações.
Quando uma empresa domina um mercado com um produto praticamente inquebrável — como o SAP ECC —, criar um substituto que exige a reescrita de código e a mudança de arquitetura parece um risco enorme. Mas, lamentavelmente, a alternativa seria ainda pior: deixar que concorrentes façam isso. E isso, com certeza, está fora de cogitação.
E esse não é um fenômeno exclusivo da SAP. A disputa interna entre o "legado consagrado" e a "nova geração promissora" acontece nos mais diversos setores do mercado:
> Caso Oracle - Enterprise Software
A Oracle vem enfrentando um dilema parecido com a SAP, em relação aos seus clientes. Isso porque o Oracle EBS (E-Business Suite), geralmente on-premises, continua rodando em milhares de empresas, enquanto a Oracle empurra agressivamente o Oracle Fusion Cloud. A dinâmica de resistência e migração é rigorosamente a mesma. Inclusive, em muitos casos a Oracle é considerada concorrente direta da SAP.
> Caso Porsche - Mercado Automotivo
A Porsche lançou o Taycan (100% elétrico) para disputar exatamente a mesma faixa de preço e o mesmo perfil de comprador do Panamera (a combustão). O objetivo? Fazer com que seu cliente continue na marca, independentemente de questões ecológicas ou de tecnologia preferida.
> Caso Sony - Mercado de Videogames
Durante mais de 3 anos após o lançamento do PS5, a Sony continuou produzindo o PS4 e lançando jogos no formato "cross-gen" (para ambos os consoles). A base instalada do PS4 era tão grande que lançar novos jogos exclusivos para PS5 significaria deixar dinheiro na mesa.
Nos casos da Porsche e da Sony, a decisão do cliente/consumidor é embasada por duas perguntas:
1) Preciso deste novo produto?
2) Possuo orçamento para adquirir o novo produto?
E mais um fator importante nestes casos é a possibilidade de vender o produto antigo. Ou seja, o investimento realizado no produto antigo pode retornar para ajudar a subsidiar os custos da nova aquisição.2) Possuo orçamento para adquirir o novo produto?
Já nos casos da SAP e da Oracle, não existe opção de vender o produto antigo. E ainda existe o agravamento do investimento gigantesco que foi acumulado ao longo do tempo. E esse é um dos motivos que torna a decisão tão difícil. Não só pelo fator financeiro em si, mas pelos fatos que motivaram o investimento: as customizações.
O Dilema da Transição
A SAP se colocou numa posição complexa e extremamente frágil, na qual mantém dois transatlânticos na água por mais de uma década. O S/4HANA começou a ser comercializado no início de 2015, enquanto o fim do suporte do ECC havia sido decretado para o fim de 2025. Essa data do fim do suporte viria a ser alterada, porém com ressalvas de EHP. Para clientes com EHPs mais recentes (entre 6 e 8), o fim do suporte passa para o fim de 2027. E ainda, para EHPs recentes, com opção de suporte estendido até o fim de 2030, mas com custos adicionais de taxa de manutenção da SAP.
O dilema se estende aos clientes... Devemos fazer a migração? Se sim, como devemos fazer? E até quando podemos/devemos fazer? São perguntas que estão sempre vivas... Quanto custa? Leva quanto tempo? E ainda mais... Vamos mudar os processos? Todos ou apenas alguns? São essas apenas algumas das dúvidas que permeiam essa transição.
E muitas empresas ainda não sabem o que fazer. Algumas estão "empurrando" e adiando qualquer decisão até o prazo máximo. Ainda nem todos entenderam que existe uma relação direta entre o fim do suporte do ECC e o prazo de entrega do projeto de migração. O ideal é que a migração finalize antes do fim do suporte do ECC, para não correr risco algum.
Devemos lembrar também que o risco de ficar sem suporte da SAP é relativo. Puxando na memória, acho que dá pra contar nos dedos a quantidade de vezes que precisei de suporte da SAP. Mas pense no seguro de um carro, você paga pra ter caso precise e torce para não precisar... é a mesma situação. Melhor não arriscar. Mesmo que o risco seja baixo, acredito que não vale a pena submeter a operação de uma empresa a este risco.
A Grande Mudança
No fim das contas, será que toda essa discussão realmente compensa? Será que a empresa não estará simplesmente trocando um sistema por outro? Do ponto de vista técnico, as respostas são: Sim, a discussão é necessária! E não, não é uma simples troca de sistema, mas uma evolução de tecnologia. Isso porque o S/4HANA é completamente diferente do ECC. E não apenas falando de usabilidade e experiência do usuário, mas principalmente na arquitetura na qual ele foi concebido.
> Banco de Dados In-Memory
Com certeza o coração dessa mudança fica por conta do banco de dados.
No ECC, a aplicação dependia do conceito AnyDB (Oracle, SQL Server, DB2), que, além de fatores técnicos, também gerava questões de licenciamento do banco. Com esses bancos de dados relacionais tradicionais, os gargalos severos de I/O se tornam cada vez mais frequentes em ambientes com grandes volumes, já que gravação e leitura estão sempre em disco.
Já no banco SAP HANA, a dinâmica é que os dados residem na memória principal. A velocidade de leitura passa a ser incomparavelmente maior. Outro fator é o armazenamento colunar, que permite uma compressão maior dos dados, reduzindo consideravelmente o tamanho do banco. Com isso, tabelas de dados agregados ou ferramentas de relatórios não são mais necessárias, possibilitando extrações de dados online diretamente da fonte.
No ECC, a aplicação dependia do conceito AnyDB (Oracle, SQL Server, DB2), que, além de fatores técnicos, também gerava questões de licenciamento do banco. Com esses bancos de dados relacionais tradicionais, os gargalos severos de I/O se tornam cada vez mais frequentes em ambientes com grandes volumes, já que gravação e leitura estão sempre em disco.
Já no banco SAP HANA, a dinâmica é que os dados residem na memória principal. A velocidade de leitura passa a ser incomparavelmente maior. Outro fator é o armazenamento colunar, que permite uma compressão maior dos dados, reduzindo consideravelmente o tamanho do banco. Com isso, tabelas de dados agregados ou ferramentas de relatórios não são mais necessárias, possibilitando extrações de dados online diretamente da fonte.
> Simplificação das Tabelas
A mudança estrutural do banco de dados possibilitou uma simplificação na estrutura do próprio dado. Isso significa que processos que no ECC precisavam de várias tabelas, agora no S/4HANA precisam de praticamente uma tabela.
Exemplo 1: Um processo de Finanças e Controladoria, antes no ECC FI gravava nas tabelas
Exemplo 2: Um processo de Movimentação de Estoque, antes no ECC gravava nas tabelas
E devido às simplificações de tabelas no S/4HANA é que reside parte das preocupações com as customizações. Os programas Zs que antes liam as tabelas do ECC precisarão de uma grande revisão para apontamentos das novas tabelas. Nem se fala então se houver programas não normalizados que gravam dados direto em tabelas standards...Exemplo 1: Um processo de Finanças e Controladoria, antes no ECC FI gravava nas tabelas
BSEG, BSIS, BSAS, BSID e BSAD, CO gravava em COEP e ativo fixo gravava em ANEP; já no S/4HANA FI, CO e ativo fixo gravam em uma única tabela ACDOCA.Exemplo 2: Um processo de Movimentação de Estoque, antes no ECC gravava nas tabelas
MSEG, MKPF, MBEW e MARD; já no S/4HANA grava em uma única tabela MATDOC.Estratégias de Migração
Escolher o caminho de migração para o SAP S/4HANA é uma das decisões mais críticas para a equipe de arquitetura de TI e para os líderes de negócio. Essa escolha define o orçamento, a duração do projeto, o nível de esforço técnico necessário da equipe ABAP e o futuro do sistema da empresa.
E assim nasceram algumas estratégias de migração. Você já deve ter ouvido falar sobre os muitos "fields". Greenfield, Brownfield, Bluefield, Blackfield, Pinkfield, etc... rsrsrsrs... Brincadeiras à parte, são praticamente 3 estratégias, sendo elas Greenfield, Brownfield e Selective Data Transition (SDT).
> Greenfield (Nova Implementação)
A abordagem Greenfield consiste em redefinir a solução do zero. O sistema ECC atual é descartado e um novo ambiente S/4HANA é construído com base em 100% das melhores práticas da SAP (SAP Best Practices). Geralmente são levados/carregados apenas os dados mestres (clientes, fornecedores, materiais) e saldos em aberto do antigo ECC.
Uma grande vantagem é eliminar a "dívida técnica" e os códigos Zs, além de aderir a processos nativos e simplificados. Por outro lado, tem um alto custo operacional para se revisar e adequar todos os processos da empresa. A perda de todo histórico no ERP pode ser um grave problema futuro para auditorias, obrigando o desenvolvimento de um Datalake histórico ou ainda a manutenção de uma versão do ECC como leitura.
Uma grande vantagem é eliminar a "dívida técnica" e os códigos Zs, além de aderir a processos nativos e simplificados. Por outro lado, tem um alto custo operacional para se revisar e adequar todos os processos da empresa. A perda de todo histórico no ERP pode ser um grave problema futuro para auditorias, obrigando o desenvolvimento de um Datalake histórico ou ainda a manutenção de uma versão do ECC como leitura.
> Brownfield (Conversão de Sistema)
A abordagem Brownfield é a conversão técnica direta de um ambiente SAP ECC existente para o SAP S/4HANA, simples assim. Você leva tudo que havia no antigo ECC para dentro do S/4HANA, sejam dados mestres, saldos, movimentações, programas Zs, tabelas Zs e dívida técnica.
A vantagem é ter baixíssimo impacto operacional, pois os processos vigentes de negócio são praticamente mantidos. Mas por outro lado, o esforço técnico de adaptação de programas e tabelas é gigantesco. Até existem ferramentas que fazem conversão automática, porém uma boa parte dos programas ainda vai precisar passar pelas mãos dos ABAPs.
A vantagem é ter baixíssimo impacto operacional, pois os processos vigentes de negócio são praticamente mantidos. Mas por outro lado, o esforço técnico de adaptação de programas e tabelas é gigantesco. Até existem ferramentas que fazem conversão automática, porém uma boa parte dos programas ainda vai precisar passar pelas mãos dos ABAPs.
> Selective Data Transition (Abordagem Híbrida)
A Selective Data Transition é o meio-termo cirúrgico entre o Greenfield e o Brownfield. Ela permite redefinir os processos de negócio (como no Greenfield) mantendo partes selecionadas do histórico de dados e customizações estratégicas (como no Brownfield).
Sem dúvida alguma parece ser a melhor opção. Por outro lado, possui um altíssimo nível de complexidade de mapeamento para definição de quais processos podem ser levados do ECC e quais precisam ser remodelados. Além de exigir o uso de ferramentas de consultorias especializadas, fato que eleva consideravelmente o custo do projeto.
Sem dúvida alguma parece ser a melhor opção. Por outro lado, possui um altíssimo nível de complexidade de mapeamento para definição de quais processos podem ser levados do ECC e quais precisam ser remodelados. Além de exigir o uso de ferramentas de consultorias especializadas, fato que eleva consideravelmente o custo do projeto.
Conclusão
A migração do SAP ECC para o S/4HANA deixou de ser uma simples decisão de TI para se tornar uma questão de estratégia e continuidade de negócio. Adiar essa escolha é, na prática, acumular juros sobre a dívida técnica e correr riscos desnecessários à medida que os prazos de fim de suporte se aproximam.
Para Gestores e Executivos, a lição é clara: o investimento vai muito além da infraestrutura, impactando a agilidade da empresa e a capacidade de competir na era digital. Já para Desenvolvedores e Arquitetos, o recado é direto: o modelo clássico de desenvolvimento mudou. Dominar conceitos como Code Pushdown, CDS Views, RAP e a nova arquitetura do HANA não é mais um diferencial para o futuro — é a exigência do presente.
O S/4HANA é a nova realidade do ecossistema SAP. A única pergunta que resta é: a sua operação estará pronta quando o relógio zerar?
E na sua empresa, qual tem sido o maior desafio nessa transição? Vocês já definiram a estratégia de migração (Greenfield, Brownfield ou SDT) ou a discussão ainda não saiu do papel? Deixe seu comentário compartilhando a sua visão! Se este conteúdo fez sentido para você, compartilhe com seus colegas.