Quanto custa implementar SAP? O que realmente define o investimento

É a primeira pergunta de toda diretoria e a que nenhum fornecedor sério responde de imediato: quanto custa implementar SAP?

A resposta honesta é que não existe tabela. Mas existe algo mais útil do que um número solto: entender como o investimento se compõe e o que faz ele variar. Com isso, você consegue avaliar se uma proposta é razoável e, principalmente, identificar o que ficou de fora dela.

As quatro camadas de custo

1. Licenciamento

O que você paga à SAP pelo direito de usar o software. Varia conforme o modelo — licença perpétua com manutenção anual, subscrição, ou contratos como o RISE with SAP, que empacotam software e infraestrutura.

O que mais influencia: número e tipo de usuários, módulos contratados e, em modelos mais recentes, métricas de consumo ligadas ao volume de operação. Vale saber que tipos diferentes de usuário têm preços muito diferentes — dimensionar isso corretamente evita pagar licença completa para quem só consulta relatório.

2. Infraestrutura

Onde o sistema roda. On-premise significa servidor, storage, licença de banco e equipe para operar. Nuvem privada ou pública transforma esse custo em mensalidade, com a vantagem de elasticidade e a desvantagem de ser recorrente para sempre.

O erro comum aqui é comparar CAPEX com OPEX sem trazer os dois para o mesmo horizonte de tempo. Uma comparação honesta olha o custo total em cinco anos, incluindo renovação de hardware e custo de equipe de infraestrutura.

3. Consultoria de implementação

Geralmente a maior linha do orçamento. É o time que desenha, configura, desenvolve, testa e coloca no ar. O custo é função direta do esforço em horas, e o esforço é função de:

• Escopo funcional: quantos módulos e quantos processos entram
• Rota escolhida: Greenfield custa mais em consultoria que Brownfield
• Volume de desenvolvimento: cada objeto customizado é especificação, código, teste
• Número de integrações: cada interface é análise, construção e ciclo de teste
• Quantidade de empresas e países: cada localização fiscal adiciona complexidade real

4. Custo interno — a linha que some das propostas

Esta é a camada que quase nunca aparece no orçamento e que frequentemente é a segunda maior. Seu time precisa participar do projeto: key users em workshops, área de negócio validando processo, TI dando suporte a ambiente, alguém limpando dado mestre.

Se essas pessoas continuarem com cem por cento das responsabilidades atuais, uma de duas coisas acontece: o projeto atrasa ou a operação sofre. Projetos que dão certo alocam formalmente essas pessoas, e isso tem custo — de backfill, de hora extra ou de produtividade adiada.

O que faz o preço variar mais

Na nossa experiência, três variáveis explicam a maior parte da diferença entre um projeto caro e um projeto barato de escopo aparentemente igual:

Passivo técnico não mapeado. Um ambiente com muita customização desconhecida gera descoberta contínua durante o projeto. Cada descoberta vira análise não prevista. É a principal origem de aditivo.

Qualidade dos dados. Migração de dados costuma ser orçada como atividade técnica. Quando a base está suja, ela vira projeto de negócio dentro do projeto — e projeto dentro de projeto sempre estoura.

Governança de decisão. Projeto onde a decisão trava por semanas consome horas de consultoria em espera. Você paga o time para aguardar. É custo invisível e é grande.

Como avaliar uma proposta

Peça que a proposta explicite:

1. A premissa de volume: quantos objetos customizados, quantas interfaces, quantas

empresas e quantos usuários estão dentro do preço

1. O que acontece se o volume real for maior — e a que preço unitário
2. Quantos ciclos de teste estão inclusos
3. A duração do hypercare pós go-live e o que ele cobre
4. A composição do time por senioridade e alocação
5. O que é responsabilidade do cliente: limpeza de dados, disponibilidade de key

users, provisão de ambiente

Uma proposta que não responde a esses seis pontos não é comparável a nenhuma outra. Duas propostas com valores muito diferentes quase sempre estão orçando escopos diferentes — e a mais barata costuma ser a que assumiu premissas mais otimistas.

Sobre o projeto barato demais

Existe um padrão que se repete no mercado brasileiro. A proposta mais barata ganha, o projeto começa, e no terceiro mês aparece o primeiro aditivo. No sexto, o segundo. No fim, o total supera a proposta mais cara que foi descartada no início — com a diferença de que agora existe um projeto atrasado e um relacionamento desgastado.

Isso raramente é má-fé. É consequência de orçar sem conhecer o ambiente. O antídoto é o mesmo em qualquer cenário: inventário antes de orçamento.

Um assessment de readiness custa uma fração do projeto, leva poucas semanas e produz os números que tornam qualquer proposta comparável. É o investimento com melhor retorno em todo o ciclo de um projeto SAP.