Sete frameworks de consultoria para entregas de SAP e IA

Quando um programa de SAP ou de IA emperra, a causa costuma ser estrutural, e sete frameworks simples a encontram. Mapeie o estado atual. Combine quem decide o quê com uma matriz RACI. Ligue o trabalho às capacidades do negócio. Encontre as causas raiz com os cinco porquês. Ordene os requisitos com o MoSCoW. Ordene os riscos pelo que realmente pode parar o programa. Faça um post-mortem de verdade depois de cada fase. Este guia é para gerentes de programa, consultores e patrocinadores de entregas de SAP e IA. Comece pela tabela abaixo: encontre o seu sintoma e use primeiro o framework correspondente.

Uma empresa de mídia de porte médio no Catar estava implantando o SAP em várias regiões. Finanças e compras iriam para o go-live na primeira fase. Ela também queria modelos de previsão com IA nos seus relatórios.

Na sexta semana, os atrasos começaram a aparecer. Os usuários de negócio diziam ter aprovado os requisitos, mas continuavam confusos sobre o que iam receber. Casos de uso de IA tinham sido propostos e ninguém sabia dizer quem era o dono dos dados nem como o resultado seria usado. As pessoas chegavam atrasadas às reuniões, ou nem apareciam.

Era aquela fase intermediária. Cedo demais para chamar de fracasso. Tarde demais para fingir que se resolveria sozinho.

Aplicamos os frameworks passo a passo. No começo, nem tudo foi bem recebido. Algumas sessões ficaram caladas. Outras saíram do trilho. Mas a estrutura facilitou o trabalho: a equipe parou de andar em círculos, o backlog ficou administrável e os casos de uso de IA ganharam donos de verdade. O go-live aconteceu oito semanas depois do planejado. Não perfeito. Mas pousou, e a segunda fase começou em terreno melhor, com menos incógnitas.

Usei versões dos sete ao longo de 23 anos de entregas em programas de SAP, Oracle e IA no Golfo, na Europa e em outros lugares. Nenhum é exótico. Todos funcionam se você os aplicar com disciplina, e não como exercícios de documentação.

Associe o sintoma ao framework:

Sintoma que você está vendo	Framework	O que produz	Esforço típico
Os usuários aprovaram os requisitos, mas continuam confusos	1. Mapeamento do estado atual	Um mapa compartilhado de como o trabalho realmente acontece hoje	3 a 5 dias de workshops
As decisões ficam pulando de reunião em reunião	2. RACI nas decisões críticas	Donos nomeados para as 20 a 30 decisões-chave	Um workshop, depois a aplicação
Os patrocinadores se desligaram do “projeto de TI”	3. Mapeamento de capacidades	Progresso reportado em capacidades de negócio	Incorporado ao fit-to-standard
O mesmo tipo de defeito continua voltando	4. Cinco porquês	Uma causa raiz que você pode mudar	Uma sessão facilitada por problema
Tudo está marcado como alta prioridade	5. MoSCoW	Um escopo ordenado, com uma lista realista de Must Have	Uma sessão conjunta de negócio e TI
O registro de riscos parece bom, mas a equipe está tensa	6. Ranking de riscos	Listas separadas de riscos que param o programa e de riscos incômodos	Revisão semanal de 30 minutos
Os mesmos erros se repetem fase após fase	7. Post-mortem	De três a cinco mudanças com donos	Meio dia depois de cada fase

O erro mais comum no início de um programa é pular para a solução antes de documentar o que existe. A documentação de processos costuma estar desatualizada. As pessoas descrevem como as coisas deveriam funcionar, não como funcionam. A distância entre as duas versões é onde moram os problemas de implantação.

Um bom mapa do estado atual leva de três a cinco dias de workshops com as pessoas que fazem o trabalho, não com as que o gerenciam. Ele cobre as etapas do processo em ordem, os sistemas usados em cada etapa, as intervenções manuais e soluções de contorno, e os fluxos de dados entre departamentos.

Procure as etapas manuais que ninguém menciona porque se tornaram invisíveis, as soluções de contorno que rodam há tanto tempo que já contam como processo padrão e os problemas de qualidade de dados que todo mundo conhece e ninguém corrigiu.

