Por que projetos SAP estouram o orçamento e como evitar

Projetos SAP estouram o orçamento principalmente porque as empresas tentam manter o custo baixo no início e depois são atingidas na fase Explore, quando os workshops de Fit-to-Standard mostram o escopo real. Nos programas que revisei, estouros de 40 a 60 por cento são comuns.

Resposta curta: um orçamento SAP estoura quando foi definido antes de alguém conhecer o escopo, e quando quem controla esse escopo é o fornecedor, não o cliente. Acompanhe a contagem de WRICEF durante a fase Explore, seja dono do escopo e mantenha 10 a 20 por cento de contingência do seu lado.

As médias de pesquisas parecem mais tranquilas. O ERP Report 2026 da Panorama Consulting constatou que mais de um quarto das organizações ultrapassou o orçamento de ERP, tendo como principal causa necessidades adicionais de tecnologia. As médias de pesquisa e os programas que acabam na mesa de um consultor são populações diferentes, então planeje para a segunda.

40-60%

de estouro de orçamento que vejo com frequência nos programas SAP que reviso

Fonte: Noel D'Costa, observação publicada

Este artigo trata do estouro, não do número inicial. Para faixas de custo por porte de empresa, para onde vai o dinheiro, valores de diária e uma fórmula de orçamento, leia meu guia sobre quanto custa uma implementação SAP.

Em 21 programas SAP que liderei ou resgatei, as mesmas causas se repetem. A maioria delas é visível antes da assinatura do contrato.

1. O orçamento é definido baixo, depois o Explore mostra o escopo real

Esse é o motivo mais comum que vejo. As empresas tentam manter o custo baixo no início, muitas vezes porque o business case precisa de um número que o conselho aprove. Então chega a fase Explore.

No SAP Activate, o Explore é onde os workshops de Fit-to-Standard confrontam os processos padrão da SAP com a forma como o negócio realmente funciona (SAP Learning). Cada lacuna encontrada ali vira um item de backlog: um relatório, uma interface, uma conversão, uma melhoria, um formulário ou um workflow. Nenhum deles estava no preço original.

O orçamento não estava errado porque alguém errou uma conta. Estava errado porque foi definido antes de o escopo existir. Se puder, faça uma avaliação curta de Fit-to-Standard antes de aprovar o número final.

2. O fornecedor controla o escopo

O maior erro de custo que vejo antes da assinatura é permitir que o fornecedor controle o escopo. Quando o integrador de sistemas escreve o escopo, o escopo descreve o que o integrador pretende entregar, não o que o negócio precisa.

As lacunas aparecem depois como solicitações de mudança, e cada solicitação de mudança é precificada pelo mesmo fornecedor. Escreva o escopo você mesmo, ou peça a alguém independente da implementação que o escreva com você.

3. Mudanças de escopo sem controle de custo

Uma rede varejista orçou US$ 5 milhões e terminou em US$ 12,3 milhões. Um levantamento de requisitos fraco levou a mudanças constantes de escopo. No meio do caminho, a empresa descobriu que seus processos de estoque não batiam com a funcionalidade padrão do SAP, e veio uma customização extensa.

Ela também tinha subestimado a migração de dados dos sistemas legados. Alinhar os processos ao padrão já no desenho teria saído muito mais barato.

4. Cronogramas definidos por pressão executiva

Um programa industrial global estourou o orçamento em 143% (US$ 14 milhões contra US$ 5,8 milhões planejados) e entrou em operação com 11 meses de atraso. As causas: pressão irrealista de cronograma por parte dos executivos, uma equipe interna subdimensionada, módulos demais ao mesmo tempo e um parceiro de menor custo sem experiência no setor.

Mais barato não é automaticamente melhor. Um cliente que escolheu a opção de implementação de menor custo acabou gastando 30% a mais corrigindo problemas que uma equipe mais experiente teria evitado.

5. Pessoas internas em tempo parcial

Programas que designam representantes em tempo parcial em vez de donos de processo dedicados perdem dias em cada decisão. A equipe interna subdimensionada daquele programa industrial global foi uma das razões do atraso de 11 meses.

Suas melhores pessoas vão estar comprometidas com o programa por metade do tempo ou mais, durante meses. Nem o tempo delas nem a desaceleração em torno do go-live aparecem em uma cotação de fornecedor.

6. Dados descobertos tarde

Problemas de dados descobertos na pré-produção são os mais caros. O profiling deve acontecer junto com os requisitos, não depois da configuração. Três meses de limpeza sob a pressão do sistema produtivo são, de forma consistente, o maior item de custo de atraso nos programas que estouram.

