Gestão de partes interessadas em SAP: evite conflitos antes que comecem

A gestão de partes interessadas em SAP decide se um programa termina no prazo ou passa o último trimestre em discussões. Ela se resume a quatro hábitos. Mapear quem importa e o que cada grupo valoriza. Registrar por escrito quem tem autoridade para decidir o quê. Manter uma cadência de comunicação que acompanhe a fase do SAP Activate. Registrar cada decisão importante com as suas alternativas. Este guia é para diretores de programa, PMOs e patrocinadores executivos de programas S/4HANA. Use a tabela de papéis e a cadência fase a fase abaixo para montar o seu plano de engajamento antes do primeiro workshop.

Certa vez trabalhei em um rollout de SAP em que a TI queria controles rígidos no sistema e Finanças precisava de mais flexibilidade. Quando chegamos, as duas equipes tinham parado de conversar. Finanças estava frustrada. A TI estava na defensiva. A liderança queria saber por que ninguém se comunicava.

Montamos um mapa de papéis, fizemos reuniões regulares de alinhamento e criamos uma fonte única de verdade para as decisões. Se essa base tivesse sido montada no início, teríamos poupado meses de discussão.

O padrão vale muito além desse programa. A tecnologia raramente falha sozinha. Os programas falham quando as decisões não são tomadas e as expectativas nunca foram definidas. Falham quando a comunicação depende de relações pessoais em vez de uma cadência, e quando conflitos que pertenciam ao nível operacional chegam à liderança com semanas de atraso.

Nem todos em um programa SAP têm as mesmas preocupações nem a mesma influência. Se você os trata como um único público, envia atualizações irrelevantes e deixa passar os riscos reais.

Papel	O que valorizam	Como engajá-los
Patrocinador executivo (CEO, COO, CFO do grupo)	Retorno, risco de negócio, credibilidade do programa	Direto, regular, curto
Comitê de direção (CIO, CFO, líderes de unidades de negócio)	Cronograma, orçamento, escopo	Revisões estruturadas do comitê, com decisões
Liderança de Finanças (CFO, controllers)	Reconhecimento de receita, integridade dos relatórios, controles	Participação cedo no desenho; aprovação do escopo de FI/CO
Líderes de operações e de negócio	Continuidade dos processos, treinamento, usabilidade	Workshops de desenho; responsabilidade pelo teste de aceitação do usuário (UAT)
Liderança de TI (CIO, chefe de arquitetura)	Arquitetura, segurança, integração, suporte	Aprovação do desenho técnico
Donos de processos de negócio	Precisão dos processos, exceções, casos-limite	Conduzem os workshops de desenho; aprovam a configuração
Usuários finais	Curva de aprendizado, trabalho diário, mudanças nas funções	Treinamento e gestão de mudanças
Integrador de sistemas (SI)	Escopo de entrega, solicitações de mudança, alocação de equipe	Governança formal e documentos de escopo
RH e gestão de mudanças	Impacto sobre as pessoas, mudanças de funções, comunicação	Uma frente de trabalho paralela à entrega

A matriz de poder e interesse mostra onde gastar esforço. O CIO, o CFO e o patrocinador ficam no alto dos dois eixos: eles aprovam mudanças, adiam o go-live e alocam pessoas, e, se se desengajam, o programa perde a sua cobertura. Donos de processos, controllers e arquitetos têm alto interesse e menos poder formal, mas o conhecimento que têm de como o negócio realmente funciona os torna essenciais no desenho. Membros do conselho e executivos de fora do programa precisam de briefings a cada marco, não de atualizações semanais. Os usuários finais têm pouca influência e a maior exposição: a adesão deles no go-live decide se o sistema funciona na prática.

Influência sobre o resultadoAltaMédiaBaixa

• Conselho, executivos de fora

• Patrocinador, CFO, CIO

• Donos de processos
• Controllers, arquitetos

• Usuários finais

BaixoMédioAltoImpacto do programa sobre cada grupo

O engajamento mais eficaz acontece antes que alguém tenha uma reclamação. Defina três coisas no kick-off.

Direitos de decisão

Quem pode aprovar uma mudança de escopo? Quem aprova o UAT? Quem pode levar um adiamento do go-live ao comitê de direção? Escreva, colha as assinaturas e coloque no termo de abertura do projeto. Quando uma decisão é contestada no meio do projeto, é esse documento que você aponta.