No Catar, o mapa do estado atual veio de workshops com usuários, não da documentação. Foi aí que a confusão sobre os requisitos aprovados começou a se dissipar.

Bem feito, um mapa do estado atual leva dias. Tratado como um exercício de coleta de documentos, leva meses e produz algo em que ninguém confia.

Os direitos de decisão são o elemento estrutural que mais falta nos projetos de SAP e IA. Todo mundo tem uma opinião. Ninguém sabe quem dá a palavra final. As decisões vão para a reunião seguinte, que as remete ao comitê de direção, que as devolve ao grupo de trabalho.

Uma matriz RACI (Responsible, Accountable, Consulted, Informed) dá a cada decisão e a cada entregável um dono. Uma pessoa é a Accountable e pode ser também a Responsible ou delegar essa execução. Os Consulted dão contribuições. Os Informed ficam sabendo do resultado.

A versão prática: liste as vinte a trinta decisões mais críticas da fase atual e faça um workshop de RACI com os decisores presentes. Onde uma atribuição é contestada, você aprendeu algo: ou a governança não está clara, ou existe uma briga política por autoridade. Seja como for, traga isso à tona na semana dois, não na semana catorze.

RACI sem aplicação é decoração. Os nomes precisam corresponder às pessoas com autoridade real. Atribuir a responsabilidade final a um título de cargo, e não a uma pessoa com nome, é um jeito de evitar a conversa sobre quem é dono do risco.

Programas de SAP e IA geram muita atividade técnica que o negócio não enxerga. A ligação entre o que está sendo construído e o resultado que deveria entregar fica abstrata. Os patrocinadores se desligam, e “o projeto de TI” leva a culpa por atrasos que na verdade são decisões do negócio.

O mapeamento de capacidades liga a função do sistema à capacidade de negócio: aquilo que a organização precisa ser capaz de fazer. Em vez de acompanhar se o fluxo de pedido de compra está configurado, você acompanha se a organização consegue processar faturas de fornecedores em até três dias após o recebimento. A configuração é o mecanismo. A capacidade é o resultado.

No SAP Activate, isso se encaixa nos workshops de fit-to-standard da fase Explore. Cada processo no escopo é uma capacidade, e cada lacuna entre o padrão SAP e a capacidade exigida é uma decisão: aceitar o padrão, configurar uma variante ou estender. Manter a conversa no nível das capacidades segura a atenção do negócio durante toda a construção e expõe capacidades que todos presumiam estar no escopo, mas que ninguém confirmou.

Quando o mesmo tipo de problema continua aparecendo ao longo de sprints ou fases, remendar cada ocorrência não resolve. A causa está a montante.

Os cinco porquês são a ferramenta de causa raiz mais simples. Pergunte por que o problema aconteceu, depois por que isso aconteceu, até chegar a algo que você pode mudar. Cinco rodadas costumam chegar à causa real. Duas rodadas costumam parar no sintoma.

Um exemplo de migração de dados. A carga de teste tem erros de qualidade de dados: esse é o sintoma. Por quê? A extração da origem tinha mapeamentos de campos errados. Por quê? A especificação de mapeamento nunca foi revisada pelo dono dos dados no negócio. Por quê? O dono dos dados só foi designado depois que o mapeamento terminou. Por quê? O plano não tornou o envolvimento do dono dos dados uma dependência do mapeamento. Essa é a causa raiz, e a correção é uma decisão de governança, não uma correção de dados. Meu texto sobre por que a migração de dados do SAP falha mostra com que frequência essa mesma cadeia aparece.

1. 01Erros na carga de testeO sintoma
2. 02Mapeamentos de campos erradosPor que a carga falhou?
3. 03Especificação nunca revisadaPor que os mapeamentos estavam errados?
4. 04Dono designado tarde demaisPor que a especificação não foi revisada?
5. 05Plano ignorou a dependênciaPor que o dono chegou tarde?

A causa raiz é uma decisão de governança, não uma correção de dados

A análise de causa raiz em uma sala sem culpados produz respostas honestas. Em uma sala que atribui culpa, produz defensividade. O trabalho do facilitador é manter a conversa no processo, não nas pessoas. Meu guia de pensamento estruturado e resolução de problemas mostra como decompor um problema confuso antes de começar a perguntar por quê.

