Migração do SAP ECC para o S/4HANA: estudo de caso de varejo no Oriente Médio

Este é o meu estudo de caso favorito. Um conhecido varejista do Oriente Médio, de moda e bens de consumo, migrou do SAP ECC 6.0 para o S/4HANA. Tinha cerca de 18.000 funcionários, mais de 1.200 lojas em sete países e um canal de e-commerce em crescimento. Operava o ECC havia anos, e 44% dos objetos do seu sistema eram personalizados. Escolhemos uma conversão brownfield com redesenho seletivo. O fechamento mensal passou de se arrastar pelos fins de semana para terminar antes do almoço, e o código personalizado caiu quase pela metade.

Se você opera um sistema ECC muito personalizado e se pergunta quanto dele levar adiante, foi assim que um programa respondeu a essa pergunta.

A personalização tinha se acumulado devagar, uma correção urgente de cada vez. Quando começamos, até pequenas atualizações traziam risco. As integrações eram frágeis: uma pequena mudança em finanças podia quebrar algo nas operações de varejo. O negócio queria flexibilidade e velocidade. A TI estava consumida apagando incêndios. Os dois lados admitiam que remavam em direções opostas.

Lembro de uma sessão em que a equipe de supply chain riu um pouco ao admitir que dezenas dos seus relatórios “críticos” quase não eram mais usados. Cortá-los foi prático e, curiosamente, libertador.

O fim da manutenção padrão do ECC foi o gatilho. O SAP ERP 6.0 nos pacotes de aprimoramento 6 a 8 sai da manutenção padrão no fim de 2027 (SAP News). Os motivos reais eram mais profundos. As finanças rodavam extrações manuais a cada fechamento mensal. As lojas precisavam de uma visibilidade de estoque que jobs batch noturnos não davam. A maior parte do esforço da TI ia para manter o código personalizado vivo.

O SAP Readiness Check confirmou o que suspeitávamos: um sistema muito personalizado, com uma remediação significativa pela frente. A Simplification Item List mostrou onde o S/4HANA padrão já fazia o que o código personalizado do ECC vinha fazendo. As finanças descobriram que alguns relatórios personalizados mantidos havia muito tempo agora eram redundantes. O alívio naquela reunião foi evidente.

Uma conversão técnica simples só empurraria os problemas adiante. Uma reconstrução greenfield completa jogaria fora uma década de configuração que funcionava. O brownfield com redesenho seletivo foi o equilíbrio: manter o que era sólido, limpar o que precisava de limpeza, reconstruir só o que estava quebrado. Meu guia de migração do ECC para o S/4HANA explica como pesar esses caminhos.

Conversão simplesBrownfield com redesenho seletivoReconstrução greenfield completa

Configuração mantidaConversão simplesToda ela, problemas inclusiveBrownfield com redesenho seletivoO que era sólidoReconstrução greenfield completaNenhuma, uma década de trabalho descartada

44% de objetos personalizadosConversão simplesLevados adiante como estãoBrownfield com redesenho seletivoCada um marcado para aposentar, substituir ou readequarReconstrução greenfield completaNão levados adiante

O que isso significaConversão simplesOs problemas vão junto para o S/4HANABrownfield com redesenho seletivoLimpar o que precisa de limpeza, reconstruir só o que está quebradoReconstrução greenfield completaTodo processo que funcionava reconstruído do zero

Desafio	O que fizemos
44% de objetos personalizados	Negócio e TI marcaram cada objeto juntos: aposentar, substituir ou readequar; gates de qualidade por fase
Integrações frágeis	Plano de regressão cobrindo POS, WMS, finanças, RH e portais de fornecedores; links ponto a ponto movidos para padrões do SAP Integration Suite
Qualidade de dados	Data stewards por função com SLAs; acompanhamento diário de defeitos; limpeza concluída antes do QA
Adoção entre países	Guias de trabalho por função, rondas de apoio no local perto do go-live, treinamento ligado a tarefas reais

Código personalizado em escala

