Showing results for 
Search instead for 
Did you mean: 

Global DEV/PRD

Former Member
0 Kudos

We are going to implement a complex SAP system which includes:

One Financial ECC (DEV-> QAS -> PRD)

One Manufacturing ECC (DEV->QAS->PRD)

One Sales ECC (1 DEV -> 1 QAS -> multiple PRDs devided by organizations)

Each ECC runs its own proecesses, which means the configuration is not the same for 3 of them.

My question:

1) In this situration, is it necessary to build a global DEV in front of those 3 DEV systems?

2) For sales ECC, system is planned to be devided by organization. My understanding is that Global Rollout is suitalbe for this situration, am I right? Global Rollout methodology supports 1 common DEV with multiple PRD systems? We do not want to build too much DEVs for Sales.

3) We are going to manage Change Request by using SolMan, is it better to setup one maintance project or 3 individual projects for each of them?

4) What is the best way to transfer CRs from Sales DEV to multiple Sales PRDs? Assume the configuration is the same cross Sales PRDs.

Thanks for your comment in advance.

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

The questions you ask are a consulting project each in themselves. Short answers to your questions are as below:

1) For a global template rollout, the standard recommendation is to have a template d-q-p systems feeding several d-q-p user system landscapes. However, depending on your development and change processes - you can build your landscape as per your suggestion without the global dev system.

2) When you say divided, does it mean multi client, or multi system? How are you planning on handling your end to end testing requirements with a single QA and multiple Prods when the two systems are not identical? System refreshes? TDMS? In this scenario, you can have a single dev - but multiple QAs is your need. My suggestion would be build Dev-QA(Multiple)-Consolidation(Template Consolidation)-Prod(Multiple) OR Dev-UnitTest-QA(Multiple)-Prod(Multiple)

3) Its easiest to setup one maintenance project per transport track i.e in your case per production system - though you can setup everything in a single maintenance project.

4) Implement the distibute transports functionality as defined in note 999944.

For supporting this landscape - make sure that you developers and functional configurators know how to use transports efficiently as well as how to maintain versions of programs across multiple prd systems. And best implement Cross System Object Locks to ensure multiple support requirements do not overlap in the development of a single object.