Alkemia · Enterprise Apps Strategy

Por que programas de SAP Cloud ERP falham
e a maioria das respostas está antes da assinatura do contrato.

A falha aparece na entrega e é explicada por ela. Mas a rota escolhida contra a cultura que a organização tem, o integrador selecionado sobre alegações que ninguém conferiu e o escopo que entrou como marcador de posição já estavam no material da proposta. São sinais legíveis na qualificação, e a qualificação é a primeira fase a ser cortada quando o calendário aperta, porque é a única que não produz entregável visível.
Para quem vai decidir rota, integrador e contrato de um programa de Cloud ERP
O que a fase pré-assinatura decide

A entrega controla execução: cronograma, equipe, qualidade de dado, gestão de mudança. O que ela herda foi decidido antes de existir, e não é revisável de dentro dela. Herda a rota, e com ela o volume de redesenho de processo que a organização vai ter que absorver. Herda o integrador, seu perfil de senioridade e seu modo de falha característico. Herda o escopo que o pedido assinado congelou. Herda o modelo de operação do fornecedor e as obrigações que o contrato distribuiu. Um programa bem executado sobre heranças ruins produz exatamente o que as heranças permitem.

Duas coisas diferentes

O que a entrega controla, e o que ela recebe pronto.

Sob controle da entrega

Execução

Plano de cutover, qualidade e reconciliação de dados, treinamento de usuário, ritmo de testes, remediação de código, validação de processo pelos donos de negócio.

É aqui que a maior parte da atenção executiva se concentra, e é aqui que o programa é julgado quando dá errado.

Recebido pronto

Herança

Rota de migração, integrador e o modo de falha do perfil escolhido, escopo congelado no pedido, marcos de provisionamento, modelo de operação do fornecedor, fronteira de responsabilidade entre fornecedor e integrador.

Cada item aqui teve sinal legível antes da assinatura, e depois dela passa a ser restrição, avaliada sem alternativa do outro lado.

Onde o desvio começa

O desvio começa antes da entrega, na fase em que a rota é escolhida.

A pesquisa publicada mede o desvio dessa classe de programa. No estudo Business Transformation Unlocked, da Horváth, com 200 empresas usuárias de SAP com receita anual a partir de 200 milhões de euros, na região DACH, em países selecionados do Norte e do Leste da Europa e nos Estados Unidos, com campo no primeiro trimestre de 2025, os programas de S/4HANA correm em média 30 por cento mais que o planejado, um quarto das organizações estourou muito o orçamento e outros 40 por cento estouraram fortemente, e 65 por cento relatam déficits de qualidade fortes a muito fortes. Entre as causas que os próprios respondentes citam estão a expansão de escopo durante o projeto e os loops de revisão de conceitos e processos, que é a forma que a disputa de redesenho assume depois que a entrega já começou.

Os autores do mesmo estudo localizam a origem antes da entrega. Escrevem que a base de boa parte dos problemas já é lançada no setup do programa, onde o planejamento inadequado e a consideração insuficiente da abordagem de transformação adequada à situação atual sobrecarregam a organização, com a complexidade subestimada e a competência organizacional superestimada. Do lado do cliente, a pesquisa Pulse of the SAP Customer 2025, da ASUG, com 787 membros consultados em novembro de 2024, coloca a mudança para o S/4HANA como o desafio número um mais citado, 26 por cento, contra 10 por cento de orçamento. Nenhum dos dois estudos cobre a América Latina, e nenhum mede o desfecho condicionado ao descasamento entre rota e organização. O que eles estabelecem é a classe e a atribuição.

O que torna esse custo evitável é a ordem. A pergunta sobre apetite de redesenho de processo é respondível em poucas conversas executivas, e a resposta é um insumo da escolha de rota. Feita na ordem inversa, a rota é escolhida primeiro e a organização descobre o próprio apetite durante os workshops, com o contrato já assinado.

Para quem parte do ECC, a pressão de calendário que corta essa fase vem de datas que a própria SAP publica. Nas aplicações centrais do SAP Business Suite 7 (a geração on-premise anterior ao S/4HANA, da qual faz parte o SAP ERP 6.0, o ECC), a manutenção mainstream vai até o fim de 2027, e a estendida opcional, com prêmio de dois pontos percentuais sobre a base de manutenção, até o fim de 2030, ambas limitadas aos três enhancement packages (EHP) mais recentes de cada aplicação. A opção de transição SAP ERP, private edition, oferece uma subscrição de continuidade entre 2031 e 2033 e exige migração para SAP ERP, private edition, em SAP HANA concluída antes do fim de 2030. O efeito dessas datas sobre o programa é indireto: elas encurtam a fase em que a rota ainda pode ser escolhida.

Os nove sinais

