Managing SAP Separation Projects

a Technical Perspective

Applies to:
SAP ECC 6.0 onwards on a complex NW Landscape with multiple legacy and third party application
systems. As this white paper is about managing separation projects from technical perspective, the versions
generally do not matter. For more information, visit the ABAP homepage.

Summary
Similar to SAP integration projects as a result of acquisition/mergers, separation projects can be complex. In
this presentation, author is attempting to outline the technical approach and managing the expectations from
the client during an SAP separation initiative. This document is outlining, where/how to begin the complex reimplementation of an up and running SAP implementation after copying the entire system landscape into a
newer one.
Author:

Venkat Gururajan

Company: IBM Global Business Services

Created on: 3 July 2010

Author Bio
Venkat Gururajan is an SAP Consultant with specialization in logistics modules, ABAP
development and system integration. He has 14+ years of consulting in SAP/Oracle with 8
years of core manufacturing planning and execution experience.

SAP COMMUNITY NETWORK

2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com

1

Managing SAP Separation Projects a Technical Perspective

Table of Contents
Background and Introduction ......................................................................................................................... 3
Customer Requirement ................................................................................................................................. 3
Understanding the existing systems landscape ............................................................................................. 3
Comparing with the proposed landscape ....................................................................................................... 4
(ETL System proposed to be eliminated moving all the interfaces to ECC/HR to Portals) ............................... 5
Determining the key business processes ....................................................................................................... 5
Can the parent organizations IT Support help? ............................................................................................. 5
Inventory of the Custom programs and enhancements .................................................................................. 6
Data migration from conversions perspective and How SAP can help? .......................................................... 6
What are the common fixes? ......................................................................................................................... 7
Unit and Quality System Testing ................................................................................................................... 7
Integration Cycles and Defect Resolution ...................................................................................................... 7
Performance and Stress Testing ................................................................................................................... 7
Critical deliverables ....................................................................................................................................... 8
Are we done yet? .......................................................................................................................................... 8
Related Content ............................................................................................................................................ 9
Disclaimer and Liability Notice ..................................................................................................................... 10

SAP COMMUNITY NETWORK

2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com

2

Managing SAP Separation Projects a Technical Perspective

Background and Introduction

In the last two decades, Mergers and acquisitions are a common adopted phenomenon in the Industry. While
saving the acquisitioned organization from bankruptcy or declining profits, the primary intent of Mergers and
acquisitions for the parent company is to leverage advantages of new technology or improving profitability
with the new customer base or rapid growth/establishment beyond the geographical borders. The exact
opposite of Mergers is separation or disintegration, this is planned and accomplished to improve the
profitability of a division of the organization and to leverage the existing infrastructure and technology for
prospective customers and buyers.
As Information systems drive the business from annual planning to point of sale, supporting end to end
business process, it is critical to have the established application systems in place, with the same way it was
functioning with the parent organization.
In this white paper, I am attempting to capture the key points of implementing the separation initiative and
how to accomplish seamlessly integrated business process while optimizing the existing business process
without going for a big bang process redefinition and blue printing approach. BPR and re-implementation is
normally planned, after the separated organization starts up and running and becomes profitable as a new
entity.

Customer Requirement
The proposed customer requested an RFP to copy modify test - deploy all of the existing systems as a
new landscape and separate the Design and Manufacturing divisions into two separate entities. While the
Design organization becomes parent, needing no change to the current system, the implementation work
was primarily focused on the Manufacturing division and the operating application systems comprised of
multiple Non SAP systems and a comprehensive Netweaver landscape integrated with custom portals
running on a Java engine. The customer also requested replacement of few of the existing systems that do
not add value in terms of functionality as well expensive from the annual license maintenance costs. It is
important to note that the Manufacturing requires an order processing functionality to complete the supply
chain, which was owned by the Design and marketing division so far and this specific part requires a process
redefinition. This process requires partial blue printing of order management and a mini development project.

Understanding the existing systems landscape

