Como começar certo o seu projeto de implementação SAP

Para começar bem uma implementação SAP, defina cinco coisas antes que alguém configure uma transação. Escolha o modelo de implantação. Assine um termo de abertura com escopo e direitos de decisão. Nomeie donos de negócio que vão participar dos workshops de design. Comece cedo o trabalho de dados e de cutover. Monte um cronograma com contingência de verdade. Acerte isso no primeiro mês e a maior parte das falhas caras nunca acontece.

Sempre achei que, se o sistema fosse configurado corretamente, uma implementação SAP correria bem. Blueprint, construção, teste, go-live. Foi esse o modelo mental que segui por anos.

Implemento ERPs, incluindo SAP, há 25 anos no Oriente Médio, no Sudeste Asiático e na Europa. Mesmo quando as equipes seguiam o SAP Activate passo a passo, os projetos ainda tinham problemas. Quase nunca eram problemas técnicos. Responsabilidades mal definidas. Premissas que ninguém verificou. Planejamento de cutover que começou tarde demais. Essas rachaduras parecem inofensivas no começo. Depois que se espalham, esforço tardio não corrige o que a visibilidade antecipada teria evitado.

Uma implementação SAP é um programa de mudança de negócio com um componente de software. As frentes de trabalho são desenho de processos, configuração, migração de dados, integração, testes, treinamento e gestão de mudanças. Cada uma tem seu próprio cronograma, seus riscos e seu responsável.

As equipes que a tratam como um exercício de configuração subfinanciam tudo o que não é configuração. É a causa mais constante de go-lives difíceis que vejo.

Para um programa que começa agora, há mais uma frente a resolver primeiro: o modelo de implantação. S/4HANA Cloud Public Edition (GROW with SAP), Private Edition (RISE with SAP) ou on-premise. Essa escolha define como cada uma das outras frentes funciona.

O SAP Activate é o método de entrega da SAP. Tem seis fases, cada uma com quality gates no final. Aqui está para que serve cada fase e o ponto que eu não deixaria escapar.

Fase	O que acontece	O que eu garanto que esteja certo
Discover	Business case, escopo de alto nível, modelo de implantação	Custo e prazo realistas, não os otimistas
Prepare	Governança, termo de abertura, equipe, registro de riscos, ambientes	Decisores nomeados com autoridade real
Explore	Workshops de fit-to-standard, decisões sobre gaps, aprovação do design	Donos de negócio na sala, e não só a TI
Realize	Configuração, desenvolvimento, integração, testes de sistema	Planejamento do cutover já em andamento
Deploy	Testes de aceitação do usuário, cargas de dados, treinamento, cutover	Pelo menos um ensaio geral completo
Run	Go-live, hypercare, transição para o suporte	Hypercare com equipe até o primeiro fechamento mensal

A falha de cronograma mais comum é um Explore lento. Ele comprime o Realize, que comprime o Deploy. O teste de aceitação do usuário (UAT) é encurtado, o ensaio de dados é pulado, e o go-live acontece mesmo assim porque a data já foi anunciada. Os primeiros 90 dias depois do go-live pagam a conta.

1. 01Explore atrasaFit-to-standard e a aprovação do design escorregam
2. 02Realize é comprimidoMenos tempo para construir e testar
3. 03Deploy é comprimidoMenos tempo para UAT, cargas de dados e treinamento
4. 04Os testes são cortadosUAT encurtado, ensaio de dados pulado
5. 05Go-live na data anunciadaPorque a data foi anunciada

O custo cai no hypercare, nos primeiros 90 dias

1. Aprovação do design sem o negócio

O Explore produz um design. A qualidade dele depende de os donos de processo que o aprovaram terem entendido o que estavam assinando. Quando só a TI e os consultores participam dos workshops, o design pode estar tecnicamente correto e ainda assim ser irreconhecível para as pessoas que vão usá-lo. O UAT passa a ser descoberta em vez de validação.

Um teste simples: três meses depois da aprovação, peça a um dono de processo que explique como um pedido de compra vai funcionar depois do go-live. Se ele não consegue, a aprovação não foi real.

2. Governança que existe só no papel

Sem governança aplicada de fato, o escopo cresce de modo informal e as decisões são adiadas. Boa governança significa um patrocinador executivo nomeado, um comitê de direção com direitos de decisão definidos, um gerente de projeto capaz de sustentar um gate de fase e um processo de controle de mudanças com um aprovador nomeado.