Nove classes de sinal, e o que cada uma produz depois.

A triagem que a Alkemia roda na qualificação cobre nove categorias. Abaixo estão as categorias e a consequência que cada uma prevê. As perguntas que produzem o diagnóstico, o peso de cada achado e o critério de escalonamento fazem parte do método e ficam fora desta página.

  • A

    A rota, contra a cultura que a organização realmente tem

    A abordagem de migração é escolhida numa conversa. A capacidade de executá-la é outra pergunta, e quase nunca é feita.

    Uma organização acostumada a preservar processo, colocada dentro de uma entrega que exige redesenhá-lo, entra em disputa logo nos primeiros workshops. A disputa aparece como calendário que escorrega e escopo que volta para a mesa.

    O que produz depois: A pesquisa publicada atribui esse desvio à fase em que a rota é escolhida. No estudo Business Transformation Unlocked, da Horváth, com 200 empresas usuárias de SAP com receita anual a partir de 200 milhões de euros, na região DACH, em países selecionados do Norte e do Leste da Europa e nos Estados Unidos, com campo no primeiro trimestre de 2025, os programas de S/4HANA correm em média 30 por cento mais que o planejado, e entre as causas que os próprios respondentes citam estão a expansão de escopo durante o projeto e os loops de revisão de conceitos e processos.

  • B

    O integrador, e a base sobre a qual ele foi escolhido

    Depois da assinatura, quem executa é o integrador, e é ali que custo e risco de entrega se concentram. A escolha se faz sobre alegações que chegam numa proposta.

    Cada perfil de integrador tem uma força e um modo de falha próprio: o integrador global entrega escala e depois troca a equipe sênior da descoberta por uma equipe júnior na execução; o regional entrega proximidade e depende de um sênior que pode ser puxado para outro negócio; a boutique entrega profundidade e vira gargalo quando o rollout cresce. Nenhum é melhor, e escolher sem nomear o modo de falha é escolher no escuro.

    O que produz depois: Governança de integrador sem dono. Quando a resposta para quem decide entrar em produção com achado em aberto é o próprio integrador que executa, a decisão de go-live foi terceirizada para quem tem interesse nela.

  • C

    O relógio que começa antes de o ambiente existir

    Data de assinatura, data de início da subscrição e data de provisionamento são três datas diferentes, e o contrato trata as duas primeiras como se fossem a mesma.

    A cobrança chega na data contratual. O ambiente costuma não existir nessa data. Em negócios complexos o provisionamento se estende por 30 a 60 dias ou mais, e o relógio real só começa quando um formulário de onboarding é preenchido, o que acontece depois da assinatura.

    O que produz depois: O cronograma do business case escorrega pela duração do atraso, e esse escorregão se propaga para cada entregável ancorado nele. A finança do cliente registra custo contra um serviço que ainda não pode ser usado.

  • D

    O escopo que entrou como marcador de posição

    Entidades legais declaradas como "todas as do grupo", pontos de integração ainda não inventariados, volume de documentos estimado e ainda não medido.

    Nada disso parece problema na fase de proposta. Um marcador de posição gera revisão, e a revisão acontece depois, quando já existe compromisso.

    O que produz depois: A lista de materiais infla entre a versão preliminar e o pedido assinado, e a diferença aparece como custo que ninguém aprovou, dentro de um orçamento que já foi defendido internamente.

  • E

    O modelo de operação que o cliente presume

    A expectativa sobre o serviço gerenciado do fornecedor, contra o modelo que esse serviço realmente pratica.

    Uma organização que espera reunião diária com a liderança de entrega do fornecedor, e recebe um modelo baseado em chamado com trilha de escalonamento publicada, descobre a diferença no primeiro incidente. E uma área de TI que não separa as obrigações de operação do fornecedor das obrigações de configuração funcional do integrador vai cobrar a pessoa errada.

    O que produz depois: O atrito de relacionamento nos primeiros noventa dias depois da assinatura costuma nascer aqui, justamente na janela em que o programa precisa de cooperação para andar.

  • F

    A postura jurídica e de compras

    Quando compras entra na conversa, e se o jurídico já viu um contrato de nuvem antes ou só contratos de licença on-premise.

    São dois instrumentos diferentes, com lógicas diferentes de obrigação, medição e saída. Um time jurídico competente em licenciamento perpétuo revisa um contrato de subscrição procurando as cláusulas erradas.

    O que produz depois: A negociação trava perto do fim, sob pressão de calendário, ou pior: fecha no prazo e produz obrigações pós-assinatura que ninguém consegue fazer valer quando precisa.

  • G

    A métrica de licença, e o que decide qual delas se aplica

    O contrato mede consumo por mais de uma métrica, e o que decide qual vale numa integração é um detalhe técnico que a proposta não discute.

    As regras estão publicadas pelo fornecedor e quase nunca são lidas contra a arquitetura que o cliente realmente opera. A métrica é decidida pela identidade que chega ao núcleo e pelo caminho por onde o documento é criado, de modo que duas integrações com o mesmo resultado de negócio caem em métricas diferentes quando esses dois elementos diferem. A proposta descreve o resultado. O caminho fica na arquitetura, que ninguém anexa.

    O que produz depois: A conta chega depois, com a integração já em produção, quando trocar o caminho custa mais do que teria custado escolhê-lo. O relatório de estimativa do fornecedor não fecha a questão: ele conta registros que existem hoje, e a licença mede documentos criados no período, então as duas fontes de erro empurram em direções opostas.

  • H

    A exposição técnica que já está nos relatórios do próprio cliente

    Os relatórios que dimensionam a conversão saem do sistema do cliente e existem antes da assinatura. Quase sempre só o resumo é lido.

    Um agregado perde informação exatamente onde a exposição específica mora: uma contagem de objetos não carrega qual processo, qual tabela ou qual obrigação regulatória está em risco. Quem lê só o sumário herda a cegueira de quem o gerou, e apresenta isso como cobertura.

    O que produz depois: O dimensionamento entra no contrato calibrado por um número que ninguém abriu. Quando o agregado e o texto do relatório discordam, essa divergência era o achado, e ela aparece com o escopo já fixado.

  • I

    A fronteira entre quem faz o quê, e o que disso está na taxa

    Cada tarefa de operação responde a duas perguntas independentes: está dentro da taxa, e quem tem direito de executá-la.

    As duas respostas não andam juntas. Existe tarefa incluída e executada pelo fornecedor, tarefa que só o cliente pode executar, tarefa de custo adicional que só o fornecedor executa, e tarefa de custo adicional em que o cliente escolhe quem faz. Parte delas só existe se estiver escrita no documento comercial, e o que não está escrito não foi contratado.

    O que produz depois: A descoberta acontece no primeiro incidente que ninguém tem obrigação de atender, ou na primeira fatura por um serviço que o cliente presumia incluído. Nos dois casos a resposta já estava no contrato assinado.

