Funções e responsabilidades essenciais na equipe de implementação do SAP

Uma implementação do SAP precisa de oito funções com donos nomeados e dedicados: patrocinador executivo, gerente de projeto, líderes funcionais, líder de TI, líder de migração de dados, líder de gestão de mudanças, parceiro de implementação e um assessor independente do programa. O RISE with SAP acrescenta os contatos de entrega da própria SAP e torna explícita a responsabilidade pelo Clean Core. Este guia é para patrocinadores e diretores de programa que estão montando uma equipe ou consertando uma. Ele cobre o que cada função assume, o que quebra sem ela, os tamanhos de equipe por porte da empresa e como montar o Centro de Excelência (CoE) antes do go-live. Comece verificando qual das oito funções está nas mãos de alguém que também tem um trabalho no dia a dia. Esse é o seu maior risco.

Trabalhei com dezenas de equipes SAP ao longo dos anos. Vi projetos bem financiados, com fornecedores experientes, fracassarem porque funções-chave estavam vagas ou divididas entre pessoas com outros trabalhos. Também vi projetos subfinanciados darem certo porque as pessoas certas estavam na sala, totalmente comprometidas e com responsabilidades claras.

Uma varejista global com quem trabalhei tinha orçamento, apoio da liderança e o SAP como ERP escolhido. Mas a equipe de implementação era um desastre. Funções-chave estavam vagas. Ninguém era dono das decisões críticas. A comunicação corria para todos os lados sem chegar a lugar nenhum. Os prazos escorregaram, os custos subiram e a confiança desabou.

Toda implementação do SAP precisa dessas funções preenchidas. O título importa menos do que a responsabilidade.

1. Patrocinador executivoDecisões, financiamento, escalonamento
   Assessor do programa de ERPSupervisão independente, riscos, alinhamento executivo
2. Gerente de projetoCronograma, orçamento, coordenação

• Líderes funcionais e especialistasDesenho de processos, configuração de módulos
• Líder de TI e equipeIntegração, desenvolvimento, segurança
• Líder de migração de dadosQualidade dos dados, sequência de cargas, cutover
• Líder de gestão de mudançasTreinamento, adoção, comunicação
• Parceiro de implementaçãoArquitetura, desenho de integração, entrega

Função	Responsabilidade principal	O que quebra sem ela
Patrocinador executivo	Decisões estratégicas, financiamento, autoridade de escalonamento	Deriva, brigas de escopo, ninguém desempata
Gerente de projeto	Cronograma, orçamento, coordenação entre equipes	Atrasos, bloqueios sem solução, estouro de custos
Líderes funcionais e especialistas	Desenho dos processos de negócio, configuração de módulos	Configuração errada, gambiarras depois do go-live
Líder de TI e equipe	Integração, desenvolvimento, segurança, desempenho	Dívida técnica, interfaces quebradas, instabilidade
Líder de migração de dados	Qualidade dos dados, sequência de cargas, precisão do cutover	Dados inutilizáveis, go-live fracassado, meses de limpeza
Líder de gestão de mudanças	Treinamento, adoção, comunicação	Resistência dos usuários, planilhas paralelas
Parceiro de implementação	Arquitetura, desenho de integração, entrega	Excesso de construção, falhas de integração
Assessor do programa de ERP	Supervisão independente, riscos, alinhamento executivo	Decisões tomadas isoladamente, erros evitáveis

Patrocinador executivo

O patrocinador não é um nome em um slide do comitê de direção. É quem toma as decisões que mais ninguém pode tomar: orçamento, mudanças de escopo, compromissos de recursos entre departamentos. Quando a função é cerimonial, o projeto fica à deriva.

Trabalhei com uma empresa que pulou essa função. O projeto ficou à deriva. Nenhuma decisão, nenhum progresso, dinheiro jogado fora.

