A SAP fez um movimento inteligente: colocou os agentes para acelerar a própria transformação. Dentro do RISE with SAP, 7 assistentes de modernização — Análise de Sistema, Gestão de Dados, Custom Code, Configuração, Gestão de Testes, Rollout e Gestão de Projeto — entram no processo de migração em Q3–Q4/26, com a promessa de cortar mais de 35% do esforço. E os agentes já operam em cenários híbridos (S/4HANA on-prem + ECC) para quem começou a jornada. É avanço de verdade — a SAP está usando agente para encurtar o gargalo que sempre foi a migração. Mas o número que importa é o outro: os 65% que sobram. O assistente automatiza o mecânico; a integração SAP↔não-SAP e o fiscal brasileiro não se automatizam — e é aí que a migração de fato fecha ou empaca.
O que a SAP anunciou: 7 assistentes de modernização no RISE (-35% de esforço)
A proposta é direta: embutir agentes especializados em cada etapa penosa de uma migração. Os 7 assistentes cobrem análise de sistema, gestão de dados, remediação de custom code, configuração, gestão de testes, rollout e gestão de projeto. Automatizando análise, remediação de código e testes em escala, a SAP estima mais de 35% de redução do esforço de migração. Para quem já encarou um projeto S/4HANA, cortar um terço do trabalho mecânico é uma promessa que merece atenção.
É importante dar o crédito: essa é a aplicação mais útil de agentes que a SAP poderia ter escolhido. Migração é repetitiva, demorada e cara justamente nas partes que agentes fazem bem — varrer código, mapear dependências, gerar e rodar testes. O ceticismo aqui não é sobre o agente funcionar; é sobre o que a manchete de "-35%" deixa de fora.
O que os agentes automatizam de fato: análise, custom code, config, testes
Os assistentes são muito bons no trabalho mecânico e bem-definido: identificar custom code incompatível com o S/4HANA, sugerir remediações, mapear objetos de configuração, gerar massas de teste e rodar regressão. Esse é o tipo de tarefa onde escala e paciência importam mais do que julgamento — e é exatamente onde um agente supera o esforço humano manual.
Repare no padrão: tudo isso é interno ao mundo SAP e tem resposta relativamente determinística. "Este código usa uma tabela que mudou" é uma pergunta com resposta verificável. É por isso que o agente entrega esses 35% com confiança. O problema aparece quando a pergunta deixa de ser mecânica e passa a ser decisão de arquitetura.
Convém também ler o "35%" como o que ele é: uma média de esforço, não de risco nem de valor. As tarefas que o agente automatiza são numerosas, mas costumam ser as de menor risco do projeto — se um teste gerado falha, você regenera. As tarefas que sobram são menos numerosas, porém carregam o risco concentrado: um erro na integração de pedido ou na apuração fiscal não se corrige com um rerun, ele aparece como pedido perdido ou como autuação. Ou seja, o agente comeu a parte grande e macia do bolo; o que resta é a casca dura onde o projeto realmente pode quebrar.
Cenários híbridos (S/4HANA + ECC): agentes pra quem já começou a jornada
Um detalhe estratégico do anúncio: a SAP passou a habilitar os agentes e o Joule em cenários híbridos — S/4HANA on-prem convivendo com ECC — para clientes que já se comprometeram com a modernização, inclusive quem ainda está em ECC com compromisso de migrar (a HARTING assinou RISE em set/26 como prova de tração). Isso reconhece a realidade: quase ninguém migra num único salto; a maioria opera um estado híbrido por um bom tempo.
E o estado híbrido é, por definição, um problema de integração. Enquanto S/4HANA e ECC coexistem — e enquanto ambos precisam falar com CRM, e-commerce, WMS e parceiros fiscais — alguém tem que manter os dados e os processos consistentes entre eles. O agente de migração acelera o caminho para o S/4HANA; ele não gerencia a convivência híbrida com o resto do seu parque.
O que o assistente NÃO faz: a decisão de integração SAP↔não-SAP
Aqui está a fronteira. Um "assistente de custom code" resolve o código que é SAP; ele não decide como o S/4HANA conversa com o mundo não-SAP. Que pedido do e-commerce vira ordem no ERP? Com qual contrato, qual garantia de entrega, qual comportamento em caso de falha? Como o estoque se reconcilia entre o WMS e o SAP em tempo real? Essas são decisões de integração — envolvem trade-offs de negócio, não têm resposta única e não são automatizáveis por um agente que só enxerga o interior do SAP.
É por isso que a conta dos "-35%" precisa de contexto. Ela mede o esforço mecânico interno. Os outros 65% — onde mora a integração com sistemas externos e a localização — continuam exigindo engenharia e decisão. O agente encurta a parte que já era a mais tratável; a parte difícil segue sendo difícil.
O fator Brasil: IBS/CBS dual, NF-e/SPED e a camada de localização
No Brasil, esse ponto deixa de ser abstrato. A reforma tributária (IBS/CBS) já está em produção com campos obrigatórios e valor legal desde janeiro de 2026 (com alíquotas de teste CBS 0,9% / IBS 0,1%), e o regime é dual: ICMS/PIS/COFINS e IBS/CBS rodando em paralelo. Um ERP internacional como o S/4HANA exige uma camada de localização e retrabalho de integração com parceiros fiscais (Synchro, Mastersaf ou custom), além de NF-e e SPED. Nada disso sai de um assistente de custom code genérico.
O regime dual é especialmente cruel para automação: por um período, a empresa precisa calcular e reportar os dois sistemas tributários ao mesmo tempo, com reconciliação entre eles. É um problema de dado, de integração e de conformidade — três coisas que dependem do seu processo específico e da legislação brasileira, não do catálogo de assistentes da SAP.
Some a isso um detalhe de calendário que assusta quem planeja: a reforma não espera a sua migração terminar. Enquanto o agente acelera o caminho para o S/4HANA, as obrigações de IBS/CBS já estão valendo em produção — o que significa que a localização fiscal precisa funcionar no ambiente atual e ser reprojetada no ambiente-alvo, muitas vezes durante o estado híbrido em que ECC e S/4HANA coexistem. É exatamente o tipo de exigência transversal — toca dado, integração, ERP e parceiro fiscal ao mesmo tempo — que nenhum assistente de etapa única resolve, porque o problema não vive dentro de uma etapa: vive na costura entre elas.
Os 65% que restam: costura OData/iDoc/RFC + event-driven + reconciliação fiscal
Concretamente, os 65% que o assistente não faz têm nome e sobrenome. Primeiro, a costura de integração entre o S/4HANA/ECC e o mundo não-SAP via OData, iDoc e RFC, sobre arquitetura orientada a eventos que garante entrega mesmo sob pico ou indisponibilidade. Segundo, uma porta de escrita contratada e idempotente para pedido, estoque, preço e nota fiscal — para que um retry não gere pedido em dobro. Terceiro, a reconciliação de dado e fiscal: conferir que o que entrou no e-commerce bateu com o ERP e com a apuração tributária (IBS/CBS dual, NF-e, SPED).
Nenhuma dessas três peças fica pronta porque o agente cortou 35% do esforço interno. Elas são o projeto de integração que sempre existiu — e que agora, com a migração acelerada, chega mais cedo à mesa. Acelerar o mecânico só antecipa o momento em que a integração e o fiscal precisam estar decididos.
A sequência que ancora: deixar o agente acelerar o mecânico, mas decidir a integração e o fiscal
A recomendação prática não é ignorar os assistentes — é usá-los para o que são bons e não confundir aceleração com conclusão. Deixe o agente varrer o custom code, gerar testes e configurar em escala; capture os 35%. Em paralelo, trate a integração SAP↔não-SAP e a localização fiscal como o que sempre foram: decisões de engenharia com trade-offs de negócio, feitas por quem conhece o seu parque e a legislação.
A armadilha é a inversão: assumir que, porque o agente acelerou a migração, a integração "vem junto". Não vem. Agente-que-migra encurta o caminho mecânico; a integração e o fiscal continuam sendo projeto. Quem entende essa sequência colhe os 35% e fecha os 65% — em vez de descobrir, no cutover, que o S/4HANA novo não conversa com o resto da operação.
Como a CCX faz a integração SAP↔não-SAP que a migração acelerada exige
A CCX faz exatamente os 65% que o assistente de migração não cobre. Na frente de Integrações & APIs Enterprise, fazemos a costura SAP↔e-commerce e Protheus↔e-commerce em tempo real — sincronização de estoque, preço, pedido e NF — com expertise em OData, iDoc e RFC sobre arquitetura event-driven (Kafka/RabbitMQ) e porta de escrita idempotente. Em Data & BI, cuidamos da reconciliação de dado e do suporte à apuração fiscal no regime dual (IBS/CBS, NF-e/SPED).
E em Consultoria em Tecnologia, desenhamos o projeto de migração por trás do assistente: arquitetura-alvo, decisões de integração e plano de cutover que o agente não decide. O assistente da SAP corta ~35% do esforço mecânico — não decide a sua integração nem resolve o fiscal brasileiro. Integrar SAP ao seu e-commerce → A CCX faz os 65% que restam: a costura OData/iDoc/RFC + event-driven e a reconciliação fiscal em data & BI, com o projeto de migração em consultoria em tecnologia.
FAQ (People Also Ask)
Os agentes do RISE with SAP fazem a migração sozinhos? Não. Os 7 assistentes de modernização automatizam o esforço mecânico (análise, custom code, configuração, testes) e prometem -35% de esforço. As decisões de integração SAP↔não-SAP e a localização fiscal não são automatizadas.
Por que a integração SAP↔não-SAP não se automatiza? Porque envolve trade-offs de negócio e não tem resposta única: qual contrato de escrita, qual garantia de entrega, como reconciliar estoque em tempo real. O assistente só enxerga o interior do SAP; a costura com o mundo externo é decisão de engenharia.
O que a reforma tributária (IBS/CBS) exige do meu SAP? Uma camada de localização e reconciliação para o regime dual (ICMS/PIS/COFINS e IBS/CBS em paralelo), obrigatório em produção desde jan/26, além de NF-e e SPED — integração com parceiros fiscais que um assistente de custom code genérico não entrega.