Planejamento e controle de projetos SAP: mantenha o rumo

A maioria dos programas SAP tem um plano. Bem menos têm controle. O planejamento define escopo, cronograma, orçamento e riscos. O controle é o trabalho semanal de acompanhar o progresso em relação a esse plano, gerenciar dependências, escalar cedo e avaliar cada mudança antes de aprová-la. Este guia é para diretores de programa, PMOs e patrocinadores cujo programa SAP está à deriva, ou que querem impedir que isso aconteça. Ele cobre como é o controle, três fracassos públicos que mostram o que acontece sem ele e uma cadência semanal de controle, com responsáveis, que você pode adotar ainda esta semana.

Quando eu estava começando, trabalhei em um programa SAP que parecia ótimo no papel. Cronogramas, registros de riscos, logs de mudanças, tudo o que você esperaria. Ninguém seguia. O comitê de direção raramente se reunia. As finanças esperavam a migração de dados. A TI ainda não tinha começado. Ninguém acompanhava as dependências. Todos presumiam que outra pessoa estava mantendo tudo no rumo.

No sexto mês, metade do projeto estava atrasada e estávamos correndo atrás dos nossos próprios erros. O pior é que ninguém viu isso chegando.

Não era um problema de planejamento. Era um problema de controle. Não havia alocação real de recursos, nem mitigação de riscos adequada, nem caminho de escalonamento. O plano tinha sido produzido uma vez e depois abandonado em favor de reuniões.

O planejamento cobre escopo, cronograma, orçamento, recursos, o registro de riscos e os compromissos de marcos. A maioria das equipes produz isso. A questão é se alguém usa isso semana a semana.

O controle cobre acompanhar o progresso real em relação ao plano, levantar variações cedo, gerenciar dependências, escalar quando as coisas escorregam e refazer a linha de base quando escopo ou prazo mudam formalmente. A maioria das equipes faz isso mal.

1. 01Acompanhar o progressoReal versus plano, por pacote de trabalho
2. 02Levantar variaçõesQualquer tarefa com três dias de atraso
3. 03Verificar dependênciasQuem fica bloqueado se isso escorregar
4. 04EscalarPor um caminho combinado de antemão
5. 05Avaliar mudançasPrimeiro tempo, custo e recursos
6. 06Refazer a linha de baseSó depois de uma mudança formal

Toda semana, com responsáveis nomeados

Veja o que quebra quando falta controle:

O que quebra sem controle	Por que acontece
Os prazos escorregam em silêncio	Ninguém confere entre as revisões de marco
As premissas ficam sem verificação	Cada equipe espera que outra cuide da dependência
O escopo se expande informalmente	Mudanças aprovadas em reuniões, sem avaliação de impacto
Riscos ignorados até se concretizarem	Registro de riscos atualizado a cada trimestre, e não toda semana
Os custos passam do orçamento	O esforço está nas planilhas de horas, mas não é associado a pacotes de trabalho
As equipes param de se comunicar	As reuniões de status viram atualizações sem ações

São casos públicos, não histórias de clientes. As causas-raiz são as que vejo repetidamente no trabalho de consultoria.

Lidl: cerca de sete anos e uma estimativa de € 500 milhões, e depois a interrupção

A Lidl iniciou seu projeto eLWIS no SAP Retail em 2011. A prática de avaliação de estoque da empresa diferia do modelo padrão da SAP, e a Lidl optou por adaptar o software em vez da prática. Em 2018 o sistema estava no ar na Áustria, na Irlanda do Norte e nos EUA, mas o conselho concluiu que os objetivos originais não eram alcançáveis a um custo razoável. A Lidl interrompeu o projeto e voltou a desenvolver seu sistema próprio. A imprensa especializada estimou o gasto em cerca de € 500 milhões, e o membro do conselho responsável por TI tinha saído em 2017. A Heise noticiou a decisão em julho de 2018. A lição: anos de customização para proteger uma prática legada são uma falha de controle, não uma falha do software.

Hershey: cerca de US$ 100 milhões em pedidos de Halloween não entregues

