Avaliação de riscos em projetos SAP: a versão prática

Uma avaliação de riscos de projeto SAP lista o que pode tirar o programa dos trilhos e pontua cada risco por probabilidade e impacto. Cada risco recebe um único responsável nomeado e uma resposta combinada antes que ele aconteça, e a lista é revisada toda semana. Os riscos que afundam programas SAP raramente são surpresas: migração de dados, integração, disponibilidade de pessoas, desvio de escopo e adoção. Este guia é para gerentes de programa e patrocinadores que querem um registro de riscos que mude decisões, e não um que fique parado numa pasta. Ele oferece uma matriz pontuada, um modelo de registro, três falhas públicas como casos analisados e os riscos que o RISE with SAP e o Clean Core acrescentam. Comece colocando um responsável nomeado em cada risco que você já tem.

A maioria das avaliações de riscos SAP é montada antes do primeiro comitê de direção, revisada uma vez e nunca mais tocada. Isso não é gestão de riscos. É um documento.

Já vi riscos serem ignorados porque eram desconfortáveis demais para levantar cedo. Esse silêncio quase sempre custa mais depois. O que começa como um pequeno problema de integração no Materials Management de repente bloqueia as Finanças. Um relatório que parecia bom nos testes quebra depois de uma atualização do sistema. Vi isso acontecer mais de uma vez.

Os riscos não eram surpresas. Estavam documentados. Ninguém agiu sobre eles.

Escopo. O projeto começa com módulos padrão. Depois alguém acrescenta “só mais um relatório”, depois um dashboard, depois algumas melhorias. O perigo está nas mudanças de escopo introduzidas de modo informal em workshops, e-mails e conversas de corredor, das quais o gerente de projeto só toma conhecimento depois que a configuração está pronta. Meu guia sobre como evitar o scope creep cobre os controles.

Recursos. O arquiteto é puxado para um problema em produção. Um desenvolvedor-chave sai. Os usuários de negócio faltam aos ciclos de teste porque o dia a dia deles não para. Obtenha a disponibilidade por escrito. Promessas verbais evaporam sob a pressão sobre o quadro de pessoal.

Técnico. Mapeamentos de campos nunca validados contra a estrutura de destino. Interfaces que passam no teste unitário e quebram no volume real de transações. Código customizado que parece bom até chegar a carga de produção. Tudo isso é previsível, se você sabe onde procurar.

Prazo. Um blueprint atrasado espreme os testes, mas a data do go-live continua fixa. UAT, treinamento e preparação de dados ficam apressados. O mesmo padrão aparece em quase todo programa que perde um gate de fase e não move o plano seguinte.

Adoção. As pessoas rejeitam o que não entendem. Um treinamento fraco ou tardio produz contornos, os contornos degradam os dados e o sistema leva a culpa por uma falha de gestão de mudanças.

Esses casos são públicos e bem documentados. Os padrões se repetem em qualquer escala.

Lidl: cerca de € 500 milhões em sete anos

A Lidl iniciou o seu projeto eLWIS no SAP for Retail em 2011, entrou em produção em alguns países menores e o abandonou em 2018, a um custo reportado de cerca de € 500 milhões. Uma causa amplamente divulgada: a Lidl avaliava o estoque a preços de compra, enquanto o modelo de varejo padrão da SAP usa preços de venda. A Lidl customizou em vez de mudar a prática, e a empresa disse que os objetivos originais não podiam ser alcançados com um esforço razoável.

Lição: uma incompatibilidade entre o seu modelo de dados e o padrão da SAP é um risco da primeira semana, não uma descoberta do quinto ano.

HP: cerca de US$ 400 milhões em receita perdida

Em 2004, a HP migrou parte do seu negócio de servidores para um sistema consolidado de pedidos e cadeia de suprimentos baseado em SAP. Pedidos se perderam entre o front-end legado e o SAP e exigiram trabalho manual, e o backlog dobrou. O CEO da HP disse que os problemas custaram ao grupo de servidores e armazenamento cerca de US$ 400 milhões em receita e US$ 275 milhões em lucro operacional, deixando um backlog de US$ 120 milhões. O CIO da HP disse depois que a equipe havia planejado três semanas de disrupção e deveria ter tido contingência para quatro a seis.

Lição: dimensione a contingência para um cutover ruim, não para um cutover médio, e monte buffers de estoque ou de canal antes de virar a chave.

Nike: mais de US$ 100 milhões em vendas perdidas

Em 2000, a Nike entrou em produção com o software de planejamento de demanda da i2 antes do seu programa de ERP SAP. O software foi muito customizado para funcionar com os sistemas legados da Nike, era lento e travava com o volume de produtos. Ele fazia pedidos em excesso de alguns modelos de tênis e de menos de outros. A Nike perdeu mais de US$ 100 milhões em vendas e as suas ações caíram cerca de 20%. Mais tarde, a Nike levou o planejamento de curto e médio prazo para o SAP.

