Planejamento da alocação de recursos em projetos SAP

Planejar a alocação de recursos de um projeto SAP significa decidir de quais funções você precisa, em qual fase do SAP Activate, por quantas horas por semana, e depois verificar toda semana se a realidade ainda corresponde ao plano. Aloque por função, não por número genérico de pessoas. Molde o plano à curva das fases: perfis funcionais em Explore, perfis técnicos em Realize, dados, Basis e mudança em Deploy. Confirme a disponibilidade por escrito com os gestores diretos. Este guia é para diretores de programa, PMOs e CIOs que estão montando ou resgatando um plano de recursos de S/4HANA. Use as tabelas de FTE e as faixas de valores diários abaixo como pontos de partida.

Vi dezenas de implementações enfrentarem os mesmos problemas de recursos. O plano pressupõe uma estabilidade que desaparece assim que a execução começa.

Certa vez vi uma equipe perder uma semana inteira porque ninguém tinha percebido que o líder de segurança tinha licença e treinamento em sequência. Não foi sinalizado nem acompanhado, e isso atrasou em nove dias uma revisão crítica de acessos ao sistema.

A maioria dos planos SAP se apoia em estimativas redondas, disponibilidade em tempo integral e fluxos de trabalho previsíveis. Essa versão do mundo raramente sobrevive ao primeiro mês de Realize.

Eu planejo em torno de três coisas: o que o trabalho realmente exige, o que as pessoas disponíveis realmente vão entregar e o que muda quando a realidade difere do plano. Um plano que se sustenta cobre seis dimensões:

1. Quantidade de pessoas por função e por fase do Activate. Não uma alocação uniforme. Explore em nada se parece com Realize.
2. Horas por semana confirmadas pelo gestor direto. Por escrito, não presumidas.
3. Compromissos simultâneos por pessoa. Quem consta com 100% e também cobre o suporte à produção vai entregar muito menos.
4. Substituto para cada função do caminho crítico. O treinamento cruzado não é opcional em um programa de 18 meses.
5. Dependências entre frentes de trabalho. Cada uma com um responsável nomeado, uma data de entrega e um caminho de escalonamento, visível no dia em que atrasa.
6. Cadência de atualização. Semanal nas fases ativas. O plano do kick-off é a versão um.

Os planos dão errado quando quem planeja usa funções genéricas de TI. O SAP exige especialização funcional e técnica específica. O conjunto padrão de um programa S/4HANA:

Liderança do programa. Gerente de programa, líder de PMO e arquiteto de soluções. O arquiteto é responsável pela coerência do desenho entre os módulos.

Consultores funcionais. Um líder por módulo no escopo: Contabilidade Financeira (FI), Controladoria (CO), Gestão de Materiais (MM), Vendas e Distribuição (SD), Planejamento da Produção (PP), Extended Warehouse Management (EWM), além de Gestão de Capital Humano (HCM), Manutenção de Planta (PM) e Sistema de Projetos (PS) quando estiverem no escopo. Se você ainda usa o Warehouse Management (WM) clássico, planeje a migração: os direitos de uso do Compatibility Pack para ele no S/4HANA on-premise terminaram no fim de 2025.

Consultores técnicos. Desenvolvedores ABAP para relatórios, interfaces, conversões, enhancements, formulários e workflows (RICEFW), e para extensões Clean Core sobre APIs liberadas ou o SAP BTP. Especialistas em integração para o SAP Integration Suite (Cloud Integration, antes CPI), o SAP Process Orchestration onde ele ainda roda e qualquer middleware de terceiros.

Plataforma. Consultores Basis para HANA, patches de kernel, transportes, cópias de sistema e ajuste de desempenho. Consultores de segurança para o desenho de roles de acesso, a análise de segregação de funções e o SAP GRC Access Control quando estiver no escopo.

Dados. Especialistas em migração que usam o app “Migrate Your Data” do SAP S/4HANA Migration Cockpit (a antiga transação LTMC foi descontinuada), o Migration Object Modeler para objetos customizados e o SAP Data Services para transformações complexas. Meu guia sobre por que a migração de dados SAP falha explica por que essa equipe precisa começar mais cedo do que a maioria dos planos permite.

