Modelos de implementação do SAP: um guia fase a fase

O SAP Activate traz um modelo para quase todos os entregáveis de um programa S/4HANA. Você os encontra no SAP Activate Roadmap Viewer e, em programas na nuvem, dentro do SAP Cloud ALM. Encontrá-los é fácil. Difícil é saber quais levar a sério.

Este guia é para gerentes de programa, líderes de PMO e patrocinadores que estão montando uma implementação. Ele cobre os modelos que eu exijo em cada fase, mostra um layout funcional para cada um e aponta onde as equipes tomam atalhos. Se você tem uma semana antes do kickoff, faça primeiro o documento de escopo e a matriz de partes interessadas. Tudo o que vem depois se apoia nesses dois.

O padrão nos programas de ECC e S/4HANA em que trabalhei, em manufatura, varejo e serviços financeiros, é consistente. As equipes que seguem os modelos encontram os problemas mais cedo. As que os tratam como papelada opcional descobrem no meio do projeto que cada decisão que nunca registraram virou uma disputa de escopo.

Este é o conjunto que espero ver aprovado, com a pessoa responsável por cada um e o ponto em que ele precisa estar liberado.

Fase	Modelo	Responsável	Aprovado antes de
Prepare	Documento de escopo do projeto	Gerente do programa (o patrocinador aprova)	Explore começar
Prepare	Business case	CFO ou dono do negócio	A verba ser liberada
Prepare	Matriz de partes interessadas	Gerente do programa	Os workshops de Explore serem agendados
Explore	Planilha de requisitos e fit-gap	Arquiteto de solução com os donos de processo	Realize começar
Realize	Registro de configuração	Líderes funcionais	Cada transporte ir para o QA
Realize	Registro de desenvolvimento customizado	Líder de desenvolvimento	A construção de qualquer objeto começar
Realize	Estratégia de testes	Gerente de testes	Os testes de integração de sistemas começarem
Realize	Plano de migração de dados	Líder de migração de dados	A primeira carga de simulação (mock load)
Deploy	Plano de cutover	Gerente de cutover	O ensaio geral final
Deploy	Avaliação de prontidão para o go-live	Diretor do programa (o patrocinador assina)	A reunião de go/no-go
Run	Modelo de suporte de hypercare	Líder de entrega de serviços	O go-live
Run	Planilha de monitoramento de desempenho	Líder de Basis	O go-live

O Activate tem seis fases: Discover, Prepare, Explore, Realize, Deploy e Run. Ele combina conteúdo de SAP Best Practices, configuração guiada e uma abordagem de entrega ágil. Para a maioria dos clientes, o Discover acontece antes da assinatura do contrato, então os modelos abaixo começam em Prepare.

1. 01DiscoverEm geral antes da assinatura do contrato
2. 02PrepareDocumento de escopo, business case, matriz de partes interessadas
3. 03ExplorePlanilha de requisitos e fit-gap
4. 04RealizeRegistro de configuração, registro de desenvolvimento, estratégia de testes, plano de migração
5. 05DeployPlano de cutover, prontidão para o go-live
6. 06RunModelo de hypercare, monitoramento de desempenho

Todos os modelos assinados antes do seu gate

A sequência das fases não é opcional. Trabalhei com uma varejista que tentou pular partes dela e acabou refazendo três meses de trabalho. Cada quality gate existe por um motivo.

Ao adaptar os modelos, mantenha cerca de 80% da estrutura padrão. Mude só o que reflete o seu contexto: requisitos do setor, controles regulatórios, particularidades regionais. Reescrever tudo derrota o propósito.

O que mudou nas ferramentas em 2026

A estrutura do Activate é a mesma de antes. As ferramentas ao redor dela é que mudaram.

