Implementação vs. rollout do SAP: diferenças e quando escolher

Uma implementação do SAP constrói o sistema onde ele não existe. Um rollout pega um sistema SAP que já funciona em algum lugar do grupo e o estende a um novo país, entidade ou unidade de negócio. A maioria das pessoas acha que um rollout é apenas uma implementação menor. Essa suposição causa mais retrabalho nesses programas do que qualquer decisão técnica.

Certa vez deixei um CFO acreditar que um rollout regional do SAP seria plug-and-play. Expliquei os riscos, mas não insisti. Estávamos usando um template global, e ele presumiu que todas as localidades se encaixariam sem muito esforço. Não foi assim. Uma região precisava de tratamento fiscal adicional. Outra tinha campos obrigatórios de dados de funcionários por causa da legislação local. O que parecia um trabalho de copiar e colar exigiu customização de verdade.

Por isso a escolha muda a forma de alocar equipe, orçar e conduzir o trabalho. Se errar, o sistema ainda pode entrar em produção, só que não do jeito que você planejou.

Uma implementação parte do zero. Você define o escopo, mapeia processos, configura, migra dados e constrói integrações. Aplica-se quando a organização não tem SAP ou substitui um sistema legado por completo.

Um rollout reaproveita um desenho que já funciona: processos, configuração, padrões de dados mestre. O trabalho está na distância entre esse template e o que o novo local precisa. Impostos, relatórios legais, moedas, idiomas, integrações locais e as pessoas que vão usar o sistema.

1. 05Usuários locaisTreinamento adaptado ao processo local, no idioma local
2. 04Integrações locaisBancos, sistemas de declaração fiscal e de logística no novo país
3. 03Dados locaisDados de clientes, fornecedores e materiais mapeados para os padrões globais
4. 02Requisitos locaisImpostos, relatórios legais e campos obrigatórios. Apenas requisitos, não preferências
5. 01Template globalProcessos, configuração e padrões de dados mestre que já funcionam

Assim os dois se comparam na prática:

Área	Implementação do SAP	Rollout do SAP
Ponto de partida	Sem SAP, ou um sistema legado sendo substituído	SAP já em operação na matriz ou em outra entidade
Desenho	Desenho novo, fit-to-standard	Template global com desvios locais controlados
Duração típica	12 a 24 meses, mais para grandes grupos	6 a 12 meses por local
Principal risco	Incógnitas em todas as frentes de trabalho	Localização e prontidão local
Dados	Carga completa a partir dos sistemas legados	Dados locais mapeados para os padrões globais de dados mestre
Testes	Ciclo completo: unitário, integração, UAT, desempenho	Localização, interfaces locais, UAT
Gestão de mudanças	Programa completo desde o zero	Materiais existentes adaptados às equipes locais

Uma implementação faz sentido quando:

1. A organização nunca usou SAP.
2. O sistema atual está falhando e precisa ser substituído por inteiro.
3. Uma fusão, aquisição ou novo modelo operacional faz com que o desenho antigo não sirva mais.
4. Uma solução setorial entra pela primeira vez, como o SAP for Utilities ou o SAP for Public Sector.
5. Nenhum template existente cobre o escopo de que você precisa.

Implementações levam mais tempo e custam mais no início. Você ganha um desenho que corresponde ao seu negócio e uma equipe que entende cada escolha por trás dele. Empresas que atropelam os requisitos acabam gastando de 30 a 50 por cento a mais corrigindo erros depois. Já vi isso acontecer várias vezes.

Um rollout faz sentido quando o SAP já funciona bem em algum lugar do grupo, os processos centrais são estáveis e o template é flexível o bastante para absorver requisitos locais sem quebrar. Se qualquer um desses três pontos estiver frágil, corrija o template antes de levá-lo a qualquer lugar.

A parte técnica costuma terminar no prazo. Os atrasos vêm das pessoas e de premissas que não se sustentam no novo país.

Um template imposto às equipes locais

O que funcionou bem para a América do Norte pode ser insuficiente na Ásia ou no Oriente Médio. Estruturas fiscais, fluxos de aprovação e regras de entrada de dados variam. Certa vez trabalhei com uma empresa que presumiu que seu template europeu funcionaria no Oriente Médio. Isso gerou atrasos, reescritas e muita tensão. Os processos de negócio eram simplesmente diferentes demais.

A solução é dar ao novo local um dono do negócio com autoridade para decidir. Equipes da matriz que definem processos para lugares que não conhecem produzem desenhos que fracassam no primeiro contato com os usuários locais.

Localização descoberta nos testes

Tratamento fiscal, relatórios legais e campos de dados obrigatórios precisam ser confirmados antes de o desenho começar. Certa vez apoiei um cliente em que uma simples diferença de configuração fiscal atrasou o go-live em mais de um mês. Não era uma questão de tecnologia. Ninguém havia validado as necessidades locais cedo o suficiente.

Dados mestre que não se alinham

Códigos de produto, números de cliente e classificações de fornecedor precisam seguir os padrões globais. Divergências descobertas depois do go-live são caras de corrigir e quebram a consolidação dos relatórios. Mapeie os dados locais para o modelo global durante o desenho, não no UAT.

Treinamento que explica o sistema global, não o local

Os rollouts tendem a reutilizar o treinamento da implementação original. Esse material explica como o sistema funciona na matriz. Não explica as adaptações locais. Usuários que não entendem por que a versão deles é diferente vão criar gambiarras.

A estrutura acima continua valendo. O modelo de implantação do template muda parte da economia e as regras de extensão.