The first step is to understand the clients system landscape and the proposed modifications with respect to
the applications replacement by moving them over to existing applications as added functionality. In this
separation initiative, the client has a comprehensive Netweaver landscape with HR-HCM located in a
separate box considering confidentiality of Human resources information. The plant maintenance system is
on SAP PM Module as a separate application box located in the manufacturing facility. Materials & Inventory
Management, Quality Management, Sales and Distribution and Shipping happened from the central ECC
System. ECC System is tightly integrated with the legacy Manufacturing Execution System for Shop floor
control and executing orders. Minimal HR data is replicated with ECC for supporting functionalities requiring
HR information. Similarly, Custom portals running on a Java Engine is seamlessly integrated with HR
application box and the employees had access to only the Portals, considering security and confidentiality.
Other than the described NW landscape, the client had 19 non SAP systems connected with ECC via a file
server system, that received and send file based information to the external banking and financial systems.
Customer came up with an additional request to replace one of the ETL systems that had around 40
programs running for data transformation, specifically for HR Module.

SAP COMMUNITY NETWORK

2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com

3

Managing SAP Separation Projects a Technical Perspective

Comparing with the proposed landscape

The integration team has a major responsibility to digest the new landscape, as it plays a crucial role in the
implementation. With any application system changes, such as addition or modification of application
systems and/or workflow changes, technical objects change. This would pave way to new development or
modification of existing objects. This is very similar to to-be process definition in traditional SAP
implementation, excepting the fact that most of the technical objects exist, that need changes in terms of
routing and enhancements.
With my client, we had the opportunity to replace one of the major ETL server, that routed about 40
workflows specific to HR-HCM critical for human resources department. A technical team was exclusively
formed to scrutinize the workflows and optimize the development requirement considering the allowed go live
time given to us.

SAP COMMUNITY NETWORK

2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com

4

Managing SAP Separation Projects a Technical Perspective

(ETL System proposed to be eliminated moving all the interfaces to ECC/HR to Portals)

Determining the key business processes

Identifying the required business processes for the new spun off division is the next important step, as these
processes need to be tested and established on the new landscape. All of the Integration testing cycles
depend on these business processes and the scripts required for executing the end to end test cases.
Similar to first time SAP implementation, a Business process team is formed by the customer working closely
with the functional and technical team from consulting. Basis plays a key part in retrieving the log from each
of the application server on frequently executed transactions. The Business users have the list of commonly
used transactions, used on a day to day basis. The SAP and Non SAP technical teams take the inventory of
the custom programs and enhancements on each of the application systems. These 3 ways of collecting
information help consolidate the business processes, without a gap and identifying their applicability in the
new landscape and manufacturing specific business processes.
With the functional and testing teams getting ready with the business process and the required test scripts,
the technical teams work deep delving on the inventory of the custom enhancements and programs. It may
be noted that some of the programs are run once a year and they should be part of the testing and approved
business processes.

Can the parent organizations IT Support help?

Yes, while the separated organization may not have the expert employees who have been using the
functionality for long, it is important to involve the parent organization and seek a team of experts. From
functional and technical perspective, Knowledge transition sessions need to be scheduled and with the help
of a running list of business process, transaction codes, custom programs as well custom enhancements
supporting specific SAP transactions. This is a key step to be completed, in order to have a confident start of
implementation with a detailed level of understanding of the application systems. It is also important to collect
the functional and technical specifications and have them recorded in a common team room accessible by all
of the project team members. During KT sessions, the Business process team from the client side should
also be involved.

SAP COMMUNITY NETWORK

2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com

5

Managing SAP Separation Projects a Technical Perspective

By this, we will have the documentation of all the existing objects that help the client as well the production
support team to cross verify the specification for any functionality maintenance or fix.

Inventory of the Custom programs and enhancements

