Como criar um comitê de direção eficaz em um projeto SAP

Um comitê de direção de projeto SAP é o pequeno grupo de executivos que toma as decisões que a equipe do projeto não pode tomar: orçamento, mudanças de escopo, conflitos entre departamentos e o go/no-go final. Funciona quando os membros têm autoridade de verdade, se reúnem com frequência suficiente para decidir na própria reunião e avaliam a prontidão com base em evidências, e não no calendário. Este guia é para patrocinadores e diretores de programa que estão montando um comitê ou consertando um que virou plateia de relatórios de status. Cobre o que o comitê precisa decidir, os membros por porte de projeto, como as decisões devem funcionar, um checklist de go/no-go e o que o RISE with SAP e as ferramentas de IA mudam.

Nunca vi um projeto SAP ter sucesso com um comitê de direção fraco. É no comitê que as decisões difíceis acontecem. Ou acontecem em tempo real, ou se acumulam até explodir no cutover.

Em uma implantação de SAP, o comitê se reunia uma vez por mês. A equipe do projeto apontou fluxos de aprovação quebrados, testes incompletos e treinamento ausente. A liderança disse que iria “analisar”. Nunca analisou. O projeto entrou em operação, e o financeiro passou os seis meses seguintes arrumando a casa.

Em outra empresa, o comitê se reunia toda semana e tomava decisões de verdade. Quando os testes revelaram lacunas, realocou recursos. Quando um processo não funcionava, corrigiu. Esse projeto entrou em operação sem sustos.

Um comitê liderou. O outro ficou em reuniões.

Se o comitê só recebe relatórios de status, ele já está falhando. A tabela mostra a diferença na prática.

Função	Como é o bom	Como é o fraco
Decisões importantes	Analisa o caso e decide na hora	“Vamos discutir fora da reunião”; o assunto volta no mês seguinte
Impedimentos	O RH está atrasando os testes? Quem preside liga direto para o chefe do departamento	Reconhece o problema e o registra
Escopo	Pesa cada solicitação de mudança contra o plano	Carimba o que for escalado com mais barulho
Risco	Vê um fornecedor com dificuldades e providencia um reserva antes que os atrasos cheguem	Espera para ver se resolve sozinho
Orçamento	Aprova US$ 2 milhões extras para estender o projeto por três meses porque a ruptura custaria mais	Empurra para o mês seguinte
Go/no-go	Adia o go-live em seis semanas porque os testes não estão completos e não recua	Aprova o go-live porque a data está no calendário

A última linha é a que mais importa. Já vi comitês adiarem go-lives mesmo quando as equipes queriam seguir em frente. O comitê de um cliente farmacêutico adiou o go-live em seis semanas porque os testes não estavam completos. Decisão difícil, mas o livrou de um desastre.

Com membros demais, o comitê não consegue decidir. Com poucos, faltam vozes críticas.

Porte do projeto	Orçamento e escopo	Membros	Quem precisa estar na sala
Pequeno	Menos de US$ 0,5 milhão, um departamento, menos de 6 meses	3 a 5	Chefe do departamento, líder de TI, representante do financeiro
Médio	De US$ 0,5 milhão a US$ 5 milhões, vários departamentos, 6 a 18 meses	5 a 8	Líderes de negócio dos departamentos afetados, liderança de TI, financeiro
Grande	Mais de US$ 5 milhões, toda a empresa, 18 meses ou mais	8 a 12	C-level de finanças, RH, operações e TI; gerente do programa; líder de gestão de mudanças

A regra que aplico: inclua pessoas com autoridade real de decisão. Já vi comitês fracassarem porque cargos seniores não podiam aprovar nada sem consultar outra pessoa. Se o CFO não puder comparecer, envie alguém com mandato genuíno para decidir, não para voltar e relatar.

Quem preside o comitê deve ser o patrocinador do projeto, em geral um executivo de nível C que consegue cobrar outros executivos. Um gerente de nível médio na presidência não consegue contrariar um CFO, e essa autoridade importa quando surgem conflitos de escopo ou de orçamento.

Com base em evidências. Trabalhei com um cliente industrial cuja equipe de TI dizia que uma mudança de processo acrescentaria três meses. A área de negócio insistia que era “simples”. O comitê se recusou a decidir antes de ver estimativas de esforço, análise de dependências e planejamento de capacidade. A TI tinha razão. O comitê acertou porque exigiu evidências em vez de ficar do lado de quem falava mais alto.

