Quality gates no SAP: como configurá-los e onde falham

Um quality gate é um ponto de controle formal entre as fases do projeto. Antes de a equipe avançar, ela precisa demonstrar que os critérios acordados foram atendidos. Passou, segue em frente. Reprovou, corrige os problemas primeiro. Em um programa SAP, os gates ficam nas transições de fase do SAP Activate, cada um com um responsável nomeado que tem autoridade para dizer “ainda não está pronto”.

Uma grande empresa de bens de consumo em Singapura estava implantando o SAP em escala global. A equipe correu com os testes para cumprir os prazos. Vi esse desastre acontecer. Os testes de usuário mal foram feitos, mas os executivos insistiram no lançamento mesmo assim. Em poucos dias, os problemas apareceram: configurações ausentes, fluxos de trabalho quebrados, dados completamente errados. As semanas de caos depois do lançamento foram causadas por problemas que já eram visíveis antes do go-live. Ninguém parou para verificar.

Eu nunca pulo as revisões de quality gate. Sem atalhos, sem carimbos. Dá mais trabalho no início e poupa meses de limpeza depois.

Um gate é um ponto de decisão com um padrão escrito, aprovação documentada e autoridade real para adiar o projeto. Não é uma revisão de andamento nem uma atualização de status do comitê de direção.

Sem essa autoridade, as revisões viram carimbos. E gates de fachada são piores do que nenhum, porque criam falsa confiança. Um cliente do varejo fazia “revisões” que eram, na prática, carimbos. Seis meses depois, estava irremediavelmente atrasado, porque ninguém tinha tratado os problemas que essas revisões deveriam ter pego.

O SAP Activate tem seis fases: Discover, Prepare, Explore, Realize, Deploy e Run. Cada transição é um gate natural. Isto é o que espero que cada gate verifique.

Gate da fase	Foco de qualidade	Evidência a ver	Aprovado quando
Discover	Business case, alinhamento executivo	Business case, roadmap de alto nível	Business case assinado, patrocinador comprometido
Prepare	Governança, equipe, riscos	Termo de abertura, modelo de governança, registro de riscos	Termo de abertura aprovado, responsáveis pelos riscos nomeados, equipe integrada
Explore	Fit-to-standard, desenho, abordagem de integração	Decisões de fit-gap, desenhos de processo, arquitetura de integração	Donos de processo aprovaram; todo gap tem uma decisão
Realize	Configuração, testes de integração	Relatórios de execução de testes, log de defeitos	Limites de teste atingidos, defeitos críticos fechados
Deploy	Dados, treinamento, prontidão do cutover	Reconciliação da migração, registros de treinamento, plano de cutover	Ensaio geral concluído, plano de rollback acordado
Run	Estabilização e transferência	Log de incidentes, relatórios de desempenho	Incidentes dentro dos limites acordados, transferência ao suporte assinada

Na prática, Explore, Realize e Deploy concentram o maior risco. Um problema que passa por uma dessas três fases custa mais caro quando aparece depois do go-live.

1. 01DiscoverBusiness case assinado, patrocinador comprometido
2. 02PrepareTermo de abertura aprovado, responsáveis pelos riscos nomeados
3. 03ExploreTodo gap tem uma decisão
4. 04RealizeLimites de teste atingidos, defeitos críticos fechados
5. 05DeployEnsaio geral feito, rollback acordado
6. 06RunIncidentes dentro dos limites, transferência assinada

Cada gate assinado por um responsável com autoridade para dizer que ainda não está pronto

Escreva os critérios de entrada e de saída de cada gate no termo de abertura do projeto antes de a configuração começar. Critérios escritos sob pressão de prazo descrevem o que a equipe consegue mostrar hoje, não o que o projeto precisa. Um cliente tentou combinar fases para “ganhar tempo”. Acabou refazendo semanas de trabalho.

Critérios com resposta sim ou não

“Testes concluídos” não é um critério. Gera discussão. Trabalhei com um cliente do varejo cujo gate dizia apenas “UAT concluído”. Metade da equipe entendia que todos os testes tinham sido executados; a outra metade, que todos os defeitos tinham sido corrigidos.

“95% dos casos de teste executados, todos os defeitos de prioridade 1 resolvidos, nenhum defeito de prioridade 2 em aberto há mais de cinco dias” é um critério. Produz uma resposta.

Os gates de um cliente de manufatura falharam porque os critérios eram vagos demais. Ninguém sabia se tinham realmente passado. Quando os critérios viraram limites mensuráveis, as discussões sobre a transição de fase acabaram.

Um responsável com autoridade para adiar

Todo gate precisa de um responsável nomeado que possa adiar o projeto. Uma pessoa, não um comitê. Vi um projeto naufragar porque ninguém tinha poder para adiar a fase seguinte, embora a equipe não estivesse pronta.