From SAP Perspective, all of the Z or Y programs can be listed with RPR_ABAP_SOURCE_SCAN program
provided by SAP. In order to see the outbound or inbound file based interfaces, a string with Open Dataset
can be used to see how many such programs are developed and being used. Similarly Batch Data
communication programs can be found. For all the types of RICEF, specific strings can be used to list the
programs and inventory can be collected. Another method to collect the data is using the Standard SAP
tables TRDIR and TADIR. Similarly, for transaction codes, table TSTC can be used to see how many custom
transactions are created. All of the above suggestions are for SAP and for Non SAP integrated application
systems, project team members can determine how many custom programs are created and maintained.
With the SAP RICEF inventory list, the technical team has to work further in classifying the Z or Y programs
as per the clients technical naming conventions. A stand alone testing of these programs will verify, if these
programs execute flawlessly or require some fix. Testing of these programs have to happen on a Integration
or quality system, where the production data is refreshed recently. A comprehensive spread sheet can be
created with the above information such as Program type, unit testing successful or not etc.
Further the technical teams need to work with the business and functional teams to see the program
applicability in the new environment. My client had an SAP landscape thats more than a decade old. Many
of the programs were written for one time execution. Many of the programs did not execute properly short
dumping with valid data, as these programs were identified as never executed and not required.
However, from consulting, we need to have this repository ready, which would assist the fix and testing or
commenting of the code for future use.
It should be noted that it is not advisable to delete any of the unused program or a transaction code. Have
the code commented with a fixed message that this program is identified as unused and requires
enhancement for execution.
After this comprehensive exercise (it took 3 months for a 27 member team to complete 4K custom programs
to be unit tested and categorized), business consent needs to be taken for proceeding further. The functional
and Business teams can identify the code and approve them for deployment. Extended syntax checks for
most of these programs need to be done and any negative results to be recorded in the spread sheet.
Other than the above, ALE Interfaces need to be verified for IDoc data distribution, for distribution in the new
landscape and testing the same during IT cycles.

Data migration from conversions perspective and How SAP can help?
It is quite normal that when a company operates as a single entity from design and manufacturing
perspective in the same country, only one company code is defined. When the design/marketing is located in
one country and manufacturing is located in a different country multiple company codes and controlling areas
are defined for accounting purposes from inter-company perspective. Defining and managing multiple
company codes help SAP AG slice the data. This would help eliminate a conversion process as the data preexists in the system built ground up. Making sure, data is managed based on separate company codes is a
key factor for engaging System Landscape Optimization process performed by SAP.
As it is a separation initiative, Data migration is one of the major process absent from conventional SAP
deployments. SAPs System Landscape Optimization can not only perform integrations between two
companies but also separations. Based on key master data such as company code and controlling area, the
data that is not relevant to the separating division can be deleted by SAPs intelligence programs. The key
parameters for deleting or retaining are verified / validated and confirmed to SAP, before they begin the SLO
process. SLO normally takes a day time or more, depending on the system landscape and the data volume.
After SLO is completed, Functional and Business owners verify the configuration, Master and transaction
data. It is important to verify and validate key information such as organization structure. The org structure
before SLO may not fit the separated organization and some changes may be required. As the HR Systems
normally run on Workflows, a correct definition of organization structure is imperative for business process.

SAP COMMUNITY NETWORK

2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com

6

Managing SAP Separation Projects a Technical Perspective

What are the common fixes?

With the new system landscape, the entire network path needs redefinition based on the logical systems
names. All of the IDoc interfaces have to be re-routed with the new logical system name. RFC connections
need to be verified that are in use. For file based interfaces, any hard coding needs to be verified and logical
file paths to be defined in line with better programming practices. Any report program that does not have a
transaction code needs to be modified.
Going down further a step, for complex interfaces, Code inspector needs be run, and results to be verified for
and nested select statement & multiple loop statements written by inexperienced programmers. Client may
already have a complaint that these programs take longer time to run, from consulting we will have a
response to fix the issue.
The above suggestions are within SAP landscape and when there multiple systems sending and receiving
data from SAP, each application system needs to be validated for connectivity, file path and directory
existence etc.
On the Non SAP side, identified programs need to be executed for testing and integration purposes.
Managing the business partners is the key here. Informing them of the new application servers and the
network access parameters is required in this phase. Testing with dummy interfaces (not valid data) is a
good idea to observe the data flow.

