Projetos de implantação de ERP da SAP

BY CONTEÚDO SAP, ON MAIO 29TH, 2011

Recordar é viver! Os grandes projetos de implantação de ERP SAP já aconteceram.

Hoje, as grandes corporações globais e transnacionais já possuem o ERP instalado
e em operação a quase uma década. Os esforços para projetos de implantação do
ERP, atualmente, estão direcionados as médias empresas. Mas como é ou como
funciona um projeto de implantação de ERP SAP?
O assunto é extenso e optamos por contá-lo por partes, seguindo as etapas ou
fases de um projeto. Sobre as fases, sugerimos a leitura do artigo sobre o roadmap
da metodologia ASAP, neste blog ou no site da SAP, para melhor compreensão de
um projeto do seu início até o fim.
Um projeto de implantação de SAP é estratégico para o posicionamento da empresa
no mercado e patrocinado diretamente pela presidência. A SAP, ciente da dimensão
dos seus projetos, desenvolveu uma metodologia conhecida como ASAP –
Accelerated SAP – usada por ela e pela boa parte das consultorias parceiras para
gestão dos projetos de implantação do ERP ou outras plataformas.
A metodologia objetiva conduzir o projeto através de cinco fases de forma a garantir
a entrega do sistema em ambiente produtivo, de acordo com o escopo e prazo
contratados, e com a qualidade assegurada. A ASAP possui ferramentas aceleradoras
em cada fase de projeto que permitem a redução de tempo de consultoria e
aceleração na realização das atividades pelas equipes de projeto.
Na fase de desenho da solução, a fase 2, algumas ferramentas disponíveis ajudam
na organização da documentação e acompanhamento do andamento e status do
projeto. O “Solution Manager” cumpre com este papel e é considerada a ferramenta
de gestão de projetos SAP. Outra ferramenta utilizada como aceleradora da fase de
desenho são questionários prontos, separados por módulo do R/3, que ajudam a
delimitar o escopo para a implantação do módulo. Estes questionários são conhecidos
como “Q&Adb” (Questions&Answers database) e são preenchidos pelo consultor de
acordo com as respostas fornecidas pelos usuários-chave do módulo SAP. O uso do
“Q&Adb” auxilia também na definição do conjunto de atividades de customização do
módulo em função das respostas recebidas. Depois da aplicação do questionário são
realizadas reuniões de detalhamento dos processos existentes no cliente e
levantamento de requisitos para a implantação. Com as respostas ao questionário e
as informações do levantamento de processo é possível elaborar o documento de
Business Blueprint onde essencialmente é feito o detalhamento da situação atual (As
Is) e desenhada a situação futura (To Be) de um processo de negócio no R/3 do
cliente. A avaliação de impactos organizacionais, tecnológicos, pessoas e
organização, a identificação dos gaps de processo são itens do escopo de um
blueprint. Os gaps são situações ou processos de negócio do cliente que não são
cobertos pela solução standard do R/3.
Recentemente, para o desenho do “As Is” e “To Be” do Blueprint, tem sido utilizada
a ferramenta Aris que, segundo a SAP, possui integração com o Solution Manager. O
resultado é a criação automática de processos, sub-processos e atividades no
Solution Manager com os respectivos desenhos de processo (As Is e To Be). As
atividades são as transações do R/3 que serão utilizadas na solução do ERP do cliente.
Dessa maneira, o escopo de customização do módulo é definido através das
transações que serão utilizadas.
Na fase 3, a fase de maior duração do projeto e chamada de “Realização” corresponde
a construção da solução validada na fase de desenho. O Solution Manager continua
como a ferramenta de gestão e passa a assumir um papel importante de acesso
central aos ambientes SAP do projeto e repositório da documentação da fase 2. Outra
ferramenta aceleradora usada na fase é o LSMW – Legacy System Migration
Workbench – usado para gerar programas de carga de dados automaticamente no
R/3 dispensando o desenvolvimento de programas ABAP. Normalmente, as cargas
são de dados mestres do módulo, cargas de saldos de estoque e conta contábil. É
disponibilizado também o serviço da SAP de consultoria e suporte remoto ao projeto,
conhecido como OSS – Online Service Support. O gerenciamento de chamados na
OSS é feito também pelo Solution Manager. Para elaboração de materiais de
treinamento existem ferramentas facilitadoras que geram automaticamente o
material sendo uma bastante difundida no mercado o RWD uPerform da empresa
RWD, site http://www.rwd.com/solutions/products.aspx
Na fase 3, a SAP faz um trabalho mais próximo do cliente para garantir a qualidade
na solução. Mediante agendamento, consultores da SAP realizam a revisão de
processos com a respectiva equipe do módulo; este trabalho é conhecido como
“Project Review”. O objetivo é verificar se as melhores práticas da solução standard
estão sendo aplicadas e sugerir correções pontuais. Outro serviço oferecido pela SAP
ao cliente é o “Safety Guarding” que ajuda na identificação dos riscos do projeto,
detalhamento dos riscos e sugestões para mitigá-los. Sem a mitigação dos riscos em
potencial, a SAP aconselha ao cliente a não entrar em produção.
A Gestão de Mudança é outro importante trabalho no projeto de implantação e anda
em paralelo com as fases do projeto. Ela é responsável pela mudança de cultura na
organização, fator crítico de sucesso para o projeto. A Gestão de Mudança cuida da
relação das pessoas com a nova realidade corporativa que nasce junto com o projeto
de implantação. Normalmente, os impactos causados pela implantação de um
sistema de gestão integrada podem ser de âmbito organizacional, de pessoas, de
processos e tecnologias. Identificar estes impactos e gerenciá-los de forma a reduzir
os riscos da implantação é atividade da Gestão de Mudança em conjunto com a
gerência do projeto. Um trabalho importante e sob a supervisão da Gestão de
Mudança é a gestão do treinamento de usuários para capacitá-los no trabalho com o
novo sistema.
A mudança de cultura acontece também quando a mudança é disseminada, divulgada
na corporação. Vender o projeto de implantação entre os colaboradores do cliente é
também fator crítico de sucesso. Divulgar o projeto e suas fases, as atividades
planejadas e seu andamento, formar comunicadores oficiais do projeto e envolver os
gerentes das áreas são algumas atividades que ajudam na mudança de cultura da
organização.
As fases 2 e 3 são as fases de trabalho intenso para os consultores. Trabalhar com
algumas das ferramentas descritas anteriormente e conduzir e orientar o trabalho da
equipe exige muito jogo de cintura e foco em resultados. Nestas duas fases a
quantidade de “deliveries” ou entregas é grande. Para se ter uma idéia, algumas
entregas previstas nas fases 2 e 3: documentos de blueprint prontos e validados
junto com o cronograma detalhado com as atividades da equipe até o final da fase
3, elaborar apresentações e ministrar workshops para a equipe, elaborar documentos
da customização do módulo, fazer documentos de especificação funcional para os
desenvolvimentos ABAP, preenchimento de planilhas com perfis de usuário, atualizar
o Solution Manager e o cronograma, enfim, são muitas as entregas durante as duas
fases.
Além das atividades de documentação do projeto há também as reuniões durante as
duas fases. Normalmente são reuniões de detalhamento de processo, Workshop com
a equipe, reuniões com outras equipes de módulos do R/3 para detalhar a integração
do sistema, reuniões de acompanhamento do projeto, reuniões com a Gestão de
Mudança, reuniões de Project Review com a SAP, workshops para apresentação das
ferramentas aceleradoras do projeto e reuniões com o comitê gestor do projeto.
O consultor que gerencia este trabalho tem um perfil sênior ou especialista no
módulo. Ele pode ser auxiliado por consultores plenos ou juniores e também por
estagiários. Isso dependerá, evidentemente, do tamanho do projeto e a negociação
com o cliente durante a fase 1 de preparação do projeto. Para a composição das
equipes, existem métricas estabelecidas para auxiliar na determinação da quantidade
de recursos da consultoria de acordo com o número de key-users planejados para
compor a equipe de projeto do cliente. Os Key-users são alocados em cada equipe
de módulo do projeto. É escolhido um líder em cada módulo que será o par do
consultor sênior na condução das atividades da equipe. Têm situações de projeto
onde a equipe do módulo é tão grande que se justifica o uso de um organograma
com as funções segundo uma hierarquia.
A grande dica para o consultor desenvolver um bom trabalho nas fases 2 e 3 é ajustar
o escopo da implantação do módulo com o cronograma detalhado que será entregue
para a gerência do projeto. O cronograma deve respeitar os marcos de fase da
metodologia, isto é, as datas de início e fim previstas para cada fase e o consultor
junto com a equipe deverão fazer um exercício de encaixar as atividades de projeto
na fase respectiva.
Na realização da fase 3, é comum o cliente tomar a iniciativa de tentar incluir no
escopo novos processos que não haviam sido devidamente mapeados na fase 2. Este
é um ponto de atenção constante para o consultor pois poderá colocar em risco os
prazos assumidos no cronograma. Cada nova demanda assinalada pelo cliente é
passível de uma avaliação criteriosa e individual. Estas demandas poderão ser
simples do ponto de vista de implementação como poderão ser demandas que
necessitam de uma redefinição do escopo e prazo do cronograma do módulo. A
estratégia praticada pela consultoria é atender até onde é possível sem prejuízo do
cronograma ou avaliar se a demanda poderá ser atendida como melhoria após a
entrada em produção. Se ambos os casos não se aplicam à solicitação do cliente,
uma negociação com a gerência do projeto e posteriormente com o comitê gestor se
fará necessária.
Na próxima atualização, continuaremos a comentar sobre as fases 2 e 3 e o papel
fundamental da equipe de basis no projeto.