Patrocinadores eficazes ficam até o hypercare. Participam das reuniões mensais do comitê de direção depois do go-live e tomam as pequenas decisões que destravam o que está parado há semanas. Meu guia sobre como montar um comitê de direção do projeto SAP explica como estruturar esse fórum.

Gerente de projeto

O gerente de projeto cuida do dia a dia: cronograma, registro de riscos, coordenação, atualizações. Em um programa SAP grande, é uma função em tempo integral para alguém que já fez isso antes.

Vi um cliente perder o desenvolvedor líder no meio da implementação. O projeto inteiro parou por semanas enquanto ele corria atrás de um substituto.

O problema oposto é igualmente danoso. Trabalhei com uma empresa que tinha mais de 30 pessoas na equipe. Ninguém sabia quem era dono das decisões. Mudanças simples exigiam cinco reuniões. O cronograma passou de 12 para 18 meses só pelo custo da comunicação.

Líderes funcionais e especialistas no assunto

Essas pessoas traduzem a operação do negócio em configuração do SAP. Precisam conhecer o negócio o bastante para questionar processos ruins, e o SAP o bastante para saber o que é possível.

Trabalhei com um cliente industrial cuja equipe se destacou porque os líderes funcionais passaram um tempo no chão de fábrica antes de desenhar os processos.

Especialistas pela metade sempre deixam lacunas. Ou o projeto recebe a atenção deles, ou recebe só o nome deles em uma folha de aprovação. Não é a mesma coisa.

Líder de TI e equipe

A equipe de TI é dona da base técnica: desenvolvimento, Basis, segurança, integração e desempenho. No S/4HANA, também é dona da disciplina de Clean Core, mantendo o código customizado fora do núcleo.

A integração é o que a maioria das equipes subestima. Cada conexão com um sistema externo precisa ser desenhada, construída, testada e ter um dono. As interfaces quebram no UAT quando ninguém mapeou os fluxos de dados. Coloque a TI nas sessões de blueprint, não depois das decisões.

Líder de migração de dados

Essa função é atribuída tarde e com poucos recursos. Quando os problemas de dados aparecem, o programa já está sob pressão de prazo.

Um cliente achou que podia pular a limpeza de dados. Grande erro. O sistema dele foi inútil por meses. Limpar dados com o sistema em produção custa mais do que uma limpeza adequada logo no início.

Um líder de migração dedicado faz conciliações em cada carga, e é assim que os problemas estruturais aparecem antes do go-live. Isso não acontece quando a função fica com alguém que tem outras três frentes de trabalho. Meu texto sobre por que a migração de dados do SAP falha explica o método.

Líder de gestão de mudanças

É a função mais consistentemente subdimensionada. Já vi sistemas de milhões de dólares parados porque ninguém queria mudar a forma de trabalhar.

Vi uma implementação tecnicamente perfeita fracassar porque os usuários a detestavam. A configuração estava correta e o desenho do processo era sólido. Mas as pessoas que a usavam todos os dias não tinham participado do desenho. Não entendiam por que as coisas tinham mudado e continuaram usando seus velhos arquivos de Excel.

Um cliente de varejo teve sucesso porque ouviu as preocupações dos caixas com o novo sistema e ajustou a abordagem.

O mínimo para um programa corporativo são duas pessoas dedicadas à gestão de mudanças. Uma só não dá conta de desenho do treinamento, comunicação, gestão da resistência e acompanhamento da adoção ao mesmo tempo.

Assessor do programa de ERP

Um assessor independente não é o parceiro de implementação. O trabalho é supervisionar e corrigir o rumo: verificar se a direção ainda faz sentido, identificar riscos que a equipe de entrega está perto demais para ver e fechar a distância entre o que os executivos acham que está acontecendo e o que realmente está.

Já exerci esse papel para clientes com equipes de entrega fortes, mas sem uma voz independente. Trabalhei com um cliente industrial que quase implementou os módulos errados porque ninguém tinha ligado a estratégia de crescimento dele ao roadmap do SAP.

