Older Entries

LEAVE A COMMENT

DIC AS FI, DICAS SAP

SAP FI

Projetos de implantao de ERP da SAP

(concluso)
BY CONTEDO SAP, ON SETEMBRO 10TH, 2011

Estratgias de implantao
Um aspecto interessante aps a implantao do ERP da SAP que os novos
usurios do sistema passam a compartilhar das mesmas dificuldades dos usurios
de SAP em todo o mundo. Um problema na transao FB01, por exemplo, pode
ter sido a mesma dificuldade de um usurio na ndia ou nos Estados Unidos e a
soluo pode se aplicar a dificuldade do usurio no Brasil. As transaes so as
mesmas, independente da instalao do ERP na empresa. O que muda o uso.
Algumas corporaes utilizam mais transaes e outras menos, de acordo com o
escopo da implementao do ERP.
A fase 4, preparao final, a fase para detalhar a estratgia de implantao para
a soluo desenvolvida ao longo das fases 2 e 3 do projeto. Nesta fase
detalhado um plano para a entrada em produo do R/3, o famoso GO LIVE do
SAP. O plano, elaborado e revisado pela gerncia do projeto, chamado de
Cutover. O Cutover prev cada atividade a ser executada para o GO LIVE. As
atividades de cutover so especificadas pelo consultor do mdulo SAP seguindo
uma determinada seqncia para execuo. um perodo que demanda bastante
ateno no detalhamento e execuo das atividades. Uma atividade em especial,
a realizao das cargas de dados mestres em ambiente produtivo, exige um
seqenciamento das cargas sem erros. Em funo do seqenciamento das
atividades, em maior parte de forma serial, um atraso ou paralisao de atividade
impede o incio de uma atividade subseqente.
A comunicao do andamento das atividades de cutover para o comit gestor do
projeto passa a ser diria. Algum gargalo identificado relacionado e discutido na
reunio do comit gestor e gerncia do projeto.
Nesta fase, boa parte do treinamento dos usurios finais deve estar concluda, o
estresse teste do servidor de produo realizado e o ambiente disponvel para as
cargas. Os impactos de mbito organizacional, nas pessoas, de processo e
tecnolgico, mapeados no blueprint, foram devidamente tratados e, na fase 4 do
projeto, j no se mantm classificados como impactos na organizao. Sobre os
riscos do projeto, estes sero tratados no prximo tpico.
Para um projeto de implantao, as estratgias adotadas para o GO LIVE so
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 condio de sistemas legados e so usados para
consultas ocasionais. O plano de Cutover prev uma data de corte dos sistemas
com um intervalo de, no mximo, uma semana entre o corte e a data de entrada
em produo do R/3. Este intervalo necessrio para a migrao de saldos de
estoques e contas contbeis para o R/3.
Durante a semana que a organizao est sem sistema, os apontamentos e

transaes so realizados em planilhas Excel, no papel ou algum outro recurso.

muito importante o trabalho prvio das reas da organizao com os clientes e
fornecedores para que, durante este perodo, as transaes com a organizao
sejam minimizadas ao mximo, de preferncia, interrompidas. Aps a migrao
dos saldos para o R/3, os apontamentos e transaes so refeitos diretamente no
novo sistema corporativo. Da em diante, vida nova!
Figura 1 Estratgias para a implantao de ERP SAP implantao Big Bang

De acordo com a complexidade para o perodo de corte previsvel e

recomendvel a elaborao de um plano especfico para o perodo. Segundo o
plano, devido ao curto espao de tempo, as atividades executadas no tm um
horrio definido para trmino. O pr-requito a realizao das atividades com
xito para liberao do ambiente produtivo dentro de uma semana. Caso alguma
atividade do plano ficou pendente ou aconteceu algum erro desconhecido, se no
resolvido internamente pela equipe de projeto, o comit gestor deliberar sobre a
ocorrncia. A liberao do ambiente produtivo ficar a cargo de avaliao em
conjunto com a gerncia 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 estratgia adotada nos projetos a implantao em ondas de
implantao, conhecida tambm como implantao faseada. Esta estratgia
prev uma implantao inicial em um pas ou empresa, segmento de negcio,
planta ou rea da organizao e, aps a estabilizao do R/3, so feitas
implantaes sucessivas para os demais pases ou empresas, segmentos de
negcio, plantas ou reas da organizao.
A opo pelo uso dessa estratgia est normalmente relacionada com o
gigantismo da organizao, como por exemplo, a quantidade de usurios finais a
serem treinados no R/3. Alguns fatores relevantes corroboram tambm, como
diversidade e complexidade dos segmentos de negcio; questes regionais como