O contrário funciona. Um cliente do varejo nomeou um diretor sênior como responsável pelo gate. Quando ele dizia “não está pronto”, todos ouviam. Coloque essa autoridade no termo de abertura.

Apoio executivo antes de a pressão chegar

Executivos adoram quality gates até que um gate ameace um prazo. Um CIO passou por cima de um gate reprovado para cumprir a meta trimestral. Os problemas resultantes custaram o dobro do que custaria o atraso. Já vi esse padrão se repetir muitas vezes, por isso hoje peço o aval executivo ao framework de gates antes de o projeto começar.

Evidência do sistema de registro

As decisões do gate precisam de evidência: relatórios de execução de testes, logs de defeitos, aprovações de processos, reconciliações de migração. Extraia tudo da ferramenta, não do que as pessoas dizem que está pronto. Um dos meus clientes descobriu, pelos relatórios do Solution Manager, que 40% dos seus casos de teste “concluídos” nunca tinham sido executados. Eles pegaram isso antes do gate, não depois.

1. Associe os gates às transições de fase. No SAP Activate, no mínimo depois de Prepare, Explore, Realize e Deploy. Um cliente do setor de energia criou pontos de controle aleatórios entre as fases e acabou com uma bagunça.
2. Defina critérios de entrada e de saída antes de a configuração começar. Acorde a cobertura de testes, os limites de defeitos e os donos de processo que devem assinar. Coloque tudo no termo de abertura e obtenha a assinatura do patrocinador.
3. Agende os gates com folga. Coloque cada gate no calendário como uma atividade, não só como um marco. Um dos meus clientes do varejo reservava uma semana inteira antes de cada gate apenas para a limpeza.
4. Escolha revisores que possam decidir. Os líderes de negócio aprovam os processos. Os líderes técnicos aprovam a configuração e a integração. Consultores nunca assinam pelo negócio.
5. Mantenha a evidência em um só lugar. Seis meses depois, um auditor vai perguntar quem aprovou a migração de dados. A resposta deve levar minutos para ser encontrada.
6. Torne os resultados visíveis. Um cliente colocou o painel de gates na parede da sala do projeto. Era impossível ignorar.

Exemplo de critérios de saída para os dois gates mais importantes

Gate Realize:

1. Execução de testes igual ou acima do limite acordado, com os resultados armazenados na ferramenta de testes.
2. Nenhum defeito de prioridade 1 em aberto; defeitos de prioridade 2 dentro do prazo máximo acordado.
3. Todo processo crítico aprovado pelo respectivo dono de processo nomeado.
4. Testes de integração executados em cadeias de processo completas, com resultados documentados.
5. Todo desenvolvimento customizado aprovado de acordo com as regras de clean core do programa.

Gate Deploy:

1. Ensaio geral da migração de dados concluído e reconciliação assinada pelo líder de dados.
2. Conclusão do treinamento por perfil igual ou acima do limite acordado.
3. Plano de cutover ensaiado, com cronogramas e pontos de decisão go/no-go.
4. Plano de rollback documentado e testado.
5. Equipe de hypercare nomeada, com caminhos de escalonamento e definições de severidade acordados.

Se o gate Deploy mostrar exceções de reconciliação não resolvidas ou usuários sem treinamento e o negócio ainda assim quiser seguir, faça disso uma decisão documentada, com um signatário nomeado. Não um padrão porque ninguém quis dizer não.

Duas coisas mudaram a forma como desenho os gates nos programas atuais.

Clean core agora é um critério de gate. A SAP classifica as extensões do nível A (apenas interfaces liberadas) ao nível D (modificações e gravações diretas em tabelas). No gate Explore, todo gap deve ter uma decisão: configurar, desenvolver como extensão com API liberada ou rejeitar. No gate Realize, verifique se nenhum objeto novo de nível D entrou escondido. A Public Edition impõe isso tecnicamente. A Private Edition e o on-premise não impõem, então é o gate que garante.

O SAP Cloud ALM é a ferramenta padrão. Está incluído nas assinaturas cloud da SAP com Enterprise Support, cloud edition, e no SAP Enterprise Support para clientes on-premise (SAP Support). Cobre fit-to-standard, atribuição de tarefas, orquestração de testes e rastreabilidade. A manutenção mainstream do SAP Solution Manager 7.2 termina no fim de 2027, e a SAP recomenda migrar para o Cloud ALM antes disso (SAP Support). Se você está no meio de um programa no Solution Manager, termine nele. Planeje os novos programas em torno do Cloud ALM.

Ferramentas para gerenciar gates

A ferramenta importa menos do que a disciplina. Um cliente do varejo montou um processo de gates limpo no SharePoint que funcionou muito bem em uma implementação de porte médio. Também já vi gates falharem em uma configuração completa do Solution Manager porque a equipe mantinha planilhas paralelas.

