Modelo de escopo de projeto SAP: o que definir e o que excluir

Um modelo de escopo de projeto SAP define o que o programa vai entregar, o que deliberadamente não vai entregar, quem é dono de cada parte e como o escopo pode mudar. As nove seções abaixo cobrem tudo isso. As duas que mais importam são justamente as que as equipes pulam: as exclusões explícitas e o escopo de migração de dados. Preencha o modelo antes de começar a configuração e obtenha a assinatura do patrocinador e dos donos de processo.

Às vezes as equipes preenchem um modelo de escopo e seguem em frente. Essa parte parece fácil. Semanas depois, durante o desenho ou a construção, alguém aponta um processo que "se presumia estar no escopo". A conversa fica desconfortável. Ninguém escreveu isso. Ninguém quis deixar de fora. Já vi isso acontecer vezes demais. Algumas premissas não verificadas no início empurram o projeto, em silêncio, semanas para fora do rumo.

A função do documento de escopo não é registrar o que as pessoas disseram na sala. É forçar clareza antes que a configuração cristalize premissas caras de reverter.

São nove seções, cada uma com a pergunta que precisa responder.

1. Objetivos

Por que este trabalho está sendo feito e o que o negócio vai enxergar quando ele terminar? Vincule cada objetivo a um resultado mensurável: reduzir o fechamento mensal em três dias, eliminar as conciliações manuais entre três entidades, ter uma visão única do estoque em todas as plantas. Objetivos vagos geram critérios de sucesso vagos, e a discordância aparece nos testes de aceitação do usuário (UAT).

2. Definição do escopo

Módulos, entidades legais, plantas, países, idiomas, integrações e o modelo de implantação. Seja específico. "Finanças" não é escopo. "Contabilidade Financeira e Controladoria (FI/CO), cobrindo contas a pagar, contas a receber, razão geral e contabilidade de centros de custo da entidade legal dos Emirados Árabes Unidos no S/4HANA Cloud Private Edition" é escopo.

3. Exclusões

É aqui que a maioria dos modelos de escopo falha. Se algo não está escrito como excluído, alguém vai presumir que está incluído. Exclusões a registrar pelo nome:

1. Países ou entidades adiados para uma fase posterior.
2. Integrações legadas mantidas como estão por enquanto.
3. Dados históricos anteriores a uma data de corte definida.
4. Relatórios movidos para uma lista de melhorias pós-go-live.
5. Requisitos regulatórios adiados até a confirmação jurídica.

Indique para cada exclusão a fase para a qual ela vai, se houver. Uma exclusão assinada transforma uma discussão de duas semanas em uma conversa curta.

4. Escopo de migração de dados

Um ponto cego constante. Responda por escrito a três perguntas:

1. O que migra? Apenas itens em aberto ou também o histórico? Todos os clientes e fornecedores ou só os ativos? Materiais de todas as plantas ou apenas das entidades que entram em operação no go-live?
2. Quais são as regras de corte? A data de referência para pedidos de compra, de venda e ordens de trabalho em aberto, e o que acontece com os itens em andamento no cutover.
3. O que é arquivado em vez de migrado? As regras legais de retenção do histórico e por quanto tempo o sistema legado continua acessível para consulta.

Premissas não documentadas aqui viram disputas durante a construção. Meu artigo sobre por que a migração de dados do SAP falha trata desse planejamento em profundidade.

5. Escopo não funcional

Esses itens são deixados de lado no planejamento e aparecem como bloqueios no fim dos testes. Coloque-os no escopo:

1. Disponibilidade e janela de manutenção. No RISE, consulte os termos de disponibilidade do seu contrato.
2. Desempenho no pico de carga, como o fechamento mensal.
3. Registro de auditoria: quais transações e por quanto tempo os logs são mantidos.
4. Segurança e controle de acesso por perfil.
5. Latência dos relatórios: tempo real, quase em tempo real ou diária.

