Recuperação de projetos SAP: como resgatar um programa fora do rumo

Recuperar um projeto SAP significa parar uma migração ou implementação que saiu do rumo, descobrir o que é realmente verdade sobre ela e replanejar a partir dessa verdade. A primeira semana decide se vai funcionar: avalie o status do programa, revise o desenho e avalie o que está realmente implantado no sistema.

Resposta curta: se essas três verificações concordam entre si e com o plano, o programa precisa de um empurrão, não de um resgate. Se discordam, nenhum esforço extra sobre o plano atual vai resolver, e você precisa de uma recuperação formal com uma nova linha de base.

Este artigo trata desse diagnóstico e do que vem depois. É um dos desdobramentos do meu guia de migração de ECC para S/4HANA, que trata de caminhos, cronogramas e prazos. Aqui a pergunta é mais estreita: o seu programa está com problemas, e agora?

A maioria dos programas atrasados não precisa de resgate. Precisa de decisões mais rápidas, de um key user liberado ou de um fornecedor cobrado por uma data. Isso é um empurrão.

Um resgate é diferente. Os sinais vêm das mesmas três verificações que faço na primeira semana, e o sinal é simples: o status, o desenho e o que está implantado não concordam entre si nem com o plano.

Alguns padrões que eu trataria como sinais de resgate:

1. O status está verde, o sistema não. Os relatórios dizem que a maior parte da construção está pronta, mas o sistema de teste não consegue rodar um order-to-cash básico.
2. O desenho está assinado, a construção o ignora. A configuração foi feita a partir de anotações de workshop, e não do desenho aprovado.
3. O plano tem uma data de go-live, ninguém consegue explicar o caminho até ela. Testes, cargas de dados e ensaios de cutover não têm uma janela realista.
4. O escopo só cresce. A lista WRICEF (relatórios, interfaces, conversões, enhancements, formulários e workflows) continua subindo muito depois da fase Explore.

Qualquer um desses pode ser resolvido com um empurrão. Dois ou mais ao mesmo tempo, em geral, não.

A primeira semana serve para descobrir o que é verdade. Não para corrigir, não para buscar culpados e não para escrever um novo plano. Avalio três coisas, nesta ordem: o status, o desenho e o que está realmente implantado.

Isto é o que cada verificação cobre e o que uma discordância indica:

Verificação	O que eu olho	A pergunta que ela responde	Se discordar das outras
Status do programa	Plano, relatórios de status, RAID log, solicitações de mudança em aberto, gasto contra o orçamento	O que o programa acredita sobre si mesmo?	O reporte é otimista ou está desconectado da entrega
Desenho	Desenho de processos de negócio, resultados do Fit-to-Standard, lista WRICEF, decisões de desenho em aberto	O que foi prometido ao negócio?	A construção se afastou do que foi acordado, ou o desenho nunca foi concluído
O que está implantado	Os sistemas de desenvolvimento e teste, configuração, transportes, custom code, cargas de dados até agora	O que de fato existe hoje?	Foi reportado progresso sobre trabalho que não está no sistema

A terceira verificação é a que a maioria das revisões pula. Ela significa sentar diante do sistema e rodar processos, e não ler documentos sobre o sistema.

Relatórios de status e documentos de desenho são afirmações. O sistema é evidência.

Quem deve fazer as verificações

As pessoas que escreveram os relatórios de status não devem ser as que os verificam. Isso não é uma acusação. É o mesmo motivo pelo qual auditores não auditam o próprio trabalho.

Eu colocaria alguém independente do parceiro de implementação no comando da primeira semana, com acesso total aos sistemas e o direito de falar com qualquer pessoa do programa. Se isso não for possível, pelo menos faça o parceiro mostrar o sistema implantado ao vivo, e não em slides.

Em 2018, trabalhei na recuperação de um programa de aviação. Os módulos tinham sido implantados, mas nada havia sido configurado com base nos requisitos do negócio.

É exatamente essa a situação que as três verificações da primeira semana existem para revelar. Módulos implantados não são o mesmo que um desenho que funciona, e só olhar dentro do sistema mostra a diferença.

As companhias aéreas ligam de perto manutenção, compras e finanças, então uma lacuna em uma área se propaga. Trato de como o SAP se encaixa nesse setor na minha página sobre SAP para aviação.