Mudança. Líder de mudança, líder de treinamento e responsável pela prontidão do negócio. Costuma ficar com equipe insuficiente, porque a necessidade só aparece em Deploy.

Lado do cliente. Analistas de negócio (um por módulo principal), responsáveis pelos processos (um por domínio de processo) e testadores vindos da operação para o UAT.

Tratar essas funções como vagas intercambiáveis é o erro de planejamento mais comum. Um consultor sênior de FI não conduz uma sessão de desenho de SD. Um desenvolvedor ABAP júnior não desenha a arquitetura de uma integração. Para as responsabilidades função por função, veja minha lista das funções essenciais na equipe de implementação SAP.

A demanda por recursos não é uniforme. As fases do Activate criam curvas previsíveis que uma alocação uniforme não enxerga.

Prepare (normalmente as semanas 1 a 4). Leve. Gerente de programa, arquiteto e um líder por módulo para definir o escopo. Os usuários de negócio confirmam o escopo. Basis e segurança iniciam a preparação dos ambientes.

Explore (normalmente os meses 2 a 5). Pesada em consultores funcionais e usuários de negócio, com os workshops de desenho ditando o cronograma. ABAP e integração ficam leves até que as decisões de desenho se firmem. O Basis prepara os sistemas de sandbox e de qualidade.

Realize (normalmente os meses 5 a 12). Pesada em perfis técnicos: configuração, construção, testes unitários e de integração. A carga de ABAP atinge o pico. Os usuários de negócio entram nos ciclos de teste. A equipe de dados constrói os objetos de migração e executa simulações de carga.

Deploy (normalmente os meses 12 a 14). Pesada em migração de dados, Basis, segurança, mudança e treinamento. O UAT consome a capacidade do negócio. Os ensaios de cutover exigem equipes no mesmo local. O planejamento do hypercare começa.

Run (a partir do mês 14; hypercare normalmente de 30 a 90 dias). Uma equipe central enxuta e cobertura de suporte intensa. Basis e gestão de aplicações aumentam enquanto os consultores diminuem.

Trate essas fases como janelas de igual demanda e você vai superdimensionar Prepare, subdimensionar Realize e ficar sem gente para a migração de dados em Deploy. A curva das fases é o formato mais importante do plano.

1. PrepareCerca de 11 FTEsSemanas 1 a 4. Os líderes definem o escopo e o Basis prepara os ambientes
2. ExploreCerca de 36 FTEsMeses 2 a 5. Perfis funcionais e usuários de negócio
3. RealizeCerca de 56 FTEs, o picoMeses 5 a 12. Construção, e a carga de ABAP atinge o pico
4. DeployCerca de 42 FTEsMeses 12 a 14. Dados, Basis, segurança, mudança
5. RunCerca de 12 FTEsA partir do mês 14. Hypercare normalmente de 30 a 90 dias

Emergências constantes. Quando a equipe vive apagando incêndio, o plano deixou de prever a realidade. Uma única ausência não deveria ser capaz de descarrilar uma frente de trabalho.

Os usuários de negócio somem quando você precisa deles. As sessões de desenho e o UAT travam porque os usuários de negócio não estão disponíveis. É uma das fontes de atraso mais comuns. A causa é quase sempre a mesma: o tempo foi presumido, não formalmente comprometido. A pressão operacional vence sempre que o compromisso não foi formalizado.

Perfis técnicos espalhados demais. O trabalho de Gerald Weinberg sobre gestão de software estimou que alguém dividido entre três projetos entrega cerca de 60% da sua capacidade total, e o restante se perde na troca de contexto. O resumo da American Psychological Association sobre as pesquisas de alternância de tarefas aponta a mesma ordem de perda: breves bloqueios mentais ao alternar entre tarefas podem custar até 40% do tempo produtivo. O plano parece eficiente. O resultado, não.