O novo sistema de SAP, Siebel e Manugistics da Hershey estava planejado para entrar em produção em abril de 1999, um mês tranquilo para o mercado de doces. Atrasou três meses e entrou em produção em julho, quando os pedidos de Halloween começavam a chegar. Os pedidos não conseguiam ir do sistema para os armazéns. O CEO disse aos analistas que os problemas impediriam a Hershey de entregar cerca de US$ 100 milhões em produtos para o Halloween, e as vendas do terceiro trimestre caíram 12,4%. O relato da revista CIO atribui a falha real ao momento escolhido. Um controle de cronograma que protegesse a alta temporada teria forçado outra data de go-live.

Revlon: uma fábrica desorganizada e uma deficiência material nos controles

A Revlon colocou o SAP no ar em sua fábrica de Oxford, na Carolina do Norte, sua maior unidade de manufatura, em fevereiro de 2018. Interrupções de serviço atingiram a manufatura e as remessas para grandes varejistas dos EUA. Em março de 2019 a Revlon divulgou uma deficiência material no controle interno ligada à implantação, citando a ausência de avaliação contínua e eficaz de riscos e o número insuficiente de pessoas treinadas nas operações afetadas. Investidores processaram a empresa; a TechTarget cobriu o processo, que alegava que cerca de US$ 64 milhões em remessas não foram atendidos.

Nenhum deles fracassou porque o SAP era a escolha errada. Fracassaram em fundamentos de planejamento e controle que existem há décadas.

Estrutura analítica do projeto

Uma estrutura analítica do projeto (EAP) divide o escopo total em entregáveis com responsáveis claros. Sem ela, o trabalho fica invisível até atrasar. Em um programa SAP ela cobre desenho de processos, configuração, migração de dados, integração, testes, treinamento e cutover, cada um detalhado em tarefas com responsável e data de entrega.

O valor não está no documento. Ele força a conversa sobre o que precisa acontecer, quem faz e do que depende. São as dependências que matam projetos. Um atraso na migração de dados bloqueia o teste de integração, que bloqueia o UAT, que aperta a janela de cutover. A EAP torna essa cadeia visível.

Gestão do cronograma

Cronogramas falham por motivos previsíveis. Pessoas são puxadas para outras frentes. As estimativas estavam erradas. As decisões demoram mais do que o planejado. Inclua contingência desde o primeiro dia, como uma folga explícita ao lado das tarefas com mais chance de precisar dela, e não como gordura espalhada por toda parte.

Acompanhe o cronograma toda semana. Um atraso de uma semana na semana quatro é uma conversa. Um atraso de quatro semanas na semana dezesseis é uma crise. Mesmo problema, custo de correção muito diferente.

Trate o momento do go-live como uma decisão à parte. Nunca entre em produção em um período de pico do negócio. A lição da Hershey vale para toda empresa.

Controle do orçamento

Os orçamentos estouram por três motivos: mudanças de escopo não gerenciadas, migração de dados subestimada e custos de hypercare acima das estimativas iniciais. Acompanhe o gasto real em relação ao plano desde a primeira semana. Quando uma variação chega ao comitê de direção, em geral já é tarde para corrigir sem ruptura.

O controle de mudanças é a principal proteção do orçamento. Toda mudança de escopo recebe uma avaliação de impacto em tempo, custo e recursos antes da aprovação. Se a avaliação vem depois da aprovação, a mudança passou por cima do orçamento. Meu guia sobre como evitar o scope creep em implementações SAP aprofunda o comitê de mudanças.

Gestão de riscos

Um registro de riscos mantido a cada trimestre é teatro. Os riscos precisam de revisão semanal, responsáveis nomeados e planos de resposta. Nomeie estes em todo programa SAP: qualidade de dados descoberta tarde, atrasos de integração, lacunas na disponibilidade de recursos, compressão da janela de cutover e baixa adoção pelos usuários.

Um cliente perdeu três meses quando o fornecedor de migração de dados descumpriu prazo atrás de prazo. Ouvíamos sempre “só mais duas semanas”, até ser tarde demais para trocar de fornecedor sem estourar o orçamento. Um risco com responsável e data-gatilho teria forçado essa decisão meses antes. Minha matriz de avaliação de riscos do SAP traz um modelo para pontuar e atribuir esses riscos.

Comunicação e escalonamento