Não são funcionalidades. São restrições que o sistema precisa cumprir. Se não estão no escopo, ninguém projeta para elas.

6. Papéis e responsabilidades

Cada frente de trabalho precisa de um consultor líder e de uma contraparte do negócio com poder de decisão, ambos nomeados. A lacuna que mais vejo é a responsabilidade pelo UAT: quem pode assinar que um processo foi testado e aceito? Decida isso antes do início da construção, não duas semanas antes do go-live.

7. Controle de mudanças

Não basta escrever "mudanças exigem aprovação formal". É preciso um processo específico: o que dispara uma solicitação de mudança, quem avalia o impacto em prazo e orçamento, quem aprova e o que fica registrado. Sem isso, o "podemos incluir isto?" vira "achávamos que isso estava incluído" e depois uma prorrogação de três semanas que ninguém planejou.

8. Regras de extensão

Como o desenvolvimento customizado será aprovado. A SAP agora classifica as extensões do nível A, apenas APIs liberadas, ao nível D, modificações no core (SAP News, agosto de 2025). No Public Edition, sob o GROW, o sistema só permite interfaces liberadas. No Private Edition, sob o RISE, e no on-premise, o core ainda pode ser modificado; por isso o escopo deve declarar o nível-alvo e quem aprova as exceções. Meu guia de clean core explica os níveis.

9. Premissas e restrições

Liste as premissas por trás do escopo para que alguém seja obrigado a verificá-las. Depois as restrições: prazos regulatórios que fixam uma data de go-live, tetos de orçamento, pessoas que atuam só em meio período e datas de desativação do legado.

A personalização é a forma de crescimento descontrolado do escopo que leva mais tempo para aparecer. Um relatório customizado aprovado vira cinco. Uma exceção de workflow vira precedente para todos os pedidos seguintes.

Classifique cada solicitação antes de aprovar qualquer coisa:

Categoria	Teste	O que fazer
Essencial	O processo não funciona, legal ou operacionalmente, sem ela	Aprovar, com a extensão mais barata que seja segura para upgrades
Importante, mas não crítica	Melhora a eficiência, mas não impede a operação	Aprovar apenas com uma justificativa clara de custo-benefício
Desnecessária	Uma preferência ou a cópia de como o sistema legado funcionava	Questionar e depois rejeitar ou adiar

A maioria das personalizações desnecessárias existe porque alguém não queria mudar a forma de trabalhar, não porque o SAP não conseguisse suportar o processo. E o custo de construção é só o começo. Cada objeto customizado acrescenta testes, treinamento, documentação e trabalho de upgrade durante todo o tempo em que existir.

Defina um congelamento de mudanças. Escolha uma data, em geral de quatro a seis semanas antes do go-live, a partir da qual nenhuma nova solicitação é aceita para a release. Tudo o que vier depois vai para o backlog pós-go-live. O congelamento precisa da assinatura do comitê de direção. Uma data anunciada apenas pelo gerente de projeto será ignorada na primeira vez que um diretor de área pressionar.

1. 01Solicitação registradaO que conta como mudança é definido de antemão
2. 02ClassificadaEssencial, importante ou desnecessária
3. 03Impacto avaliadoPrazo e orçamento, por um avaliador nomeado
4. 04DecisãoUm aprovador nomeado aprova, rejeita ou adia
5. 05Escopo versionadoNovo número de versão e lista do que mudou

Depois do congelamento de mudanças, as novas solicitações vão para o backlog pós-go-live

Analytics é onde as conversas sobre escopo esquentam. Todo mundo quer relatórios e ninguém diz quantos.

Combine uma lista fixa de relatórios durante o desenho. Pergunte às pessoas o que precisam, não o que talvez queiram. Marque cada relatório como saída padrão do SAP ou desenvolvimento customizado e assine a lista junto com o restante do escopo. Relatórios padrão custam uma fração dos customizados. Identifique ao mesmo tempo as fontes de dados de cada relatório; um relatório que busca dados de três sistemas é um requisito de integração. Se painéis e planejamento fazem parte do escopo, meu guia do SAP Analytics Cloud mostra o que definir primeiro.

