Older Entries

LEAVE A COMMENT DICAS 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 RoadmapBY 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/623972d55a11d2bbf700105a5e5b3c/content.htm

As definies esto em ingls de acordo com o site para manter o entendimento e no conter vcios de traduo:

1. Project PreparationIn 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 Define your project goals and objectives o Clarify the scope of your implementation o Define your project schedule, budget plan, and implementation

sequence o 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. RealizationIn 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 PreparationIn 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 & SupportIn 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.