Projetos de implantação de ERP da SAP

(continuação I)
BY CONTEÚDO SAP, ON JUNHO 23RD, 2011

Equipe Basis e sistema de transporte no R/3

A equipe de tecnologia do projeto que cuida do hardware e software do sistema R/3
é conhecida como Basis. A principal missão desta equipe é criar os acessos e manter
os sistemas e mandantes do R/3 disponíveis para o projeto. Posteriormente, prepara
e libera o ambiente de produção para receber as change requests do projeto, usuários
e perfis de acesso. A equipe Basis é a primeira equipe de consultores a chegar no
cliente para uma implantação SAP. Uma equipe Basis é composta por consultores e
o consultor líder de equipe, o líder da equipe de tecnologia do cliente e analistas de
sistemas do cliente. A equipe inicia o trabalho na fase 1 do projeto, a fase de
preparação, e o primeiro desafio é instalar o R/3 e ferramentas aceleradoras da ASAP,
criar o sistema de desenvolvimento e disponibilizar os acessos as ferramentas
aceleradoras.
Para cada projeto, a equipe Basis define a arquitetura de sistemas para o R/3 do
cliente. A figura abaixo mostra uma arquitetura utilizada em boa parte dos projetos
de implantação:
Figura 1 – Landscape dos sistemas DEV e QAS em projetos de implantação SAP R/3