Identificar problemas cedo é a outra metade. Certa vez identifiquei uma lacuna crítica de competências na equipe de dados de um cliente três meses antes de ela atrasar o go-live. Corrigimos antes que virasse uma crise.

O modelo de oito funções continua valendo. Três coisas precisam ser encaixadas nele em 2026.

Os contatos de entrega da própria SAP no RISE

No RISE with SAP em nuvem privada, a SAP opera a infraestrutura e as operações técnicas. O documento de funções e responsabilidades prevê que os clientes combinem os serviços com um SAP Cloud Architect Advisor, um Client Delivery Manager ou a equipe do centro de clientes da nuvem privada da SAP. Coloque quem a SAP designar no seu quadro, ao lado da equipe do parceiro, e nomeie do seu lado a pessoa responsável por essa relação. No on-premise, a SAP é uma fornecedora de software e isso não se aplica.

Clean Core e responsabilidade pelas extensões

No S/4HANA Cloud Public Edition, o Clean Core é imposto pelo próprio desenho: as extensões passam por APIs liberadas, ferramentas de key user ou pelo SAP BTP. Na nuvem privada e no on-premise, as modificações ainda são possíveis, mas cada uma torna os upgrades mais difíceis. Alguém precisa ser dono dessa linha.

Em programas maiores, é um arquiteto de Clean Core ou líder de extensões BTP dedicado, subordinado ao arquiteto de soluções. Em programas de médio porte, o arquiteto de soluções costuma absorver o papel, mas a responsabilidade precisa estar por escrito. Ao avaliar parceiros, pergunte quantas extensões BTP eles entregaram e peça para ver exemplos.

A IA muda a produtividade, não a responsabilidade

O SAP Joule for Consultants (disponível de forma geral desde 2025) responde a perguntas de configuração a partir da própria base de conhecimento da SAP e explica código ABAP. O SAP Build Code gera código de extensão em Java e JavaScript no SAP BTP. O Microsoft Copilot redige resumos para o comitê de direção e relatórios de status.

Os ganhos aparecem em funções com muito fluxo de trabalho, como análise de requisitos, relatórios de status e desenvolvimento customizado, e só quando as pessoas usam as ferramentas de forma consistente. Trate qualquer número de produtividade que lhe apresentarem como uma afirmação a testar no seu próprio programa.

A equipe fica um pouco menor do que o mesmo escopo exigia antes dessas ferramentas, mas não de forma dramática. Inclua as ferramentas nas definições das funções em vez de tratá-las como uma atividade paralela. A IA redige mais rápido. As pessoas continuam sendo donas do que o rascunho diz.

A tabela mostra o dimensionamento típico de cada função por escala da empresa. Use-a como ponto de partida e ajuste conforme o escopo e a geografia. Para a mesma pergunta fora do SAP, veja meu guia da equipe de implementação de ERP.

Função	Pequena empresa	Médio porte	Grande empresa
Patrocinador executivo	Diretor sênior	CIO ou CFO	Alta diretoria (C-level) com comitê de direção
Gerente de projeto	1 em tempo integral	1-2 em tempo integral	Gerente de programa mais gerentes das frentes de trabalho
Líderes funcionais	1-2 por módulo	Dedicados por módulo	Vários por módulo
Equipe de TI	2-3 (compartilhados)	4-6 (dedicados)	8+ especialistas
Migração de dados	1 líder	1 líder mais analistas	Frente de trabalho dedicada
Gestão de mudanças	1 no mínimo	2 no mínimo	3-5 dedicados
Líder de Clean Core ou de extensões BTP	Arquiteto de soluções	Arquiteto de soluções	Função dedicada
Contatos da SAP (RISE)	Contato nomeado	Contato nomeado	Contatos nomeados com revisões trimestrais
Parceiro de implementação	5-10 consultores	15-25 consultores	30+ com um diretor de programa