1. O SAP Cloud ALM guarda os modelos nos programas em nuvem. É o sucessor do Solution Manager na SAP e está incluído no SAP Enterprise Support e em assinaturas de nuvem como o RISE with SAP. Escopo, requisitos, planos de teste e tarefas de cutover podem ficar ali, com rastreabilidade entre eles. O Solution Manager 7.2 sai da manutenção padrão no fim de 2027, com manutenção estendida até 2030 para algumas funções, então os ambientes on-premise existentes têm alguns anos, não uma década.
2. O Joule agora está dentro das ferramentas da metodologia. A SAP disponibilizou o Joule no Activate Roadmap Viewer em 2025 e no SAP Cloud ALM, então uma equipe pode pedir orientação sobre tarefas ou rascunhar conteúdo a partir do roadmap. Ele acelera o primeiro rascunho. Não substitui a pessoa que assina o fit-gap.
3. O clean core agora é uma regra de design, com níveis. Em agosto de 2025, a SAP substituiu seu modelo de extensibilidade de três camadas por quatro níveis de clean core, de A a D. O nível A usa apenas APIs liberadas, no SAP BTP ou dentro do sistema com ABAP Cloud. O nível D não é clean de forma alguma. O modelo de fit-gap precisa de uma coluna para dizer onde cada gap vai parar.
4. A edição pública estreita o fit-gap. A SAP agora comercializa o S/4HANA Cloud Public Edition como SAP Cloud ERP, vendido a empresas de médio porte como SAP GROW. As mesmas seis fases se aplicam, com artefatos mais leves, e só são permitidas extensões por APIs liberadas, então a coluna de gap tem menos respostas possíveis.

Os projetos que pulam esta base pagam o preço em Explore e Realize.

Modelo de escopo do projeto

Define o que o projeto inclui e o que não inclui. Quando alguém tentar acrescentar escopo três meses depois (e vai tentar), este documento é o ponto de referência. O termo de abertura do projeto SAP fica acima dele e traz o detalhe de governança.

Seção	Detalhes
Título, patrocinador, gerente de projeto	Implementação do SAP S/4HANA Finance; CFO; gerente de projeto sênior nomeado
Contexto	Situação atual e o motivo da mudança
Objetivos	Reduzir o ciclo de fechamento de 14 dias para 5; eliminar conciliações manuais
Dentro do escopo	FI/CO, integração MM/SD, migração de dados, UAT, go-live
Fora do escopo	Módulos de RH, migração de relatórios legados, integrações de terceiros além do ERP
Premissas	Patrocinador executivo disponível para o comitê de direção mensal; dados de teste acordados até a semana 6
Restrições	Data de go-live fixa; apenas recursos internos para a configuração
Entregáveis	Sistema configurado, planos de teste, plano de cutover, material de treinamento
Cronograma	Prepare: semanas 1-4; Explore: semanas 5-10; Realize: semanas 11-26
Aprovação	Aprovação do patrocinador do projeto e do PMO exigida antes do início de Explore

Modelo de business case

Percorre a análise de custo-benefício em um formato que a equipe de finanças consegue ler. Já tive clientes que obtiveram a aprovação do programa na primeira submissão com esta estrutura, porque os números são claros e as premissas estão escritas.

Uma regra a que me atenho: o integrador de sistemas que vai executar o trabalho não deve escrever este documento. O incentivo dele é começar. O seu é terminar. Meu modelo de business case do SAP aprofunda o modelo de benefícios.

Seção	Detalhes
Responsável e resumo	CFO ou diretor do programa; por que agora, o que muda, o que permanece igual
Declaração do problema	Questões operacionais específicas (duração do ciclo de fechamento, soluções paliativas manuais, idade do sistema)
Abordagem proposta	Greenfield / brownfield / seletiva, com resumo do escopo
Benefícios	Quantificados: dias a menos no ciclo de fechamento, economia de FTEs, redução da taxa de erros, redução do risco de auditoria
Custo e financiamento	Implementação, licença ou assinatura, tempo dos recursos internos, contingência; origem do orçamento
Riscos	Os três principais, com probabilidade e impacto
Recomendação	Prosseguir / prosseguir com condições / adiar, com a justificativa

Matriz de identificação de partes interessadas

Mapeia todos os afetados pela implementação e o nível de influência de cada um. Mostra num relance quem precisa de atualizações semanais e quem só precisa de um aviso antes do go-live.