Unit and Quality System Testing

To prepare for the Integration cycles, all of the identified technical objects and configuration are to be tested
and ready on the development system (and quality system). With the identified programs by the business
teams, functional teams should be working with the technical teams to verify the results, before transports
are sent across the landscape.
Before the Integration cycle is begun, SAP performs the SLO and deletes the unneeded data. Sending
custom transports before or after is a strategic decision that depends on the type and number of transports to
be sent. In my experience, we had sent the transports after SLO was completed and did not foresee any
technical problems.

Integration Cycles and Defect Resolution

As the integration cycle begins, the defect management begins as well. Many unforeseen issues surface and
those are fixed by specific team depending on the type of defect Data or Configuration or Program issue or
Basis issue. These are captured in lessons learnt. With the third Integration cycle testing, most of the defects
are fixed and mock cutover clearance is requested from the customer show casing all of the testing
processes, number of defects or any special requirements. With the clearance of Mock cutover, Move to
production clearance is requested from the client.
During production cutover, depending on the number of days, delta data load may be necessary. In my
project experience, the number of Master / Transaction data created was handful and we did not have to run
any conversion program, as the cutover window was very small (< 3 days).

Performance and Stress Testing

Normally three rounds of Integration and SIT Testing is planned for any SAP initiative. As we approach the
last two cycles of SIT Testing, Performance and stress testing needs to be planned. This starts with the
Basis team sizing the systems and optimizing the landscape for best performance.
From data and workflow perspective it is the responsibility of functional and technical teams to simulate the
environment of real time (production), to observe any enhancements/changes need to be made to the new
environment being tested. Prerequisite to this process is the established landscape with all or most of the
important business processes in place. Another important input is the volume of data being transacted on a
daily basis and the number of batch/real time jobs run. This is preferably managed by a team of experts in
stress testing with the support of SIT/Integration teams.

SAP COMMUNITY NETWORK

2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com

7

Managing SAP Separation Projects a Technical Perspective

Critical deliverables
As the SI team completes the various testing cycles, documentation needs to be generated specific to the
functional and technical areas. All the functional specifications, Technical specifications, Unit testing results,
an indexed document of list of technical objects with proper document naming conventions need to be
generated or modified that was received as a result of knowledge transition from the production support
team. Other than these final deliverables, there would also be SIT/Integration related documents generated
during testing cycles stored on the share point.

Are we done yet?

As I had mentioned earlier, the Order processing functionality and shipping processes may change, specific
to the type of manufacturing industry. There are two options, to manage these enhanced functionalities at the
time of separation or to manage them as a separate release. Sales order processing and shipping needs to
be validated and any additional enhancements that may need to be done and at the same time, there could
be some enhancements that may have to stripped (applicable to the parent organization). It is a PMO level
decision and the need to implement the separation solution based on some time lines, to report financials to
the government. Either way, Sales and Distribution as well Shipping and transport modules need be
thoroughly relooked and changes, if any to be implemented and tested. Also the implementation might lead
way to further enhancement projects such as Supply Chain Management, Customer Relationship
Management etc, as business opportunity to the System Implementers.

SAP COMMUNITY NETWORK

2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com

8

Managing SAP Separation Projects a Technical Perspective

Related Content
For more information, visit the ABAP homepage.

SAP COMMUNITY NETWORK

2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com

9

Managing SAP Separation Projects a Technical Perspective

Disclaimer and Liability Notice

This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not
supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade.
SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document,
and anyone using these methods does so at his/her own risk.
SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or
code sample, including any liability resulting from incompatibility between the content within this document and the materials and
services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this
document.

SAP COMMUNITY NETWORK

2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com

10