Nos 21 programas SAP que liderei ou resgatei, o maior erro que vejo é não planejar direito no início da implementação. Um resgate costuma ser esse planejamento que faltou, feito tarde e sob pressão.

Duas outras causas aparecem repetidamente:

1. O fornecedor controla o escopo. Quando o integrador de sistemas escreve o escopo, ele descreve o que o integrador planeja entregar. As lacunas chegam depois como solicitações de mudança, precificadas pelo mesmo fornecedor.
2. O custom code estoura. Na minha experiência, custom code é a fase da migração que mais estoura o prazo, e também é o custo oculto mais esquecido.

O lado orçamentário disso, incluindo por que a fase Explore é onde os custos saltam, está no meu artigo sobre por que projetos SAP estouram o orçamento. Não vou repetir aqui.

Controle fraco é o outro fio comum. Se o programa nunca teve um ritmo semanal de acompanhamento, escalonamento e controle de mudanças, o resgate precisa instalar um. Meu guia sobre planejamento e controle de projetos SAP apresenta essa cadência com os responsáveis.

Quando você sabe o que é verdade, a recuperação tem uma sequência clara. Pular uma etapa geralmente significa fazer o resgate duas vezes.

Sequência de recuperação de um programa SAP

1. 01

   Diagnosticar

   Status, desenho e o que está implantado, confrontados entre si.

2. 02

   Retomar o escopo

   Escopo do cliente, congelado, com cada mudança precificada.

3. 03

   Nova linha de base

   Um único plano novo construído sobre evidências, com contingência do seu lado.

4. 04

   Gates nas fases

   Um quality gate no fim de cada fase restante.

5. 05

   Ensaiar e fazer o cutover

   Ensaios completos antes de confirmar uma data de go-live.

1. Retome a responsabilidade pelo escopo

Antes que alguém replaneje, decida quem é dono do escopo. Se a resposta ainda for o fornecedor, o novo plano vai falhar do mesmo jeito que o antigo.

Escreva o escopo do lado do cliente, compare-o com o que está implantado e congele-o. A partir daí, cada mudança é uma decisão precificada e com um dono.

2. Faça uma nova linha de base uma única vez, com base em evidências

Uma recuperação recebe uma nova linha de base, não uma série de pequenos adiamentos. Construa-a a partir do que o sistema mostra, e não do que o plano antigo esperava.

Reestime primeiro o custom code, porque é dele que os estouros mais vêm. Depois os dados, já que a migração de dados representa de 30 a 40 por cento do esforço e costuma estar atrasada em um programa com problemas.

Mantenha de 10 a 20 por cento de contingência do seu lado, liberada apenas contra riscos nomeados. Meu artigo irmão sobre o custo da migração S/4HANA explica o que define os números.

3. Coloque um quality gate no fim de cada fase

Programas com problemas geralmente passaram de fase em fase por datas, e não por evidências. Corrija isso.

No SAP Activate, a fase Explore conduz os workshops Fit-to-Standard, e os requisitos delta aprovados entram no product backlog para o Realize. Se o programa saiu do Explore sem um desenho concluído, volte e conclua-o. O SAP Cloud ALM suporta quality gates como pontos de controle com checklists, exibidos na visão geral do projeto, para que o gate não precise viver em uma planilha.

4. Ensaie antes de se comprometer com uma data

Em uma conversão brownfield, planejo três conversões simuladas antes do cutover. Programas com problemas costumam cortar ensaios para ganhar tempo, o que transfere o risco para o fim de semana do go-live.

O downtime de cutover que já vi vai de um fim de semana a uma semana. Um programa resgatado deve conhecer o seu número a partir de um ensaio, e não de uma estimativa.

5. Verifique o prazo com que você realmente trabalha

Para o SAP ERP 6.0 nos enhancement packages 6 a 8, a manutenção padrão termina em 31 de dezembro de 2027, com manutenção estendida opcional até o fim de 2030 por um adicional de dois pontos percentuais (SAP News). Uma recuperação que empurra uma migração do ECC para depois de 2027 deve orçar abertamente a manutenção estendida.

Não deixe a data de 2027 forçar um go-live que os ensaios não sustentam. Um go-live atrasado custa taxas de manutenção. Um go-live fracassado custa muito mais.