Lição: nunca presuma que uma integração funciona até que ela tenha rodado em volume de produção com dados reais.

Uma avaliação construída sobre suposições é pior do que nenhuma, porque cria uma falsa confiança. Seis insumos importam:

1. Documentação de escopo: termo de abertura, escopo aprovado e requisitos assinados. Se não existem, o risco de escopo já é alto.
2. Compromissos de recursos: compromissos por escrito dos chefes de departamento, uma matriz de competências para os papéis críticos e um substituto nomeado para cada posição-chave.
3. Orçamento e prazo: orçamento aprovado com contingência e um cronograma comparado com programas semelhantes. Seis meses e financiamento mínimo para um rollout completo é um risco a apontar já.
4. Compromissos do fornecedor: contratos com níveis de serviço e penalidades. No RISE, as responsabilidades da SAP e o caminho de escalonamento.
5. Cenário técnico: compatibilidade com legados, complexidade da migração de dados, modelo de implantação e um plano de Clean Core para qualquer trabalho customizado.
6. Registros de projetos anteriores: registros de riscos, registros de problemas e post-mortems de programas SAP ou ERP anteriores. A maioria dos riscos não é nova.

Pontue cada risco em probabilidade e impacto, de 1 a 5, e multiplique. O exemplo abaixo é um ponto de partida típico para um programa S/4HANA; as suas pontuações serão diferentes.

Risco	Probabilidade (1-5)	Impacto (1-5)	Pontuação	Prioridade
Falha na migração de dados	4	5	20	Alta
Atrasos na integração	4	4	16	Alta
Restrições de recursos	4	4	16	Alta
Estouro de orçamento	3	5	15	Média
Código customizado no core bloqueando upgrades	3	5	15	Média
Scope creep	4	3	12	Média
Lacunas na cobertura de testes	3	4	12	Média
Desempenho sob carga de pico	3	4	12	Média
Lacunas de conformidade	2	5	10	Média
Nenhum caminho de escalonamento para a SAP (RISE)	2	5	10	Média
Baixa adoção pelos usuários	3	3	9	Média
Exposição a custos de assinatura ou licença	2	4	8	Média
KPIs não acompanhados	3	2	6	Baixa

Pontuações de 16 ou mais precisam de um responsável nomeado e de ação agora. Pontuações de 8 a 15 precisam de monitoramento, com um gatilho de escalonamento definido. Abaixo de 8, mantenha no registro sem gastar tempo prioritário. As pontuações são um ponto de partida, não um veredito: uma lacuna de conformidade pontuada em 10 pode virar 25 em um setor regulado.

Uma pontuação sozinha não muda nada. Cada risco precisa destes campos, preenchidos.

Campo	O que escrever	Exemplo
Risco	O evento, em uma frase	Os dados mestre de fornecedores não são higienizados antes da carga simulada 2
Responsável	Uma pessoa nomeada	Líder de contas a pagar
Pontuação	Probabilidade × impacto	4 × 5 = 20
Gatilho	O ponto mensurável em que você age	Taxa de duplicidade acima de 5% na extração da carga simulada 1
Resposta	Evitar, mitigar, transferir ou aceitar, com a ação	Mitigar: dois analistas de contas a pagar na limpeza por três semanas
Próxima revisão	Data	A revisão de riscos da próxima segunda-feira
Status	Aberto, em ação, encerrado	Em ação

Coloque o custo em termos reais sempre que puder. “Risco alto” é vago. “Uma semana de atraso no UAT custa cerca de seis dígitos em tempo da equipe e pode empurrar o go-live em três semanas” chama a atenção.

O código customizado é uma categoria de risco à parte. No S/4HANA Cloud Public Edition, o código customizado no core não é possível. As extensões passam pelo SAP BTP, por APIs liberadas ou por ferramentas de key user. Na nuvem privada e no on-premise você ainda pode modificar o core, e os parceiros acostumados a fazê-lo vão fazer. Essa dívida técnica aflora no primeiro grande upgrade. Acompanhe quantas das customizações identificadas têm uma abordagem de Clean Core acordada, verifique a experiência do parceiro com extensões em BTP e monte um fórum de revisão até o fim da fase Explore.

O RISE muda quem é dono da disponibilidade. A SAP opera a infraestrutura, então o risco passa de “a nossa equipe é dona da disponibilidade” para “a SAP é dona dela, e precisamos de um caminho rápido até ela quando algo falha”. Registre os contatos nomeados da SAP, o caminho de escalonamento e os níveis de serviço, além de um plano de incidentes combinado antes do go-live. Sem eles, problemas que deveriam ir para a SAP ficam tempo demais dentro da equipe do projeto.

A IA ajuda com a papelada, não com o julgamento. Assistentes baseados no Joule no SAP Cloud ALM e ferramentas como o Microsoft Copilot conseguem redigir entradas de registro e pacotes para o comitê de direção a partir de relatórios de status, registros de defeitos e atas. Isso acelera a manutenção do registro em programas com dados de origem limpos. Ela encontra riscos que já estão visíveis nos dados. Não decide quais riscos merecem ação, não faz os responsáveis agirem nem escala os riscos que a liderança preferiria ignorar.

