Modelos de implementação do SAP: o conjunto do SAP Activate por fase

Os modelos do SAP Activate são os modelos de implementação e aceleradores que a SAP publica para cada fase de um programa S/4HANA, do documento de escopo no Prepare ao plano de cutover no Deploy. Você os encontra no SAP Activate Roadmap Viewer e, em programas na nuvem, no SAP Cloud ALM.

Resposta curta: você não precisa de todos. Precisa de cerca de uma dúzia, cada um com um responsável nomeado e um ponto de aprovação, e deve manter cerca de 80% da estrutura padrão da SAP. A tabela abaixo é o conjunto que eu exijo nos 21 programas SAP que liderei ou resgatei.

Encontrar os modelos é fácil. Saber quais levar a sério é a parte difícil.

Este é o conjunto de modelos de implementação SAP que espero ver aprovado, com o responsável e o ponto que cada um precisa ultrapassar.

Fase	Modelo	Responsável	Aprovado antes de
Prepare	Documento de escopo do projeto	Gerente do programa (o patrocinador aprova)	O início do Explore
Prepare	Business case	CFO ou dono do negócio	A liberação do orçamento
Prepare	Matriz de partes interessadas	Gerente do programa	O agendamento dos workshops do Explore
Explore	Planilha de requisitos e fit-gap	Autoridade de design (negócio e TI)	O início do Realize
Realize	Log de configuração	Líderes funcionais	Cada transporte ir para QA
Realize	Registro de desenvolvimentos customizados	Líder de desenvolvimento	O início da construção de qualquer objeto
Realize	Estratégia de testes	Gerente de testes	O início dos testes integrados
Realize	Plano de migração de dados	Líder de migração de dados	A primeira carga simulada
Deploy	Plano de cutover	Gerente de cutover	O ensaio geral final
Deploy	Checklist de prontidão para o go-live	Diretor do programa (o patrocinador assina)	A reunião de go/no-go
Deploy	Modelo de suporte do 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 SAP Activate tem seis fases: Discover, Prepare, Explore, Realize, Deploy e Run. Ele combina o conteúdo SAP Best Practices, uma metodologia e a configuração guiada. O Discover é a fase de pesquisa sem compromisso, então para a maioria dos clientes ele termina antes da assinatura do contrato, e os modelos abaixo começam no Prepare.

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

Cada modelo aprovado antes do seu gate

No Roadmap Viewer, cada roadmap é dividido em fases, entregáveis e tarefas. Os modelos ficam arquivados como aceleradores: guias práticos, documentos de exemplo e checklists vinculados à tarefa que precisa deles. Você pode filtrar por fase, frente de trabalho ou acelerador, que é o caminho mais rápido para reunir os entregáveis do SAP Activate de uma fase.

Ao adaptá-los, 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 joga fora o motivo de usá-los.

O que mudou nas ferramentas

A estrutura de fases é a mesma. As ferramentas ao redor dela mudaram.

1. O SAP Cloud ALM é onde os modelos ficam em programas na nuvem. Ele é fornecido aos clientes com o SAP Enterprise Support e vem com assinaturas de nuvem da SAP, como o RISE with SAP. O Solution Manager 7.2 tem manutenção padrão até o fim de 2027 e manutenção estendida até 2030 para funções selecionadas.
2. O Joule está dentro das ferramentas da metodologia. A SAP adicionou o Joule ao Roadmap Viewer em 2025 e ao SAP Cloud ALM, então uma equipe pode pedir orientação sobre uma tarefa ou um primeiro rascunho. Ele não substitui a pessoa que assina o fit-gap.
3. O Clean Core agora tem níveis. Em agosto de 2025 a SAP introduziu quatro níveis de Clean Core, de A a D, em que o nível A usa apenas APIs liberadas e o nível D não é limpo. Sua planilha de fit-gap precisa de uma coluna indicando onde cada gap vai parar.

Os projetos que pulam essa base pagam por isso no Explore e no Realize. Estes três documentos são os que as equipes pulam para chegar mais rápido à configuração.