Ferramenta	Papel na gestão de gates	Ideal para
SAP Cloud ALM	Fit-to-standard, tarefas, testes, rastreabilidade	Novos programas S/4HANA, cloud ou on-premise
SAP Solution Manager 7.2	Acompanhamento de projeto, gestão de testes e defeitos	Programas que já rodam nele
Jira e Confluence	Tarefas, defeitos, critérios e evidência dos gates	Equipes que já usam ferramentas Atlassian
Tricentis Tosca	Automação de testes e relatórios de cobertura	Programas com forte automação de testes
ServiceNow	Fluxos de aprovação e trilha de auditoria	Empresas que já usam ServiceNow

Qualquer que seja a escolha, ela precisa ser a fonte única da verdade. Uma planilha paralela sempre mostra a versão que a equipe quer mostrar. Minha comparação de ferramentas de teste e validação SAP aprofunda o lado dos testes.

Pulados sob pressão de prazo. Quando os projetos atrasam, os gates são a primeira coisa a ser cortada. Em um projeto, as revisões viraram carimbos e o go-live foi um pesadelo: os sistemas caíram, os pedidos travaram e eles fizeram rollback completo. As três semanas que “economizaram” custaram três meses de recuperação.

Critérios vagos. Já tratado acima. Se um critério precisa de interpretação, é só um ponto de partida para conversa.

Revisores sem tempo. Quando os principais revisores estão divididos entre vários projetos, as revisões viram preenchimento de checklist. A revisão do gate Realize em um programa de porte médio deveria levar pelo menos meio dia, com a evidência lida antes.

Cultura. Equipes acostumadas a atropelar marcos procuram formas de contornar os gates. Isso muda quando um executivo diz na abertura que os gates são obrigatórios e depois prova isso recusando-se a passar por cima do primeiro que causar um atraso.

Três números que mostram se os gates funcionam

Acompanhe estes números para saber se os gates estão protegendo o projeto ou só parecem protegê-lo.

1. Vazamento de defeitos: a parcela dos defeitos encontrados depois de um gate que o gate deveria ter pego.
2. Taxa de aprovação na primeira tentativa: se todo gate passa de primeira, os critérios provavelmente não têm força.
3. Incidentes no go-live: incidentes de alta prioridade nos primeiros 30 dias são um veredito direto sobre o gate Deploy.

Os gates pertencem ao termo de abertura desde o primeiro dia. Meu guia do termo de abertura de um projeto de implementação SAP mostra onde eles se encaixam, e o guia do comitê de direção trata de quem deve ter a autoridade para fazê-los valer.

O que é um quality gate em projetos SAP?

Um ponto de controle formal entre as fases do projeto. A equipe precisa demonstrar que critérios específicos e mensuráveis foram atendidos antes de avançar. Cada gate tem um responsável nomeado com autoridade para adiar o projeto. No SAP Activate, os gates ficam nas transições de fase, especialmente depois de Explore, Realize e Deploy.

Quais são os quality gates no SAP Activate?

O SAP Activate tem seis fases (Discover, Prepare, Explore, Realize, Deploy e Run), e cada transição é um gate. Discover verifica o business case. Prepare verifica a governança e o termo de abertura. Explore verifica a aprovação do desenho e as decisões sobre gaps. Realize verifica os resultados de teste e os defeitos. Deploy verifica dados, treinamento e prontidão do cutover. Run verifica a estabilização e a transferência.

O que os critérios de quality gate no SAP devem incluir?

Critérios com resposta sim ou não. Para Realize: limites de execução de testes, defeitos em aberto por prioridade, aprovações dos donos de processo e resultados dos testes de integração. Para Deploy: reconciliação da migração, conclusão do treinamento por perfil, um plano de cutover ensaiado, um plano de rollback testado e uma equipe de hypercare alocada. Cada critério precisa de um responsável que produza a evidência.

Por que os quality gates falham em implementações SAP?

Eles são pulados sob pressão de prazo, os critérios são vagos, os revisores não têm tempo de se preparar ou um executivo passa por cima de um gate reprovado. A causa raiz é tratar os gates como burocracia em vez de proteção.

Qual ferramenta devo usar para gerenciar quality gates no SAP?

Para novos programas, o SAP Cloud ALM. Ele está incluído nas assinaturas cloud da SAP e no Enterprise Support, e oferece suporte a fit-to-standard, testes e rastreabilidade. O SAP Solution Manager 7.2 sai da manutenção mainstream no fim de 2027. Jira, Tricentis Tosca e ServiceNow funcionam bem onde a empresa já os utiliza. A regra é uma única fonte da verdade.

Como avaliar a prontidão para o go-live no último quality gate?

Verifique cinco itens com evidência: migração de dados ensaiada e reconciliada, treinamento concluído para cada perfil, plano de cutover ensaiado com pontos go/no-go, plano de rollback testado e hypercare com equipe alocada e caminhos de escalonamento. Se algum falhar e o negócio ainda quiser seguir, registre como uma decisão de negócio assinada.