Depois de meses de anúncios de IA da SAP, saiu o número que mede a adoção real — e ele é desconfortável. Só cerca de 3% dos clientes SAP usam o Joule em produção. A plataforma oferece mais de 40 agentes e 2.400 skills, e mesmo assim quase ninguém está rodando. A razão não é falta de vontade nem preço: é que a migração pro S/4HANA, que precisa vir antes, ainda está aberta na maioria das empresas.
Para quem toca um projeto SAP, essa é a estatística que reorganiza o roadmap. Ela diz, em uma frase: a IA da SAP não é o gargalo — a migração é. E entender isso é a diferença entre virar um dos 3% que rodam e ficar preso nos 97% que "têm IA" no slide e nada em produção.
O número que mede a adoção real: ~3% do Joule em produção
Segundo levantamento reportado por CIO, heise e E3, o Joule chega ao mercado com um catálogo impressionante — 40+ agentes, 2.400 skills — e uma adoção real de apenas cerca de 3% dos clientes em produção. É o contraste que define o momento: capacidade abundante, uso escasso.
Quando a distância entre o que a plataforma oferece e o que os clientes conseguem operar é tão grande, o problema quase nunca é a plataforma. É a base sobre a qual ela precisa rodar. E é exatamente aí que o levantamento aponta.
Por que 6 em 10 pulam a IA da SAP na migração pro S/4HANA
O dado mais revelador: 6 em cada 10 empresas em transição pro S/4HANA não estão aproveitando os agentes de IA da SAP — mesmo podendo ligar o Joule sem gasto adicional relevante. O motivo declarado é direto: a enormidade da própria transformação as consome. Seis em dez se consideram "não ágeis, eficientes e flexíveis o suficiente" para operar o ERP na nuvem com o copiloto.
Traduzindo: a empresa está com as duas mãos na migração. Não sobra capacidade — técnica ou organizacional — para ligar e governar um copiloto por cima de uma base que ainda está em obras. Pular a IA, nesse contexto, não é desinteresse. É priorização racional.
O dado incômodo: quase toda 2ª empresa estourou tempo e orçamento
A troca de sistema se mostrou mais difícil que o previsto. Quase toda segunda empresa teria que alocar mais tempo e orçamento em retrospecto. Ou seja: metade dos projetos descobriu, no meio do caminho, que a migração era maior do que o plano previa.
Isso tem uma consequência direta sobre a IA. Se a migração — o item mais caro e mais longo do roadmap — está estourando, qualquer iniciativa que dependa dela para funcionar herda o mesmo atraso. O Joule não é exceção: ele precisa de dado migrado e integrado para entregar valor. Sem essa base, ele fica esperando na fila.
O paradoxo: 43% dizem que a IA molda a estratégia — e quase ninguém roda
Aqui está a tensão que fecha a tese. Enquanto só ~3% rodam o Joule em produção, 43% dizem que os anúncios de IA da SAP são fator primário na estratégia de ERP. Todo mundo está comprando a narrativa da IA — e quase ninguém consegue executá-la.
Esse descompasso entre expectativa e execução é o terreno onde decisões ruins nascem. A diretoria compra a promessa, cobra o resultado, e a pressão empurra o time a ligar o copiloto antes da hora — sobre uma fundação que ainda não está pronta. É a receita para virar mais um número na estatística dos 97%.
A tese: a IA da SAP não é o gargalo, a migração é
Junte os números e a leitura estratégica é inevitável: a IA da SAP não é o gargalo — a migração é. O Joule não está parado porque é ruim. Está parado porque a base sobre a qual ele roda ainda não foi concluída. O caminho para os 3% não passa por um copiloto melhor; passa por fechar a migração e a integração primeiro.
Essa inversão de foco é o insight prático do momento. Enquanto o mercado debate qual agente é mais capaz, os que estão rodando descobriram que a pergunta certa é outra: a minha fundação está pronta para receber um agente?
Por que a IA não conserta uma migração mal feita
É tentador imaginar que a IA vai atalhar a bagunça — que o copiloto "dá conta" do dado fragmentado. Não dá. A IA não conserta uma migração mal feita. Um copiloto sobre dado fragmentado, custom code pesado e processo inconsistente só devolve, mais rápido, a inconsistência de baixo.
Pense no mecanismo. O Joule lê o dado do ERP para agir. Se esse dado está espalhado, duplicado ou desatualizado, o agente age sobre uma base ruim — e amplifica o erro na velocidade da máquina. Se o processo por baixo é inconsistente, o agente automatiza a inconsistência. IA é um multiplicador: multiplica o que já está lá. Sobre uma base quebrada, ela multiplica a quebra.
A sequência que separa os 3% dos 97%
A ordem que separa quem roda de quem espera é chata, conhecida e não-negociável: fundação primeiro, IA depois. Na prática:
- Migração limpa — completar a transição pro S/4HANA sem arrastar a dívida técnica antiga.
- Clean core — reduzir customizações que travam upgrades e poluem o dado, mantendo o núcleo padrão.
- Integração SAP ↔ não-SAP governada — conectar o ERP ao e-commerce, ao OMS e aos sistemas satélites por integrações reais (OData, iDocs, RFC) e arquitetura orientada a eventos.
- Dado reconciliado — estoque, custo e imposto batendo entre os sistemas, para o agente ler uma verdade única.
Só depois disso o Joule vira valor, porque agora ele age sobre uma base confiável. Quem inverte a ordem — liga o copiloto antes de fechar a fundação — entra direto na estatística de estourar tempo e orçamento.
O relógio de 2027: a ordem certa é também a mais rápida
Há um agravante de calendário. Com o prazo de 2027 apertando e a migração já sendo o item mais caro do roadmap, não há folga para retrabalho. E é aqui que a intuição engana: ligar a IA "para adiantar" parece mais rápido, mas é o caminho mais lento, porque gera retrabalho quando a base muda por baixo.
A ordem certa — fundação primeiro — é também a mais barata e a mais rápida no total, porque você constrói uma vez, sobre base estável, sem refazer. Não deixe a promessa da IA empurrar o time a ligar o Joule antes de fechar a migração e a integração. É exatamente aí que o valor vaza.
Como a CCX fecha a fundação sob o Joule
É essa fundação que trava os 97% — e é ela que a CCX fecha. A prática de Integração SAP ↔ e-commerce e Migrações de Plataforma completa o que precisa vir antes do agente: migração limpa, clean core e a malha SAP↔não-SAP governada, com OData, iDocs e RFC e arquitetura orientada a eventos em Kafka ou RabbitMQ — a integração em tempo real entre ERP e canal de venda que sincroniza estoque, preço, pedido e nota.
Antes de tocar o código, a Consultoria em Tecnologia faz o diagnóstico que define a ordem certa — o que migrar, integrar e padronizar antes de ligar o Joule — e desenha a arquitetura-alvo. Data & Business Intelligence reconcilia o dado fragmentado de estoque, custo e imposto que impede o copiloto de virar valor. E, com o prazo de 2027 apertando, as Squads On-Demand trazem a capacidade sênior escassa de SAP e integração, com onboarding em 48 horas, para destravar a migração dentro do prazo.
Só ~3% dos clientes SAP rodam o Joule em produção — e 6 em 10 pulam a IA porque a migração já é dura demais. A IA não conserta uma migração mal feita: a ordem é fundação primeiro, IA depois. A CCX fecha essa fundação dentro do prazo de 2027 — pra você sair dos 97% e virar os 3% que rodam. Integrar SAP ao seu e-commerce →
Perguntas frequentes
Quantos clientes SAP usam o Joule em produção?
Segundo levantamento de CIO, heise e E3, apenas cerca de 3% dos clientes SAP usam o Joule em produção — apesar de a plataforma oferecer 40+ agentes e 2.400 skills.
Por que as empresas estão pulando a IA da SAP na migração?
Porque 6 em cada 10 empresas em transição pro S/4HANA se consideram sem agilidade suficiente para operar o ERP na nuvem com o copiloto — a própria migração já as consome. Quase toda segunda empresa estourou tempo e orçamento.
A IA da SAP conserta uma migração mal feita?
Não. Um copiloto sobre dado fragmentado, custom code pesado e processo inconsistente devolve a inconsistência mais rápido. A ordem correta é fundação primeiro (migração limpa, clean core, integração, dado reconciliado), Joule depois.
Qual a sequência certa para adotar o Joule com o prazo de 2027?
Fechar a migração pro S/4HANA e a integração SAP↔não-SAP antes de ligar a IA. A ordem certa é também a mais barata e rápida, porque evita o retrabalho de construir sobre base instável.