Documento de escopo do projeto

Ele define o que o programa inclui e o que não inclui. Quando alguém tentar acrescentar escopo três meses depois (e vai tentar), este é o ponto de referência.

As seções que eu espero:

1. Título, patrocinador e gerente do programa.
2. Contexto: situação atual e o motivo da mudança.
3. Objetivos em números, por exemplo "ciclo de fechamento de 14 dias para 5".
4. Dentro do escopo, por módulo e processo (FI/CO, integração MM/SD, migração de dados, UAT, go-live).
5. Fora do escopo, escrito de forma tão explícita quanto o escopo (RH, migração de relatórios legados, integrações fora do ERP).
6. Premissas e restrições, como a disponibilidade do patrocinador para um comitê de direção mensal e uma data de go-live fixa.
7. Cronograma por fase, com aprovação do patrocinador e do PMO antes do início do Explore.

Compare o cronograma com o que é realista. Na minha experiência, programas GROW levam de 6 a 9 meses, RISE de 9 a 18 meses, conversões brownfield de 12 a 18 meses e greenfield de 18 a 24 meses; meu guia de cronograma de implementação SAP detalha isso por fase.

Modelo de business case

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

A estrutura:

1. Responsável e resumo: por que agora, o que muda, o que continua igual.
2. Definição do problema: duração do ciclo de fechamento, contornos manuais, idade do sistema.
3. Abordagem proposta: greenfield, brownfield ou seletiva, com um resumo do escopo.
4. Benefícios quantificados: dias a menos no fechamento, tempo de FTE, taxas de erro, risco de auditoria.
5. Custo e financiamento: implementação, licença ou assinatura, tempo interno, contingência.
6. Os três principais riscos, com probabilidade e impacto.
7. Recomendação: seguir, seguir com condições ou adiar.

Uma regra que eu mantenho: o integrador de sistemas que vai executar o trabalho não deve escrever este documento. O incentivo dele é começar. O seu é terminar, e meu modelo de business case SAP se aprofunda no modelo de benefícios.

Matriz de partes interessadas

Ela mapeia todos os afetados pela implementação, sua influência e como você vai envolvê-los. Ela mostra quem precisa de uma atualização semanal e quem precisa de um aviso antes do go-live.

Para cada grupo, registre papel, interesse, influência e forma de envolvimento. Um conjunto típico: o CFO como patrocinador (comitê de direção mensal), o diretor de TI como responsável técnico, o diretor financeiro como principal dono de processo, os gerentes de fábrica e os usuários de contas a pagar e a receber como usuários impactados, e a auditoria interna nos quality gates.

Use a mesma matriz para planejar os workshops do Prepare que levantam os requisitos de alto nível. Numere-os já no formato que você usará no Explore (REQ-001 e assim por diante), para que o rastro até o pedido original sobreviva.

O Explore é onde o desenho é fechado em workshops de Fit-to-Standard com base no SAP Best Practices. É também onde os orçamentos SAP estouram, porque a contagem de WRICEF (workflows, relatórios, interfaces, conversões, melhorias e formulários) cresce aqui.

Não deixe a sequência das fases escorregar. Em um projeto de varejo europeu em 2023, o cliente tentou pular o Explore e passou três meses construindo com base em requisitos incompletos. Meu detalhamento do custo de implementação SAP mostra como esse tipo de retrabalho vira orçamento.

Planilha de requisitos e fit-gap

O mapeamento de requisitos liga cada necessidade do negócio a um componente do sistema e a um caso de teste. A análise de fit-gap mostra então onde o SAP padrão atende à necessidade e onde não atende.

Mantenho os dois em uma única 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 usuário-chave, extensão de desenvolvedor no sistema ou uma extensão side-by-side no SAP BTP.