Rápido. Já vi um cliente cujo comitê se reunia a cada duas semanas, mas sempre terminava com “vamos discutir isso fora da reunião”. Os problemas se acumularam até o projeto ficar seis meses atrasado. O comitê de outro cliente decidia na própria sala, e o projeto terminou antes do prazo e abaixo do orçamento. Comitês lentos produzem projetos atrasados.

Com autoridade explícita. Comitês eficazes podem contrariar chefes de departamento, aprovar orçamento não planejado e rejeitar acréscimos de escopo no meio do caminho. Se esses poderes não estiverem escritos e entendidos, o comitê vira consultivo, e comitês consultivos não entregam projetos SAP.

Sobre o escopo, com seletividade. Em um dos meus clientes, um departamento de repente exigiu 20 relatórios extras. O comitê perguntou se cada um era necessário agora e se quebraria o cronograma. Aprovou cinco relatórios críticos e deixou o resto para depois do go-live. Essa decisão provavelmente salvou a data do go-live.

Mantenha as reuniões entre 60 e 90 minutos. Principais riscos, as decisões específicas que precisam ser tomadas e ações com responsáveis e prazos. Nada de atualizações técnicas que poderiam ser lidas antes. Se o mesmo assunto aparece em três reuniões seguidas sem solução, você tem um problema de governança, não de complexidade.

Use dados, não apresentações. Trabalhei com um cliente do setor de energia que montou um painel com execução de testes, resolução de defeitos, conclusão de treinamento e consumo de orçamento. As reuniões deixaram de ser sobre entender em que pé as coisas estavam e passaram a ser sobre resolver problemas.

Mostre o sistema ao comitê. O comitê de um cliente farmacêutico percorreu um cenário de “um dia na vida”. Percebeu que o design aprovado obrigaria a equipe a usar cinco telas diferentes em um processo comum. Mandou refazer o design na hora.

Planeje para a política. A falha mais comum não é incompetência. São departamentos protegendo território e equipes adiando testes por causa do trabalho de fim de ano. Em um projeto, o RH não parava de adiar os testes da folha de pagamento porque estava ocupado com as tarefas de fim de ano. O comitê repriorizou o trabalho e designou testadores reserva, e o projeto ficou nos trilhos em vez de escorregar por meses.

Use verificações independentes nos principais gates. Um cliente industrial pediu a revisores externos que avaliassem sua prontidão antes de aprovar o go-live. A revisão encontrou vários problemas sérios que a equipe do projeto tinha deixado passar ou minimizado. Meu guia sobre quality gates do SAP mostra como estruturar esses pontos de controle.

A pressão do calendário é a base errada para aprovar o go-live. Antes da votação, o comitê deve ver evidências de cada um destes pontos:

1. Testes de integração e de aceitação do usuário concluídos, sem defeitos críticos em aberto
2. Última migração simulada de dados reconciliada e assinada pelo financeiro
3. Ensaio do cutover concluído dentro da janela planejada
4. Usuários-chave treinados, com suporte presencial e material de apoio prontos
5. Prontidão do negócio confirmada por escrito por cada dono de processo
6. Plano de rollback testado e acordado
7. Equipe de hypercare, caminho de escalonamento e suporte ao primeiro fechamento em vigor

Se algum item estiver vermelho, um comitê forte diz não. Um atraso de seis semanas é recuperável. Um go-live fracassado que atrapalha as operações ou o fechamento financeiro pode levar meses para se estabilizar. Já arrumei go-lives demais que foram aprovados porque a data parecia imóvel. Alimente a pauta do comitê a partir de um registro de riscos atualizado, para que esses itens apareçam cedo.

O RISE traz a SAP para o modelo de governança. No RISE with SAP, a SAP opera a infraestrutura e as operações técnicas. O documento de papéis e responsabilidades do RISE, da SAP, prevê que os clientes trabalhem com um SAP Cloud Architect Advisor, um Client Delivery Manager ou o centro de atendimento de nuvem privada da SAP. Para questões de plataforma, como desempenho, disponibilidade ou níveis de serviço, o comitê precisa de um caminho até esses contatos que não passe pelo parceiro de implementação. Convide-os para os itens de pauta relevantes, e não como membros permanentes.

