
Índice
- O que o SAP realmente cobre
- A metodologia SAP Activate
- O gate do ensaio de fechamento de três dias
- Planejamento antes de a configuração começar
- Mapeie os processos atuais como realmente funcionam
- Decida entre padrão e extensão para cada processo
- Audite a qualidade dos dados antes de a migração de dados começar
- Monte primeiro a equipe, depois feche o escopo
- Desafios comuns e o que fazer a respeito
- Antes, durante e depois do go-live
- Dois programas que funcionaram
- O que mudou para os programas que começam agora
- As edições em nuvem são o padrão
- O clean core é classificado, não binário
- Joule e SAP Build Code na equipe de entrega
- O que isso significa para um programa que começa agora
- Perguntas frequentes
Uma implementação SAP é o programa que leva as áreas de finanças, compras, cadeia de suprimentos, vendas e RH de uma empresa para um único sistema SAP, normalmente o S/4HANA. Ela segue seis fases no método SAP Activate e tem sucesso ou fracassa pelo trabalho feito antes de alguém configurar qualquer coisa: desenho de processos, qualidade dos dados e a equipe certa.
Este guia é para executivos e líderes de programa prestes a começar uma. Ele percorre as fases, o que cada uma precisa entregar, o planejamento que vem primeiro e o que mudou para os programas que começam agora. Se for ler uma só seção, leia “Planejamento antes de a configuração começar”.
Depois de 25 anos implementando ERP, vi o mesmo padrão se repetir muitas vezes. Empresas que tratam a implementação como instalação de software sofrem. Empresas que tratam o sistema como o último passo, depois do trabalho de processos, entregam no prazo e conseguem os resultados que prometeram ao conselho.
O S/4HANA é o ERP atual da SAP e roda no banco de dados em memória SAP HANA. Sistemas ECC mais antigos ainda funcionam em muitas empresas, mas a manutenção padrão do ECC termina em 31 de dezembro de 2027, com manutenção estendida opcional até o fim de 2030 mediante uma taxa maior.
Os módulos principais que a maioria das implementações toca primeiro:
| Módulo | O que gerencia |
|---|---|
| FI (Contabilidade Financeira) | Livro-razão, contas a pagar, contas a receber, contabilidade de ativos |
| CO (Controladoria) | Centros de custo, centros de lucro, ordens internas, relatórios gerenciais |
| MM (Gestão de Materiais) | Compras, estoque, movimentações de mercadorias, gestão de fornecedores |
| SD (Vendas e Distribuição) | Order-to-cash, precificação, expedição, faturamento |
| PP (Planejamento de Produção) | Ordens de produção, planejamento de capacidade, MRP |
| HCM (Gestão de Capital Humano) | Dados mestre de RH, folha de pagamento, gestão de tempos |
A maioria das empresas começa com FI/CO e um ou dois módulos operacionais. O restante é construído nas fases seguintes.