ID do req.	Requisito	Componente SAP	Fit / gap	Caminho de resolução	Ref. de teste
REQ-001	Lançamentos automáticos de fechamento mensal	Fechamento de período FI-GL	Fit	Configuração de documentos recorrentes	TC-001
REQ-002	Aprovação de pedidos de compra no celular	Compras MM, app de aprovação Fiori	Fit no S/4HANA	Configuração padrão do app e do workflow	TC-003
REQ-003	Automação do faturamento intercompany	Faturamento SD, integração FI	Fit	Configuração do faturamento intercompany	TC-010
REQ-004	Arquivamento de dados para regras de privacidade	Information Lifecycle Management	Gap	Configuração de políticas ILM	TC-025
REQ-005	Relatórios de centro de custo em tempo real	CO, analytics embarcado ou SAC	Gap	Analytics embarcado ou conexão live do SAC	TC-030
REQ-006	Portal de autoatendimento para fornecedores	SAP Ariba ou portal de fornecedores	Gap	Integração com o Ariba	TC-020

É aqui que o dinheiro é economizado. Em uma migração de ECC para S/4HANA de uma indústria europeia em 2023, os workshops de fit-gap reduziram as melhorias planejadas em 35%, e a economia chegou a seis dígitos.

Duas regras fazem a planilha funcionar. O fornecedor não deve controlar o escopo, porque cada gap que ele marca como desenvolvimento é trabalho faturável para ele. Uma autoridade de design de negócio e TI é dona das decisões de Clean Core, e modificações no código SAP precisam de um aprovador nomeado; minha estratégia de Clean Core SAP explica os níveis.

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

Log de configuração

Ele registra cada alteração no sistema: quem fez, por quê e em qual transporte entrou. Quando algo quebrar depois, você rastreia o problema em minutos, não em dias.

Cada entrada precisa de:

1. ID da configuração e módulo (por exemplo MM-CONF-001).
2. Caminho de configuração e objeto alterado.
3. Processo de negócio afetado e o motivo.
4. Quem configurou e quando.
5. Número da requisição de transporte.
6. Valores-chave antes e depois.
7. Casos de teste vinculados e status de aprovação.

Registro de desenvolvimentos customizados

Cada objeto customizado ganha uma linha antes que alguém escreva código: ID, descrição, papel do desenvolvedor, esforço, status e tipo de extensão. A coluna do tipo de extensão é onde o Clean Core é aplicado.

Em uma implementação S/4HANA de varejo europeu em 2024, o registro cortou em 30% o código customizado planejado. Ele mostrou onde o SAP padrão funcionaria muito bem.

Estratégia de testes

Ela reúne todos os testes em um só lugar: quem testa o quê, quando, em qual ambiente e com qual padrão.

1. Escopo: testes funcionais, integrados, de regressão, de desempenho e UAT nos módulos do escopo.
2. Ambientes: desenvolvimento, QA, UAT e pré-produção.
3. Ferramentas: gestão de testes no SAP Cloud ALM ou na sua ferramenta atual, com as ferramentas de automação e de desempenho nomeadas.
4. Ciclo de vida dos defeitos, com severidade e prioridade definidas na triagem.
5. Critérios de saída: todos os defeitos críticos fechados, UAT aprovado, uma taxa de aprovação na regressão acordada com antecedência.

O SAP Activate termina o Realize com os testes integrados e os testes de aceitação do usuário. Escreva os critérios de saída antes de os testes começarem, não quando os resultados chegarem.

Plano de migração de dados

A migração de dados é a frente de trabalho com mais chance de machucar você. O plano cobre escopo (parceiros de negócios, materiais, partidas em aberto, saldos), sistemas de origem, regras de mapeamento, ferramentas (o SAP S/4HANA Migration Cockpit), cargas simuladas, validação e rollback.

A validação é a parte que as equipes planejam de menos: acorde contagens de registros, amostragem e conciliação de saldos antes da primeira carga simulada.

No SAP Activate, o Deploy cobre a preparação da produção, o cutover, o go-live e o hypercare. Estes modelos transformam um fim de semana caótico em um evento gerenciado.

Modelo de plano de cutover SAP