Sem ele, as decisões contestadas vão para quem grita mais alto ou tem o ouvido do patrocinador. Nenhuma das duas coisas é governança, e ambas geram ressentimento. O meu guia sobre como escrever um termo de abertura de projeto SAP explica o que a seção de direitos de decisão deve conter.

Cadência de comunicação

Decida no kick-off com que frequência o programa se comunica, por qual canal e com que conteúdo. Comitê de direção a cada duas semanas. Líderes de frentes de trabalho toda semana. Usuários finais a cada marco, com avisos de treinamento. Se as pessoas só ouvem falar do programa quando algo está errado, vão supor que ele está sempre em apuros.

Linha de base de escopo

Registre o que está no escopo e o que está explicitamente fora. As exclusões importam tanto quanto as inclusões, porque cada fronteira indefinida é um conflito futuro. Pense em um líder de finanças que presume que a gestão de despesas está no escopo e descobre na fase Realize que não está. Essa pessoa será difícil pelo resto do programa, não porque seja difícil por natureza, mas porque o programa quebrou uma promessa implícita.

As necessidades de engajamento mudam à medida que o programa avança pelas fases do SAP Activate. O que funciona na fase Explore não funciona na Deploy. Use isto como espinha dorsal do seu plano de engajamento:

Fase	Foco do engajamento	Cadência	Quem lidera
Discover e Prepare	Mapa de papéis, estrutura de governança, briefings com o patrocinador, primeiras sessões de alinhamento com Finanças, Operações e TI	Briefing com o patrocinador no início; comitê de direção instituído	Diretor do programa
Explore	Workshops de fit-to-standard com líderes de negócio e donos de processos; decisões de fit-gap revisadas antes da aprovação	Sessões de trabalho semanais; comitê de direção no fechamento da fase	Arquiteto de solução e donos de processos
Realize	Preparação do UAT; proteção do tempo dos líderes de negócio para os testes; status de defeitos e de migração de dados	Comitê de direção quinzenal; líderes de frentes de trabalho semanalmente	Gerente do programa
Deploy	Prontidão para o cutover, critérios de go/no-go acordados antes de o cutover começar	Stand-ups diários de cutover; briefing executivo de go/no-go	Líder de operações de negócio, com apoio de TI e do SI
Run	Comunicação de hypercare, canais de incidentes, revisões de estabilização	Diária por duas semanas, depois semanal; revisões em 30, 60 e 90 dias	Líder de suporte e donos de processos

Duas fases dão mais problema. Na Explore, ter as pessoas erradas na sala significa que as decisões são reabertas na Realize, depois que a configuração já começou. Na Realize, donos de UAT indisponíveis ou despreparados são um padrão comum. Resolva isso no plano durante a Explore, não duas semanas antes de os testes começarem.

O modelo tradicional tinha três partes: o cliente, o SI e os patrocinadores. No RISE with SAP, a SAP entra como participante da entrega. Ela cuida da infraestrutura e das operações técnicas, e a sua equipe de customer success acompanha a adoção e o valor. Daí decorrem três mudanças de governança.

1. Um fórum de revisão de extensões. Cada lacuna 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, não é possível modificar o core. No Private Edition é possível, mas cada modificação acrescenta trabalho nos upgrades. Um fórum pequeno abaixo do comitê de direção, com um arquiteto autorizado a decidir, evita que todo debate sobre customização chegue ao comitê. Sem ele, a dívida técnica aparece no primeiro upgrade importante.
2. Uma cadência de customer success com a SAP. A equipe da SAP atua em adoção, uso do BTP e roadmap. Ela corre em paralelo à governança da implementação e continua após o go-live. Incorpore-a à sua governança em vez de conduzi-la separadamente.
3. Um caminho de escalonamento até a SAP. Quando algo falha no nível da plataforma, o CIO precisa saber para quem ligar na SAP, e não só no parceiro. Confirme os contatos e os níveis de serviço antes de assinar.

Os programas GROW with SAP na Public Edition precisam dos mesmos três itens, em versão mais leve: menos decisões de extensão, porque há menos espaço para estender, uma cadência de sucesso mais padronizada e um escalonamento que em geral passa primeiro pelo parceiro. Os programas on-premise mantêm o modelo tradicional, com a SAP como fornecedora e não como participante.

As ferramentas de IA ajudam com a papelada do engajamento, não com os relacionamentos.

Os resumos de reuniões são o ganho mais claro. O Microsoft Copilot transforma a gravação de uma reunião do comitê de direção em uma minuta que precisa de uma revisão rápida em vez de uma redação longa. As decisões que ele registra costumam estar certas, porque trabalha a partir da transcrição, e não da memória.