O caminho crítico muda toda semana. Remanejamentos constantes, frentes de trabalho que começam tarde e mudanças semanais de prioridade geralmente remontam a um escopo pouco claro ou a dependências mal sequenciadas. Corrija o escopo antes de corrigir o plano de recursos.

1. Disponibilidade de fachada. Alguém consta com 100% e também cuida do fechamento mensal e do suporte à produção. Pergunte quantas horas por semana, em que mais a pessoa trabalha e se o gestor direto confirmou por escrito.
2. Funções compartilhadas sem limites. Uma pessoa fazendo desenho de solução, testes e gestão de mudanças ao mesmo tempo. Divida as responsabilidades por tarefa, não por cargo, e nunca torne uma pessoa crítica em dois lugares ao mesmo tempo.
3. Falta de tempo dos usuários de negócio. Os workshops atrasam e as aprovações do UAT levam semanas a mais. Obtenha o tempo comprometido por escrito e assinado pelo chefe do departamento, acompanhe a presença e escalone os padrões cedo.
4. Sem margem. Uma ausência paralisa uma frente de trabalho. Crie margem no nível da tarefa, não só no da fase, e treine de forma cruzada pelo menos uma pessoa em cada função central.
5. Um plano nunca atualizado. Montado no kick-off e nunca revisado. Revise-o toda semana durante a entrega ativa, vincule-o aos gates de fase e atualize-o quando a realidade mudar.

Comece pela disponibilidade confirmada. Procure os gestores diretos antes de o projeto começar. Confirme as horas por semana e os demais compromissos, e documente. Quando a disponibilidade mudar no meio do projeto, essa linha de base é o seu fundamento para escalonar.

Molde-o por fase. A carga de um desenvolvedor ABAP em Explore difere da de Realize. Os usuários de negócio têm pico em Explore, para o desenho, e em Deploy, para o UAT. Uma alocação uniforme parece equilibrada no papel e falha na prática.

Mapeie as dependências de forma explícita. A migração de dados alimenta os testes de integração, que alimentam o UAT, que conduz o cutover. Dê a cada dependência um responsável, uma data e um sinalizador, para que um atraso fique visível no mesmo dia.

Proteja o tempo dos usuários de negócio no nível do comitê de direção. O trabalho do dia a dia deles continua. Sem a aprovação explícita da gestão deles sobre as horas por semana, eles vão largar o projeto quando a pressão operacional chegar. Quem deve pedir esse tempo aos chefes de departamento é o patrocinador, não o gerente de projeto.

Atualize o plano toda semana. Um plano intocado há duas semanas provavelmente está errado. Acompanhe a utilização real contra a planejada. Alguém com 120% por duas semanas seguidas é sinal de que a pessoa está sobrecarregada ou de que o plano está errado.

São faixas indicativas de quantidade de pessoas e de valores, para usar como pontos de partida. Setor, escopo, geografia e parceiro mudam todos eles. Use as tabelas como verificação de sanidade, não como cotação.

Brownfield de médio porte (US$ 5 milhões a US$ 15 milhões, cerca de 12 meses)

Escopo típico: uma única entidade jurídica ou um grupo pequeno, três ou quatro módulos (normalmente FI, CO, MM, SD), processos padrão e desenvolvimento customizado limitado.

Frente de trabalho	Prepare	Explore	Realize	Deploy	Run
Gerente de programa	1	1	1	1	0,5
Arquiteto de soluções	1	1	1	0,5	0
Consultores funcionais (FI/CO, MM, SD mais um)	1	4	4	2	1
ABAP e técnico	0	1	3	1	0,5
Integração	0	0,5	2	1	0,5
Basis	0,5	0,5	1	2	1
Segurança e autorizações	0	0,5	1	1,5	0,5
Migração de dados	0	1	2	3	0
Líder de testes	0	0,5	1	1	0
Mudança e treinamento	0,5	1	1	2	0,5
Analistas de negócio do cliente	1	4	3	2	1
Total de FTE no pico	5	14	20	17	5