Os executivos precisam de manchetes. As equipes de entrega precisam de detalhes. Os gerentes de projeto precisam de dados de variação. Uma única atualização para todos não ajuda ninguém.

Documente e ensaie os caminhos de escalonamento antes de uma crise. Em uma implementação SAP, a TI presumia que as finanças estavam revisando a configuração, e as finanças presumiam que era a TI. Ninguém levantou o assunto até o go-live estar a três meses e faltarem aprovações críticas; a correção foi uma correria de última hora, custo extra e uma implantação adiada. Outra empresa fez certo: o reporte era estruturado e ligado a ações, de modo que, quando surgia um problema, todos sabiam quem era o responsável, qual era o impacto e como seria resolvido.

É no escopo que o escalonamento se paga. Trabalhei com uma companhia aérea que começou com uma simples melhoria no sistema de reservas. Seis meses depois, já tinha acrescentado mudanças de fidelidade, escalas de tripulação e módulos financeiros. Nenhuma era urgente. Ninguém disse não. O prazo dobrou e os custos subiram 70%.

O manual on-premise não sobrevive ao RISE with SAP sem mudanças. Três coisas são diferentes.

O RISE muda para quem você escala

No RISE with SAP, a SAP cuida da infraestrutura e das operações técnicas e oferece uma equipe de customer success que acompanha a adoção. Sua estrutura de controle precisa incluí-los. Para problemas de plataforma (desempenho do sistema, região do hyperscaler, níveis de serviço da SAP), o gerente do programa precisa de um caminho de escalonamento documentado até a SAP que não passe pelo parceiro de implementação. Escreva isso antes de precisar.

O Clean Core dá ao controle de escopo um respaldo técnico

Toda lacuna agora exige uma decisão: configurar, estender por meio de APIs liberadas (on-stack com ABAP Cloud ou side-by-side no SAP BTP) ou rejeitar. No S/4HANA Cloud Public Edition, modificar o núcleo não é uma opção. Na edição privada e no on-premise é possível, mas a orientação de Clean Core da SAP trata isso como último recurso, porque cada modificação acrescenta trabalho de upgrade.

Isso ajuda o controle de escopo. Um pedido para “só ajustar o processo padrão de order-to-cash” deixa de ser uma conversa casual de configuração e vira uma extensão com esforço de desenho, construção e teste. Coloque um pequeno fórum de revisão de extensões abaixo do comitê de direção, com um arquiteto que tenha autoridade para aprovar ou rejeitar. Sem ele, toda discussão sobre customização acaba no comitê de direção.

A IA redige os relatórios, as pessoas tomam as decisões

A IA agora ajuda com a papelada do controle. O SAP Cloud ALM, a ferramenta de ciclo de vida de aplicações da SAP, guarda tarefas do projeto, requisitos e status de testes, e pode gerar rascunhos de requisitos a partir de transcrições de workshops. O Microsoft Copilot redige resumos de variação para os pacotes do comitê de direção a partir de dashboards e relatórios de status. A detecção de anomalias no Power BI ou no SAP Analytics Cloud sinaliza KPIs que fogem do padrão habitual. Isso é útil para uso de recursos, volume de solicitações de mudança e chamados de suporte, e menos para métricas que oscilam naturalmente.

O que a IA não faz é agir. Um dashboard pode mostrar o atraso do cronograma em vermelho por seis semanas. Se o comitê de direção não fizer nada, o atraso continua.

Este é o ritmo mínimo para um programa em entrega ativa. Se faltar alguma linha, acrescente-a antes de qualquer outra coisa.

Controle	Prática mínima	Responsável	Frequência
Estrutura analítica do projeto	Toda tarefa tem um responsável, uma data de entrega e suas dependências	Líder do PMO	Atualizada semanalmente
Revisão do cronograma	Sinalize qualquer tarefa com mais de três dias de atraso; verifique o caminho crítico	Gerente do programa	Semanal
Acompanhamento do orçamento	Real versus plano por pacote de trabalho	Líder financeiro do programa	Semanal, reportado mensalmente
Revisão de riscos	Todo risco ativo tem um responsável, um gatilho e uma resposta	Líderes de frente de trabalho	Semanal
Controle de mudanças	Avaliação de impacto em tempo, custo e recursos antes da aprovação	Presidente do comitê de mudanças	Semanal ou conforme chegarem os pedidos
Revisão de extensões (RISE e GROW)	Decisão de configurar, estender ou rejeitar para cada lacuna	Arquiteto de soluções	Quinzenal
Comitê de direção	Decisões, não status; materiais enviados com antecedência	Patrocinador executivo	Quinzenal; semanal no cutover e no hypercare