Toda discussão de escopo de SAP e IA tem uma armadilha de consenso. Ninguém quer fazer concessões, então tudo vira alta prioridade. Quando tudo é alta prioridade, nada é, e a equipe de construção tenta fazer tudo.

O MoSCoW (Must have, Should have, Could have, Won't have this time) força a escolha. Must Have é o mínimo necessário para o go-live. Should Have é importante, mas não bloqueia. Could Have é desejável se o tempo e o orçamento permitirem. Won't Have é explicitamente adiado.

A disciplina está na linha do Must Have. A primeira rodada de um exercício de MoSCoW costuma colocar coisas demais em Must Have. A orientação do DSDM, da Agile Business Consortium, de onde o MoSCoW vem, estabelece um teto de 60% do esforço em Must Haves e alerta que passar disso põe a entrega em risco. A distância entre a primeira rodada e uma lista realista é, em sua maior parte, premissas não testadas.

Faça o MoSCoW com negócio e tecnologia na mesma sala. Feitas em separado, a lista de Must Have da TI e a do negócio acabam incompatíveis, e ninguém as concilia até a configuração já ter começado.

A maioria dos registros de riscos é uma lista longa pontuada por probabilidade e impacto, revisada todo mês, com status RAG que raramente mudam. Eles registram o risco sem gerar ação.

Separe os riscos que podem parar o programa dos riscos que apenas o tornam mais difícil. O primeiro grupo precisa de donos, planos de resposta e visibilidade semanal. O segundo precisa de monitoramento.

No Catar, o registro de riscos parecia bom no papel, mas todo mundo estava no limite. Uma matriz rápida de risco e impacto, revisada toda semana e não todo mês, trouxe à tona as preocupações reais.

Um registro que parece bom enquanto a equipe se sente tensa quase sempre esconde alguma coisa. O registro não é a verdade; as conversas ao redor dele são. Uma revisão semanal que pergunta “o que tirou o seu sono ontem à noite?” revela mais do que “qual é o status do item 14?”. Minha matriz de avaliação de riscos de projetos SAP traz um modelo para a pontuação e a atribuição de donos.

Os post-mortems depois de uma fase ou do go-live impedem que os mesmos erros se repitam na fase seguinte. Também são a primeira coisa cortada quando o cronograma está sob pressão.

Um post-mortem útil faz quatro perguntas. O que planejamos alcançar e o que alcançamos? O que deu certo e deve ser repetido? O que deu errado e o que causou isso? O que faríamos diferente? Ele deve terminar com de três a cinco ações específicas com donos, não com um documento resumindo o que aconteceu.

A falha comum é um exercício de justificativa em que as equipes defendem decisões em vez de examiná-las. Mantenha o foco no futuro. A pergunta não é quem causou os atrasos da semana seis. É que mudança estrutural os evita na fase seguinte.

No Catar, o post-mortem aconteceu logo depois do go-live e focou em ação, não em culpa. É em boa parte por isso que a segunda fase começou em terreno melhor.

Os frameworks não mudaram. O que mudou é como eles são aplicados, de três maneiras.

O rascunho ficou mais rápido; a escuta, não. As ferramentas de IA agora transformam transcrições de workshops e documentos de processo em um primeiro mapa em minutos, e o SAP Cloud ALM consegue redigir requisitos a partir das transcrições de fit-to-standard. Os workshops em si levam o mesmo tempo de sempre, porque ouvir é o ponto. O tempo economizado no rascunho deve ir para desafiar o mapa com as pessoas.

Os rascunhos de RACI chegam prontos, e a parte difícil continua. Um assistente de IA de uso geral produz uma RACI a partir de um termo de abertura e de uma lista de pacotes de trabalho em um minuto. A disciplina passa a ser a negociação: cada célula exige uma conversa de verdade sobre autoridade e escalonamento. O tempo economizado na montagem do rascunho deve ir para essas conversas difíceis.

O MoSCoW fica mais difícil com a IA na sala. Um ranking de requisitos feito por IA é plausível, bem acabado e muitas vezes errado sobre a política local. Consultores que o aceitam sem questionar produzem listas de prioridades piores do que os que começam com uma folha em branco. Trate o rascunho da IA como ponto de partida, nunca como resposta.

O julgamento por cima desses frameworks vale mais agora, não menos. Se você está desenvolvendo essas habilidades como consultor, os caminhos de carreira do SAPopedia mostram quais importam em cada etapa de uma carreira em SAP.

O que são frameworks de consultoria e por que os projetos de SAP os usam?

São abordagens estruturadas para análise, decisão e resolução de problemas. Em programas de SAP e IA, dão a líderes de negócio, arquitetos, gerentes de projeto, integradores e patrocinadores um método comum.

Sem um, cada grupo recorre ao seu próprio modelo mental: resultados de processo, arquitetura, ou prazo e recursos. Frameworks como o mapeamento do estado atual, a RACI e o MoSCoW tornam o desacordo explícito e solucionável. O SAP Activate é, ele mesmo, um framework de fases, gates e entregáveis; estes sete funcionam dentro dele e tratam das questões estruturais e humanas que a metodologia sozinha não resolve.

Como funciona o mapeamento do estado atual em uma implantação de SAP?

Ele documenta como os processos realmente funcionam antes de a configuração começar, em contraste com o que a documentação existente diz que deveriam funcionar. Construa-o em workshops com as pessoas que operam os processos: etapas, sistemas, passagens de bastão, intervenções manuais e soluções de contorno.

Ele alimenta os workshops de fit-to-standard da fase Explore do SAP Activate, onde o estado atual vira a linha de base comparada com os processos padrão da SAP. Conclua-o antes desses workshops, ou a sua análise de lacunas se apoiará em suposições.

O que é a priorização MoSCoW e quando ela é usada em programas SAP?

O MoSCoW separa os requisitos em Must have, Should have, Could have e Won't have this time. Os Must Haves são o mínimo para o go-live; os Won't Haves são explicitamente excluídos para que não voltem de fininho.

Ele é mais útil na fase Explore, quando os achados de fit-gap orientam as decisões de extensão, e na fase Realize, quando defeitos e melhorias disputam tempo de construção. O problema habitual são Must Haves demais na primeira rodada. O DSDM recomenda no máximo 60% do esforço em Must Haves; um facilitador que desafia cada um deles, com negócio e TI na mesma sessão, leva você até lá.

Como conduzir uma revisão de riscos eficaz em um projeto SAP?

Como uma conversa, não como uma atualização de status. Comece com perguntas abertas como “Qual é a sua maior preocupação nesta semana que não está no registro?” antes de percorrer o registro.

Para cada risco de alta prioridade, pergunte o que mudou, que ação foi tomada, se a tendência está melhorando e se o plano de resposta ainda serve. Riscos que ficam com a mesma classificação por semanas sem ação costumam estar subestimados. Revise toda semana nas fases ativas e mostre ao comitê de direção os cinco principais, com status e próxima ação, não o registro completo.

O que torna útil um post-mortem depois de um go-live de SAP?

Mudanças específicas e acionáveis para a fase seguinte. Um resumo do que aconteceu é um registro, não um post-mortem.

Cubra o que você se propôs a alcançar, o que alcançou, o que funcionou e o que não funcionou. Vá além de explicações superficiais como “faltaram pessoas”: o plano de recursos estava errado, o escopo estava errado ou o caminho de escalonamento estava quebrado? Termine com de três a cinco mudanças, cada uma com dono e data.

Como os frameworks de consultoria ajudam na implantação de IA em ambientes SAP?

Os projetos de IA fracassam pelas mesmas razões estruturais que os de SAP, mais algumas próprias: dados sem dono, medidas de sucesso indefinidas e nenhum processo acordado para agir sobre o resultado.

O mapeamento do estado atual mostra quem é dono dos dados de que um modelo precisa e qual é a qualidade deles. A RACI responde quem valida o resultado, quem decide agir sobre ele e quem responde quando está errado. O MoSCoW separa os casos de uso essenciais dos interessantes. Comece com dois ou três casos de uso essenciais, com donos e medidas de sucesso claros, não com quinze de uma vez.