Os registros de decisões vêm em segundo lugar. Os recursos de IA do Confluence, agora sob a marca Rovo da Atlassian, podem transformar anotações de reuniões em entradas estruturadas de registro de decisões, depois que você monta um modelo.

O rascunho de requisitos ajuda na fase Explore. O SAP Cloud ALM consegue redigir requisitos a partir das transcrições dos workshops de fit-to-standard. Ainda é preciso uma pessoa para validar cada linha.

A análise de sentimento é, na maior parte, teatro em programas com menos de 100 pessoas. O sinal é fraco, os falsos positivos são comuns e ser visto monitorando sentimento tem um custo político real. Em programas muito grandes, ela pode identificar cedo grupos que estão se desengajando. Na maioria dos programas, gaste o orçamento de IA em outro lugar.

A resistência ao SAP quase sempre tem uma base racional. Quem reage costuma estar protegendo algo: uma solução de contorno que cobre uma lacuna do sistema antigo, uma verificação manual que o processo padrão não mostra ou a preocupação com a capacidade da equipe de absorver a mudança. Encontre essa base antes de reagir. Trate a preocupação de fundo e a resistência costuma desaparecer sem confronto.

“Precisamos desta customização”

Em geral isso protege um processo que funciona hoje e que a pessoa não confia que o SAP padrão consiga atender. Percorra o processo padrão e pergunte exatamente onde ele falha. Muitas vezes a preocupação é um caso-limite que a configuração resolve. Às vezes é legítima. Você só descobre tendo a conversa, e sob o clean core o que está em jogo é maior, porque a resposta decide se você vai construir e manter uma extensão.

“Não estamos prontos para o go-live”

Leve isso a sério. Quando um líder de negócio diz que não está pronto, ele costuma ter um motivo: qualidade dos dados, treinamento incompleto, um processo não testado. Descubra a preocupação específica. Se for válida, ela deve adiar o go-live. Se for ansiedade e não evidência, responda com preparação direcionada, não com uma nova data.

A versão mais comum: o UAT expôs problemas que não foram corrigidos. Seguir em frente joga o problema do UAT para a produção. Um atraso de duas semanas costuma custar muito menos do que um período de hypercare gasto com problemas que já eram conhecidos antes do go-live.

“Ninguém nos avisou desta mudança”

Isso é uma falha de comunicação. A pessoa estava na lista de distribuição, mas não na sessão de desenho, ou a mudança estava em um documento que ela nunca leu. Não discuta quem comunicou o quê. Peça desculpas, explique a mudança, inclua a pessoa nas próximas revisões de desenho da sua área e corrija a lacuna no plano de engajamento.

Quando um conflito passa do nível operacional, três coisas importam.

Mantenha-o dentro da governança. Uma disputa entre Finanças e TI sobre acesso ao sistema pertence ao comitê de direção, e não deve ser resolvida informalmente por quem for mais insistente. A resolução informal de conflitos estruturais gera ressentimento e decisões reabertas.

Apresente-o em termos de negócio. Finanças e TI discutindo controle de acesso é política. Finanças e TI apresentando o risco de segurança em contraste com o custo operacional é uma decisão de negócio, e o comitê de direção pode tomá-la. Traduzir uma coisa na outra é trabalho do gerente do programa ou do líder do SI, dependendo do contrato.

Registre cada decisão importante. O que foi decidido, por quem, quando e quais alternativas foram consideradas. Em seis meses alguém vai dizer “nunca concordamos com isso”. Quando o comitê perguntar por que uma configuração foi escolhida, ou um recém-chegado questionar uma decisão passada, você precisa do registro, não de uma reconstrução de memória. Um registro de decisões compartilhado, atualizado toda semana e revisado no comitê, custa quase nada e poupa muito.

Se a caixa de entrada do gerente do programa está cheia de escalonamentos urgentes, o plano não está funcionando. Programas saudáveis funcionam com decisões estruturadas, não com apagar incêndio todos os dias.

Sinais saudáveis: as reuniões do comitê de direção produzem decisões, e não adiamentos; os líderes de negócio comparecem aos workshops e ao UAT sem precisar ser cobrados; as mudanças de escopo chegam pelo processo de mudanças; os problemas pós-go-live chegam por canais definidos; o registro de decisões está atualizado e é citado no comitê.

Sinais de alerta: pessoas procuram o gerente do programa fora da estrutura de governança; líderes de negócio aprovam entregáveis sem lê-los e os contestam depois; o patrocinador some entre as reuniões do comitê; pessoas que não participaram do desenho questionam o congelamento de mudanças; o mesmo conflito aparece em três reuniões seguidas do comitê.