O sistema de Desenvolvimento, conhecido pela sigla DEV ou DES, possui no mínimo,

quatro mandantes: o mandante 000 (3 zeros) usado como referência para
restauração de outros mandantes e disponibilizado pela SAP na aquisição do R/3; o
mandante 100, cópia do 000, mandante conhecido como “Gold” usado para a
customização do R/3; o mandante 200 disponibilizado para desenvolvimento e testes
dos programas ABAP; o mandante 220 disponibilizado para testes da customização
e realização do teste unitário. O mandante 210, conhecido como “Sandbox”, é um
mandante desejável e muito útil nos projetos. A customização é aberta (SPRO) e
permite realizar testes da customização do módulo pelos consultores, teste de
programas de carga de dados mestres (LSMW) e treinamento do analista funcional
ou usuário-chave do cliente.
A transação SCC1 faz o transporte de customizações do mandante de origem, no
caso o 100, para o mandante no qual se deseja trazer as customizações, 220 ou 210.
Outro sistema disponibilizado por Basis é o sistema de Qualidade conhecido pela sigla
QAS de “Quality Assurance System”. Este sistema possui um único mandante. O
sistema QAS é separado do sistema DEV de forma lógica ou, até mesmo, fisicamente,
em outro servidor. Como então transferir o trabalho desenvolvido no sistema DEV
para o sistema QAS?
A resposta está no sistema de transporte do R/3. O sistema de transporte realiza a
transferência da customização realizada em DEV para o QAS de acordo com a
liberação de “Change Requests”. Uma “Change Request” é um “pacote” criado no
mandante DEV 100 (Gold) quando o consultor realiza uma customização. O “pacote”
contem a customização realizada pelo consultor. Este “pacote” estará habilitado ao
transporte para o QAS a partir da sua liberação. Se a “Change Request” não foi
liberada, o seu conteúdo não será transportado para outro sistema sendo possível
somente o transporte entre mandantes do mesmo sistema. Por exemplo, o transporte
de “Change Request” do mandante DEV 100 (Gold) para o DEV 220 (teste unitário).
Existem dois tipos de “pacotes” ou “Change Requests” no sistema de transporte do
R/3: A “Change Request Customizing” usada para guardar a parametrização feita
pelo consultor funcional e a “Change Request Workbench” usada para guardar um
desenvolvimento em Abap/4 feito pelo consultor Abap. O primeiro tipo de change
request é criada no DEV 100 (Gold) e o segundo tipo no mandante DEV 200 (Abap).
O transporte entre o sistema de desenvolvimento (DEV) e o ambiente de qualidade
(QAS) poderá ocorrer de forma automática, a partir da liberação de uma “Change
Request” no DEV 100 ou DEV 200 ou de forma manual, utilizando a transação STMS
– Transport Management System. Nos dois tipos de transporte, a “Change Request”
tem que estar liberada. A forma automática, com intervalos de 5 em 5 minutos, é a
mais comum nos projetos.
Uma vez que a customização do projeto e desenvolvimentos Abap foram
transportados para o sistema de qualidade (QAS), o sistema está apto para os testes
de validação da solução do projeto, conhecido como Teste Integrado. Além da
customização e desenvolvimentos abap, o ambiente de qualidade recebe uma carga
dos dados mestres para o Teste Integrado e possui também os perfis de acesso já
estabelecidos para os futuros usuários do R/3. Com a conclusão do Teste Integrado,
que retornaremos mais a frente para discorrer sobre a importância deste teste, existe
uma segunda etapa de transporte. Desta vez do sistema QAS para o sistema
Produtivo, conhecido pela sigla PRD.
Figura 2 – Landscape dos sistemas QAS e PRD em projetos de implantação SAP R/3