Parte interessada	Papel	Interesse	Influência	Engajamento
CFO do grupo	Patrocinador executivo	ROI do programa, melhoria do fechamento financeiro	Alta	Comitê de direção mensal, atualização semanal por escrito
Diretor de TI	Dono técnico	Estabilidade do sistema, integração, segurança	Alta	Conselho semanal do programa, diário durante Realize
Diretor financeiro	Dono de processo-chave	Design de FI/CO, processo de fechamento	Alta	Workshops em Explore, aprovação do UAT
Gerentes de planta	Usuários impactados	Mudanças nos processos de MM/PP	Média	Comunicação mensal de mudanças, participação no UAT
Usuários finais (AP/AR)	Operadores	Mudanças no nível das transações	Baixa	Treinamento, suporte de hypercare
Auditoria interna	Governança	Rastreabilidade, controles, conformidade	Média	Revisões de artefatos nos quality gates

Use a mesma matriz para planejar os workshops de Prepare que capturam os requisitos de alto nível por departamento. Numere esses requisitos no formato que você vai usar em Explore (REQ-001 e assim por diante), para que nada seja renumerado depois e o rastro até o pedido original sobreviva.

Explore é onde a implementação ganha forma. Estes modelos expõem a distância entre o que o SAP faz de fábrica e o que o negócio precisa.

Modelo de mapeamento de requisitos e fit-gap

O mapeamento de requisitos captura as necessidades do negócio por departamento e rastreia cada uma até um componente do sistema e um caso de teste. Já vi empresas pularem essa etapa e acabarem com sistemas que ninguém usa, porque a construção se baseou no que os consultores supuseram, e não no que o negócio disse.

A análise de fit-gap mostra então onde o SAP padrão atende a cada necessidade e onde não atende. É um choque de realidade para a maioria dos meus clientes. Gosto de ver o momento em que uma equipe percebe que pode usar a funcionalidade padrão em vez de código customizado caro.

Mantenho os dois numa só planilha, com uma coluna para o caminho de resolução. No S/4HANA, cada gap precisa de uma resposta explícita: configuração padrão, extensão de key user, extensão de desenvolvedor dentro do sistema ou extensão side-by-side no SAP BTP. As modificações clássicas no código SAP são a resposta mais cara e deveriam exigir um aprovador nomeado.

ID do req.	Requisito	Componente SAP	Fit / Gap	Caminho de resolução	Ref. de teste
REQ-001	Lançamentos automáticos de fechamento mensal	FI-GL, fechamento de período	Fit	Configurar modelos de documentos recorrentes	TC-001
REQ-002	Aprovação de pedido de compra via Fiori	Compras MM, aplicativo de aprovação Fiori	Gap (não existe no ECC)	Aplicativo padrão do S/4HANA e configuração de workflow	TC-003
REQ-003	Automação do faturamento intercompany	Faturamento SD, integração com FI	Gap	Configuração de faturamento intercompany	TC-010
REQ-004	Monitoramento de jobs em lote	Aplicativo Application Jobs	Fit	Aplicativo padrão	TC-015
REQ-005	Portal de autoatendimento para fornecedores	SAP Ariba ou portal de fornecedores	Gap	Integração com o Ariba	TC-020
REQ-006	Arquivamento de dados em conformidade com o GDPR	ILM, arquivamento de dados	Gap	Configuração de política de ILM	TC-025
REQ-007	Relatórios de centro de custo em tempo real	CO, embedded analytics ou SAC	Gap	Embedded analytics ou conexão live com o SAC	TC-030
REQ-008	Suportar 500 usuários simultâneos	Dimensionamento do HANA	Gap (300 testados)	Revisão do dimensionamento e reforço da infraestrutura	TC-035

Esta é a fase de construção. Estes modelos são a trilha de auditoria de cada decisão de configuração, de cada desenvolvimento e de cada resultado de teste.

Modelo de acompanhamento de configuração

Registra cada mudança no sistema: quem a fez, por quê e em qual transporte ela entrou. Quando algo quebra depois, você rastreia o problema em minutos, não em dias.