Erro	O que causa	Como evitar
Objetivos não mensuráveis	Disputas no UAT sobre o que significa "funcionando"	Definir resultados mensuráveis desde o início
Exclusões não escritas	Trabalho absorvido sem aprovação	Listar pelo nome o que está fora do escopo
Escopo de migração de dados vago	Volumes errados, cutover atrasado, retrabalho	Definir o que migra, os cortes e o arquivamento
Requisitos não funcionais ausentes	Problemas de auditoria e de desempenho no go-live	Incluir no escopo disponibilidade, desempenho, logs e segurança
Sem donos de UAT nomeados	Testes se arrastam, ninguém consegue aprovar	Nomear pessoas com autoridade
Sem controle de mudanças	Adições informais, testes comprimidos	Escrever o processo de mudanças no escopo
Sem aprovação formal	Escopo questionado depois, sem responsabilização	Patrocinador e donos de processo assinam
Analytics deixado para depois	Pedidos de relatórios duas semanas antes do go-live	Combinar a lista de relatórios durante o desenho
Modelo de implantação ou regras de extensão em aberto	O debate invade a fase de construção	Decidir os dois antes de assinar o escopo

Revise o escopo em cada marco de fase do SAP Activate e depois de cada mudança aprovada, com um número de versão e uma lista do que mudou. O escopo faz parte do termo de abertura do projeto por referência, de modo que os dois documentos contem a mesma história.

O que um modelo de escopo de projeto SAP deve incluir?

Nove seções: objetivos com resultados mensuráveis, definição do escopo (módulos, entidades, países, integrações, modelo de implantação), exclusões explícitas, escopo de migração de dados, requisitos não funcionais, papéis nomeados, controle de mudanças, regras de extensão e premissas com restrições. As exclusões são a seção que mais costuma faltar.

Como evitar o crescimento descontrolado do escopo em projetos SAP?

Escreva as exclusões de forma explícita, faça toda mudança passar por uma solicitação formal com avaliação de impacto e um aprovador nomeado, classifique as personalizações antes de aprová-las e defina um congelamento de mudanças assinado de quatro a seis semanas antes do go-live. O objetivo não é recusar toda mudança. É tornar a mudança visível, avaliada e autorizada.

O que é o escopo de migração de dados em um projeto SAP?

É a definição de quais dados entram no SAP e sob quais regras: quais objetos (clientes, fornecedores, materiais, pedidos em aberto, histórico), as datas de corte e o que é arquivado em vez de migrado. Ele determina o esforço e o cronograma e decide por quanto tempo os sistemas legados precisam continuar acessíveis.

O que é o escopo não funcional em projetos SAP?

São as restrições que o sistema precisa cumprir, em contraste com os processos que ele suporta: disponibilidade, desempenho no pico de carga, registro de auditoria, segurança e controle de acesso e latência dos relatórios. Costumam ficar fora do escopo e só são descobertas nos testes. Em setores regulados, o registro de auditoria é uma obrigação legal.

Como tratar as personalizações no escopo?

Classifique cada solicitação como essencial, importante ou desnecessária. Para cada uma aprovada, registre o requisito, por que o SAP padrão não o atende, o esforço, o impacto nos testes, o custo de manutenção e a abordagem de extensão. No Private Edition e no on-premise, declare o nível-alvo de clean core e quem aprova as exceções.

Quando o escopo de um projeto SAP deve ser revisado?

Em cada marco de fase do SAP Activate, depois de cada solicitação de mudança aprovada e sempre que orçamento, recursos ou cronograma mudarem. Guarde cada versão com data, número de versão e um resumo do que mudou. Esse histórico protege a equipe quando o escopo é questionado mais tarde.