No RISE with SAP (Private Edition), cada novo país acrescenta usuários a uma assinatura precificada em equivalentes de usuário completo (FUEs). O custo é previsível e há menos trabalho de infraestrutura. O custo também continua depois do go-live, então compare as opções ao longo de vários anos, não apenas no primeiro.

No GROW with SAP (Public Edition), verifique primeiro se a SAP entrega uma versão local para o país. A SAP listava versões locais para 59 países e regiões em fevereiro de 2024. Para os demais países, a localização como autoatendimento da SAP permite que parceiros construam uma versão local do cliente com a Configuration Localization Tool, atualmente por meio de um programa de adotantes iniciais (SAP Learning). Se nenhuma das duas opções se aplica, o que você tem é um problema de escopo, não um rollout.

O Clean Core vale para todo desvio local. A Public Edition só aceita extensões por meio de interfaces liberadas. Na Private Edition é uma escolha de governança, mas cada modificação local que você permite é mais um objeto a retestar em cada upgrade, multiplicado por cada país. A disciplina que defendo é simples: legislação fiscal, relatórios legais e exigências regulatórias justificam um desvio. Preferências locais, não.

Antes de comprometer uma data para o próximo país, obtenha um sim em cada um destes pontos. Cada um tem um responsável.

1. Dono do negócio local (novo país): nomeado, com autoridade para aprovar o desenho local.
2. Assessor fiscal e jurídico: impostos, relatórios legais e campos de dados obrigatórios documentados antes do início do desenho.
3. Dono do template (matriz): lista de desvios propostos, cada um marcado como requisito ou preferência.
4. Líder de dados: dados locais de clientes, fornecedores e materiais mapeados para os padrões globais.
5. Líder de integração: sistemas locais que precisam se conectar, como bancos, declaração fiscal ou logística, identificados e dimensionados.
6. Líder de mudança: treinamento adaptado ao processo local, no idioma local, com exemplos locais.
7. Diretor do programa: um local por vez, com as lições do último go-live aplicadas ao seguinte.

Meu guia de template de escopo ajuda no item 3, e o guia de termo de abertura do projeto mostra como registrar por escrito os direitos de decisão.

Uma implementação greenfield no Egito. Uma empresa industrial regional sediada no Egito estava presa a sistemas antigos e desconectados e a muito trabalho manual. Cadeia de suprimentos, acompanhamento da produção e relatórios financeiros não conversavam entre si. Eles implementaram o SAP S/4HANA do zero e conectaram finanças, compras e produção em um único sistema. Configuraram o planejamento automatizado da cadeia de suprimentos e treinaram mais de 5.000 funcionários em quatro países antes do go-live. Não atropelaram nada. Reduziram os custos operacionais em 25% e os erros de previsão em 35%.

Um rollout para 15 mercados. Uma empresa de varejo já tinha o SAP S/4HANA rodando na matriz e precisava dele em 15 novos mercados. Cada um tinha regras fiscais, moedas e práticas de negócio diferentes. Partiram de um template global, ajustaram para cada local, fizeram o rollout em fases ao longo de dois anos em vez de tudo de uma vez e prepararam treinamento para cada região. O resultado foi uma consolidação financeira mais rápida, controle de estoque em tempo real em todas as lojas e relatórios 20% mais precisos no nível do grupo.

Um construía algo que não existia. O outro estendia algo que funcionava. Nenhum foi plug-and-play. Se você está no início do primeiro tipo, meu guia sobre como iniciar uma implementação do SAP do jeito certo é o lugar para começar.

Qual é a diferença entre implementação e rollout do SAP?

Uma implementação constrói o SAP do zero: requisitos, desenho de processos, configuração, migração de dados, integração, testes e go-live. Um rollout estende um sistema SAP existente e seu template global a um novo país, entidade ou unidade de negócio. O trabalho do rollout é a distância entre o template e as necessidades locais: impostos, relatórios legais, idioma, integrações locais e treinamento.

Quando uma empresa deve escolher a implementação em vez do rollout?

Escolha uma implementação quando não há SAP para estender ou quando um sistema legado está sendo substituído por inteiro. Também é o melhor caminho quando o modelo de negócio mudou tanto que o desenho existente não serve mais, ou quando nenhum template cobre o escopo necessário. Forçar o rollout de um template inadequado gera mais retrabalho do que um desenho limpo.

Quanto tempo leva um rollout do SAP em comparação com uma implementação?

Uma implementação normalmente leva de 12 a 24 meses, mais para grandes grupos. Um rollout normalmente leva de 6 a 12 meses por local, dependendo da localização, das integrações e dos dados. A maior variável é o quanto os requisitos locais foram validados antes do início do desenho.

Quais são os maiores desafios em um rollout do SAP em vários países?

Quatro aparecem repetidamente. Templates impostos às equipes locais sem a participação delas. Requisitos de localização descobertos durante os testes. Dados mestre que não correspondem aos padrões globais. Treinamento que explica o sistema global em vez do local. A maioria são problemas de pessoas e de planejamento, não técnicos.

Um rollout do SAP é sempre mais barato do que uma implementação completa?

Em geral sim, porque o desenho já existe e foi comprovado. A economia diminui quando um país tem regras fiscais ou de folha de pagamento complexas, precisa de várias integrações locais ou tem dados ruins. No RISE with SAP, a assinatura de cada novo país continua depois do go-live, então compare os custos ao longo de vários anos.

Como funciona um template global em um rollout do SAP?

O template global é o desenho SAP documentado e configurado para os processos padrão do grupo. Cada rollout parte dele e acrescenta apenas as mudanças locais realmente necessárias. Cada desvio cria uma obrigação de manutenção em cada upgrade, então governe-os: requisitos como a legislação fiscal justificam um desvio, preferências não.