A onda de modernização de ERP no Brasil não desacelerou. A Britânia anunciou a adoção do S/4HANA na nuvem privada (SAP Cloud ERP Private), e a SAP reportou a maior adoção de Cloud ERP com IA na América Latina no terceiro trimestre de 2026. Adotar o cloud ERP é um ótimo passo — mas há um descompasso de calendário que o varejista sente na pele: migrar o core é um projeto de meses, e o pico de vendas é em 23 dias.
E agora soma-se um efeito novo. Se a IA acelera e qualifica a demanda — o cliente chega decidido, o agente fecha mais rápido —, mais pedido bate no core por minuto, justamente quando ele costuma estar em code-freeze. O que decide se a venda acontece no pico não é o roadmap da migração nem o módulo de IA recém-adotado: é a integração entre o SAP e o e-commerce, que precisa absorver essa rajada e transformar cada pedido em venda e nota, sem travar.
A onda de cloud ERP no Brasil
A adoção de S/4HANA em nuvem — privada ou pública — é parte de um movimento maior de saída do ECC e de busca por elasticidade, atualização contínua e IA embarcada. O caso Britânia e os números da SAP na LatAm confirmam que a direção está definida. Para quem vende, isso é bom no médio prazo: um core mais moderno tende a operar melhor. O problema é o curto prazo, e o curto prazo tem data marcada.
O descompasso de calendário: migrar leva meses, o pico é em 23 dias
Migração de ERP é projeto plurianual na prática: desenho, parametrização, testes, cutover, estabilização. A Black Friday não espera esse cronograma. O resultado comum é um core em transição — parte no novo, parte no antigo, com janelas de congelamento — chegando ao pico com pouca margem para mudanças. É saudável congelar o core no pico; o risco não está no freeze em si, e sim em depender do core para absorver cada oscilação de volume.
A IA acelera a demanda: mais pedido por minuto batendo no core
Aqui os temas da semana se encontram. Se o cliente já chega decidido por uma IA e o agente fecha mais rápido (os dados de Acquia e Visa apontam exatamente isso), o padrão de chegada de pedidos muda: picos mais agudos, concentrados nos minutos de maior tração. Um core em freeze, no meio de uma migração, não foi desenhado para ser a fila de entrada dessa rajada. Ele foi desenhado para processar com consistência — no ritmo dele.
O freeze e o risco: integração que trava = pedido que não vira venda nem nota
É no elo entre o e-commerce e o SAP que a venda se concretiza (ou se perde). Se a integração é síncrona e acoplada, cada pedido espera o core responder; quando o volume sobe, forma-se back-pressure, a fila estoura e pedidos se perdem ou duplicam. O cliente comprou, mas o pedido não entrou — e a nota não sai. No pico, isso não é incômodo: é receita evaporando em tempo real e passivo fiscal se acumulando para depois.
A saída é arquitetural, não heroica. Uma integração desacoplada e orientada a eventos coloca um buffer entre a venda e o core: o e-commerce aceita o pedido e publica um evento; uma fila (Kafka ou RabbitMQ) segura a rajada; o SAP consome no ritmo que aguenta, com retry automático em falhas transitórias. A loja nunca fica refém do tempo de resposta do ERP, e nenhum pedido se perde porque o core estava ocupado.
Como funciona, passo a passo, uma integração desacoplada
Vale descer um nível para ver por que o padrão event-driven resolve o problema do pico. Em uma arquitetura acoplada, o e-commerce chama o SAP de forma síncrona a cada pedido e espera a resposta; se o core está lento ou congelado, a loja trava junto. No padrão desacoplado, o fluxo se inverte:
- Captura — o e-commerce aceita o pedido e publica um evento ("pedido criado") numa fila (Kafka ou RabbitMQ). A resposta ao cliente não depende do SAP.
- Buffer — a fila absorve a rajada. Se chegam mil pedidos por minuto e o core processa duzentos, os oitocentos restantes esperam ordenadamente, sem se perder.
- Consumo no ritmo do core — um worker entrega os pedidos ao SAP via OData, iDoc ou RFC na velocidade que o ERP aguenta, respeitando o freeze.
- Retry e idempotência — falhas transitórias (timeout, indisponibilidade momentânea) são re-tentadas automaticamente, e cada pedido tem uma chave única para nunca ser processado em duplicidade.
- Confirmação — quando o SAP processa, um evento de volta atualiza o status na loja e dispara a emissão da nota. O ciclo fecha sem que a loja tenha ficado refém do core em nenhum instante.
É esse desenho que transforma um pico imprevisível em uma carga que o ERP processa com consistência — inclusive no meio de uma migração.
O que monitorar no pico
Integração desacoplada só é confiável se você consegue enxergar o que acontece dentro dela em tempo real. Três sinais merecem um painel dedicado durante a Black Friday: o tamanho e a idade da fila (back-pressure crescendo é o primeiro aviso de que o core não está acompanhando), a taxa de retry e de erro por tipo de pedido (para distinguir uma falha transitória de um problema estrutural) e o lag entre a venda e a nota (quanto tempo um pedido leva da captura à confirmação no SAP). Ver esses números antes que virem pedido perdido é a diferença entre ajustar a vazão e descobrir o prejuízo no fechamento.
Como a CCX mantém a integração SAP ↔ e-commerce desacoplada
É exatamente esse padrão que a CCX implementa na oferta de Integrações & APIs Enterprise aplicada ao mundo SAP. A integração SAP ↔ e-commerce (e também Protheus ↔ e-commerce) é construída de forma desacoplada, com OData, iDoc e RFC na borda do ERP e arquitetura event-driven com Kafka/RabbitMQ, buffer e retry no meio — para que o pico seja absorvido pela fila, e não pelo core em freeze. Cada pedido vira venda e nota no ritmo seguro do SAP, sem travar a loja.
Em volta disso, a Consultoria em Tecnologia desenha a arquitetura-alvo da integração durante e depois da migração (diagnóstico, arquitetura-alvo, roadmap), e a Observabilidade 360° (com Datadog, Grafana, Prometheus e tracing distribuído) deixa visível, em tempo real, se há back-pressure ou fila crescendo — antes que vire pedido perdido.
Adotar o S/4HANA na nuvem é o passo 1. Fazer esse core vender no minuto de maior volume é a integração que absorve a rajada e transforma cada pedido em venda e nota. Integrar SAP ao seu e-commerce →
Perguntas frequentes
Dá pra integrar o S/4HANA com o e-commerce sem mexer no core?
Sim. A integração desacoplada vive na borda e numa camada intermediária de eventos; o core expõe interfaces padrão (OData, iDoc, RFC) e consome pedidos no ritmo dele. Não é preciso alterar a lógica interna do ERP para absorver o pico.
O que é back-pressure na integração de ERP?
É o acúmulo de pressão quando a produção de pedidos (o e-commerce no pico) é mais rápida do que o consumo (o ERP processando). Sem um buffer, essa pressão estoura filas e causa perda ou duplicação. Uma fila com retry absorve a pressão e normaliza o fluxo.
É seguro fazer code-freeze no SAP durante a Black Friday?
Sim, e é recomendável. O ponto não é evitar o freeze, e sim não depender do core para absorver oscilações. Com integração desacoplada, você congela o ERP com tranquilidade porque a fila segura a rajada e o core processa quando pode.
Migrei agora para a nuvem — isso já resolve o pico?
A migração moderniza o core, mas não garante, por si só, que o pico seja absorvido sem travar. Quem decide isso é a camada de integração entre a venda e o ERP. É ela que transforma pedido acelerado em venda e nota no momento de maior volume.
Kafka ou RabbitMQ: qual usar na integração do pico?
Ambos servem como buffer entre a venda e o core; a escolha depende do perfil da carga e do ecossistema. RabbitMQ brilha em roteamento de mensagens e filas de trabalho com confirmação; Kafka brilha em alto throughput e retenção de eventos para reprocessamento. O que importa mais que a ferramenta é o padrão: desacoplar, bufferizar e consumir com retry e idempotência.
E se a integração falhar no meio do pico?
Com o padrão desacoplado, uma falha transitória não derruba a venda: o pedido fica na fila e é re-tentado. Falhas estruturais ficam visíveis pelos sinais de observabilidade (fila crescendo, erros por tipo), permitindo intervir sobre a vazão sem perder o que já entrou. O pior cenário — pedido aceito pelo cliente e perdido antes de chegar ao ERP — é justamente o que o buffer evita.