Um resgate costuma levantar a questão de manter ou não o integrador de sistemas atual. Às vezes, substituir o parceiro é o certo. Muitas vezes, o problema maior é como o programa foi montado, e um novo parceiro o herda.

Estas são as perguntas que eu faria antes de decidir:

1. Vocês podem nos mostrar o sistema implantado, ao vivo, contra o desenho assinado? Não um ambiente de demonstração, e não slides.
2. Quais objetos WRICEF estão construídos, testados e transportados, e quais só estão reportados como concluídos?
3. Qual é o desenho de alto nível de vocês para concluir, e para quais referências podemos ligar em que vocês recuperaram um programa como o nosso? Referências e o desenho de alto nível são as duas coisas que peço a qualquer parceiro antes de assinar.
4. O que vocês precisam de nós e não estão recebendo? Decisões pendentes e key users em tempo parcial costumam ser metade da história.
5. Para clientes RISE with SAP: quais problemas cabem à SAP e não ao parceiro, e quem os escala?

O sinal de alerta é o mesmo que me faz descartar um parceiro na seleção: respostas genéricas. Se o plano de recuperação serviria para qualquer empresa, ele não foi escrito para a sua. Meu guia sobre como escolher um parceiro de migração S/4HANA trata do lado da seleção.

Se o programa nunca teve uma avaliação adequada do sistema de origem, faça uma agora. O SAP Readiness Check analisa o seu sistema existente, e a SAP recomenda executá-lo em produção para ter uma imagem precisa do uso real. Meu artigo sobre o SAP Readiness Check e a avaliação de migração explica o que ele não vê, a começar pelos objetos customizados.

Reserve meio dia com o seu diretor de programa e o seu líder SAP, e peça que lhe mostrem três coisas lado a lado: o último relatório de status, o desenho assinado e o sistema de teste rodando um processo de negócio completo. Se as três contarem a mesma história, empurre. Se não contarem, inicie uma recuperação formal antes do próximo comitê de direção.

Se você quer uma visão independente de um programa que saiu do rumo, ajudo organizações exatamente com esse tipo de diagnóstico. Você pode agendar uma conversa comigo.

O que é a recuperação de um projeto SAP?

A recuperação de um projeto SAP é o trabalho de trazer de volta ao controle uma implementação ou migração SAP que saiu do rumo. Ela começa com um diagnóstico do status do programa, do desenho e do que está realmente implantado, depois retoma a responsabilidade pelo escopo, define uma única nova linha de base e acrescenta quality gates às fases restantes.

Como saber se o meu projeto SAP precisa de um resgate?

Compare três coisas: o que dizem os relatórios de status, o que diz o desenho assinado e o que está realmente implantado no sistema. Se concordam entre si e com o plano, o programa precisa de um empurrão. Se discordam, mais esforço sobre o plano atual não vai resolver, e você precisa de uma recuperação formal.

O que deve acontecer na primeira semana da recuperação de uma implementação SAP?

Só diagnóstico. Avalie o status do programa, revise o desenho e avalie o que está realmente implantado, de preferência sob a liderança de alguém independente do parceiro de implementação. Não escreva o novo plano antes de concluir essas três verificações.

Devemos substituir o nosso parceiro de implementação SAP durante uma recuperação?

Não automaticamente. Peça ao parceiro que mostre o sistema implantado contra o desenho assinado e que apresente um desenho de alto nível para a conclusão, com referências de recuperações semelhantes.

Se as respostas forem genéricas, é um sinal forte para trocar. Se o problema real for a responsabilidade pelo escopo ou decisões pendentes do seu lado, um novo parceiro vai herdá-lo.

Por que as migrações para SAP S/4HANA saem do rumo?

A causa raiz mais comum que vejo é não planejar direito no início da implementação. Deixar o fornecedor controlar o escopo é outra, e custom code é a fase que mais estoura o prazo. A migração de dados, com 30 a 40 por cento do esforço, também costuma estar atrasada.

Uma recuperação vai empurrar a nossa migração do ECC para depois do prazo de 2027?

Pode ser. A manutenção padrão do SAP ERP 6.0 nos enhancement packages 6 a 8 termina em 31 de dezembro de 2027, e a manutenção estendida opcional vai até o fim de 2030 com um adicional de dois pontos. Orce a manutenção estendida em vez de forçar um go-live que os seus ensaios não sustentam.