1. ID da configuração e módulo: [p. ex., MM-CONF-001, MM]
2. Caminho no IMG e objeto de configuração: [p. ex., Tabela T161, tipos de documento de pedido]
3. Finalidade e processo de negócio afetado
4. Configurado por e data
5. Número da ordem de transporte: [p. ex., DEVK900123]
6. Valores principais: antes e depois
7. Casos de teste vinculados
8. Status de validação e aprovação

Registro de desenvolvimento customizado

Cada objeto customizado ganha uma linha antes de alguém escrever código. Um dos meus clientes cortou o código customizado em 30% porque o registro mostrou onde o SAP padrão funcionaria muito bem.

ID de dev.	Objeto	Descrição	Desenvolvedor	Esforço (h)	Status	Tipo de extensão
CD-001	Tile Fiori: visão geral de centros de custo	Tile de relatórios de CO em tempo real para finanças	Desenvolvedor Fiori	12	Concluído	Extensão de desenvolvedor
CD-002	Relatório de faturamento intercompany	Relatório para conciliação intercompany	Desenvolvedor ABAP	20	Em andamento	Extensão de desenvolvedor
CD-004	Aplicativo de status de pagamento de fornecedores	Aplicativo Fiori para consultas de pagamentos do AP	Desenvolvedor BTP	10	Aguardando QA	Side-by-side no BTP
CD-005	Notificação de recebimento de mercadorias	Disparo de e-mail no lançamento de entrada de mercadorias	Desenvolvedor de integração	24	Planejado	Baseado em eventos, no BTP

Modelo de estratégia de testes

Reúne todos os planos de teste em um só lugar: quem testa o quê, quando, em qual ambiente e segundo qual padrão.

Seção	Detalhes
Escopo	Funcional, integração, regressão, desempenho e UAT nos módulos do escopo (os testes de intrusão ficam com a segurança da informação)
Ambientes	DEV, QA, UAT (pré-produção), staging para validação final
Ferramentas	Gestão de testes no SAP Cloud ALM ou Jira/Xray; automação com Tricentis Tosca ou similar; desempenho com JMeter ou LoadRunner
Ciclo de vida do defeito	Novo, Em andamento, Resolvido, Verificado, Fechado; severidade e prioridade definidas na triagem
Critérios de saída	Todos os defeitos críticos fechados; aprovação do UAT recebida; taxa de aprovação da regressão de pelo menos 95%; metas de desempenho atingidas

Modelo de planejamento da migração de dados

A migração de dados é a frente de trabalho com mais chances de machucar você. Este modelo a divide em etapas que expõem problemas de qualidade dos dados antes do cutover, e não durante ele. O artigo sobre padrões de falha na migração de dados mostra o que dá errado quando essa etapa é pulada.

Seção	Detalhes
Escopo	Dados mestre de clientes, dados mestre de fornecedores, partidas em aberto, dados mestre de materiais, saldos de estoque, hierarquias de centros de custo
Sistemas de origem	ECC 6.0 EHP 7 (principal); sistema legado de RH (atribuições de funcionários a centros de custo)
Sistema de destino	S/4HANA (release atual)
Mapeamento e regras	Clientes e fornecedores para o Business Partner; centros de custo para a nova hierarquia; remover dados bancários inválidos; unificar duplicidades
Ferramentas de migração	SAP S/4HANA Migration Cockpit (principal); Migration Object Modeler para objetos customizados; scripts de pré-processamento
Estratégia de carga	Carga de simulação no QA; migração delta e conciliação; cutover para produção
Abordagem de validação	Contagem de registros da origem ao destino; amostragem aleatória de 10%; relatórios de conciliação de saldos
Plano de rollback	Backup pré-cutover; sistema legado em standby por 48 horas

A fase Deploy é quando você entra em produção. Estes modelos transformam um fim de semana caótico em um evento gerenciado.

Modelo de planejamento do cutover