Brownfield corporativo (US$ 30 milhões a US$ 80 milhões, 15 a 18 meses)

Escopo típico: várias entidades, de seis a nove módulos, integração complexa, desenvolvimento customizado significativo e várias implantações por país.

Frente de trabalho	Prepare	Explore	Realize	Deploy	Run
Gerente de programa e PMO	2	2	3	3	1
Arquitetos de soluções (líder mais módulo)	2	3	3	1,5	0,5
Consultores funcionais (todos os módulos no escopo)	2	10	12	5	2
ABAP e técnico	0	3	8	3	1
Integração e middleware	0,5	2	5	2	1
Fiori e UI5	0	1	3	1	0,5
Basis	1	1	2	4	2
Segurança e GRC	0,5	1,5	2	3	1
Migração de dados	0	2	5	6	0,5
Testes	0,5	1	3	4	0
Mudança e treinamento	1	2	3	5	1
Analistas de negócio do cliente	2	8	7	5	2
Total de FTE no pico	11	36	56	42	12

Valores diários por função e região (2024 a 2025)

São valores faturados pelo parceiro por especialista, não salários. O valor médio ponderado do programa costuma ficar de 30 a 50% abaixo do valor onshore sênior, porque a maioria dos programas combina arquitetos onshore com entrega offshore.

Função	Onshore EUA/Reino Unido/Alemanha	GCC (EAU/Arábia Saudita)	Nearshore (América Latina/Leste Europeu)	Offshore (Índia)
Arquiteto de soluções (sênior)	US$ 2.000 a US$ 3.500	US$ 1.500 a US$ 2.500	US$ 900 a US$ 1.500	US$ 500 a US$ 1.000
Consultor funcional (sênior)	US$ 1.500 a US$ 2.800	US$ 1.200 a US$ 2.000	US$ 700 a US$ 1.400	US$ 300 a US$ 700
Consultor funcional (pleno)	US$ 1.000 a US$ 1.800	US$ 800 a US$ 1.400	US$ 500 a US$ 900	US$ 200 a US$ 500
ABAP e técnico (sênior)	US$ 1.400 a US$ 2.500	US$ 1.000 a US$ 1.800	US$ 600 a US$ 1.200	US$ 300 a US$ 700
Especialista em integração	US$ 1.500 a US$ 2.800	US$ 1.100 a US$ 1.900	US$ 700 a US$ 1.300	US$ 350 a US$ 800
Basis	US$ 1.400 a US$ 2.200	US$ 1.000 a US$ 1.800	US$ 600 a US$ 1.100	US$ 300 a US$ 700
Segurança e GRC	US$ 1.500 a US$ 2.500	US$ 1.100 a US$ 1.900	US$ 700 a US$ 1.300	US$ 350 a US$ 800
Migração de dados	US$ 1.300 a US$ 2.200	US$ 1.000 a US$ 1.700	US$ 600 a US$ 1.100	US$ 300 a US$ 700
Líder de mudança e treinamento	US$ 1.200 a US$ 2.000	US$ 900 a US$ 1.500	US$ 500 a US$ 1.000	US$ 250 a US$ 600
Consultor júnior (qualquer função)	US$ 800 a US$ 1.400	US$ 500 a US$ 900	US$ 400 a US$ 700	US$ 150 a US$ 350

A divisão entre onshore, nearshore e offshore

A maioria dos programas SAP combina regiões. É uma decisão de custo versus velocidade, não uma decisão binária.

Os programas do setor privado nos EUA costumam ter de 30 a 60% de onshore em FTE. O onshore se concentra em arquitetura, mudança, análise de negócio e funções funcionais sêniores, onde a proximidade com o negócio importa. O offshore se concentra em ABAP, construção de integrações e execução da migração de dados, onde o trabalho é mais fácil de especificar. Os programas do governo federal dos EUA costumam ser totalmente onshore, com restrições de US person, conforme a carga de trabalho.