As habilidades técnicas fazem o sistema ser construído. A inteligência emocional decide se as pessoas o usam.

Trabalhei com uma indústria em que o gerente do depósito sorria nas reuniões, mas minava o projeto pelos bastidores. Um gestor de mudanças perspicaz percebeu os sinais cedo e o transformou em defensor do projeto. Descobrir isso no go-live teria sido muito mais difícil de corrigir.

O gerente de projeto de um cliente era tecnicamente brilhante, mas não conseguia adaptar a mensagem. Um CFO precisa de uma comunicação diferente da que a equipe do depósito precisa. O resultado foi pouca adesão em toda a organização e um go-live doloroso.

A resposta para “funcionários ou consultores?” quase sempre é os dois.

Os funcionários conhecem o negócio: os processos, a política interna e as gambiarras que ninguém documenta. Trabalhei com uma indústria cujos funcionários identificaram problemas de implementação que os consultores externos deixaram passar por completo. Essas percepções a pouparam de uma configuração desastrosa do depósito.

Os funcionários muitas vezes não têm experiência de implementação. Um cliente de varejo insistiu em uma equipe totalmente interna. Seis meses depois, estavam irremediavelmente atrasados porque aprendiam o SAP enquanto o implementavam.

Os consultores trazem reconhecimento de padrões. Levei um consultor a um cliente e ele identificou de imediato uma abordagem de migração de dados que teria derrubado o go-live.

O risco com consultores é a transferência de conhecimento. Se ninguém por dentro aprende o sistema, os honorários de consultoria continuam muito depois do lançamento.

O modelo que funciona: duplas de acompanhamento. Um cliente farmacêutico deu a cada consultor uma contraparte interna que será dona daquela área depois do go-live. O consultor entrega, a contraparte aprende e o conhecimento fica. Em torno desse modelo, seis práticas fazem a diferença:

1. Monte a equipe antes de escolher o software. Um cliente comprou módulos que sua equipe não sabia manter, e seis meses de caos se seguiram.
2. Dedique as pessoas integralmente. Tempo parcial significa que o trabalho do dia a dia vence quando a pressão chega. Já vi configuração crítica esperar semanas porque alguém estava ocupado demais.
3. Coloque todos no mesmo lugar sempre que possível. Um cliente industrial economizou semanas de idas e vindas ao reunir a equipe na mesma sala três dias por semana.
4. Defina os caminhos de escalonamento cedo. Um cliente de varejo tinha um documento de uma página mostrando exatamente como as decisões subiam na cadeia. Isso evitou incontáveis atrasos.
5. Registre as decisões com a justificativa. Trabalhei com uma empresa que anotava o que decidia e por quê. Isso evitou discussões intermináveis quando novos executivos chegaram no meio do projeto.
6. Marque os marcos ao longo do caminho. Um cliente industrial fazia eventos mensais de reconhecimento. Uma coisa pequena, mas manteve o moral alto durante uma exaustiva implementação de 18 meses.

O erro que as empresas cometem depois do go-live é desfazer a equipe de implementação. É exatamente nessa hora que o CoE precisa assumir as melhorias, os upgrades, a governança, o treinamento de novos usuários e manter a configuração alinhada ao modo como o negócio realmente funciona.

Planeje isso durante a implementação. Tive um cliente industrial que ignorou esse conselho. Três meses depois do go-live, os principais especialistas em configuração saíram. Ninguém sabia manter o que tinha sido construído, e o sistema começou a se degradar imediatamente.

Estas são as funções do CoE a planejar desde os primeiros meses da implementação.