Um sinal isolado raramente inviabiliza um programa. O que decide é a acumulação e a distribuição deles entre categorias.

O integrador, em detalhe

Três alegações que não sobrevivem ao registro público.

  • 01

    Certificado, alocado e designado são três populações diferentes

    As pessoas que o fornecedor certifica são um conjunto. As que uma proposta conta como consultores são um conjunto maior, que inclui perfis não certificados e adjacentes. As que ficam nomeadas no contrato de serviço do cliente são um conjunto bem menor, tirado de um dos dois. A proposta cita o maior dos três, e o cliente escuta o menor.

  • 02

    Competência global, com zero engajamento no país do cliente

    Um integrador pode ter competência genuína no nível mais alto da escala do fornecedor, com contagem expressiva de engajamentos, e ter zero engajamento registrado no país do cliente. A capacidade existe e pode ser trazida de fora, o que transforma a alegação em quatro perguntas distintas: de alocação, de idioma, de tarifa e de continuidade.

  • 03

    A entidade que assina pode ser mais nova que o histórico apresentado

    A entidade que executa o contrato pode não ser a entidade cuja capacidade foi apresentada. Quando ela é mais nova do que o histórico que a proposta reivindica, esse histórico pertence a outra pessoa jurídica e não viaja junto com o contrato. É uma verificação de minutos que muda uma decisão de anos.

A proposta é o único registro do processo escrito para o cliente ler. Existem outros, que não foram escritos para essa finalidade, e a divergência entre eles é o achado. Ela é sistemática: corre numa direção só, e é maior exatamente nas alegações que o cliente não consegue conferir sem ajuda.

Um programa bem executado sobre heranças ruins entrega exatamente o que as heranças permitem.

Alexandre Pereira

O próximo passo

Ler os sinais enquanto eles ainda são reversíveis.

Para o patrocinador executivo que responde pelo programa, para o CFO que responde pelo compromisso plurianual e para o CIO que responde pela arquitetura, a pergunta operacional é: das nove categorias, quantas já têm sinal no material que está na mesa hoje. Uma conversa de 30 minutos, sem compromisso, é suficiente para identificar quais categorias merecem verificação e quais dependem de evidência que ainda não foi pedida. Se a conclusão for que o programa está bem posicionado, essa também é uma resposta útil. O melhor momento para fazer isso é antes da assinatura. O segundo melhor é antes do go-live. O terceiro é hoje.

Falar da sua decisão

contact@alkemia.io

Quando o trabalho precisa ir além da conversa, o ponto de entrada é o diagnóstico pré-assinatura.