O plano de cutover mapeia a janela de indisponibilidade hora a hora. Cada tarefa tem um responsável, um horário de início e uma dependência. Ninguém deveria estar parado às 2h da manhã se perguntando o que fazer em seguida.

Acorde quatro coisas antes de escrever a lista de tarefas: a janela (por exemplo, de sexta às 22h00 a sábado às 06h00), o gatilho de 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:

Passo	Tarefa	Responsável	Início	Status
1	Congelar o sistema legado (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	Carga de migração em produção	Líder de migração de dados	23:00	Pendente
4	Importar os transportes restantes	Basis	00:30	Pendente
5	Comutar interfaces e roteamento de rede	Líder de integração	01:30	Pendente
6	Smoke test: lançamento FI, entrada de mercadorias, ordem de venda	Líder de QA	02:00	Pendente
7	Confirmação do negócio e go/no-go	Diretor do programa	03:00	Pendente
8	Abrir o sistema aos usuários do negócio	Basis	06:00	Pendente

Checklist de prontidão para o go-live

Ele decide se você está realmente pronto para virar a chave. Cada item é respondido com sim ou não, com evidência.

1. Funcional: processos-chave e cenários entre módulos testados, defeitos P1 e P2 em aberto listados, usuários-chave confirmam a prontidão.
2. Dados: dados mestre e transacionais carregados e conciliados, relatórios de conciliação aprovados, congelamento do legado confirmado.
3. Finanças: a configuração do fechamento de período testada para cada empresa e entidade.
4. Técnico: plano de cutover aprovado, transportes em produção, jobs em background agendados, monitoramento configurado.
5. Pessoas: cobertura do treinamento, perfis de acesso validados, equipe de hypercare montada.
6. Decisão: riscos críticos e mitigações, go / no-go / condicional, aprovado com nome, cargo e data.

A linha de finanças está ali por um motivo. Em um programa de varejo no GCC em 2024, a revisão de go-live pegou um problema de configuração do fechamento financeiro em todas as 25 entidades dois dias antes do go-live; ele teria provocado uma recuperação de seis dígitos.

Já usei esta avaliação para recomendar um adiamento de duas semanas em dois programas. É para isso que ela serve.

Modelo de suporte do hypercare

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

1. Janela e cobertura do hypercare, por exemplo quatro semanas com horário estendido.
2. Canais de suporte: a fila de incidentes, um canal de chat e uma ponte telefônica para P1.
3. Níveis de suporte: service desk, consultores funcionais, depois Basis e desenvolvimento.
4. Tempos de resposta e de resolução por severidade.
5. Critérios de saída: nenhum problema P1 ou P2 em aberto e uma passagem assinada para a organização de suporte.

O Run é o suporte e a gestão do sistema em produção. O modelo que a maioria das equipes abandona cedo demais é o que acompanha o desempenho.

Planilha de monitoramento de desempenho

Ela acompanha a saúde do sistema dia a dia, para você perceber lentidões antes que os usuários reclamem. Em um programa de serviços financeiros europeu em 2024, ela pegou um problema de banco de dados na semana 3 do hypercare que teria derrubado o sistema durante o fechamento mensal.

As métricas que acompanho, cada uma com meta, limite de alerta e responsável:

1. Tempo de resposta de diálogo (percentil 95): meta abaixo de 1 segundo, alerta em 2 segundos, Basis.
2. Jobs em background: 100% concluídos no horário, alerta em qualquer falha, líder de operações.
3. Tempo de consulta ao banco de dados: meta abaixo de 200 ms, alerta em 500 ms, administrador de banco de dados.
4. Taxa de erro das interfaces: abaixo de 1%, alerta em 2%, líder de integração.
5. Tempo de execução dos jobs do fechamento mensal: dentro da janela acordada, alerta em 30% acima da linha de base, operações financeiras.

O SAP Activate incorpora quality gates aos roadmaps das fases, com pontos de verificação em cada fase. Meu guia sobre quality gates SAP mostra como configurá-los; aqui está o porquê de eles precisarem ter dentes.

Defina critérios de aprovação e reprovação em cada gate. "95% dos testes de regressão aprovados." "Todos os cenários de integração FI estão verdes." Critérios assim permitem que você segure a linha quando o negócio quer lançar numa data, independentemente da qualidade.

Um quality gate em um programa de indústria europeia em 2024 nos parou quando a taxa de aprovação dos testes integrados estava em 74%. Seguramos, corrigimos os problemas e entramos em produção duas semanas depois. Os chamados de suporte no primeiro mês após o go-live foram metade do que programas comparáveis costumam ter.

A aprovação executiva também não deve ser um carimbo; o problema do fechamento financeiro do varejo no GCC citado acima foi pego exatamente nessa revisão. Um gate que o patrocinador pode derrubar com um telefonema não é um gate. Escreva quem pode dispensá-lo antes de precisar.

Para o processo completo em torno destes modelos, veja meu guia passo a passo de implementação SAP.

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

Onde posso baixar os modelos do SAP Activate?

No SAP Activate Roadmap Viewer, em me.sap.com/roadmapviewer. Abra o roadmap da sua implantação e filtre por fase ou por acelerador para ver os modelos, guias e checklists de cada tarefa.

Em programas na nuvem, o mesmo conteúdo está disponível no SAP Cloud ALM, onde tarefas e entregáveis podem ser acompanhados dentro do projeto.

Quais são os entregáveis do SAP Activate em cada fase?

O Prepare entrega o escopo, o plano, a governança e o business case. O Explore entrega os resultados do Fit-to-Standard, o backlog de requisitos e fit-gap e o desenho da solução. O Realize entrega o sistema configurado e testado, incluindo os testes integrados e os testes de aceitação do usuário.

O Deploy entrega o cutover, o go-live e o hypercare. O Run cobre o suporte e a melhoria do sistema em produção.

Qual fase do SAP Activate tem os modelos mais importantes?

O Prepare. O documento de escopo, o business case e a matriz de partes interessadas definem todas as decisões seguintes, e são eles que as equipes pulam para chegar mais rápido à configuração.

O Explore vem logo atrás, porque a planilha de fit-gap decide a contagem de WRICEF, e é aí que os orçamentos estouram.

É possível personalizar os modelos do SAP Activate?

Sim. Mantenha cerca de 80% da estrutura padrão e mude só o que é específico do seu caso: regras de validação na indústria farmacêutica, compras do setor público, controles SOX. Faça essas mudanças no início do Prepare, não no Deploy.

Não personalize a ponto de eliminar a sequência das fases, os quality gates ou a avaliação de prontidão para o go-live.

O que um modelo de plano de cutover SAP deve incluir?

Uma lista de tarefas cronometrada para a janela de indisponibilidade, com responsável, horário de início e dependência para cada tarefa. Antes da lista, acorde a janela, o gatilho de rollback, o tempo necessário para reativar o sistema legado e os smoke tests.

Acorde quem decide o rollback, e até que horas, antes de o cutover começar. Decisões de rollback tomadas às 4h da manhã sem critérios acordados são onde começam os problemas pós-go-live.

O que entra em um checklist de prontidão para o go-live SAP?

Prontidão funcional, de dados, financeira, técnica e de pessoas, cada uma respondida com sim ou não e com evidência, mais uma decisão de go / no-go registrada com nomes e datas.

Teste a configuração do fechamento de período para cada entidade antes do go-live. É a verificação com mais chance de salvar você de uma recuperação de seis dígitos.

Os modelos do SAP Activate funcionam para greenfield e brownfield?

Sim. A diferença está principalmente no Explore. Uma conversão brownfield leva a configuração adiante, então o fit-gap se concentra no que precisa mudar e em qual código customizado o S/4HANA padrão agora pode substituir; um programa greenfield parte do SAP Best Practices.

O plano de cutover também é diferente, porque uma conversão de sistema segue uma sequência técnica diferente de uma carga de dados greenfield.