Um fórum de clean core fica abaixo do comitê. Em programas RISE, crie uma autoridade de design (design authority) que aprove ou rejeite pedidos de customização com base nos princípios de clean core. Ela só escala para o comitê quando um pedido crítico para o negócio é bloqueado. Sem essa camada, toda customização vira briga no comitê. On-premise, o modelo tradicional continua valendo e a SAP é fornecedora, não participante.

1. Comitê de direçãoPresidido pelo patrocinador. Orçamento, escopo, conflitos, go/no-go
   Contatos de entrega da SAPConvidados para itens de plataforma, sem passar pelo parceiro

• Escritório de gerenciamento do programaExecução diária, registro de riscos, coordenação
• Autoridade de design de clean coreDecide sobre customizações, escala só pedidos críticos bloqueados

A IA economiza tempo na papelada. O Microsoft 365 Copilot redige atas a partir da reunião gravada. O trabalho passa a ser revisar um rascunho em vez de escrever do zero, e as decisões vêm da transcrição. O Rovo, da Atlassian, consegue transformar anotações de reunião em entradas estruturadas de um registro de decisões, depois que o modelo é montado. Assistentes baseados no Joule no SAP Cloud ALM podem redigir uma primeira avaliação de impacto para um pedido de escopo, de modo que o comitê decida na reunião em vez de adiar.

Deixe a análise de sentimento de lado por ora. Alguns fornecedores vendem a análise de sentimento das comunicações do programa como insumo para o comitê. Na maioria dos programas, é teatro: o sinal é fraco, os falsos positivos são comuns e ser visto monitorando o sentimento tem custo político. Só em programas muito grandes ela pode sinalizar cedo grupos que estão se desengajando. Para a maioria dos comitês, não é onde gastar o orçamento de IA.

Qual é o papel de um comitê de direção em um projeto SAP?

Tomar as decisões que a equipe do projeto não pode tomar: aprovações de orçamento, mudanças de escopo, escalonamento de recursos e o go/no-go final. Resolve conflitos entre departamentos e cobra dos chefes de departamento os compromissos de testes e treinamento. Se só recebe atualizações de status, não está fazendo o seu trabalho. O valor está nas decisões tomadas, não nas reuniões a que se comparece.

Quantas pessoas devem fazer parte de um comitê de direção SAP?

De três a cinco em um projeto pequeno, de um único departamento; de cinco a oito em um projeto médio; de oito a doze em um programa grande. A falha mais comum é gente demais: um comitê de 20 vira plateia de apresentação. Todo membro deve ter autoridade real de decisão sobre alguma coisa. No RISE, chame os contatos de entrega da SAP para os itens de plataforma, e não como membros permanentes.

Como o RISE with SAP muda o comitê de direção?

A SAP passa a participar da entrega na infraestrutura e nas operações técnicas, então o comitê precisa de um caminho direto até os contatos designados da SAP, que não passe pelo parceiro de implementação. Ele também precisa de uma autoridade de design de clean core abaixo dele para tratar os pedidos de customização, escalando apenas os pedidos bloqueados que sejam críticos para o negócio. On-premise, a SAP continua sendo fornecedora.

Qual é a diferença entre um comitê de direção e um PMO?

O escritório de gerenciamento de projetos (PMO) conduz a execução do dia a dia: tarefas, registros de riscos e coordenação entre as frentes de trabalho. O comitê de direção toma as decisões que o PMO não pode tomar: remanejamento de orçamento, mudanças de escopo e go/no-go. Em organizações maiores, um comitê no nível do portfólio fica acima de vários projetos e distribui recursos entre eles.

O que deve constar na pauta de um comitê de direção?

Decisões, não atualizações. Comece pelos três a cinco principais riscos, depois as decisões específicas que precisam de aprovação, depois os conflitos entre departamentos a resolver e, por fim, as ações da última reunião com responsáveis e prazos. Se um item aparece três vezes sem solução, escale a forma como ele está sendo tratado em vez de discuti-lo de novo.

Quando o comitê de direção deve adiar o go-live?

Quando os testes não estão completos, os usuários-chave não foram treinados, a migração de dados não está reconciliada, uma integração crítica está instável ou o plano de rollback não foi testado. Um adiamento quase sempre sai mais barato do que a limpeza pós-go-live. Um atraso de seis semanas é recuperável; um go-live fracassado que atrapalha a cadeia de suprimentos ou o fechamento financeiro pode levar meses para se estabilizar.