Landscape SAP R/3 (QAS e PRD)

O transporte das “Change Requests” para o sistema de produção (PRD) é realizado
e monitorado pela equipe Basis durante a fase de preparação, a fase 4 na
metodologia ASAP. No sistema de transporte do R/3 é possível o transporte
automático a partir da liberação da “Change Request” no DEV 100 para o QAS e PRD.
Mas esta opção não é habilitada em um projeto de implantação.
O sistema de produção (PRD) possui também mandante único, batizado usualmente
de 400 ou 500 e é o ambiente onde a corporação passará a trabalhar após a entrada
em produção do SAP R/3. O sistema PRD, assim como ocorre entre os sistemas DEV
e QAS, é separado lógica ou fisicamente do sistema QAS. O PRD pode estar instalado
no mesmo servidor, em servidor separado ou até em servidor de empresa
terceirizada que oferece o serviço de “hosting” e manutenção do ambiente. Estará
de acordo com o desenho de arquitetura preconizado e definido pela equipe Basis e
gerência de TI do cliente.
A equipe de Basis é, portanto, a equipe que manterá os sistemas DEV, QAS e PRD,
com os respectivos mandantes, disponíveis para a equipe de projeto e cliente.
O “landscape” de sistemas e mandantes do R/3 representa o ambiente de trabalho
do projeto a partir da fase de realização (fase 3).
Na próxima atualização, testes unitário e integrado e validação da solução.

Testes e validação da solução