O contrato em si, e o que nele fixa o custo ao longo do prazo, está em seis decisões antes de assinar.

Perguntas frequentes

Falha de programa, em termos de decisão.

Por que programas de ERP falham?
A falha aparece na entrega e costuma ser explicada por ela: dados sujos, treinamento insuficiente, gestão de mudança fraca. Boa parte dessas causas já tinha sinal antes da assinatura. A rota de migração escolhida contra a cultura que a organização tem, o integrador selecionado sobre alegações que ninguém verificou, o escopo que entrou como marcador de posição, o relógio contratual que começa antes de o ambiente existir. Esses sinais são legíveis na fase de qualificação, e essa é a fase que o cronograma corta primeiro, porque é a única que não produz entregável visível.
Qual é o custo de escolher a rota errada?
Nenhum estudo público mede o desfecho condicionado a esse descasamento específico. O que existe é o perfil de desvio da classe inteira. No estudo Business Transformation Unlocked, da Horváth, com 200 empresas usuárias de SAP com receita anual a partir de 200 milhões de euros, na região DACH, em países selecionados do Norte e do Leste da Europa e nos Estados Unidos, com campo no primeiro trimestre de 2025, os programas de S/4HANA correm em média 30 por cento mais que o planejado, um quarto das organizações estourou muito o orçamento e outros 40 por cento estouraram fortemente, e 65 por cento relatam déficits de qualidade fortes a muito fortes. Os autores localizam a origem no setup do programa e nomeiam entre as causas a consideração insuficiente da abordagem de transformação adequada à situação atual da organização. Nenhum desses estudos cobre a América Latina.
Como se verifica um parceiro de implementação de verdade?
A proposta é o único registro do processo escrito para o cliente ler. Existem outros registros públicos que não foram escritos para essa finalidade, e a divergência entre eles é o achado. Essa divergência é sistemática: corre numa direção só, e é maior exatamente nas alegações que o cliente não tem como conferir sozinho, como contagem de consultores certificados por solução, presença no país e identidade da entidade que assina. Verificar é atividade de qualificação, feita sobre a lista curta, e o resultado muda tanto a escolha quanto as proteções que o cliente leva para a negociação.
Isso não é trabalho do integrador ou do fornecedor?
Os dois têm interesse legítimo no fechamento do negócio, e nenhum dos dois é parte neutra na escolha do outro. O integrador não avalia a própria seleção, e o fornecedor não arbitra a capacidade de entrega do integrador que revende o seu produto. A leitura independente existe por causa dessa assimetria, que permanece mesmo quando todos agem de boa-fé.
Já assinamos. Ainda vale olhar isso?
Vale, e a pergunta muda. Antes da assinatura o objetivo é escolher e proteger; depois, é descobrir o que ficou exposto e o que ainda tem alavanca. O que sobra se divide em dois. A parte operacional não exige reabrir o contrato: designar dono para as obrigações que o contrato criou e ninguém assumiu, instalar a governança do integrador, acompanhar os marcos de provisionamento. O que toca prazo, métrica ou preço só se corrige reabrindo o contrato, e reabrir tem preço. Fazer essa separação cedo é o que mantém mais coisa do lado barato.
Por que a fase pré-assinatura é sempre a cortada?
Porque ela não produz entregável visível e disputa calendário com uma data que já foi comunicada. A pressão de prazo tem origem real: a manutenção mainstream das aplicações centrais do SAP Business Suite 7 (a geração on-premise anterior ao S/4HANA, da qual faz parte o SAP ERP 6.0, o ECC) vai até o fim de 2027, e a estendida opcional, com prêmio de dois pontos percentuais sobre a base de manutenção, até o fim de 2030, ambas limitadas aos três enhancement packages mais recentes de cada aplicação. A opção de transição SAP ERP, private edition, oferece uma subscrição de continuidade entre 2031 e 2033 e exige migração para SAP ERP, private edition, em SAP HANA concluída antes do fim de 2030. O efeito dessas datas sobre o programa é indireto: elas encurtam a fase em que a rota ainda pode ser escolhida.

Os padrões descritos aqui vêm de observação advisory num escopo declarado, e valem como hipótese calibrada a esse escopo. Antes de agir, vale validar cada categoria contra a realidade do próprio programa, do próprio setor e da própria região.

SAP e os nomes de produtos SAP são marcas da SAP SE ou de suas afiliadas. A Alkemia é uma consultoria independente, sem afiliação, endosso ou representação da SAP, e não é integradora de implementação: não concorre, não vende e não entrega o projeto de implementação. Este material é informativo, descreve padrões em termos gerais e não constitui assessoria jurídica nem avaliação de nenhum fornecedor ou integrador específico. As datas de manutenção refletem posições publicadas pela SAP e consultadas em agosto de 2026.