Activities involved in demergers project

[cjogesh]

Hi Experts,

I am going to work for a demerger project, where in one of the business is being separated by the Parent organisation.

A new instance of SAP (different servers for DB) will be created for the demerged product line.

Want your 2 cents on :

a) Which would be an efficient and easy way to achieve this
- By mirroring the production server and archiving the non relevant product related data from all modules ?
- Copying the existing customizing and configuration into a different system/instance, and doing all the cutover activities and data migration activities.

SAP ECC 6.0 is the present system configuration.

Your valuable inputs are highly appreciated.

Thanks

[thx4allthefish]

I have been doing a carve-out (or demerger) last year.

In our case it was a copy from one landscape A (DEV, QAS; PRD) to a landscape B whilst skipping QAS (which was mirrored from P' after the copy). We then archived. We have now upgraded.

I would not recommend this way in general. Personally, I doubt I would ever agree to go that way again.

Why?

• The whole archiving activity took more time, effort and money than a migration of data for the to-be-carved-out-company-code would ever have taken.
• The copy from P to P' provided us nicely with all modifications done to the original which had to be dealt with during the upgrade. This cost time and money.
• The copy provided us all the un-necessary cloned transactions and programs (and roles etc.) that are not needed for business-processes of the carved-out company. Time and money again.
• ...

What should influence your decision?

• If the company-to-be-carved-out is small in data-volume, the P --> P' copy procedure should be out of the question, see my reasons above.
• If you have complex inter-company processes (IDOCs etc) and lots of interfaces with sub-systems and such: again, the P --> P' copy procedure is no good idea. Start from scratch will save you a lot of time searching furiosly in 'old '#!?=)§'.
• If an upgrade (fixes, patches etc etc) is planned in the near future on P' : get rid of the modifications, adjustments and various other problems: do not copy
• ...

Maybe others have additional ideas?

[cjogesh]

Thanks Fish, for your excellent inputs.

What should influence your decision?

You mentioned :

If the company-to-be-carved-out is small in data-volume, the P --> P' copy procedure should be out of the question, see my reasons above.
If you have complex inter-company processes (IDOCs etc) and lots of interfaces with sub-systems and such: again, the P --> P' copy procedure is no good idea. Start from scratch will save you a lot of time searching furiosly in 'old '#!?=)§'. Why do you think this should be start from scratch in this case. Rather to upload all the historical data for idocs and all business objects, the work load would be very huge..
If an upgrade (fixes, patches etc etc) is planned in the near future on P' : get rid of the modifications, adjustments and various other problems: do not copy. The system is already in ECC6.0, so this can be considered to be not applicable to my scenario....

Can you please share with me the issues used face during Mirroring and archiving all the security components, business process related transactoin and master data. The advantage that I think in this process would be :

a) No last minute cut over requirements.
b) The archiving process can go on with the system up in service (new landscape)
c) The security team can inactive the roles related to other business or can create new roles as required.

Question :

Do the number ranges transfer while mirroring/cloning SAP systems ?

Thanks for responding.

[thx4allthefish]

Why do you think this should be start from scratch in this case. Rather to upload all the historical data for idocs and all business objects, the work load would be very huge..

If you copy, you have all the setups, exits, extended or reduced IDOCs, connections, port-numbers etc. from the old system. You would have to adjust them all. Believe me - adjusting can be a lot more time-consuming than setting out anew (think on the lines of finding errors). Setting up ALE/IDOCs from scratch is not a subject that will take extreme time - debugging old setups and finding errors, OTOH, might be.

The system is already in ECC6.0, so this can be considered to be not applicable to my scenario.[/i]...

It is applicable. You will at some point in time implement support-packages and/or extension sets. There's your SPAU for you again and all the copied crap will pop up.

Can you please share with me the issues used face during Mirroring and archiving all the security components, business process related transactoin and master data. The advantage that I think in this process would be :

a) No last minute cut over requirements.
b) The archiving process can go on with the system up in service (new landscape)
c) The security team can inactive the roles related to other business or can create new roles as required.

Question :
Do the number ranges transfer while mirroring/cloning SAP systems ?

May I ask if you have led an archiving project before? You sound -no offense intended- academical ... I think you might face quite a couple of difficulties/challenges when you start - let me try to give you some (and they are only that: some) things to think about:

• To a) define 'last minute ...' - since you start the archiving project on P', it is a project. As projects go, there are always last minute requirements. Maybe I didn't understand the question correctly ... please clarify.
  
• To b) You are being over-optimistic here. Depending on the archiving object, the data volume, the performance of the system and the hardware capacity you will experience that some of the archiving cannot be done during operation times, since your users would suffer greatly. Depending on the modifications you have copied to your P' you will experience that some objects cannot be archived at all - usually this is somewhere around SD-documents: I have yet to find the customer who managed to leave his hands off SAPMV45A ...
  
• To c) As long as you have not finished the archiving project sucessfully, you cannot deactivate or delete the roles, since you will need them to correct documents (you will need users to do that, as well), make postings in order to make some documents archivable etc. etc.

Number ranges are tables on the database. Copy the database ... of course they will be thesame!

[cjogesh]

Thanks for clarifying and your valuable inputs on all the points metioned in my previous post.

Yes, you are right, this is my first time to lead such a cloning project for demerged entity. As far as archiving is concerned, I have not directly worked on it till date. However, have witnessed objects getting archived on regular basis on the P system. The job runs are planned on weekends.

I am a bit worried on the option of setting up a new system without copying, as it is possible to miss out on the customized objects due to lack of present system understanding.

To summarize :

A) configure all the modules for that particular business as per the old system (manually)
B) Copy and setup customized objects. Screen and test them for the functinoality.
C) Do integration tests for all the busienss processes.
D) Setup IDOCs and interfaces.
E) Do data migration
F) Do cut over and go live

I hope this is the flow of the process proposed by you. Please advice and update wherever necessary.

Thanks.

[thx4allthefish]

A) configure all the modules for that particular business as per the old system (manually)
B) Copy and setup customized objects. Screen and test them for the functinoality.
C) Do integration tests for all the busienss processes.
D) Setup IDOCs and interfaces.
E) Do data migration
F) Do cut over and go live

yes to all. As for C) - you would have to do that anyway - no matter the scenario.

Good luck with your project and don't hesitate to come back, if you have further questions.