SLO Service Client Merge

SLO ServiceClient Merge Speaker NameSAP Deutschland

Content • System Landscape Optimization (SLO) • Client Merge • Conversion approach (Conversion Workbench • Migration approach (Migration Workbench) • Data transfer • Further Information

Experience from numerous projects + Successful team of consultants and developers • Standardized services: The SLO service offering SLO Consulting SLO Development SAP SLO • The SAP SLO team consists of experts for SLO issues from all areas of SAP development and consulting • SLO has its own development group • and a specialized SLO consulting team SAP System Landscape Optimization

Pre-defined services for typical business scenarios Service description Standardized approach Project plans, document templates Full service (from planning to implementation) Long-standing project experience Extensive knowledge base Configurable, extendable services for new requirements SLO-specific tools Analysis tools Conversion Workbench (CWB) Migration Workbench (MWB) Use of SAP standard methods and tools LSMW*, Batch Input, BAPI System Landscape Change Consulting Organizational Structure Change Consulting SAP Conversion Services / Data Harmonization Cons. TechnicalServices Curren- cies ArchivingServices SLO – Service portfolio * LSMW – Legacy System Migration Workbench

SLO is an SAP expert group • Direct know-how transfer from and to other SAP teams / departments • First-hand SAP knowledge Consulting Development Service & Support SLO Back Office ensures quality and efficiency SLO project at customer Project-specific requirements and results Customer and partner SLO experts SLO Back Office SLO support (services, tools)SLO expert knowledgeExperience

SLO‘s pre-defined, structured approach • Service Delivery • System/ client merge by SLO specialists • Standardized phased approach • Transparent definition of objectives and results • Project support by SLO Back-office • Provision of programs for making the required changes, • Support during the complete project runtime (normal working hours) and • 7*24 h support during conversion of the production system

SLO facilitates implementation and operation of mySAP Business Suite • Harmonization of structures and processes • More transparency, fewer redundancies • Unified master data, e. g. customers, vendors, materials • Unified controlling structures • Unified chart of accounts • Improved communication and integration • More efficient information exchange through unified structures • Facilitate cross-system processes • Master Data Management (MDM) • Cross-system planning • Central purchasing • Central / cross-system reporting • Company reorganization • Merger or divestiture of companies or parts of companies • System creation • Initial load, e. g. for MDM server mySAP PLM Maintenance and QM mySAP ERP Financials Human Resources Corporate Services Operations Sales order processing and distribution mySAP SRM mySAP CRM Purchasing managem. Inventory managem./manufacturing mySAP SCM SAP NetWeaver

SLO project procedure Analysis Implementation Recommendation SLO Project management Project management Project management Efficient tool-based analysis of as-is situation Identification and quantification of optimization potential • Implementation by SLO experts • Application of SLO Services • Proven methods • Conversion • Migration • Generic environment for development • CWB, MWB SLO knowledge and experience  Check several possible solutions Recommend the best solution for the given project Reliable estimate of required work Co-operationwith otherSAP teamsif required Technical Consulting PerformanceConsulting 7x24Operations ArchivingDB-Migration ... BusinessConsulting

Overview of SLO’s technical methods Conversion (using Conversion Workbench) Change existing structures within one client / system Availability of data and document flow for all completed and open transactions in target structure Migration (using Migration Workbench) Transfer business objects across systems / clients Add to / change existing structures in target system Availability of data and document flow for all completed and open transactions in target structure in target system Data transfer (using Legacy System Migration Workbench (LSMW)) SAP standard tool for legacy data transfer Can be used for reorganization purposes Implement required structures Copy master data Transfer selected data (e. g. balances, open items) Detailed comparison of the methods

System consolidation – general overview

Typical reasons for a client merge • Reduce size of system landscape and simplify it • Make maintenance and administration easier • Reduce costs • Re-centralize • Prepare for e-commerce • Merge companies that currently have their own separate R/3 systems • Harmonize structures and business processes •  What is the reason for the given project?

 After the conversion, the target client will look as if it had always been like that Basic facts on the conversion method (for client merge) • A client merge by means of the conversion method... ... Affects the complete dataset of a client ... Cannot be restricted to certain parts of the data • E. g. individual fiscal years or applications ... Is not related to a key date ... Is not related to any SAP transactions • No logical validation (SAP standard checks) • No change documents are created

Client Merge - Principle • “Source client” remains in the system, but is no longer used productively • “Target client” contains all relevant data from the source client after the conversion and looks as if it had always been like that System B System B Client 010 Client 010 Client 020 Client 020

Client merge by means of conversion approach • ALL master and transaction data from the source client is transferred to the target client • Depending on conditions at the outset of the project, this may involve a huge renumbering effort! • Customizing settings of target client have priority • Settings from target client are not changed • Different settings from source client are discarded • Additional settings from the source client are transferred to the target • If you need to keep any settings from the source client, or change settings in the target client, this requires additional work in the preparation phase • Conflicts are found during the pre-analysis

Client merge by means of conversion approach • Organizational units from the source client are transferred to the target client without being changed in any way • Organization al units need to be disjoint, that is, each ID may occur only once in all affected clients  organizational units can be renamed by means of conversion if necessary • Example: In both the source client and the target client, there is a controlling area 0001  one of these (normally the one from the target client) needs to be renamed • If required, lower-level structures (e. g. controlling areas) can be merged later on

Client merge by means of conversion approach • “Basis package“ for client merge already contains solutions for several typical tasks, such as • Renaming of clients, logical systems, FI document types, ledger numbers • Automatic renumbering of transaction data • Automatic renumbering of documents, change documents, conditions • Renumbering of CO objects • Solutions for additional project-specific tasks (renaming, changing number ranges) are developed using the Conversion Workbench • Standardized definition of conversion logic for a given task • Implementation of necessary changes by means of generated conversion programs

Client Merge: Structure of the technical concept “Basis package“ for client merge Pre-defined solutions that can be included in the project if required Project specific additional development Size of individual components depends on requirements in the project!

Client Merge: Restrictions • The following data will NOT be considered in the standard version of a client merge: • R/3 User master data, authorizations, profiles and activity groups • New authorization concept is needed! • R/3 System tables • Spool, Batch Input, jobs • ABAP queries

Specifics • Archives can be converted by means of SLO Archiving Services. Without an archiving conversion • Only the technical view of SAP Archive Information System (SAP AS) will be fully available • Unrestricted access to archives from the applications and via reporting is no longer guaranteed after the conversion • Authorizations and Authorization objects are not converted • Manual adaptation required after the merge • Data from HR (Human Resources) is not covered by the standard service, but can be included if necessary • Often it is possible to change the relevant HR data using standard functions • Data from Industry Solutions and other mySAP Business Suite products is not covered by the standard service, but can be included if necessary • Details need to be analyzed and discussed on project basis • SLO Technical Services are available e. g. for • Analysis ofreport variants • Doing aCoding Scan

Prerequisites • The conversion blueprint must cover all applications and systems that are linked via interfaces • E. g. all clients that belong to an ALE integrated system • E. g. related systems (non-R/3 systems) for reporting, consolidation etc. • Make sure that data exchange between the systems will work correctly after the merge • Preparation of tests is an important part of the conversion blueprint! • Define general test procedures • Define test procedures for business processes • Provide test data and reports for reconciliation/comparison such as • Balance sheet, account balances, ...

Technical prerequisites • Access to server SAPSERV<X> • Transports provided by SLO must be imported • OSS connection • Test conversion and conversion of production system are usually done via remote connection • Users with the necessary authorizations must be provided (SAP_ALL, if possible) • Data backup prior to conversion • It must be possible to reload the data backup in case problems occur during the conversion! • System settings for the conversion • Change system parameters for the conversion • Note 534036 System settings for conversions • and Note 376787 Technical documentation for 4.0 Conversions • Other settings at database and operating system level

Technical background • Conversion using clusters • Can be restarted • Does not depend on size of individual tables

Client Merge: Procedure • Project phases (high-level) • Technical analysis of the system shows feasibility of the conversion and project scope • A task list for unification of Customizing and master data is created • Draw up a blueprint for the conversion and have it accepted • Maintenance of control tables, e. g. for converting document numbers and number ranges; project-specific development (if required) • Several test conversions and thorough tests of conversion results • “Customizing freeze“ before last test conversion • Do not introduce e. g. new applications, tables or business transactions • Only “approved“ transports Otherwise: Problems may occur during production conversion • Conversion of production system • Timeline • Depends on numerous factors (e. g. database size, hardware, requirements)  For details, see next slide

Client Merge: Procedure and duration of individual steps (according to experience) • Analysis: One to four weeks (and even longer for very complex projects) • Decision in favor of one solution, specification of project procedure: Depends on workflows within customer company; usually about four weeks • (If necessary, consider also time required for client transfer!) • Project-specific development: Depends on requirements found during analysis • Client Merge: Technical cyclewithout subsequent acceptance tests: Five weeks • Client Merge: First test runwith subsequent acceptance tests : Five weeks • Client Merge: Second test runwith subsequent acceptance tests : Four weeks • (If necessary, four weeks for each additional test run) • Client Merge: Last test runwith subsequent acceptance tests : Four weeks • Client Merge: Preparations for production conversion: One week • Client Merge: Production conversion and post-processing: One week (production conversion itself is done at week-end)

Test conversion • Prerequisites • Tasks as defined after the analysis must be completed • Preparation for test conversion • Provide test system (customer) • Test system = Copy of production system (the more recent, the better) • Hardware and application data are comparable to those of the production system • Test system should be available exclusively for conversion purposes during the complete project duration • Import necessary transports • Reliability of the runtime estimation for the production conversion is determined by similarity between test system and production system • As a rule, a reliable runtime estimation is not possible until after the first test conversion

Conversion of production system • Preparation • Import the transports provided by SLO and the customer-specific modifications (e. g. test results) • Execution • Conversion is usually done during a weekend so as not to interfere with daily business • Project team members must be available! • This refers in particular to the system administrator • Operating system maintenance, database, SAP Basis such as transport system... • System lock • Production system is locked during data conversion • System lock covers all clients in the system! • No other work is possible at that time – even in clients that do not participate in the conversion • System lock is not lifted until test of results has been successfully completed • Data backup prior to conversion • It must be possible to reload the data backup in case problems occur during the conversion!

Test of conversion results is sole responsibility of customer Define suitable test procedures (customer) SAP cannot provide test plans and procedures for all possible constellations Project members test conversion results using the defined test procedures Scope of tests is similar to those that are normally done after a system upgrade How many and which tests are required depends to a large extent on the specific conditions in the affected SAP system Tip: Have a look at documentation requirements and recommendations for testing that apply for the Euro conversion and adapt them accordingly Customer confirms in writing that test conversion was successful This confirmation is a mandatory prerequisite for the production conversion Client Merge: Test Tip: • Compare lists (status before and after conversion) • Account balances for G/L accounts, customers, vendors • Open items lists for G/L accounts, customers, vendors • Asset history sheet, list of stock values for assets • Inventory management list for stock account • Special Ledger • ... • Test business processes • e. g. depreciation posting runs, purchasing process from purchasing requisition to goods receipt, sales process from customer request to delivery / returns, ...

Client Merge: Main tasks of project team (customer) • Collaboration of customer (project team) is needed: • For evaluation of analysis results • As contact persons for questions (business-related as well as organizational) • Customer is responsible for: • Change management (e. g. information for end users) • Adaptation of authorization concept • Check interfaces with third-party and downstream systems and adapt them if necessary • Provide test system • Check results of the conversion • Provide system administration/ basis support (e. g. data backups)

Project team (customer) Specialists from application departments Business and organizational issues Conversion blueprint Mapping tables (if applicable) Information on customer-specific tables and programs Test results of conversions System administrators / IT staff Technical issues Information on customer-specific tables and programs Technical prerequisites Provide test system Import necessary transports Transports from test system to production system OSS connection and user System settings (number of batch processes, tablespaces) Allocation of tasks in SLO projects The members of the project team must be available during the complete project duration • This applies in particular to the weekend of the production conversion • and also for staff from third parties (if IT administration is outsourced)

A lot of experience with conversion method • After the creation the SLO team in 2000, the conversion method proved its worth in about 700 SLO projects • Chart of Accounts Conversions • Fiscal Year Conversions • Material Number Conversions • .... • Plus more than 6000 Euro conversions in which the conversion method was used as well • About 25 SLO Client Merges using the conversion method have been carried out to date (starting in 2000)

System A Client 010 System B Client 020 Client Merge by means of Migration Workbench - Principle MWB system

Migration Workbench (MWB) Access plan Run / Restart info 4711Johnnie W 1881Jim Beam 0001Johnnie W 0002 Jim Beam Controller Data reader (client) Data converter Data reader (server) Data writer (client) Data writer (server) Sender MWB Receiver

Data transfer LSMW – Legacy System Migration Workbench • General remarks • The joint client is newly created in Customizing together with the related lower-level SAP organizational units • Selected data is transferred • Copy master data • Transfer account balances, open items etc. • Data from completed and open processes is not transferred • „Old data“ can only be accessed via old structure • Document flow is destroyed • Open business transactions are transferred explicitly • Can be a problem particularly for companies with complex logistics and/or long-term processes or projects • The new joint client is used as of a key date • The source client is not used any more but are still visible in the system(s)

Data transfer LSMW – Legacy System Migration Workbench • Technical details • Objects / data that are relevant for the migration are identified basically by means of analysis of the Business Objects and processes • LSMW is a standard tool for transferring data from legacy systems (third-party) to SAP R/3 systems • It must be possible to extract the data from the source system and provide it in files • Data is imported into the SAP system by means of standard transactions • E. g. Batch Input, Call Transaction, Direct Input, BAPIs or IDocs • SAP standard checks for consistency and correctness are made

Data transfer LSMW – Legacy System Migration Workbench • Project steps (high-level description) • Analysis of Business Objects and processes shows project scope • Export relevant data • Existing solutions can be re-used • Map the old structure to the new one (LSMW) • Specify source, target and conversion rules for all relevant data • The most frequently used conversion rules are pre-defined • Change business processes • (Several) test migrations and thorough test of results • Migration into production system • Duration • Normally about four to six months LSMW in detail

SAP Standard Legacy Migration Workbench (LSMW) One or several files Legacy dataon PC Read data READ_DATA Structure relations Field mapping Conversion rules Legacy data on application server CONVERT_DATA Batch Input processing Converted data Direct Input processing IDoc inboundprocessing

Further information è SAP Service Marketplace http://service.sap.com/slo General enquiries Send an e-mail to slo.consulting@SAP.com è è Conditions and prices Contact the responsible local SAP Subsidiary

Questions? Remarks? ?

SLO Service Client Merge

SLO Service Client Merge

Presentation Transcript

SLO Training

Client-Centred Service Delivery

Client Service Index Guide

Client/Service

SLO Review

Supernova Client Service Model

SLO Update

Good Client Service:

Client-Server Movie Service

MERGE

SLO Assessment

SLO

Merge

Merge

Client-Centred Service Delivery

Merge