Na fase 3, planejar o teste da solução pressupõe que algumas atividades da fase
estejam prontas ou em estágio avançado de conclusão. De acordo com o tipo de
teste são necessários alguns “deliveries”. Por exemplo, para o Teste Unitário, a
parametrização dos processos do módulo e os desenvolvimentos abap
imprescindíveis devem estar finalizados para o teste.
Ao contrário do entendimento atual de boa parte dos profissionais de SAP, o Teste
Unitário não compreende o teste feito pelo consultor enquanto ele parametriza o
módulo. O teste é uma etapa importante da fase 3 do projeto. Devem ser previstos
o prazo e os recursos necessários para a sua realização no cronograma do projeto.
O Teste Unitário é um teste que visa verificar se as funcionalidades configuradas para
um módulo do R/3 estão funcionando, assim como os desenvolvimentos ABAP. São
testados e validados processos específicos do módulo. O teste não tem o objetivo de
verificar a integração entre os módulos. O seu planejamento é feito pela equipe do
módulo SAP, no Solution Manager, onde os cenários de teste são criados. A realização
dos cenários de teste acontece no mandante de Teste Unitário, o DEV 220, e o
registro e acompanhamento do resultado dos testes no Solution Manager. O usuário-
chave é o responsável pela execução e registro do resultado dos testes, o consultor
funcional atua na orientação do usuário-chave e ajustes na parametrização e o
consultor Abap no acerto do programa abap sob teste.
O Teste Integrado acontece no final da fase 3 e início da 4, a de preparação. Este é
o teste para a validação da solução desenvolvida durante a fase 3. O Teste Integrado
mobiliza todas as equipes do projeto na sua execução. O planejamento do teste é
feito por cada equipe, onde são identificados os processos do cliente que envolva a
integração entre os módulos, num conceito de “end to end”, ou seja, testar o
processo, no SAP, de ponta a ponta.
No Teste Integrado, além dos testes da integração entre os módulos SAP, é feito o
teste dos perfis de acesso, teste dos programas de carga de dados e validação dos
Dados Mestres e teste dos desenvolvimentos ABAP. Neste caso, as “Change
Requests” de customização dos módulos SAP e de programas Abap são transportadas
do DEV 100 (mandante Gold) e do DEV 200 (desenvolvimento Abap) para o sistema
QAS. Planilhas de carga ou bancos de dados para carga dos dados mestres são
carregados no sistema QAS utilizando os programas de carga (LSMW). A preparação
adequada do ambiente QAS para o Teste Integrado é fundamental para o sucesso do
teste e mitigação de alguns riscos no Go Live, já que tal preparação é uma prévia da
preparação do ambiente produtivo para entrada em produção do SAP.
Com o ambiente QAS preparado, os usuários-chave dão inicio ao teste dos cenários.
No Teste Integrado, a participação de funcionários das áreas de negócio da empresa
está prevista para testes de cenários específicos, mediante negociação prévia com a
gerência do projeto. São funcionários “donos” do processo que são aptos a validar a
nova solução no SAP.
Normalmente, o espaço físico para o Teste Integrado é separado do ambiente do
projeto. É uma estratégia da gerência do projeto para menos interrupções e foco no
teste. Durante o Teste Integrado, as não conformidades encontradas pelo usuário-
chave durante a realização de um cenário são documentadas no Solution Manager e
tratadas pelo consultor do módulo ou pelo consultor Abap, de acordo com a natureza
do erro. O ajuste é feito o mais breve possível pelo consultor para permitir o
andamento do teste do cenário. Na etapa de conclusão do teste, os registros de não
conformidade que ficaram sem solução ou algum gap de processo identificado são
avaliados pela equipe e direcionados à gerência do projeto. Um plano de ação é
estabelecido para tentar sanar os registros e gaps em aberto.
A realização do Teste Integrado e a validação dos processos testados pelo usuário-
chave ou “dono” do processo são duas condições para a entrada em produção.
Na próxima atualização, estratégias para o Go Live.

Projetos de implantação de ERP da SAP

(conclusão)
BY CONTEÚDO SAP, ON SETEMBRO 10TH, 2011