Os resultados do readiness funcionaram como um filtro. Negócio e TI sentaram juntos para marcar cada objeto. Alguns eram claramente redundantes, como relatórios de que ninguém lembrava ter rodado. Outros sustentavam processos de varejo realmente únicos e precisavam de um redesenho cuidadoso. Isso obrigou as equipes a decidir em vez de adiar. O SAP Signavio ajudou a definir os novos processos com base nas melhores práticas, e o smartShift cuidou das varreduras automatizadas de código e das correções de baixo valor, o que preservou o tempo dos seniores para o redesenho. Meu guia de clean core mostra como classifico o código personalizado hoje.

Integrações

O ECC se conectava a sistemas de ponto de venda (POS), ao sistema de gestão de armazéns (WMS), a finanças, a RH e a vários portais de fornecedores. Montamos um plano de regressão cobrindo todos eles e testamos depois de cada mudança de configuração significativa, não só no final. Os jobs batch noturnos precisavam terminar mais rápido no S/4HANA, ou os relatórios matinais do armazém não ficariam prontos.

Qualidade de dados

Registros duplicados de fornecedores e dados mestre desatualizados arrastaram os testes. A solução foi estrutural: um data steward em cada função, com SLAs de resolução. Se os dados não estivessem limpos no início do QA, voltavam para o steward. À medida que o cutover se aproximava, ensaiamos as cargas de ponta a ponta e acompanhamos os defeitos todos os dias. Essa rotina simples funcionou melhor do que qualquer painel sofisticado, o que ainda me surpreende. Meu artigo sobre por que a migração de dados do SAP falha cobre esse padrão.

Adoção

O treinamento alcançou 26.000 funcionários. Finanças e operações de varejo tinham prioridades diferentes, o que apareceu em um workshop inicial e mudou o desenho do treinamento. Com a pressão crescendo perto do go-live, usamos guias de trabalho por função e rondas de apoio no local. Uma líder de loja disse depois que o guia de duas páginas foi mais importante do que qualquer town hall. Acreditei nela.

Entrega em fases no SAP Activate. Finanças centrais e supply chain foram primeiro, com RH e portais de fornecedores depois, para que as equipes de suporte nunca ficassem sobrecarregadas. Cada ambiente tinha uma única função. O sandbox validava o caminho e travava o escopo. O desenvolvimento consolidava os transportes. O QA rodava volumes reais de negócio e ajustava os jobs. A pré-produção era um ensaio geral de verdade. As datas de implantação foram alinhadas aos picos e aos períodos de baixa do varejo.

Testes com o negócio. Os líderes de finanças e de supply chain testaram com ciclos reais de fechamento de período e de promoção, com roteiros escritos a partir da realidade do negócio, e não da lógica do sistema. As execuções noturnas expuseram problemas de sincronização. Lembro de um líder de armazém sorrindo quando a segunda execução passou sem problemas, depois de semanas de frustração.

Ensaios de cutover. Cada tarefa foi cronometrada, enxugada ou fundida. Só o dry run já economizou horas que uma planilha jamais revelaria. Os planos de recuperação ficavam em folhas de uma página, e as pessoas diziam que essa lista simples reduzia mais o estresse do que qualquer painel. Um piloto em loja comprovou a estabilidade do POS e do WMS antes do lançamento mais amplo.

Hypercare. Uma war room compartilhada entre TI e negócio, SLAs claros e registros diários de ações. Os plantões de fim de semana eram revezados e as passagens de suporte foram roteirizadas ao minuto. As pessoas costumam lembrar de números. Eu me lembro mais da primeira noite tranquila.

Fechamento financeiro. As equipes disseram que o fechamento mensal agora terminava antes do almoço, quando antes avançava pelos fins de semana. O CFO ficou mais satisfeito por receber seus relatórios muito mais rápido. Um líder de finanças brincou que o sistema finalmente funcionava “mais rápido que a máquina de café”. Esse tipo de momento constrói mais confiança do que qualquer apresentação de slides.

Código personalizado. Redução de quase metade, o que baixou o custo de suporte no longo prazo e o risco de regressão em cada upgrade futuro.

Relatórios e experiência do usuário. Os gerentes de loja passaram das antigas telas de transação para aplicativos SAP Fiori. O tempo de treinamento caiu porque os aplicativos funcionavam do jeito que as pessoas esperavam. Um gerente chamou a experiência de “revigorante”.

Integrações. As conexões de POS, WMS e finanças ficaram mais estáveis, e os jobs noturnos terminavam mais cedo.