Os programas no GCC costumam ter de 60 a 70% de onshore, porque as regras locais de contratação e as exigências de idioma árabe elevam essa parcela. O trabalho offshore tende aos centros do Sul da Ásia, pela sobreposição de fusos horários. Os programas europeus variam: a manufatura costuma ficar em torno de 50% de onshore, enquanto o setor público e os setores regulados vão mais alto por razões de residência de dados.

Um erro comum é otimizar a divisão só pelo custo. Uma equipe 80% offshore, com 20% de arquitetos onshore, parece barata na planilha. Os custos ocultos são o ciclo diário de passagem de bastão e os workshops de desenho mais lentos, sem contexto de negócio. A equipe mais barata raramente entrega o programa mais barato. Ao comparar parceiros, meu guia sobre parceiros de implementação SAP por nível mostra como os valores e o formato da equipe diferem entre eles.

Um plano montado uma vez e nunca reexaminado não é um plano. Trate cada premissa dele como uma hipótese a testar na primeira semana de execução, e em todas as semanas seguintes.

O que é o planejamento de alocação de recursos em projetos SAP e por que ele importa?

É decidir de quais pessoas o projeto precisa, quando e por quanto do tempo delas, e depois acompanhar se isso corresponde à realidade.

Os projetos SAP dependem de indivíduos específicos: o líder de FI/CO que entende o seu plano de contas, o especialista em migração que conhece os seus dados legados, o líder de mudança com relacionamentos no negócio. Quando eles não estão disponíveis no momento certo, o trabalho para ou é feito errado. Muitos atrasos que parecem técnicos são, na verdade, problemas de recursos.

Como uma alocação de recursos ruim causa atrasos em projetos SAP?

Pelas dependências. Um líder de configuração é puxado para outro projeto durante Realize. O trabalho dele para, o que atrasa os testes de integração, depois o UAT, depois a prontidão para o cutover. Uma ausência de duas semanas na semana oito pode virar um atraso de seis semanas no go-live.

Pequenas lacunas no começo viram grandes atrasos no fim. Quando o impacto fica visível, a recuperação custa várias vezes o que uma correção precoce teria custado.

Como conseguir o compromisso dos usuários de negócio com um projeto SAP quando eles têm o trabalho do dia a dia?

Obtenha o compromisso por escrito do gestor direto deles antes de o projeto começar: horas por semana, quais fases mais precisam deles e qual aprovação é exigida se a disponibilidade mudar.

Acompanhe a presença deles como a de qualquer outro recurso. Quando ela cair, escalone no nível do comitê de direção. Os chefes de departamento podem fazer cumprir o compromisso; a equipe do projeto não pode.

Como lidar com a saída de uma pessoa-chave no meio do projeto?

Evite pontos únicos de falha desde o início: pelo menos uma outra pessoa deve entender cada frente de trabalho crítica o bastante para mantê-la andando.

Quando alguém sai, registre imediatamente o que a pessoa sabe: decisões não documentadas e a justificativa das configurações. Isso costuma ser mais difícil do que encontrar um substituto. Para a reposição, um documento de transição, sessões gravadas e uma semana de sobreposição são o mínimo.

Quando devo escalonar um problema de recursos?

Mais cedo do que parece confortável. Escalone quando um responsável nomeado por uma dependência estiver indisponível por mais de uma semana, um usuário de negócio continuar faltando às sessões, um recurso técnico operar acima de 120% de utilização por duas semanas ou uma frente de trabalho estiver bloqueada por uma decisão de alocação adiada.

O custo de escalonar cedo demais é uma conversa constrangedora. O custo de escalonar tarde demais são semanas de atraso.

Como tratar recursos compartilhados entre vários projetos?

Presuma que as pessoas compartilhadas vão priorizar outra coisa quando a pressão chegar. Combine horas específicas por semana com o gestor principal delas, crie margem no trabalho que depende delas e mantenha-as fora do seu caminho crítico, a menos que você tenha um plano B.

Para usuários de negócio compartilhados, o pedido precisa vir do patrocinador. Um gerente de projeto pedindo tempo a um chefe de departamento perde para as prioridades operacionais sempre.