Na maioria dos meus projetos, a CFO assumiu o papel de principal defensora do projeto. Quando os departamentos não chegavam a um acordo sobre um processo, ela dava a palavra final. Isso evitou as semanas de atraso que surgem quando os problemas ficam sem solução. Meu guia sobre comitês de direção em projetos SAP explica como montar isso.

3. Planejamento tardio do cutover

O cutover é a parte operacionalmente mais complexa do programa. Um plano iniciado poucas semanas antes do go-live não será ensaiado, deixará dependências de fora e não terá um ponto de rollback real.

Comece o planejamento do cutover no Realize. Documente a sequência, faça pelo menos um ensaio geral completo e acorde os critérios de rollback com antecedência. As decisões de cutover tomadas sob pressão, por pessoas acordadas há vinte horas, sem critérios combinados de antemão, são onde começam os desastres pós-go-live.

4. Testes de integração espremidos

Sendo sincero, eu achava que testar era uma tarefa de checklist. Configurar o sistema, rodar alguns casos de teste, seguir em frente. Então vi um projeto desmoronar simplesmente porque ninguém verificou como as aprovações de compra afetavam os lançamentos financeiros. Aquele momento mudou minha forma de ver os testes de SAP.

Testes unitários provam que uma transação funciona isoladamente. As falhas que machucam depois do go-live aparecem quando um processo completo roda entre módulos. Um recebimento de mercadorias bloqueado pelo status de um pedido de compra. Uma execução de faturamento parada por uma determinação de contas ausente. Teste as cadeias completas, order to cash e procure to pay, e não deixe que elas escorreguem para as últimas semanas antes do UAT.

5. Migração de dados subestimada

Os dados de origem quase sempre são piores do que a primeira avaliação sugere. Mapeamentos de campos que parecem simples falham na carga. As contagens de registros incluem dados inativos. As regras de limpeza exigem decisões de negócio, e essas levam tempo.

Uma empresa de manufatura descobriu milhares de registros duplicados de clientes durante a migração e precisou adiar o go-live em três semanas para corrigi-los. Planeje ciclos de carga extras desde o início. Meu artigo sobre por que a migração de dados SAP falha entra em detalhes.

6. Gestão de mudanças tratada como opcional

Já vi projetos em que o sistema funcionava perfeitamente e os usuários continuavam agarrados aos processos antigos. Não porque fossem difíceis, mas porque ninguém os acompanhou na transição. Quando a gestão de mudanças é cortada, os workarounds aparecem na primeira semana e se tornam permanentes, e os chamados de suporte ficam altos por meses.

A customização pesada entra na mesma categoria. Certa vez trabalhei com um cliente que customizou mais de 60% do sistema. Depois ele teve dificuldade para fazer upgrade e perdeu o suporte do fornecedor.

Os fundamentos acima não mudaram. Três pontos precisam ser resolvidos no início de um programa hoje.

O modelo de implantação vem primeiro. A Public Edition oferece as opções de customização mais restritas, e a SAP opera o sistema. A Private Edition sob o RISE dá mais margem, e a SAP opera a infraestrutura. O on-premise dá mais controle e mais responsabilidade. Decida isso no Discover. Os programas que adiam a decisão passam o Explore discutindo o assunto.

O clean core pertence ao termo de abertura. A Public Edition só permite extensões por meio de interfaces liberadas, então aplica o clean core de forma técnica. A Private Edition e o on-premise não fazem isso, então vira uma decisão de governança. A SAP agora classifica as extensões do nível A (apenas APIs liberadas) ao nível D (modificações), como descrito na sua atualização de clean core de agosto de 2025. Registre no termo de abertura o nível-alvo e o fórum de aprovação, ou os parceiros vão recorrer por padrão às modificações.

As ferramentas de IA pertencem ao método desde o primeiro dia. O Joule está disponível dentro do SAP Activate Roadmap Viewer. O Joule para consultores responde a perguntas de configuração, e o Joule para desenvolvedores gera código ABAP Cloud. Eles podem acelerar tarefas de redação e de construção. Não eliminam as decisões de negócio, o trabalho com dados nem o esforço de mudança. Pergunte ao seu parceiro onde ele as usa e como isso aparece no plano.

A abordagem deve seguir a sua tolerância a risco, a complexidade e a capacidade de absorver mudanças. Estas são as opções mais comuns.