O SAP Activate substituiu o antigo método ASAP. Ele tem seis fases, cada uma com um gate que você supera antes de avançar.
As seis fases do SAP Activate
Discover
Confirme o caso de negócio e teste os processos prioritários em um sistema de avaliação ou demonstração.
Prepare
Mobilize: equipe, governança, documento de escopo, plano e acesso aos sistemas.
Explore
Workshops de Fit-to-Standard com os donos dos processos. Monte o backlog de configurações, integrações e extensões.
Realize
Configure, estenda, migre dados e teste. A fase mais longa. A saída exige uma execução de regressão limpa.
Deploy
Treine os usuários em processos reais, ensaie o cutover e entre em operação com uma sala de crise montada.
Run
Hypercare, otimização e transferência para o Centro de Excelência.
Esta tabela é a versão que eu fixo na parede do escritório do programa: o que cada fase precisa entregar, quem é o responsável e o que precisa ser verdade antes de a fase seguinte começar.
| Fase | Deve entregar | Responsável | Gate para avançar |
|---|---|---|---|
| Discover | Caso de negócio, escopo-alvo, escolha de implantação | Patrocinador e CFO | Orçamento aprovado |
| Prepare | Documento de escopo, plano, governança, equipe montada | Diretor do programa | Patrocinador assina o escopo |
| Explore | Resultados do Fit-to-Standard, backlog, decisões sobre extensões | Arquiteto de soluções com os donos dos processos | Nenhuma lacuna sem solução |
| Realize | Sistema configurado e testado, dados de teste migrados | Líderes funcionais e técnicos | Regressão limpa; dados conciliam |
| Deploy | Usuários treinados, cutover ensaiado, pacote de go/no-go | Gerente de cutover | Ensaio de fechamento de três dias aprovado |
| Run | Registro de hypercare, transferência ao CoE, backlog da fase 2 | Líder de entrega de serviços | Nenhum P1/P2 aberto; CoE aceita |
Os templates por trás de cada fase estão no meu guia de templates do SAP Activate.
O gate do ensaio de fechamento de três dias
O gate entre Realize e Deploy é o que as equipes mais pulam sob pressão de cronograma. Recomendo fazer um ensaio de fechamento de três dias antes do go-live de verdade. Se a área financeira não consegue fechar a contabilidade no novo sistema, sua migração de dados não está pronta, não importa o que a TI diga. Pular esse gate custa mais do que o atraso que ele teria causado.
A ordem importa. Quatro coisas precisam ser feitas antes de qualquer decisão de configuração.
- Mapear os processos atuaisComo realmente funcionam, com as soluções de contorno incluídas
- Decidir entre padrão e extensãoO padrão quase sempre é mais rápido
- Auditar a qualidade dos dadosAntes de a migração de dados começar
- Montar a equipe e só depois fixar o escopoQuem está disponível define o que você consegue entregar
Só agora a configuração começa
Mapeie os processos atuais como realmente funcionam
Não como o processo deveria ser. Como ele de fato é, com as soluções de contorno incluídas. É nelas que estão escondidos os requisitos que ninguém registrou.
Decida entre padrão e extensão para cada processo
Identifique quais processos a funcionalidade padrão do SAP cobre e quais precisam de extensão. O padrão é quase sempre mais rápido. Cada extensão acrescenta ciclos de teste, risco de upgrade e manutenção. Pela orientação de clean core da SAP, cada extensão também precisa ser colocada em um lugar deliberado, o que torna a decisão mais relevante, e não menos.
Audite a qualidade dos dados antes de a migração de dados começar
A frente de trabalho mais subestimada. Já vi empresas passarem meses corrigindo relatórios porque registros desatualizados de clientes foram carregados sem checagem. Um cliente tinha mais de 18.000 registros duplicados de clientes, e corrigi-los depois do go-live atrapalhou o faturamento por semanas.
Monte primeiro a equipe, depois feche o escopo
O escopo que você consegue entregar depende de quem está disponível para configurar, testar e responder por cada frente de trabalho. Equipes que definem o escopo primeiro e montam a equipe depois passam meses refazendo aquilo com que se comprometeram em excesso.
| Desafio | Como aparece | O que fazer |
|---|---|---|
| Scope creep | Pedidos do tipo “já que estamos mexendo aí, é só incluir...” se acumulam | Controle formal de mudanças desde o primeiro dia; todo pedido recebe uma avaliação de impacto |
| Qualidade dos dados | A migração revela inconsistências que ninguém sabia que existiam | Fazer o profiling dos dados seis meses antes do go-live; limpar no sistema de origem |
| Resistência dos usuários | Os usuários voltam ao Excel em até duas semanas depois do go-live | Envolver os usuários finais no desenho desde o Explore; envolvimento, não só treinamento |
| Falhas de integração | As conexões com terceiros quebram no UAT | Mapear as interfaces no Explore; testar cedo com volumes realistas |
| Ciclos de teste cortados | A regressão é encurtada para cumprir uma data | Proteger as fases de teste; o atraso na construção não deve comprimir o teste |
| Fadiga da equipe | O ânimo cai e as taxas de defeito sobem na reta final | Acompanhar a fadiga com um índice semanal simples de ânimo; na minha experiência, quando ele passa de 25%, as taxas de defeito nos testes disparam |
Lembro de um caso em que uma empresa pulou pequenos testes de regressão para ganhar velocidade. Uma semana depois, a área financeira não conseguia conciliar relatórios importantes. Seguiram-se meses de limpeza. Não foi uma falha grave do sistema, só um descuido evitável.
Antes, durante e depois do go-live
Antes do go-live: faça o ensaio de fechamento, valide os dados migrados com relatórios de conciliação, treine em processos reais em vez de cenários de demonstração e teste o plano de rollback. Percorra com o comitê de direção os critérios de go/no-go e obtenha uma aprovação explícita, não acenos de cabeça implícitos.
Durante o go-live: aumente o monitoramento e mantenha a equipe de cutover disponível 24 horas por dia nas primeiras 72 horas. As decisões tomadas nessas horas definem se o hypercare abre com confiança ou com uma fila.
Depois do go-live: mantenha o hypercare por pelo menos quatro semanas. Acompanhe os chamados de suporte por categoria; eles mostram onde o treinamento falhou e onde a configuração precisa de ajustes. Planeje a fase 2 a partir da linha de base estabilizada. O escopo adiado há 18 meses precisa ser reavaliado diante do que o negócio precisa agora.
O SAP não vai consertar processos quebrados. Vai expô-los. As empresas que mais aproveitam o SAP são as que redesenharam os processos primeiro e configuraram o sistema depois.
Uma indústria de médio porte vivia ficando sem matéria-prima. A área de compras culpava os planejadores; os planejadores culpavam planilhas em que ninguém confiava. Substituímos essa configuração pelo S/4HANA e apostamos forte no SAP PP, com uma configuração de MRP adequada. Os níveis de estoque passaram de palpite a dados em tempo real, os pedidos de compra passaram a ser disparados pela necessidade e, depois de seis meses, as faltas tinham caído mais de 50%. Isso surpreendeu até os céticos. O resultado veio do redesenho dos processos que precedeu a configuração. O PP sem o trabalho de processos teria produzido respostas erradas mais rápido. A área financeira também ganhou: o fechamento mensal ficou mais rápido, e o CFO disse que os números “pareciam confiáveis” pela primeira vez em muito tempo.
Uma empresa global de serviços profissionais tinha um problema diferente. Cada país operava a própria plataforma financeira, nada conciliava e os relatórios eram refeitos à mão todo mês. Implantamos o SAP Finance em etapas, sob um comitê de direção presente no dia a dia. O fechamento mensal caiu de mais de duas semanas para pouco mais de uma, os relatórios regionais finalmente bateram e até os auditores ficaram com menos ressalvas.
Um guia escrito para 2022 não sobrevive ao contato com um comprador de 2026. Quatro mudanças precisam estar no desenho desde o kickoff.
As edições em nuvem são o padrão
A SAP hoje vende duas edições de ERP em nuvem: o SAP Cloud ERP (a edição pública, antes chamada S/4HANA Cloud Public Edition) e o SAP Cloud ERP Private (a edição privada). O RISE with SAP empacota a edição privada com operação feita pela SAP e uma cadeia de ferramentas de transformação que inclui SAP Signavio, SAP LeanIX e SAP Cloud ALM. O SAP GROW é o pacote para empresas de médio porte na edição pública.
A decisão sobre a edição agora fica acima dos antigos debates sobre a forma de implantação. Big bang versus em fases, e greenfield versus brownfield versus seletivo, são escolhas que você faz dentro da edição, não no lugar dela. Se você ainda está no ECC e precisa de mais tempo, a SAP vende uma opção de transição da edição privada do ERP para 2031 a 2033, mas a própria SAP deixa claro que é uma oferta paga de transição, não uma extensão de manutenção.
O clean core é classificado, não binário
Em agosto de 2025, a SAP introduziu quatro níveis de clean core, de A a D. O nível A usa apenas APIs liberadas e estáveis, seja lado a lado no SAP BTP ou dentro do sistema com ABAP Cloud. O nível B permite APIs clássicas e tecnologias que ainda são consideradas limpas. O nível C exige medidas especiais. O nível D não é limpo.
A edição pública só permite extensões de nível A. A edição privada e o on-premise permitem extensões clássicas, então a disciplina ali vem da governança, e não de a plataforma bloquear você. O ponto prático para um programa: defina o nível e o local de cada extensão no Explore e tenha uma pessoa nomeada que possa dizer não. Parceiros sem experiência em SAP BTP e ABAP Cloud criam dívida de nível C e D desde a primeira semana.
Joule e SAP Build Code na equipe de entrega
O Joule agora está dentro do SAP Activate Roadmap Viewer e do SAP Cloud ALM, onde responde a dúvidas sobre tarefas e redige conteúdo a partir da metodologia. O SAP Build Code, disponível de forma geral desde 2024, usa o Joule para gerar lógica de aplicação, modelos de dados e testes para extensões em Java e JavaScript no SAP BTP. A SAP acrescentou ajuda semelhante de IA generativa para desenvolvedores ABAP.
A visão honesta: a IA em programas SAP é real, mas a qualidade dos dados decide o valor. Documentação de processos limpa e dados mestre limpos geram resultados úteis. Dados sujos geram ruído confiante. Nada disso elimina a necessidade de uma pessoa responsável por cada decisão.
O que isso significa para um programa que começa agora
O playbook continua funcionando. As fases continuam valendo e a ordem do trabalho continua importando. O que mudou foi a decisão sobre a edição, a disciplina com as extensões e as ferramentas da equipe. Um programa que absorve isso no kickoff trata essas mudanças como restrições de desenho. Um que as ignora gasta os três primeiros meses descobrindo o que mudou, em geral pelos pedidos de mudança do parceiro.
Para o lado de custos das mesmas decisões, veja meu detalhamento de custos de implementação SAP. Se você ainda está no ECC, o guia de migração do ECC para o S/4HANA cobre os caminhos de conversão.
Para que o SAP é usado?
O SAP executa as funções centrais do negócio (finanças, compras, cadeia de suprimentos, RH, vendas) em um único sistema com um único modelo de dados.
Na prática, um recebimento de mercadorias atualiza o estoque, dispara o processo de contas a pagar e chega aos relatórios gerenciais sem redigitação. Os relatórios só são tão precisos quanto as transações por baixo deles, e é por isso que o desenho de processos e a qualidade dos dados importam mais do que a configuração.
Quanto tempo leva uma implementação SAP?
Escopo e equipe são as duas variáveis que mais mexem no prazo. Uma implementação focada do S/4HANA, cobrindo FI/CO e um módulo operacional para uma única empresa, pode levar de 6 a 9 meses. Um rollout global com muitas entidades, módulos e idiomas leva de 18 a 36 meses.
O que alonga os prazos: problemas de dados descobertos tarde, escopo acrescentado sem mover a data, papéis-chave preenchidos em meio período e ciclos de teste cortados para recuperar atrasos anteriores. Tudo isso é controlável no planejamento.
Quais são as seis fases do SAP Activate?
Discover (caso de negócio e aderência), Prepare (equipe, governança, plano), Explore (workshops de Fit-to-Standard e backlog), Realize (configurar, estender, migrar, testar), Deploy (treinar, ensaiar o cutover, entrar em operação) e Run (hypercare e transferência para o Centro de Excelência).
Quais são os motivos mais comuns de fracasso das implementações SAP?
Três causas-raiz aparecem em quase todo programa em dificuldade. Trabalho de processos pulado, de modo que o SAP é configurado sobre processos legados quebrados. Qualidade dos dados ignorada até o cutover, quando não há tempo para corrigi-la direito. Gestão de mudanças tratada como treinamento: o treinamento mostra às pessoas onde clicar, a gestão de mudanças faz com que elas queiram.
Uma quarta é mais recente: um parceiro que constrói extensões sem um plano de clean core, deixando uma dívida que aparece no primeiro upgrade importante.
Como escolher o parceiro certo de implementação SAP?
Experiência no setor na sua escala e referências para as quais você realmente consiga ligar. Envolvimento sênior nominal: quem aparece na apresentação deve conduzir o programa. Independência: parceiros que ganham com a venda de licenças ou assinaturas têm incentivo para recomendar mais escopo. Experiência com clean core: pergunte quantas extensões em SAP BTP e ABAP Cloud eles já construíram e peça para vê-las.
Mais uma regra. O parceiro que vai executar o trabalho não deve escrever o seu business case. O incentivo dele é começar. O seu é terminar.
O que acontece depois do go-live?
O hypercare dura pelo menos quatro semanas, com a equipe completa disponível e revisão diária dos problemas em aberto. As categorias de chamados na primeira semana são o sinal mais honesto de onde o treinamento ficou aquém ou a configuração estava errada.
Depois do hypercare, o Centro de Excelência assume melhorias, planejamento de upgrades, treinamento de novos integrantes e governança de mudanças. Empresas que deixam de montar o CoE durante o programa costumam passar os dois anos seguintes pagando consultores por um trabalho que deveria ser interno.
O que é o RISE with SAP e ele serve para a minha organização?
O RISE with SAP é o pacote de assinatura da SAP para o SAP Cloud ERP Private: o software, a infraestrutura e a operação gerenciadas pela SAP e uma cadeia de ferramentas para análise de processos, arquitetura e gestão do ciclo de vida. O seu parceiro continua entregando a implementação.
Ele serve para organizações maiores que estão saindo do ECC e querem um único contrato SAP para plataforma e operação. Empresas de médio porte que conseguem trabalhar próximas do padrão devem avaliar o SAP GROW na edição pública. O RISE é uma opção mais fraca quando a regulação exige infraestrutura gerenciada pelo cliente ou quando muito código customizado não pode ser limpo no tempo disponível.
Próximo passo
Está conduzindo um programa de ERP agora?
Se este artigo tocou num programa em que você está envolvido agora, uma conversa de 30 minutos costuma render mais do que outra semana de análise interna.




