Existe um padrão que se repete em quase toda migração para o SAP S/4HANA no Brasil. A diretoria aprova dois orçamentos no mesmo comitê: um para modernizar o ERP, outro para "colocar IA no ERP". Dezoito meses depois, entrega-se um só. O ERP está na nuvem. A IA ficou para a fase 2.
Uma análise da consultoria Horváth colocou número nessa percepção: 6 em cada 10 empresas em transição para o S/4HANA não se consideram "ágeis, eficientes e flexíveis o bastante" para operar o novo ERP com o copiloto de IA. E 46% admitem, sem rodeios, que precisariam de mais tempo e mais orçamento para dar conta das duas coisas.
O detalhe que torna isso quase absurdo: o Joule — o copiloto de IA da SAP — já vem incluído na licença RISE with SAP. Ninguém está deixando de usar por causa do preço. Está deixando por falta de banda.
1. O dado: 6 em 10 não se consideram prontas para o ERP com copiloto
O achado central do levantamento é sobre capacidade organizacional, não sobre tecnologia. As empresas não dizem "o Joule não funciona" nem "a IA não entrega valor". Dizem que elas próprias não estão ágeis, eficientes e flexíveis o bastante para operar um ERP assistido por IA.
É um tipo de resposta que revela mais do que aparenta. Um copiloto de ERP não é um chatbot pendurado na tela — ele lê dado mestre, consulta pedido, propõe ação, executa transação. Para isso funcionar, os processos precisam estar padronizados, o dado precisa estar limpo e as integrações precisam ser confiáveis. Quando a empresa diz "não estamos prontos para operar com copiloto", ela está, na prática, dizendo: nosso dado e nossos processos não sustentam automação.
E os 46% que pediriam mais tempo e verba completam o quadro. O problema não é convicção. É capacidade de execução simultânea.
2. Por que o Joule cai do escopo mesmo já vindo incluído na licença
A economia de um projeto de migração explica a mecânica. Uma transição ECC → S/4HANA consome, tipicamente, todo o time funcional e boa parte do time técnico por 12 a 24 meses. Há conversão de dado mestre, redesenho de processo (o famoso "clean core"), remediação de customizações Z, testes de regressão e um cutover que ninguém quer errar.
Nesse cenário, qualquer escopo que não seja bloqueante para o go-live vira candidato natural ao corte. E IA nunca é bloqueante para o go-live. O ERP entra no ar sem copiloto. Ninguém morre. O projeto é declarado sucesso.
O corte acontece por três razões que se reforçam:
- Banda do time. As mesmas pessoas que entendem o processo de faturamento são as que precisariam desenhar o caso de uso do copiloto. Elas estão 100% alocadas no core.
- Aversão a risco no cutover. Adicionar IA ao escopo do go-live aumenta a superfície de teste. O gerente de projeto, racionalmente, empurra para depois.
- Ilusão de reversibilidade. Todo mundo assume que dá para "ligar o Joule depois". E dá — tecnicamente. O problema é que as condições que fariam o Joule funcionar bem não são ligadas depois.
3. O custo real de adiar: você vai migrar duas vezes
A "fase 2" tem um custo que raramente aparece no business case, porque ele é um custo de retrabalho, não de projeto novo.
Quando a IA entra no escopo durante a migração, decisões estruturais são tomadas com ela em mente: quais campos de dado mestre precisam de qualidade garantida, quais eventos de negócio precisam ser publicados em tempo real, quais integrações precisam ser idempotentes, qual granularidade de log é necessária para auditar uma ação sugerida por IA. Essas decisões custam pouco na hora de tomar — e caro na hora de refazer.
Quando a IA entra depois, você descobre que:
- O dado mestre foi migrado "bom o suficiente para o ERP rodar", mas não bom o suficiente para uma IA raciocinar em cima dele. Duplicidade de cadastro que um humano contorna, um agente não contorna.
- As integrações com e-commerce, WMS e fiscal foram feitas em batch, porque batch bastava para o processo atual. O copiloto precisa de estado atual, não de estado de ontem.
- Não há barramento de eventos. Cada consulta do copiloto vira uma chamada síncrona ao ERP — e o time de Basis vem cobrar explicações sobre a carga.
O resultado é uma segunda onda de projeto, com orçamento novo, para arrumar o que a primeira onda deixou meio pronto. É por isso que "fase 2" raramente tem data: não é uma continuação, é um novo projeto disfarçado.
4. O que a IA do ERP exige — e a migração normalmente não entrega
Se o Joule (ou qualquer copiloto de ERP) fosse um botão, ele já estaria ligado em 100% dos clientes RISE. Não é. Ele depende de uma fundação com três camadas:
Dado mestre confiável
Cliente, material, fornecedor, centro de custo. Não é sobre estar "migrado" — é sobre estar deduplicado, com regras de qualidade aplicadas e uma fonte de verdade definida. Um copiloto que encontra três cadastros do mesmo fornecedor não erra por burrice; erra porque a pergunta não tem resposta única.
Integrações estáveis e em tempo real
O ERP não vive sozinho. Ele conversa com e-commerce, WMS, TMS, fiscal, CRM, meios de pagamento. Se o estoque que o S/4HANA enxerga é atualizado por um job noturno, o copiloto vai sugerir ações sobre uma realidade que não existe mais. Aqui entram OData, iDocs, RFC — e a decisão, muitas vezes evitada, de expor eventos de negócio em vez de só expor tabelas.
Eventos e rastreabilidade
Quando o copiloto sugere (ou executa) uma ação, alguém vai precisar responder: com base em que dado? Em que momento? Quem aprovou? Sem uma trilha de eventos, IA no ERP é um risco de auditoria, não um ganho de produtividade. Esta é, invariavelmente, a camada que mais é cortada — porque não é bloqueante para o go-live.
Nenhuma dessas três camadas é "IA". Todas as três são engenharia de dados e integração. E todas as três são construídas mais barato durante a migração do que depois dela.
5. A saída que funciona: separar os times, não sequenciar as entregas
O erro de fundo do padrão "core agora, IA depois" é tratar como sequencial algo que é paralelo. Migrar o core e construir a camada de integração/dados são trabalhos com dependências diferentes, riscos diferentes e — crucialmente — perfis de engenheiro diferentes.
O consultor funcional de SAP que redesenha o processo de vendas não é a mesma pessoa que constrói um consumidor Kafka idempotente. Colocar os dois trabalhos na mesma fila do mesmo time é o que cria a falsa escolha entre ERP e IA.
Quem separa os times entrega as duas coisas no mesmo prazo. Quem não separa entrega uma — e agenda a outra para um trimestre que não chega.
6. Como a CCX ajuda: a camada de integrações que o core não tem banda para fazer
A CCX atua exatamente na camada que costuma cair do escopo. Nossa prática de Integrações & APIs Enterprise cobre conectividade em tempo real entre ERP e o resto do negócio: SAP ↔ e-commerce e Protheus ↔ e-commerce, com expertise em OData, iDocs e RFC, sincronizando estoque, preço, pedido e nota fiscal — e arquitetura event-driven com Kafka ou RabbitMQ quando o volume ou a criticidade exigem desacoplamento e garantia de entrega.
O modelo de engajamento que resolve o problema de banda é a squad dedicada: engenheiros sêniores (média de 10+ anos), com onboarding em 48h e escala elástica. A squad assume a frente de integrações e dados em paralelo, enquanto o seu time interno — que conhece o processo, e é insubstituível nisso — permanece focado no core da migração.
Não é uma escolha entre migrar e habilitar IA. É uma escolha entre fazer as duas coisas em paralelo com times distintos, ou fazer uma e adiar a outra indefinidamente. Migrar o ERP e habilitar IA não precisam competir pelo mesmo time.
Integrar SAP ao seu e-commerce →
7. FAQ
O que é o SAP Joule?
É o copiloto de IA generativa da SAP, embutido nas aplicações do ecossistema (S/4HANA, SuccessFactors, Ariba, entre outras). Ele interpreta pedidos em linguagem natural, consulta dados do ERP e pode propor ou executar ações dentro dos processos de negócio, respeitando as permissões do usuário.
O Joule está incluído na licença RISE with SAP?
O acesso ao Joule vem contemplado nas ofertas RISE — é um dos argumentos comerciais do pacote. Na prática, isso significa que o obstáculo à adoção quase nunca é o custo de licença, e quase sempre é a prontidão de dados, processos e integrações do cliente.
Por que 6 em 10 empresas não se sentem prontas?
Segundo o levantamento da Horváth, as empresas em transição para o S/4HANA não se consideram "ágeis, eficientes e flexíveis o bastante" para operar o ERP com copiloto — e 46% dizem que precisariam de mais tempo e orçamento. É um diagnóstico de capacidade organizacional: processos não padronizados, dado mestre com qualidade irregular e integrações em batch não sustentam automação assistida por IA.
Dá para ligar a IA depois que a migração terminar?
Tecnicamente, sim. Economicamente, é mais caro. As decisões que fazem o copiloto funcionar bem — qualidade de dado mestre, integrações em tempo real, publicação de eventos, trilha de auditoria — são baratas de tomar durante a migração e caras de refazer depois, porque implicam mexer em algo que já está em produção.
Qual é o primeiro passo para não deixar a IA fora do escopo?
Mapear, ainda na fase de desenho, quais casos de uso de IA a empresa quer nos primeiros 12 meses pós-go-live — e derivar dali os requisitos de dado, integração e evento. Depois, alocar esses requisitos a um time separado do time do core. O objetivo não é entregar IA no go-live; é entregar um ERP que suporta IA no go-live.