Abordagem	O que significa	Mais indicada para
Big bang	Todos os módulos e entidades entram em operação juntos	Organizações menores com escopo padrão, que aceitam um risco de go-live maior
Em fases por módulo	Primeiro finanças, depois cadeia de suprimentos, depois RH	Módulos com poucas dependências cruzadas; permite que a equipe aprenda entre as fases
Em fases por país ou entidade	Um template entra em operação em uma entidade e depois é expandido	Grupos com um template global
Conversão brownfield	O ECC existente é convertido para o S/4HANA	ECC maduro com processos estáveis
Greenfield	Nova implementação do S/4HANA	Legado não SAP ou ECC com muita dívida técnica
Transição seletiva de dados	Entidades ou dados escolhidos migram para um sistema redesenhado	Fusões, carve-outs, reaproveitamento parcial

Já vi pequenos rollouts entrarem em operação em menos de seis meses. Também já vi projetos se arrastarem por dois anos porque as decisões não foram tomadas a tempo. Se você está comparando uma primeira implementação com um rollout de template, meu guia de implementação versus rollout compara os dois.

Use este checklist no primeiro mês, antes de a configuração começar. Cada item tem um responsável do lado do cliente.

1. Patrocinador executivo: modelo de implantação decidido e registrado, com as razões.
2. Diretor do programa: termo de abertura assinado, cobrindo escopo, exclusões explícitas, critérios de sucesso, direitos de decisão e controle de mudanças. Acordos verbais de escopo evaporam. Meu guia do termo de abertura do projeto traz um modelo.
3. Líderes de negócio: um dono de processo nomeado por área, com tempo realmente liberado para participar dos workshops.
4. Arquiteto de soluções: meta de clean core e fórum de aprovação de extensões acordados.
5. Líder de dados: profiling de dados iniciado no Prepare, não depois da aprovação do design.
6. Líder de cutover: nomeado no Realize, com a data do ensaio já no plano.
7. Gerente de testes: cenários de teste de cadeias de processo completas listados, incluindo das aprovações até os lançamentos financeiros.
8. CFO: cronograma comparado com programas semelhantes, com contingência para um Explore lento e ciclos de dados extras. Um plano que supõe que tudo dá certo não é um plano.

O que é um projeto de implementação SAP?

É o programa que coloca o software SAP em funcionamento para operar o negócio de uma empresa. Abrange desenho de processos, configuração, migração de dados, integração, testes, treinamento e gestão de mudanças, normalmente conduzido com o SAP Activate. O esforço varia enormemente conforme o número de entidades, países e módulos, e conforme o estado dos seus dados atuais.

Quais são as fases de uma implementação SAP?

O SAP Activate tem seis fases: Discover, Prepare, Explore, Realize, Deploy e Run. O Discover define o business case e o escopo. O Prepare estabelece a governança e a equipe. O Explore conduz os workshops de fit-to-standard e confirma o design. O Realize constrói e testa. O Deploy cobre UAT, cargas de dados, treinamento e cutover. O Run é o go-live e o hypercare. Cada fase termina com um quality gate.

Quanto tempo leva uma implementação SAP?

Depende do escopo e da rapidez com que as decisões são tomadas. Já vi pequenos rollouts entrarem em operação em menos de seis meses e projetos se arrastarem por dois anos porque as decisões não foram tomadas a tempo. A causa mais comum de estouro de prazo é uma fase Explore lenta, que comprime tudo o que vem depois.

Quais são os motivos mais comuns do fracasso de implementações SAP?

Design aprovado sem envolvimento real do negócio, governança que não é aplicada, planejamento tardio do cutover, testes de integração comprimidos, migração de dados subestimada e gestão de mudanças cortada. Os seis costumam estar visíveis cedo e são baratos de corrigir nesse momento.

O que deve constar no termo de abertura de um projeto SAP?

Objetivos ligados a resultados mensuráveis, escopo por módulo, entidade, país e integração, exclusões explícitas, direitos de decisão com pessoas nomeadas, governança e escalonamento, critérios de sucesso, controle de mudanças, principais marcos e premissas-chave. Para um programa em nuvem, acrescente o modelo de implantação e a abordagem de clean core. Obtenha a assinatura do patrocinador e dos líderes de negócio antes de a configuração começar.

O que é o hypercare depois do go-live do SAP?

Hypercare é o período de suporte intensivo depois do go-live, normalmente de 30 a 90 dias. A equipe do projeto e o negócio trabalham lado a lado para corrigir problemas e estabilizar a operação. Mantenha-o com equipe durante pelo menos um ciclo de negócio completo, incluindo o primeiro fechamento mensal, porque é quando muitos problemas aparecem pela primeira vez.