Quando aparecem sinais de alerta, não force mais o plano existente. Descubra qual elemento está falhando (cadência, autoridade, comunicação ou documentação) e corrija esse. Mais e-mails e mais reuniões pioram a situação. Sobre o próprio comitê de direção, veja o meu guia para criar um comitê de direção SAP eficaz e, sobre o lado humano do go-live, as minhas anotações sobre gestão de mudanças em SAP.

O que é a gestão de partes interessadas em uma implementação SAP?

É o trabalho estruturado de identificar quem tem influência sobre o programa ou interesse nele, entender as suas preocupações, montar a comunicação e a tomada de decisões e mantê-los engajados do kick-off ao hypercare.

O SAP toca Finanças, RH, Compras, Operações e TI ao mesmo tempo, e cada área tem prioridades e influência diferentes. Gerenciá-las como um único público produz atualizações genéricas e deixa passar as preocupações que alimentam a resistência. O SAP Activate incorpora isso em todas as fases: os workshops na Explore, a responsabilidade pelo UAT na Realize e as revisões de prontidão na Deploy dependem de participantes de negócio preparados.

Como montar um mapa de papéis para um projeto SAP?

Posicione cada pessoa ou grupo em dois eixos: influência sobre o resultado e o quanto o programa os afeta. O patrocinador, o CFO e o CIO ficam no alto dos dois e precisam de contato direto e regular. Controllers, donos de processos e arquitetos têm alto interesse e precisam participar do desenho. Executivos de fora do programa precisam de briefings a cada marco. Os usuários finais precisam de comunicação direcionada sobre o que muda para eles, quando acontece o treinamento e onde buscar ajuda.

Mantenha o mapa atualizado. As pessoas mudam de função, a influência se desloca à medida que o programa ganha visibilidade e novos participantes entram conforme o escopo cresce.

O que um plano de engajamento SAP deve incluir?

Um registro de papéis (nome, função, influência, interesse, principais preocupações), um plano de comunicação (canal, frequência e conteúdo por grupo), direitos de decisão para mudanças de escopo, decisões de desenho e prontidão para o go-live, atividades para cada fase do Activate, um caminho de escalonamento para decisões contestadas e uma forma de levantar preocupações formalmente.

Atualize-o a cada gate de fase. Documente-o o bastante para que a equipe consiga executá-lo sem que o gerente do programa precise tratar pessoalmente cada interação, porque isso não escala além de trinta participantes nomeados.

Como gerenciar a resistência de líderes de negócio ao SAP?

Descubra a origem primeiro. As mais comuns são a preocupação de que o novo processo deixe passar um caso-limite importante, o medo de perder produtividade e a sensação de estar fora das decisões. As preocupações com processo pertencem a uma sessão de desenho. Os medos de produtividade pedem treinamento realista e um suporte de hypercare claro. A exclusão é uma falha de comunicação a corrigir, não a discutir.

A resistência sem base racional é mais difícil. A alavanca costuma ser o patrocinador, que precisa deixar claro que o programa tem o compromisso da liderança. Seguir em frente sem tratar a resistência é a pior opção: as preocupações reaparecem no UAT.

Como lidar com conflitos entre Finanças e TI em um programa SAP?

A maioria se resume a uma de três tensões: acesso versus segregação de funções, flexibilidade de relatórios versus governança de dados, ou ritmo da integração versus revisão de segurança.

Nomeie a tensão com precisão. “Finanças quer que os controllers tenham acesso de leitura às ordens de produção para relatórios, e a TI acredita que isso quebra a segregação de funções” pode ser resolvido; “Finanças quer flexibilidade” não pode. Leve a questão ao comitê de direção com as opções e os seus riscos. Depois registre a decisão e as alternativas, porque essas disputas voltam quando as pessoas mudam. Se o comitê não conseguir resolver, ela vai ao patrocinador. Isso é a governança funcionando como foi desenhada.

Como o RISE with SAP muda a gestão de partes interessadas?

A SAP passa a ser participante e não apenas fornecedora. Você precisa de um fórum de revisão de extensões para decidir como cada lacuna é tratada sob o clean core, de um lugar na sua governança para a cadência de customer success da SAP e de um caminho de escalonamento documentado até a SAP para problemas de plataforma, que não dependa do parceiro. Confirme os contatos de escalonamento e os níveis de serviço antes de assinar.