Mapeia a janela de indisponibilidade hora a hora. Cada tarefa, cada responsável, cada horário de início. Sua equipe nunca deve ficar parada às 2h da manhã sem saber o que fazer em seguida.

Combine quatro coisas antes de escrever a lista de tarefas: a janela (por exemplo, sexta-feira 22:00 até sábado 06:00), o gatilho do rollback, a rapidez com que o sistema legado pode ser reativado e os smoke tests que provam que o novo sistema funciona. Depois, a sequência de tarefas:

Etapa	Descrição	Responsável	Início	Status
1	Congelar o sistema ECC (sem lançamentos)	Basis	22:00	Pendente
2	Extração final de dados e conciliação	Líder de migração de dados	22:30	Pendente
3	Executar a carga de migração em produção	DBA	23:00	Pendente
4	Importar os transportes restantes para produção	Basis	00:30	Pendente
5	Troca de DNS e do balanceador de carga para o S/4HANA	Rede	01:30	Pendente
6	Smoke test: lançamento em FI, entrada de mercadorias, pedido de venda	Líder de QA	02:00	Pendente
7	Confirmação do negócio e decisão de go/no-go	Diretor do programa	03:00	Pendente
8	Liberar o sistema para os usuários de negócio	Basis	06:00	Pendente

Avaliação de prontidão para o go-live

Decide se você está de fato pronto para virar a chave. Já tive clientes que adiaram o go-live com base nesta avaliação, e eles me agradeceram depois.

Área	Verificações (cada uma respondida com sim ou não, com evidência)
Funcional	Processos-chave testados; cenários entre módulos concluídos; defeitos P1/P2 em aberto listados; usuários-chave confirmam a prontidão
Dados	Cargas de dados mestre concluídas; dados transacionais validados; relatórios de conciliação aprovados; congelamento do legado confirmado
Técnica	Plano de cutover aprovado; transportes em produção; jobs em lote agendados; monitoramento configurado
Pessoas	% de cobertura de treinamento; perfis de acesso validados; equipe de hypercare alocada; plano de suporte comunicado
Decisão	Riscos críticos e mitigações listados; Go / No-go / Condicional; aprovado por nome, cargo e data

Depois do go-live, o trabalho muda de forma. Estes modelos levam o sistema e a equipe pelo hypercare até o regime estável.

Modelo de suporte pós-implementação

Organiza como você trata os problemas depois do lançamento. Sem ele, todo problema vira P1.

Seção	Detalhes
Janela de hypercare	Semanas 1-4 após o go-live: cobertura 24/7
Canais de suporte	Fila de incidentes do ServiceNow (principal); canal de chat dedicado; ponte telefônica para incidentes P1
Níveis de suporte	1: service desk (senhas, navegação, problemas conhecidos); 2: consultores funcionais (dúvidas de processo, pequenas configurações); 3: Basis e desenvolvimento (erros de sistema, desempenho, interfaces)
SLAs (resposta / resolução)	Crítico 15 min / 2 h; Alto 30 min / 4 h; Médio 4 h / 1 dia; Baixo 1 dia / 3 dias
Monitoramento	SAP Cloud ALM ou Solution Manager; revisão diária do log de erros
Critérios de saída	Nenhum incidente P1/P2 em aberto; todos os incidentes documentados; aprovação final da transição

Modelo de monitoramento de desempenho

Permite acompanhar a saúde do sistema dia a dia e perceber lentidão antes que os usuários reclamem. Ajudei recentemente uma empresa a pegar, assim, um problema de banco de dados que teria derrubado o sistema durante o fechamento mensal.

Métrica	Meta	Ferramenta	Limite de alerta	Responsável
Tempo de resposta de diálogo (percentil 95)	Menos de 1 segundo	ST03 / SAP Cloud ALM	2 segundos	Equipe de Basis
Conclusão de jobs em segundo plano	100% conforme o agendamento	SM37 / Application Jobs	Qualquer job com falha	Líder de operações
Tempo de consulta ao banco de dados	Menos de 200 ms	SAP HANA cockpit	500 ms	DBA
Disponibilidade do sistema	Acima de 99,5%	SAP Cloud ALM	Abaixo de 99%	Infraestrutura
Taxa de erro de interfaces	Menos de 1%	Monitoramento do SAP Integration Suite	2%	Líder de middleware
Taxa de sucesso de login	Acima de 98%	Log de auditoria de segurança	Abaixo de 95%	Líder de segurança
Tempo de execução dos jobs de fechamento mensal	Dentro da janela acordada	Agendador de jobs	Mais de 30% acima da linha de base	Operações financeiras