1. Identifique os riscos nas cinco categorias. Faça workshops com a TI, o negócio e os fornecedores; cada um enxerga riscos diferentes. No RISE, inclua os contatos da SAP em pelo menos um deles. Os riscos que as equipes costumam perder: TI e negócio esperando coisas diferentes, integrações externas mal definidas, responsáveis pelo UAT que não estão disponíveis e mudanças informais de escopo.
2. Pontue cada risco em probabilidade e impacto, com números reais sempre que possível.
3. Atribua um responsável por risco. Uma pessoa, não uma equipe. Sem responsável, não há acompanhamento nem resolução.
4. Defina a resposta antes que o risco se concretize. Evitar, mitigar, transferir ou aceitar. “Monitorar e reagir” não é um plano. É uma decisão adiada.
5. Revise toda semana. Confira os riscos abertos, acrescente os novos, repontue onde as condições mudaram e escale tudo o que estiver perto do seu gatilho. Leve os principais riscos ao comitê de direção com uma proposta de decisão, e não com uma cor.

1. 01IdentificarAs cinco categorias
2. 02PontuarProbabilidade × impacto, de 1 a 5
3. 03Atribuir um responsávelUma pessoa, não uma equipe
4. 04Definir a respostaEvitar, mitigar, transferir ou aceitar
5. 05Revisar toda semanaRepontuar, escalar perto dos gatilhos

16 ou mais: um responsável nomeado e ação esta semana

O que é uma avaliação de riscos em um projeto SAP?

É o processo de identificar o que pode dar errado, pontuar cada risco por probabilidade e impacto, dar um responsável a cada um e combinar uma resposta antes que aconteça. Os programas SAP rodam vários módulos, integrações, uma migração de dados, um programa de mudança e um go-live fixo ao mesmo tempo, então a gestão informal de riscos não se sustenta. Uma lista curta de riscos reais com responsáveis vale mais do que um documento longo que ninguém lê.

Como montar uma matriz de riscos para um projeto SAP?

Liste os riscos de escopo, recursos, técnicos, prazo e adoção, além do Clean Core e do escalonamento para a SAP no RISE. Pontue cada um em probabilidade e impacto, de 1 a 5, e multiplique. Trate 16 ou mais como alto, de 8 a 15 como médio e abaixo de 8 como baixo. Dê a cada risco médio e alto um responsável e um gatilho mensurável, como “se a conclusão do UAT estiver abaixo de 80% na semana 16, a data do go-live vai para revisão”. Repontue toda semana e em cada gate de fase.

Quais são os riscos mais comuns nas implementações SAP?

Falha na migração de dados, porque os dados legados quase sempre são mais bagunçados do que o estimado. Atrasos na integração, sobretudo com interfaces legadas sem documentação e fornecedores terceiros. Scope creep que comprime testes e treinamento. Restrições de recursos, como pessoas-chave puxadas para outras frentes ou usuários indisponíveis durante o UAT no fechamento do mês. Baixa adoção por causa de um treinamento que mostra telas em vez de simular o trabalho. No RISE, acrescente o código customizado no core e a falta de um caminho de escalonamento para a SAP.

Quando fazer a avaliação de riscos durante um projeto SAP?

Antes de o projeto começar, quando riscos estruturais, como incompatibilidades do modelo de dados ou prazos irrealistas, são mais baratos de corrigir. Antes de cada gate de fase do SAP Activate, porque cada fase muda o perfil de risco. Sempre que o escopo, o orçamento ou os recursos mudarem. E quando um risco vira problema, para verificar o que mais ele afeta. Nos intervalos, revise toda semana.

Quem deve ser o responsável pelos riscos em um programa SAP?

A pessoa que pode agir sobre eles. O líder de dados é dono do risco de migração de dados, o arquiteto técnico é dono do risco de integração, o líder de mudanças é dono do risco de adoção e o arquiteto de soluções é dono do risco de Clean Core. No RISE, o CIO ou o diretor do programa é dono do caminho de escalonamento para a SAP. O gerente do programa acompanha a saúde do registro, mas não é dono de todos os riscos.

O que acontece quando a avaliação de riscos de ERP é ignorada?

Em grande escala, você tem casos como o da Lidl, que abandonou o seu projeto SAP de varejo em 2018 depois de cerca de € 500 milhões. Ou o da HP, cuja migração do sistema de pedidos SAP em 2004 custou ao seu grupo de servidores cerca de US$ 400 milhões em receita. Em escala menor, o mecanismo é o mesmo: incompatibilidades do modelo de dados descobertas tarde, integrações falhando em volume de produção e falhas de adoção por causa de um treinamento fraco. Os riscos eram identificáveis antes de virarem problemas.