Nem tudo funcionou de forma uniforme. Algumas equipes se agarraram a relatórios antigos mesmo quando havia melhores. Algumas acharam os workshops longos demais e os ensaios repetitivos. Em retrospecto, essas etapas foram a rede de segurança.

Lição	O que aconteceu	O que eu faria da próxima vez
Alinhar cedo	Em um workshop, os gerentes de loja disseram que as necessidades de relatórios deles eram muito diferentes das de finanças. Isso apareceu cedo e ajustamos; mais tarde, teria estourado no cutover	Agendar sessões estruturadas de alinhamento antes de o design começar
Começar a revisão de código no primeiro dia	Vários objetos foram retrabalhados sob pressão perto do go-live	Tomar as decisões de aposentar, substituir ou readequar desde o kickoff
Fazer dos dados um trabalho do negócio	Registros duplicados de fornecedores atrasaram os testes	Nomear data stewards por função, com SLAs, na primeira semana
Ensaiar mais do que parece necessário	Um dry run revelou conflitos de sequenciamento entre POS e WMS que ninguém havia previsto	Planejar ensaios extras; o último antes do go-live deve ser entediante

Se o mesmo programa começasse hoje, três coisas mudariam. A maioria das empresas nessa posição olharia agora para o S/4HANA Cloud Private Edition sob o RISE with SAP em vez de permanecer on-premise. As decisões de aposentar, substituir ou readequar seriam enquadradas nos níveis de clean core A a D da SAP. O acompanhamento de mudanças e de implantação rodaria no SAP Cloud ALM, porque o Solution Manager 7.2 sai da manutenção padrão no fim de 2027. Os data stewards, os ensaios, a war room conjunta e os guias de duas páginas ficariam exatamente como estavam. Para o lado das pessoas, veja meu guia de estratégias de treinamento em SAP.

Por que as empresas migram do SAP ECC para o S/4HANA?

O fim da manutenção padrão do ECC em 2027 é o gatilho. Os motivos mais fortes são operacionais: relatórios em tempo real, um fechamento mais rápido e menos esforço para manter vivos o código personalizado e as integrações frágeis. Neste caso, o negócio queria análises de varejo em tempo real e um fechamento mensal mais curto.

O que o SAP Readiness Check mostrou neste caso?

Confirmou que 44% dos objetos eram personalizados e que muitos não eram usados havia anos. Isso mudou a estrutura do trabalho com o código personalizado: aposentar primeiro, substituir pelo padrão sempre que possível e readequar apenas o que tinha valor real para o negócio. A Simplification Item List também mostrou relatórios que o S/4HANA padrão tornava redundantes.

Por que escolher brownfield com redesenho seletivo?

Uma conversão técnica simples teria levado todos os problemas adiante, e uma reconstrução greenfield completa teria descartado uma década de configuração que funcionava. O redesenho seletivo manteve o que era sólido, usou o SAP Signavio para definir novos processos onde o padrão podia substituir a lógica personalizada e reconstruiu apenas o que estava quebrado.

O que acontece se a limpeza de dados for deixada para tarde demais?

Os testes se arrastam, os ensaios falham e o go-live escorrega. Aqui, registros duplicados de fornecedores e dados mestre desatualizados causaram semanas de atrito nos testes. A solução foram data stewards em cada função, com SLAs, e a limpeza acompanhada como medida de saúde do programa.

Como as integrações foram tratadas durante a migração?

Mapeando primeiro cada conexão: POS, WMS, finanças, RH e portais de fornecedores. Um plano de regressão cobriu todas, os testes rodaram depois de cada mudança de configuração significativa e um piloto em loja comprovou a estabilidade do POS e do WMS antes do lançamento mais amplo. Mesmo assim, um dry run encontrou um conflito de sequenciamento entre POS e WMS que ninguém havia previsto.

Como é um bom hypercare depois de um go-live do S/4HANA?

Uma war room compartilhada entre TI e negócio, com SLAs claros, registros diários de ações e problemas fechados rapidamente em vez de estacionados em um backlog. Guias por função e rondas de apoio no local reduzem as chamadas de suporte mais rápido do que o treinamento formal. Reveze os plantões de fim de semana e roteirize as passagens de suporte para a equipe não se esgotar.