Os quality gates impedem que um problema de uma fase vire retrabalho caro na seguinte. Meu guia sobre quality gates do SAP mostra como configurá-los. Aqui está por que eles importam.

A aprovação executiva antes do go-live não deve ser um carimbo automático. Em um projeto em que trabalhei, o CEO percebeu na revisão do go-live um problema grande que teria atrapalhado o trabalho da equipe financeira.

Defina critérios de aprovado ou reprovado em cada gate. “95% dos testes de regressão precisam passar.” “Todos os cenários de integração de FI estão verdes.” Critérios assim dão a você uma base defensável para segurar a linha quando o negócio quer lançar numa data, independentemente da qualidade.

Em um dos meus projetos, o quality gate nos barrou quando só 75% dos testes de integração tinham passado. Corrigimos os problemas primeiro, em vez de seguir adiante às pressas. Isso poupou ao cliente cerca de € 100.000 em correções emergenciais depois do lançamento.

Um gate que o patrocinador pode derrubar com um telefonema não é um gate. Registre por escrito quem pode dispensá-lo antes de precisar disso.

O que é a metodologia SAP Activate?

O SAP Activate é a metodologia de implementação da SAP para o S/4HANA e seus outros produtos em nuvem. Ela tem seis fases (Discover, Prepare, Explore, Realize, Deploy, Run) e combina conteúdo de SAP Best Practices, configuração guiada e entrega ágil.

As listas de tarefas e os modelos de entregáveis de cada cenário de implantação são publicados no SAP Activate Roadmap Viewer.

Qual fase do SAP Activate tem os modelos mais importantes?

Prepare. O documento de escopo, o business case e a matriz de partes interessadas formam a base de todas as decisões seguintes, e são justamente os que as equipes pulam para chegar mais rápido à configuração. Esse atalho é a causa mais comum de disputas de escopo em Realize.

Explore vem em segundo lugar. As lacunas nos documentos de fit-gap e de mapeamento de requisitos aparecem meses depois como defeitos no UAT, quando corrigi-las custa muito mais do que custaria na semana 3 de Explore.

Dá para personalizar os modelos do SAP Activate?

Sim. Mantenha cerca de 80% da estrutura padrão e mude apenas o que é específico do seu contexto: validação farmacêutica, regras de compras do setor público, controles SOX. Acrescente isso no início de Prepare, não em Deploy.

Não personalize a estrutura dos quality gates, a sequência das fases nem os artefatos obrigatórios (documento de escopo, business case, avaliação de prontidão para o go-live).

Os modelos do SAP Activate funcionam tanto para greenfield quanto para brownfield?

Sim. A principal diferença está em Explore. Uma conversão brownfield leva adiante a configuração existente, então o fit-gap se concentra no que precisa mudar, em qual código customizado o S/4HANA padrão agora pode substituir e em que limpeza de dados é necessária antes da conversão. Um programa greenfield parte do SAP Best Practices e confirma quais processos padrão se encaixam.

O plano de cutover também é diferente. Uma conversão de sistema brownfield segue uma sequência diferente da de um go-live greenfield com migração completa de dados.

Quão detalhado deve ser um plano de cutover?

Hora a hora no mínimo, e mais fino que isso para a janela de indisponibilidade. Cada tarefa precisa de um horário de início, um responsável e uma dependência.

Combine os critérios de rollback antes de o cutover começar: quais condições disparam o retorno ao sistema legado, quem toma essa decisão e até que horas. Decisões de rollback tomadas às 4h da manhã, sem critérios previamente combinados, são onde começam os desastres pós-go-live.