Estratégias de implantação
Um aspecto interessante após a implantação do ERP da SAP é que os novos usuários
do sistema passam a compartilhar das mesmas dificuldades dos usuários de SAP em
todo o mundo. Um problema na transação FB01, por exemplo, pode ter sido a mesma
dificuldade de um usuário na Índia ou nos Estados Unidos e a solução pode se aplicar
a dificuldade do usuário no Brasil. As transações são as mesmas, independente da
instalação do ERP na empresa. O que muda é o uso. Algumas corporações utilizam
mais transações e outras menos, de acordo com o escopo da implementação do ERP.
A fase 4, preparação final, é a fase para detalhar a estratégia de implantação para a
solução desenvolvida ao longo das fases 2 e 3 do projeto. Nesta fase é detalhado um
plano para a entrada em produção do R/3, o famoso GO LIVE do SAP. O plano,
elaborado e revisado pela gerência do projeto, é chamado de “Cutover”. O “Cutover”
prevê cada atividade a ser executada para o GO LIVE. As atividades de “cutover” são
especificadas pelo consultor do módulo SAP seguindo uma determinada seqüência
para execução. É um período que demanda bastante atenção no detalhamento e
execução das atividades. Uma atividade em especial, a realização das cargas de
dados mestres em ambiente produtivo, exige um seqüenciamento das cargas sem
erros. Em função do seqüenciamento das atividades, em maior parte de forma serial,
um atraso ou paralisação de atividade impede o início de uma atividade subseqüente.
A comunicação do andamento das atividades de “cutover” para o comitê gestor do
projeto passa a ser diária. Algum gargalo identificado é relacionado e discutido na
reunião do comitê gestor e gerência do projeto.
Nesta fase, boa parte do treinamento dos usuários finais deve estar concluída, o
estresse teste do servidor de produção realizado e o ambiente disponível para as
cargas. Os impactos de âmbito organizacional, nas pessoas, de processo e
tecnológico, mapeados no blueprint, foram devidamente tratados e, na fase 4 do
projeto, já não se mantém classificados como impactos na organização. Sobre os
riscos do projeto, estes serão tratados no próximo tópico.
Para um projeto de implantação, as estratégias adotadas para o GO LIVE são duas:
A primeira, conhecida como “Big Bang”, é o desligamento de todos os sistemas
previstos na data de corte e a partir daí o R/3 entra substituindo. Os sistemas
desligados passam para a condição de sistemas legados e são usados para consultas
ocasionais. O plano de “Cutover” prevê uma data de corte dos sistemas com um
intervalo de, no máximo, uma semana entre o corte e a data de entrada em produção
do R/3. Este intervalo é necessário para a migração de saldos de estoques e contas
contábeis para o R/3.
Durante a semana que a organização está “sem sistema”, os apontamentos e
transações são realizados em planilhas Excel, no papel ou algum outro recurso. É
muito importante o trabalho prévio das áreas da organização com os clientes e
fornecedores para que, durante este período, as transações com a organização sejam
minimizadas ao máximo, de preferência, interrompidas. Após a migração dos saldos
para o R/3, os apontamentos e transações são refeitos diretamente no novo sistema
corporativo. Daí em diante, vida nova!

Figura 1 – Estratégias para a implantação de ERP SAP – implantação “Big Bang”

De acordo com a complexidade para o período de corte é previsível e recomendável

a elaboração de um plano específico para o período. Segundo o plano, devido ao
curto espaço de tempo, as atividades executadas não têm um horário definido para
término. O pré-requito é a realização das atividades com êxito para liberação do
ambiente produtivo dentro de uma semana. Caso alguma atividade do plano ficou
pendente ou aconteceu algum erro desconhecido, se não resolvido internamente pela
equipe de projeto, o comitê gestor deliberará sobre a ocorrência. A liberação do
ambiente produtivo ficará a cargo de avaliação em conjunto com a gerência do
projeto. É uma semana de trabalho intenso tanto para os key-users como para os
consultores e pessoas envolvidas direta ou indiretamente no projeto.
A segunda estratégia adotada nos projetos é a implantação “em ondas” de
implantação, conhecida também como implantação “faseada”. Esta estratégia prevê
uma implantação inicial em um país ou empresa, segmento de negócio, planta ou
área da organização e, após a estabilização do R/3, são feitas implantações
sucessivas para os demais países ou empresas, segmentos de negócio, plantas ou
áreas da organização.
A opção pelo uso dessa estratégia está normalmente relacionada com o gigantismo
da organização, como por exemplo, a quantidade de usuários finais a serem treinados
no R/3. Alguns fatores relevantes corroboram também, como diversidade e
complexidade dos segmentos de negócio; questões regionais como a legislação
tributária do país ou leis específicas para o segmento de negócio, nova legislação, ou
até mesmo, mudança na lei durante o projeto.
Na implantação em ondas os sistemas do cliente não são desligados imediatamente,
mas os acessos dos usuários aos sistemas legados são bloqueados e os lançamentos
e transações são feitos no R/3. Há alguns casos de projeto onde ocorreu paralelismo
de sistemas após o GO LIVE. Esta é uma opção para acompanhar o fechamento de
saldos entre os dois sistemas no primeiro mês da implantação.
A opção pela estratégia de implantação em ondas de implantação pode ocorrer no
início do projeto ou no início da fase 3 em função das características do negócio do
cliente. Esta escolha é importante fazê-la o mais breve possível pois a implantação
em ondas pressupõe a extensão do projeto até o último GO LIVE planejado.
Conseqüentemente, as fases 4 e 5 de um projeto com esta estratégia são mais longas
em relação à estratégia “Big Bang”.

Figura 2 – Estratégias para a implantação de ERP SAP – implantação “em ondas”

