Download - Managing SAP Separation Projects – a Technical Perspective · Managing SAP Separation Projects – a Technical Perspective ... visit the ABAP homepage. ... This is a key step to

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

© 2010 SAP AG 1

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 re-implementation 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.

https://www.sdn.sap.com/irj/sdn/abap

Managing SAP Separation Projects – a Technical Perspective


© 2010 SAP AG 2

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 organization’s 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



© 2010 SAP AG 3

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 client’s 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.



© 2010 SAP AG 4

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.



© 2010 SAP AG 5

(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 organization’s 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.



© 2010 SAP AG 6

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 client’s 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 that’s 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 pre-exists 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. SAP’s 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 SAP’s 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.



© 2010 SAP AG 7

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.



© 2010 SAP AG 8

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.



© 2010 SAP AG 10

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.

Download - Managing SAP Separation Projects – a Technical Perspective · Managing SAP Separation Projects – a Technical Perspective ... visit the ABAP homepage. ... This is a key step to

Top Related