a legislao tributria do pas ou leis especficas para o segmento de negcio,

nova legislao, ou at mesmo, mudana na lei durante o projeto.
Na implantao em ondas os sistemas do cliente no so desligados
imediatamente, mas os acessos dos usurios aos sistemas legados so
bloqueados e os lanamentos e transaes so feitos no R/3. H alguns casos de
projeto onde ocorreu paralelismo de sistemas aps o GO LIVE. Esta uma opo
para acompanhar o fechamento de saldos entre os dois sistemas no primeiro ms
da implantao.
A opo pela estratgia de implantao em ondas de implantao pode ocorrer no
incio do projeto ou no incio da fase 3 em funo das caractersticas do negcio
do cliente. Esta escolha importante faz-la o mais breve possvel pois a
implantao em ondas pressupe a extenso do projeto at o ltimo GO LIVE
planejado. Conseqentemente, as fases 4 e 5 de um projeto com esta estratgia
so mais longas em relao estratgia Big Bang.
Figura 2 Estratgias para a implantao de ERP SAP implantao em ondas

A estratgia em ondas minimiza os riscos da implantao tipo Big Bang para

companhias com negcios diversificados ou geograficamente dispersos.

GO LIVE e suporte
A fase 5, conhecida como GO LIVE e suporte, corresponde entrada em
produo do R/3 e suporte aos usurios finais. Nesta fase, so verificadas as
condies para entrar em produo com o R/3.
Na reunio conhecida como GO NO GO, em traduo livre vai ou no vai,

realizado um check list pelo comit gestor do projeto onde os seguintes pontos
so verificados:
Concluso do Teste Integrado;
Percentual de execuo do plano de Cutover;
Percentual de execuo do plano para o perodo de corte, se houver;
Avaliao do Safety Guarding da SAP e planos de ao para mitigao
dos riscos do projeto;
Percentual de usurios finais treinados;
Outros.
De acordo com as respostas ao check list uma avaliao do GO NO GO
realizada. Consiste essencialmente em avaliar se possvel entrar em produo
ou no. A deciso tomada pelo cliente auxiliado pela consultoria.
Sobre os itens do check list, algumas ponderaes sob a ptica do gerente de
projeto da consultoria, vejamos:
pouco provvel entrar em produo com o R/3 sem a concluso e validao do
Teste Integrado. Em rarssimos casos abre-se a exceo em funo de interesses
estratgicos do cliente, por exemplo, cumprir a data de GO LIVE pactuada com o
conselho de acionistas. Desta forma, com o Teste Integrado no concludo, uma
estratgia que a consultoria poder adotar renegociar com o cliente o perodo
de suporte ps GO LIVE e estend-lo. Esta ao permitiria concluir o Teste
Integrado dentro da fase de suporte. importante salientar que esta medida
uma exceo e restritiva para Teste Integrado com processos pendentes de teste
cuja validao, aps a entrada em produo, no traz prejuzos para o negcio 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 produo. Exemplo, o resultado positivo
no estresse teste. Esta uma condio sine qua non para o GO LIVE. Caso o
lder de Basis sinalizar alguma falta, no h GO LIVE at que o problema seja
sanado.
Outro aspecto a observar em Basis garantir os usurios e perfis de acesso,
testados no Teste Integrado, criados no ambiente produtivo.
O terceiro ponto assegurar com os lderes de Basis e consultor de cada mdulo
se o transporte das Change Requests foi com sucesso para o ambiente de
produo. comum o consultor do mdulo SAP entrar no ambiente de produo e
conferir se a parametrizao foi transportada para l. Caso seja identificada a
falta de alguma customizao, o consultor solicita o re-transporte da Change
Request que contem a parametrizao. H tambm algumas atividades de
customizao que so feitas diretamente no ambiente produtivo, como os
intervalos de numerao. Os consultores de mdulo sabem exatamente quais
atividades devem ser feitas diretamente no ambiente produtivo. O gerente de
projeto deve assegurar se as atividades tambm esto prontas.
O quarto ponto so as cargas de Dados Mestres e saldos de contas contbeis e
estoques. Assegurar com os consultores o status da carga de dados e garantir o
prazo para a sua concluso at a vspera do GO LIVE.
Em linhas gerais de um plano de cutover os pontos acima garantem o sistema
produtivo pronto para a entrada em produo. Outros aspectos so observados
pela gerncia do projeto como mobilizao dos usurios finais e equipes de apoio,
plano de contingncia para eventual indisponibilidade do SAP, continuidade do