Também falo sobre este tema em um vídeo no meu canal do YouTube (em inglês).

O sinal de alerta precoce mais claro é a própria fase Explore. Acompanhe a contagem de WRICEF: relatórios, interfaces, conversões, melhorias, formulários e workflows. Se essa lista continuar crescendo workshop após workshop, o orçamento já ficou para trás do escopo.

Os sinais abaixo apontam, cada um, para uma das causas acima. A maioria pode ser verificada em uma revisão semanal do programa.

Sinal de alerta	O que normalmente significa	O que fazer
Contagem de WRICEF crescendo ao longo do Explore	O escopo real é maior do que o escopo precificado	Refaça a linha de base do orçamento no fim do Explore, antes do início do Realize
Lacunas fechadas com "vamos construir" por padrão	Os processos padrão não estão sendo questionados	Peça ao dono do negócio que justifique cada lacuna em relação ao padrão
Documentos de escopo redigidos pelo integrador de sistemas	O fornecedor controla o que é precificado	Assuma o escopo e revise-o com alguém independente
Solicitações de mudança revisadas mensalmente ou sem preço	Pequenas mudanças se acumulam sem ninguém ver	Precifique cada solicitação de mudança e revise-as semanalmente
Profiling de dados não iniciado até o fim do Explore	Problemas de dados vão aparecer nos testes ou no cutover	Comece o profiling agora, junto com os requisitos
Key users ainda em tempo parcial	As decisões ficam lentas e o retrabalho cresce	Cubra as funções do dia a dia deles ou mude o cronograma

Cada um destes controles ataca uma das causas acima. As histórias são de programas em que trabalhei ou que revisei.

1. Seja dono do escopo. Escreva-o do lado do cliente, congele-o no fim do Explore e trate cada mudança posterior como uma decisão precificada, não como uma anotação de workshop.
2. Adote os processos padrão. Cada customização custa duas vezes: para construir e depois a cada upgrade. Um cliente industrial economizou mais de US$ 800 mil adaptando seus processos aos padrões SAP em vez de customizar. Foi doloroso para alguns departamentos, mas a diferença financeira foi enorme.
3. Divida o rollout em fases. Um cliente do varejo economizou US$ 1,2 milhão dividindo o rollout em três fases ao longo de 18 meses, em vez de fazer tudo de uma vez. O investimento inicial caiu 40%, e as lições da fase 1 tornaram as fases seguintes mais rápidas.
4. Pague por experiência, não por uma diária baixa. Um cliente do setor químico trocou um parceiro SAP generalista por um especialista no setor e gastou 20% menos no total, apesar de taxas horárias mais altas. Os especialistas trabalharam mais rápido e cometeram menos erros.
5. Mantenha a contingência do seu lado. Reserve 10 a 20 por cento além do orçamento, liberados apenas contra riscos nomeados. Contingência dentro do preço do parceiro é gasta nas prioridades do parceiro.
6. Revise as solicitações de mudança toda semana. Precifique cada uma pelo impacto em orçamento e cronograma antes de aprová-la, não no fim do mês.
7. Automatize os testes de regressão. Ferramentas como Tricentis Tosca ou a automação de testes da própria SAP se pagam em qualquer programa que rode mais de dois ciclos de teste, e cada upgrade depois do go-live é mais um ciclo.

Para o lado comercial, meu checklist de negociação de licenças SAP e a revisão de custos de contrato para CFOs mostram onde pressionar antes de assinar.

O modelo de assinatura desloca o gasto de capital para despesa operacional. Ele não elimina o risco de estouro, mas muda onde o risco fica.

O GROW with SAP roda no S/4HANA Cloud Public Edition, que só permite extensões por interfaces liberadas. Isso limita o quanto a lista de WRICEF pode crescer, e programas GROW costumam levar cerca de 6 a 9 meses. A contrapartida é menos liberdade para adaptar o SAP a processos incomuns.

O RISE with SAP roda no S/4HANA Cloud Private Edition, em que você ainda pode modificar o core. Ali, Clean Core é uma decisão de governança, não um limite técnico, então o risco da fase Explore é o mesmo do on-premise. Programas RISE normalmente levam de 9 a 18 meses, e o prazo de assinatura de vários anos precisa estar visível no business case.

AI é uma nova linha de orçamento, não uma economia para contar como certa. Alguns recursos do Joule vêm com as assinaturas de nuvem da SAP, enquanto recursos premium de AI são precificados à parte. Peça a premissa de produtividade por trás de qualquer tabela de preços de parceiro que prometa economias com AI.