Função no CoE	Responsabilidade principal
Diretor do CoE	Estratégia SAP, alinhamento com os objetivos do negócio, operação do CoE
Arquiteto de soluções	Arquitetura, desenho de integração, governança de Clean Core
Líder de Clean Core ou de extensões BTP	Catálogo de extensões, análise de impacto dos upgrades
Consultores funcionais	Otimização de módulos, melhoria de processos
Consultores técnicos	Desenvolvimento, Basis, desempenho, segurança
Líder de mudança e treinamento	Adoção, treinamento, elevação de capacidades
Líder de governança de dados	Qualidade e padrões dos dados mestre
Líder de integração	Middleware, APIs, fluxos de dados entre sistemas
Líder de suporte	Resolução de problemas, melhoria contínua
Responsável pela relação com a SAP (RISE)	Escalonamentos à SAP, revisões de serviço, alinhamento do roadmap

Uma empresa farmacêutica designou donos de módulo que tinham de aprovar qualquer mudança capaz de afetar sua área. Essa governança evitou as mudanças descoordenadas que costumam tornar os sistemas difíceis de usar depois de dois ou três anos.

Um cliente investiu 10% do orçamento do CoE em aprendizado contínuo. Três anos depois, estava implementando funcionalidades que seus concorrentes não conseguiam tocar. É assim que um CoE funcionando se parece.

Por que as equipes de implementação do SAP fracassam mesmo quando o plano parece sólido?

Em geral porque o plano cobre a tecnologia e ignora as pessoas. Os padrões comuns são funções-chave nas mãos de quem tem outros trabalhos, especialistas puxados de volta para a operação no meio do projeto e a gestão de mudanças tratada como uma função de treinamento. Quando ninguém é dono de uma decisão e não há caminho de escalonamento, os bloqueios ficam semanas parados e o projeto fracassa na coordenação, não na tecnologia.

Quais funções são inegociáveis em qualquer implementação do SAP?

Seis funções precisam de pessoas dedicadas e responsáveis: patrocinador executivo, gerente de projeto, pelo menos um líder funcional por módulo principal, um líder de TI, um líder de migração de dados e um líder de gestão de mudanças. Tire qualquer uma e a lacuna aparece nas últimas semanas antes do go-live. A gestão de mudanças é a mais subdimensionada. No RISE, acrescente um responsável claro pelas extensões e pela relação com os contatos de entrega da SAP.

O que muda no desenho da equipe para o RISE with SAP?

A SAP opera a infraestrutura e as operações técnicas, então você trabalha com contatos designados pela SAP, como um Client Delivery Manager ou um Cloud Architect Advisor. Coloque-os no quadro e nomeie o seu próprio responsável pela relação. A responsabilidade pelo Clean Core também precisa ser explícita: um arquiteto dedicado em programas grandes, ou o arquiteto de soluções nos de médio porte.

Uma equipe de projeto SAP deve usar funcionários ou consultores?

Os dois. Os funcionários trazem um contexto de negócio que os consultores não conseguem replicar rápido. Os consultores trazem um reconhecimento de padrões de implementação que os funcionários costumam não ter. Una cada consultor a uma contraparte interna que será dona daquela área depois do go-live, para que o conhecimento fique quando os consultores forem embora. As empresas que pulam isso muitas vezes pagam por anos de suporte que deveriam ter assumido internamente.

Quando começar a montar o CoE do SAP?

Durante a implementação, idealmente desde os primeiros meses. Seus melhores integrantes do CoE costumam ser seus melhores colaboradores da implementação, e se você esperar até o go-live eles seguem em frente antes de você os identificar. Um cliente industrial que esperou perdeu os principais especialistas em configuração três meses depois do go-live, e ninguém sabia manter o que tinha sido construído.

Como a IA muda o desenho da equipe SAP em 2026?

Ferramentas como o SAP Joule for Consultants, o SAP Build Code e o Microsoft Copilot elevam a produtividade em funções com muito fluxo de trabalho quando as pessoas as usam de forma consistente. A equipe fica um pouco menor do que o mesmo escopo exigia antes dessas ferramentas, mas não de forma dramática. Inclua as ferramentas nas definições das funções e mantenha a responsabilidade com as pessoas: a IA redige mais rápido, as pessoas continuam sendo donas do que o rascunho diz.