A maior parte dos fracassos de planejamento e controle não acontece porque o método estava errado, mas porque a disciplina foi abandonada por volta do quarto mês. Mantenha a cadência pequena o bastante para que a equipe ainda a siga no décimo quarto mês. Sobre o comitê de direção em si, veja meu guia para criar um comitê de direção SAP eficaz.

Qual é a diferença entre planejamento e controle de projeto?

O planejamento produz o roteiro: escopo, cronograma, orçamento, recursos e riscos. Ele define a direção no início.

O controle é o trabalho contínuo de acompanhar o progresso em relação a esse plano, levantar variações, gerenciar dependências e refazer a linha de base quando ocorrem mudanças formais. Acontece toda semana durante a vida do programa.

A maioria dos programas SAP investe pesado no planejamento e pouco demais no controle. Quando a variação aparece no comitê de direção, já se acumularam semanas ou meses de custo de recuperação.

Por que projetos SAP fracassam mesmo com um plano de projeto?

Porque ninguém trabalha o plano. As dependências não são acompanhadas, então o atraso de uma frente bloqueia outra em silêncio. Os registros de riscos são atualizados a cada trimestre. Mudanças de escopo são aprovadas informalmente. O comitê de direção se reúne uma vez por mês e vê resumos de marcos que escondem o que acontece no terreno.

Lidl, Hershey e Revlon tinham planos. Faltou controle ativo: acompanhamento honesto, escalonamento cedo e uma resposta real quando os sinais de alerta apareceram.

Como administro o scope creep em um programa SAP longo?

Dê a toda mudança de escopo uma avaliação de impacto por escrito antes da aprovação: tempo, custo e recursos. Sem ela, aprovar uma mudança é aprovar uma incógnita.

A regra mais eficaz: toda adição precisa deslocar outra coisa. Só essa restrição faz os líderes de negócio priorizarem com honestidade.

Os executivos precisam respaldar isso. Quando um CFO ou COO apoia publicamente o controle de mudanças, os pedidos informais caem rápido. Em programas RISE e GROW, a decisão de extensão para cada lacuna acrescenta uma verificação técnica por cima.

O que é uma estrutura analítica do projeto e por que ela importa para o SAP?

Uma EAP divide o escopo total em entregáveis, cada um com um responsável e uma data de entrega. Em um programa SAP isso significa desenho de processos, configuração, migração de dados, integração, testes, treinamento e cutover, tudo detalhado em tarefas.

Seu valor prático é o mapeamento de dependências. A migração de dados alimenta o teste de integração, que alimenta o UAT, que alimenta o cutover. Quando um escorrega, o impacto a jusante fica visível na hora.

Como o RISE with SAP muda o planejamento e o controle de projetos?

A SAP passa a ser participante da entrega. Ela cuida da infraestrutura e das operações técnicas, e sua equipe de customer success segue uma cadência própria sobre adoção e valor.

Três mudanças decorrem disso. Você precisa de um caminho de escalonamento documentado até a SAP para problemas de plataforma, que não passe pelo parceiro. Precisa de um fórum de revisão de extensões abaixo do comitê de direção para decidir como cada lacuna é tratada sob o Clean Core. E deve incorporar a cadência de customer success da SAP à sua governança, em vez de rodá-la em paralelo.

O que um comitê de direção deve fazer em um programa SAP?

Tomar decisões. Sua função é resolver o que a equipe do programa não consegue: conflitos de recursos, disputas de escopo, mudanças de orçamento e tudo o que exige autoridade multifuncional. Uma reunião de comitê que termina sem decisões foi uma atualização de status.

Um comitê mensal em um programa grande deixa problemas esperando até quatro semanas. Quinzenal é o mínimo na entrega ativa, e semanal no cutover e no hypercare. Envie os relatórios de progresso com antecedência e use a reunião para as decisões que eles levantam.