treinamento de usurios finais, infra-estrutura e ferramenta de help desk para a

equipe de suporte ao usurio ps GO LIVE, etc.
Sobre o Safety Guarding da SAP necessrio passar com cada equipe do
projeto o plano de ao para a mitigao dos riscos e constatar a sua concluso.
igualmente importante reavaliar os riscos identificados nos documentos de
Blueprint da fase 2 e garantir que os mesmos tenham sido mitigados.
Com a sinalizao positiva do comit gestor do projeto e avaliao dos pontos
comentados acima possvel manter a data do GO LIVE, tanto para uma
implantao com estratgia Big Bang, tanto para uma primeira onda de
implantao na estratgia em ondas.
Informao til e relevante? Doaes

4 COMMENTS

PROJETOS , SAP

PROJETOS

Projetos de implantao de ERP da SAP

(continuao II)
BY CONTEDO SAP, ON JULHO 30TH, 2011

Testes e validao da soluo

Na fase 3, planejar o teste da soluo pressupe que algumas atividades da fase
estejam prontas ou em estgio avanado de concluso. De acordo com o tipo de
teste so necessrios alguns deliveries. Por exemplo, para o Teste Unitrio, a
parametrizao dos processos do mdulo e os desenvolvimentos abap
imprescindveis devem estar finalizados para o teste.
Ao contrrio do entendimento atual de boa parte dos profissionais de SAP, o Teste
Unitrio no compreende o teste feito pelo consultor enquanto ele parametriza o
mdulo. O teste uma etapa importante da fase 3 do projeto. Devem ser
previstos o prazo e os recursos necessrios para a sua realizao no cronograma
do projeto. O Teste Unitrio um teste que visa verificar se as funcionalidades
configuradas para um mdulo do R/3 esto funcionando, assim como os
desenvolvimentos ABAP. So testados e validados processos especficos do
mdulo. O teste no tem o objetivo de verificar a integrao entre os mdulos. O
seu planejamento feito pela equipe do mdulo SAP, no Solution Manager, onde
os cenrios de teste so criados. A realizao dos cenrios de teste acontece no
mandante de Teste Unitrio, o DEV 220, e o registro e acompanhamento do
resultado dos testes no Solution Manager. O usurio-chave o responsvel pela
execuo e registro do resultado dos testes, o consultor funcional atua na
orientao do usurio-chave e ajustes na parametrizao e o consultor Abap no
acerto do programa abap sob teste.
O Teste Integrado acontece no final da fase 3 e incio da 4, a de preparao. Este
o teste para a validao da soluo desenvolvida durante a fase 3. O Teste
Integrado mobiliza todas as equipes do projeto na sua execuo. O planejamento
do teste feito por cada equipe, onde so identificados os processos do cliente
que envolva a integrao entre os mdulos, num conceito de end to end, ou

seja, testar o processo, no SAP, de ponta a ponta.

