SAP Activate: as fases de um projeto SAP e o que exigir em cada uma

SAP Activate é a metodologia oficial da SAP para projetos de implementação e migração. Não é um manual burocrático — é uma sequência de fases com entregáveis definidos, e sua principal utilidade prática é dar ao cliente uma régua objetiva para saber se o projeto está indo bem.

Este artigo percorre as seis fases com foco no que interessa a quem contrata: o que exigir ao final de cada uma e quais sinais indicam problema.

Fase 1 — Discover

O que acontece: avaliação do cenário atual e da viabilidade do projeto. Inventário de customizações, mapa de integrações, diagnóstico de dados mestres e execução do SAP Readiness Check quando há sistema existente.

O que exigir ao final: um relatório com as rotas de migração possíveis, prazo estimado e faixa de investimento para cada uma. Se o relatório recomenda uma única rota sem apresentar as alternativas, você recebeu uma proposta comercial, não um assessment.

Sinal de alerta: fornecedor que quer pular esta fase "para ganhar tempo". O tempo economizado aqui reaparece multiplicado na fase Realize.

Fase 2 — Prepare

O que acontece: montagem do time, definição de governança, provisionamento de ambientes e plano de projeto detalhado.

O que exigir ao final: a matriz de decisão. Quem decide o quê, em quanto tempo, e o que acontece quando não há acordo. Esta é a entrega mais subestimada de todo o projeto e a que mais evita atraso.

Sinal de alerta: plano de projeto sem nomes. Se as atividades do cliente não têm responsável nominal com alocação acordada, elas não vão acontecer no prazo.

Fase 3 — Explore

O que acontece: os workshops de fit-to-standard. O time percorre processo a processo comparando a operação atual ao padrão do S/4HANA. Cada diferença encontrada é uma lacuna que precisa de decisão: aderir ao padrão, configurar ou desenvolver.

O que exigir ao final: o backlog de lacunas com decisão registrada para cada item, e o custo estimado das que exigem desenvolvimento. Lacuna sem decisão registrada vira discussão na fase de testes, quando corrigir é caro.

Sinal de alerta: quando a resposta padrão para toda lacuna é "vamos desenvolver". Um projeto com desenvolvimento demais na fase Explore é um projeto que vai estourar prazo e que está recriando o passivo técnico que a migração deveria eliminar.

Esta é a fase mais importante do projeto e a que mais depende do cliente. É aqui que a velocidade de decisão da sua empresa determina o cronograma inteiro.

Fase 4 — Realize

O que acontece: configuração, desenvolvimento, migração de dados e ciclos de teste. É a fase mais longa e onde o esforço se concentra.

O que exigir ao final: no mínimo dois ciclos completos de teste integrado mais um teste de aceitação conduzido por usuários-chave, com evidência registrada. E o resultado de pelo menos um ensaio de migração de dados com volume de produção.

Sinal de alerta: ciclo de teste sendo encurtado para recuperar cronograma. É a decisão que mais frequentemente transforma um atraso de semanas em um hypercare de meses.

Fase 5 — Deploy

O que acontece: preparação e execução do cutover — a virada do sistema antigo para o novo.

O que exigir ao final: o plano de cutover cronometrado, testado em ensaio, e o plano de rollback documentado. Você precisa saber, antes da virada, exatamente quanto tempo cada atividade leva e qual é o ponto de não retorno.

Sinal de alerta: cutover sem ensaio prévio. Ensaiar significa executar o roteiro inteiro em ambiente de homologação, com cronômetro. Sem isso, a janela de virada é uma estimativa, não um plano.

Fase 6 — Run

O que acontece: hypercare — período de suporte intensivo pós go-live com o mesmo time do projeto — seguido de transição para a sustentação regular.

O que exigir ao final: a documentação completa entregue em formato editável, a transferência de conhecimento realizada e registrada, e o plano de sustentação definido, seja com time interno ou em contrato de AMS.

Sinal de alerta: time do projeto desmobilizado antes do primeiro fechamento contábil completo no sistema novo. O fechamento é o teste real da implantação, e ele acontece depois do go-live.

O que a metodologia não resolve

SAP Activate organiza o trabalho, mas não substitui três coisas que dependem inteiramente do cliente:

Patrocínio executivo real. Projeto sem patrocinador com autoridade para decidir processos entre áreas vira negociação permanente.

Disponibilidade dos key users. Se as pessoas que conhecem o processo continuarem com carga integral na operação, os workshops de fit-to-standard produzem decisões rasas — e decisão rasa aparece como retrabalho na fase Realize.

Disposição para aderir ao padrão. A promessa de eficiência do S/4HANA está no padrão. Cada exceção customizada é um pedaço dessa promessa que fica pelo caminho, e uma linha a mais no custo de manutenção de cada upgrade futuro.