Nenhum cliente SAP é igual ao outro. Os diferentes tamanhos e complexidades de seus ambientes refletem esse contraste. No entanto, as organizações têm em comum o desejo de gerenciar seus ambientes de forma segura e eficaz. 

A criação de uma paisagem separada, comumente chamada de Paisagem N+1A utilização de um sistema de gerenciamento de projetos SAP, para grandes projetos SAP, requer algumas considerações.

Ao decidir gastar tempo e dinheiro, você precisa pensar sobre isso:

  1. Escopo do projeto - Se a duração planejada do projeto SAP for superior a 2-3 meses e o impacto previsto das alterações de objeto for grande, você deverá fazer isso em um cenário de desenvolvimento/QA separado das alterações de suporte à produção.
  2. Questões de conflitos anteriores - Se, em projetos anteriores, as alterações de suporte à produção tiverem encontrado um grande número de conflitos com as alterações do projeto, resultando em problemas de sobreposição/sobrescrição e hiperatenção, é melhor executar o trabalho subsequente do projeto em um cenário de projeto SAP separado. 
  3. Atualização do SAP - Se o projeto SAP incluir uma mudança de versão do SAP, isso normalmente é realizado em um cenário separado, permitindo que a versão atual seja suportada no cenário de suporte à produção existente.

Então, agora que você decidiu usar uma paisagem separada, o que vem a seguir? 

Há vários desafios quando você tem duas instâncias de desenvolvimento enviando alterações para uma única instância de produção. No entanto, a funcionalidade do Rev-Trac pode ajudá-lo a manter os objetos sincronizados durante o modo de trabalho de cenário duplo, gerar relatórios sobre objetos desenvolvidos em paralelo e controlar o início do desenvolvimento paralelo. 

Gerenciamento de versões de objetos

Como cada sistema de desenvolvimento pode ter diferentes versões do mesmo objeto em voo em diferentes transportes, pode ser fácil migrar as alterações e descobrir que um transporte de desenvolvimento substituiu as alterações do outro cenário.   

Com a funcionalidade de clonagem/retrofit do Rev-Trac, juntamente com o Rev-Trac OOPS (Overtake and Overwrite Protection System), você pode evitar esse desafio antes que ele aconteça! O Rev-Trac já está ciente do sistema de origem da versão ativa atual no sistema de produção.

Antes de migrar um transporte, a verificação de OOPS o alertará de que você está prestes a sobrescrever com uma alteração originada de um sistema de desenvolvimento diferente da versão ativa atual. Se você migrar uma nova versão para o sistema de produção, ela deverá ser atualizada no outro sistema de desenvolvimento, para que ambos os sistemas de desenvolvimento estejam na mesma versão da produção. O Rev-Trac Cloning automatizará esse requisito de sincronização, fornecendo um fluxo de trabalho para sincronizar as alterações do objeto com as alterações existentes no projeto em andamento. 

Relatórios com o cenário de projetos SAP

Relatório de desenvolvimento paralelo em voo da Rev-Trac permite que você visualize e informe à sua comunidade de desenvolvimento quais objetos estão em andamento em ambos os cenários. Isso ajuda os gerentes de projeto a planejar o desenvolvimento de objetos com pouco ou nenhum retrabalho devido às alterações de correção do suporte à produção que ocorrem em conjunto com o trabalho do projeto. 

Desenvolvimento paralelo

Com o recurso de bloqueio estendido do Rev-Trac, você pode permitir que seus gerentes de projeto controlem quando permitir o desenvolvimento paralelo de objetos que encontram uma mensagem de bloqueio do Rev-Trac devido a outras alterações no voo. Isso permitirá que eles entendam e controlem adequadamente o desenvolvimento do objeto do projeto. 

Estar informado e preparado ao iniciar qualquer projeto SAP, sem dúvida, o ajudará a entregar o projeto dentro do prazo e do orçamento, com uma redução significativa dos problemas de hypercare! 

Se você tiver alguma dúvida ou quiser discutir abordagens de mudança/transporte para seu próximo SAP projeto, sinta-se à vontade para Entre em contato conosco.