No Teste Integrado, alm dos testes da integrao entre os mdulos SAP, feito
o teste dos perfis de acesso, teste dos programas de carga de dados e validao
dos Dados Mestres e teste dos desenvolvimentos ABAP. Neste caso, as Change
Requests de customizao dos mdulos SAP e de programas Abap so
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 so carregados no sistema QAS utilizando os programas de carga
(LSMW). A preparao adequada do ambiente QAS para o Teste Integrado
fundamental para o sucesso do teste e mitigao de alguns riscos no Go Live, j
que tal preparao uma prvia da preparao do ambiente produtivo para
entrada em produo do SAP.
Com o ambiente QAS preparado, os usurios-chave do inicio ao teste dos
cenrios. No Teste Integrado, a participao de funcionrios das reas de negcio
da empresa est prevista para testes de cenrios especficos, mediante
negociao prvia com a gerncia do projeto. So funcionrios donos do
processo que so aptos a validar a nova soluo no SAP.
Normalmente, o espao fsico para o Teste Integrado separado do ambiente do
projeto. uma estratgia da gerncia do projeto para menos interrupes e foco
no teste. Durante o Teste Integrado, as no conformidades encontradas pelo
usurio-chave durante a realizao de um cenrio so documentadas no Solution
Manager e tratadas pelo consultor do mdulo ou pelo consultor Abap, de acordo
com a natureza do erro. O ajuste feito o mais breve possvel pelo consultor para
permitir o andamento do teste do cenrio. Na etapa de concluso do teste, os
registros de no conformidade que ficaram sem soluo ou algum gap de
processo identificado so avaliados pela equipe e direcionados gerncia do
projeto. Um plano de ao estabelecido para tentar sanar os registros e gaps
em aberto.
A realizao do Teste Integrado e a validao dos processos testados pelo
usurio-chave ou dono do processo so duas condies para a entrada em
produo.
Na prxima atualizao, estratgias para o Go Live.
Informao til e relevante? Doaes

LEAVE A COMMENT

PROJETOS , SAP

PROJETOS

Projetos de implantao de ERP da SAP

(continuao I)
BY CONTEDO 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 misso desta equipe criar os acessos e
manter os sistemas e mandantes do R/3 disponveis para o projeto.
Posteriormente, prepara e libera o ambiente de produo para receber as change
requests do projeto, usurios e perfis de acesso. A equipe Basis a primeira
equipe de consultores a chegar no cliente para uma implantao SAP. Uma equipe
Basis composta por consultores e o consultor lder de equipe, o lder 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 preparao, 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 implantao:
Figura 1 Landscape dos sistemas DEV e QAS em projetos de implantao SAP
R/3

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

mnimo, quatro mandantes: o mandante 000 (3 zeros) usado como referncia
para restaurao de outros mandantes e disponibilizado pela SAP na aquisio do
R/3; o mandante 100, cpia do 000, mandante conhecido como Gold usado para
a customizao do R/3; o mandante 200 disponibilizado para desenvolvimento e
testes dos programas ABAP; o mandante 220 disponibilizado para testes da

customizao e realizao do teste unitrio. O mandante 210, conhecido como

Sandbox, um mandante desejvel e muito til nos projetos. A customizao
aberta (SPRO) e permite realizar testes da customizao do mdulo pelos
consultores, teste de programas de carga de dados mestres (LSMW) e
treinamento do analista funcional ou usurio-chave do cliente.
A transao SCC1 faz o transporte de customizaes do mandante de origem, no
caso o 100, para o mandante no qual se deseja trazer as customizaes, 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 lgica ou, at
mesmo, fisicamente, em outro servidor. Como ento 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 transferncia da customizao realizada em DEV para o QAS de acordo com a
liberao de Change Requests. Uma Change Request um pacote criado no
mandante DEV 100 (Gold) quando o consultor realiza uma customizao. O
pacote contem a customizao realizada pelo consultor. Este pacote estar
habilitado ao transporte para o QAS a partir da sua liberao. Se a Change
Request no foi liberada, o seu contedo no ser transportado para outro
sistema sendo possvel 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 unitrio).
Existem dois tipos de pacotes ou Change Requests no sistema de transporte
do R/3: A Change Request Customizing usada para guardar a parametrizao
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 automtica, a partir da liberao de
uma Change Request no DEV 100 ou DEV 200 ou de forma manual, utilizando a
transao STMS Transport Management System. Nos dois tipos de transporte, a
Change Request tem que estar liberada. A forma automtica, com intervalos de
5 em 5 minutos, a mais comum nos projetos.
Uma vez que a customizao do projeto e desenvolvimentos Abap foram
transportados para o sistema de qualidade (QAS), o sistema est apto para os
testes de validao da soluo do projeto, conhecido como Teste Integrado. Alm
da customizao e desenvolvimentos abap, o ambiente de qualidade recebe uma
carga dos dados mestres para o Teste Integrado e possui tambm os perfis de
acesso j estabelecidos para os futuros usurios do R/3. Com a concluso do
Teste Integrado, que retornaremos mais a frente para discorrer sobre a
importncia 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 implantao SAP
R/3