A estratégia em ondas minimiza os riscos da implantação tipo “Big Bang” para
companhias com negócios diversificados ou geograficamente dispersos.

GO LIVE e suporte
A fase 5, conhecida como “GO LIVE e suporte”, corresponde à entrada em produção
do R/3 e suporte aos usuários finais. Nesta fase, são verificadas as condições para
entrar em produção com o R/3.
Na reunião conhecida como “GO NO GO”, em tradução livre “vai ou não vai”, é
realizado um check list pelo comitê gestor do projeto onde os seguintes pontos são
verificados:

 Conclusão do Teste Integrado;

 Percentual de execução do plano de Cutover;
 Percentual de execução do plano para o período de corte, se houver;
 Avaliação do “Safety Guarding” da SAP e planos de ação para mitigação dos
riscos do projeto;
 Percentual de usuários finais treinados;
 Outros.

De acordo com as respostas ao check list uma avaliação do “GO NO GO” é realizada.
Consiste essencialmente em avaliar se é possível entrar em produção ou não. A
decisão é tomada pelo cliente auxiliado pela consultoria.
Sobre os itens do check list, algumas ponderações sob a óptica do gerente de projeto
da consultoria, vejamos:
É pouco provável entrar em produção com o R/3 sem a conclusão e validação do
Teste Integrado. Em raríssimos casos abre-se a exceção em função de interesses
estratégicos do cliente, por exemplo, cumprir a data de GO LIVE pactuada com o
conselho de acionistas. Desta forma, com o Teste Integrado não concluído, uma
estratégia que a consultoria poderá adotar é renegociar com o cliente o período de
suporte pós GO LIVE e estendê-lo. Esta ação permitiria concluir o Teste Integrado
dentro da fase de suporte. É importante salientar que esta medida é uma exceção e
restritiva para Teste Integrado com processos pendentes de teste cuja validação,
após a entrada em produção, não traz prejuízos para o negócio do cliente.
Sobre o plano de “Cutover” vale atentar para quatro pontos:
O primeiro é garantir, junto à equipe de Basis, que o ambiente produtivo do R/3
possui os requisitos para a entrada em produção. Exemplo, o resultado positivo no
estresse teste. Esta é uma condição “sine qua non” para o GO LIVE. Caso o líder de
Basis sinalizar alguma falta, não há GO LIVE até que o problema seja sanado.
Outro aspecto a observar em Basis é garantir os usuários e perfis de acesso, testados
no Teste Integrado, criados no ambiente produtivo.
O terceiro ponto é assegurar com os líderes de Basis e consultor de cada módulo se
o transporte das “Change Requests” foi com sucesso para o ambiente de produção.
É comum o consultor do módulo SAP entrar no ambiente de produção e conferir se a
parametrização foi transportada para lá. Caso seja identificada a falta de alguma
customização, o consultor solicita o re-transporte da “Change Request” que contem
a parametrização. Há também algumas atividades de customização que são feitas
diretamente no ambiente produtivo, como os intervalos de numeração. Os
consultores de módulo sabem exatamente quais atividades devem ser feitas
diretamente no ambiente produtivo. O gerente de projeto deve assegurar se as
atividades também estão prontas.
O quarto ponto são as cargas de Dados Mestres e saldos de contas contábeis e
estoques. Assegurar com os consultores o status da carga de dados e garantir o prazo
para a sua conclusão até a véspera do GO LIVE.
Em linhas gerais de um plano de “cutover” os pontos acima garantem o sistema
produtivo pronto para a entrada em produção. Outros aspectos são observados pela
gerência do projeto como mobilização dos usuários finais e equipes de apoio, plano
de contingência para eventual indisponibilidade do SAP, continuidade do treinamento
de usuários finais, infra-estrutura e ferramenta de “help desk” para a equipe de
suporte ao usuário pós GO LIVE, etc.
Sobre o “Safety Guarding” da SAP é necessário passar com cada equipe do projeto o
plano de ação para a mitigação dos riscos e constatar a sua conclusão. É igualmente
importante reavaliar os riscos identificados nos documentos de Blueprint da fase 2 e
garantir que os mesmos tenham sido mitigados.
Com a sinalização positiva do comitê gestor do projeto e avaliação dos pontos
comentados acima é possível manter a data do GO LIVE, tanto para uma implantação
com estratégia “Big Bang”, tanto para uma primeira onda de implantação na
estratégia em ondas.