Isso importa para a forma como um grande programa impacta a demonstração de resultados. Pelo IFRS e pelo US GAAP, os custos de construir um ativo que você controla podem ser capitalizados; os custos de operar, treinar e preparar não podem. A nuvem muda a resposta para uma grande fatia do orçamento.

Elemento de custo	Licença on-premise	Assinatura em nuvem (RISE / GROW)
Taxas de licença ou assinatura	Capitalizar como ativo intangível	Despesa ao longo do prazo (contrato de serviço)
Serviços de configuração e construção	Capitalizar se diretamente atribuíveis	IFRS: muitas vezes vão para despesa, a menos que criem um ativo separado que você controla. US GAAP: capitalizar os custos de implementação e amortizar ao longo do prazo de hospedagem
Mão de obra interna na construção	Capitalizar se diretamente atribuível	Mesma divisão acima
Treinamento e gestão de mudanças	Despesa	Despesa
Limpeza de dados	Despesa	Despesa
Ferramentas de conversão de dados que você mantém	Capitalizar se reutilizáveis	Avaliar caso a caso
Hypercare e suporte	Despesa	Despesa

A posição do IFRS vem da decisão de agenda de 2021 do IFRS Interpretations Committee sobre custos de configuração e customização em contratos de computação em nuvem. A posição do US GAAP vem da ASU 2018-15. Sobretudo pelo IFRS, um business case de RISE que assume a capitalização do on-premise pode superestimar de forma relevante o lucro do primeiro ano.

A documentação decide quanto você mantém. Um cliente industrial economizou US$ 2,3 milhões em despesas do exercício ao capitalizar corretamente, porque registrou as atividades dos consultores com cuidado suficiente para defender a abordagem. Outro cliente enfrentou uma reapresentação dolorosa porque não conseguiu comprovar suas decisões de capitalização.

Os auditores examinam com rigor grandes projetos capitalizados. Acorde a política com eles antes de o programa começar, não no fechamento do ano.

A maioria dos programas que estouram não teve uma falha de planejamento. Teve uma falha de honestidade na fase de planejamento. Um CFO que aprova um plano realista com a contingência adequada gasta menos do que um que aprova um plano otimista sem nenhuma.

Este guia faz parte do meu guia de implementação SAP, que reúne todos os temas, do business case ao go-live.

Por que implementações SAP estouram o orçamento?

Na maioria das vezes porque o orçamento é mantido baixo no início e depois a fase Explore mostra o escopo real. Os workshops de Fit-to-Standard transformam lacunas em relatórios, interfaces, conversões, melhorias, formulários e workflows que nunca foram precificados. Escopo controlado pelo fornecedor, equipes internas em tempo parcial e trabalho de dados tardio pioram o quadro.

Quanto os projetos SAP costumam estourar o orçamento?

Nos programas que revisei, estouros de 40 a 60 por cento são comuns. A pesquisa de 2026 da Panorama Consulting constatou que mais de um quarto das organizações ultrapassou o orçamento de ERP. Os programas que chegam a um consultor tendem a ser a cauda problemática dessa população.

Quais são os sinais de alerta precoce de um estouro de orçamento SAP?

O sinal mais claro é uma contagem de WRICEF que continua crescendo ao longo da fase Explore. Outros são documentos de escopo redigidos pelo fornecedor, solicitações de mudança que não são precificadas semanalmente, profiling de dados ainda não iniciado e key users ainda trabalhando em tempo parcial. Refaça a linha de base do orçamento no fim do Explore se a lista tiver crescido.

Como evitar o aumento descontrolado de escopo em um projeto SAP?

Seja dono do escopo do lado do cliente, em vez de deixar o integrador de sistemas escrevê-lo. Congele-o no fim do Explore, questione cada lacuna em relação ao SAP padrão e precifique cada solicitação de mudança antes de aprová-la. Revise as solicitações de mudança semanalmente, não no fim do mês.

O RISE with SAP reduz o risco de estourar o orçamento?

Não por si só. O RISE roda no Private Edition, em que o core ainda pode ser modificado, então o risco da fase Explore é o mesmo do on-premise. O GROW with SAP no Public Edition limita as extensões a interfaces liberadas, o que reduz o quanto o escopo pode crescer.

É possível capitalizar os custos de implementação do RISE with SAP?

Em parte, e depende do seu referencial contábil. A assinatura em si normalmente vai para despesa. Pelo IFRS, serviços de configuração e customização em um contrato SaaS muitas vezes também vão para despesa, a menos que criem um ativo separado que você controla; pelo US GAAP (ASU 2018-15), os custos de implementação são capitalizados e amortizados ao longo do prazo de hospedagem.