Landscape SAP R/3 (QAS e PRD)

O transporte das Change Requests para o sistema de produo (PRD)

realizado e monitorado pela equipe Basis durante a fase de preparao, a fase 4
na metodologia ASAP. No sistema de transporte do R/3 possvel o transporte
automtico a partir da liberao da Change Request no DEV 100 para o QAS e
PRD. Mas esta opo no habilitada em um projeto de implantao.
O sistema de produo (PRD) possui tambm mandante nico, batizado
usualmente de 400 ou 500 e o ambiente onde a corporao passar a trabalhar
aps a entrada em produo do SAP R/3. O sistema PRD, assim como ocorre
entre os sistemas DEV e QAS, separado lgica 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 servio de hosting e manuteno
do ambiente. Estar de acordo com o desenho de arquitetura preconizado e
definido pela equipe Basis e gerncia de TI do cliente.
A equipe de Basis , portanto, a equipe que manter os sistemas DEV, QAS e
PRD, com os respectivos mandantes, disponveis 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 realizao (fase 3).
Na prxima atualizao, testes unitrio e integrado e validao da soluo.
Informao til e relevante? Doaes

ASAP Roadmap
BY CONTEUDOSAP, ON SETEMBRO 15TH, 2010

Sempre bom ter o ASAP Roadmap disponvel. Ajuda a relembrar algumas coisas
A metodologia objetiva conduzir o projeto atravs de cinco fases de forma a
garantir a entrega do sistema SAP em ambiente produtivo, de acordo com o escopo
e prazo contratados e com qualidade assegurada.
As 5 fases da metodologia so apresentadas no Roadmap do projeto conforme
figura.
Figura 1 ASAP Roadmap

A definio de cada fase da metodologia foi retirada do documento ASAP

Roadmap disponvel no site da SAP
http://help.sap.com/saphelp_47x200/helpdata/en/48/623972d55a11d2bbf700105a
5e5b3c/content.htm
As definies esto em ingls de acordo com o site para manter o entendimento e
no conter vcios de traduo:
1.
Project
Preparation
In this phase you plan your project and lay the foundations for successful
implementation. It is at this stage that you make the strategic decisions crucial to
your project:
o
o
o
o

Define your project goals and objectives

Clarify the scope of your implementation
Define your project schedule, budget plan, and implementation
sequence
Establish the project organization and relevant committees and
assign resources

2. Business Blueprint
In this phase you create a blueprint using the Question & Answer database
(Q&Adb), which documents your enterprises requirements and establishes how
your business processes and organizational structure are to be represented in the
SAP System. You also refine the original project goals and objectives and revise the
overall project schedule in this phase.
3.
Realization
In this phase, you configure the requirements contained in the Business Blueprint.
Baseline configuration (major scope) is followed by final configuration (remaining
scope), which can consist of up to four cycles. Other key focal areas of this phase
are conducting integration tests and drawing up end user documentation.
4.
Final
Preparation
In this phase you complete your preparations, including testing, end user training,
system management, and cutover activities. You also need to resolve all open
issues in this phase. At this stage you need to ensure that all the prerequisites for
your system to go live have been fulfilled.
5.
Go
Live
&
Support
In this phase you move from a pre-production environment to the live system. The
most important elements include setting up production support, monitoring system
transactions, and optimizing overall system performance.