Coke One Data Enablement Strategy

Swen Sagawe – Data Enablement - Program Scale Coke One
Swen Sagawe– Data Enablement - Program Scale

Data Enablement Strategy
Data Enablement
Swen Sagawe Global Data Enablement Manager, Program

Scale
The Coke One™ and Program Scale™ systems, platform, structures, content and material contain confidential and proprietary
information and are protected by copyright and other applicable laws. Copyright © 2006-2009 The Coca-Cola Company. Coke Version 1.0 6.4.2011
One™ and Program Scale™ are trademarks of The Coca-Cola Company.
1
Swen Sagawe– Data Enablement - Program Scale
“The Coke One™ and Program Scale™ systems, platform, structures, content and material contain confidential and proprietary
information and are protected by copyright and other applicable laws. Copyright © 2006-2010 The Coca-Cola Company. Coke
One™ and Program Scale™ are trademarks of The Coca-Cola Company.”
2
Agenda
 Objectives of the workshop
 Pre-requisites for workshop attendees

 Overview & total context of how to handle Master Data Models, Conversions and Mappings in a
full circle.
 FDD/UPM reference
– UDM (Unified Data Model)
– Local CODD (Conversion Object Data Definition)
– Master Data Inventory
 Present documentations
– Detailed document walk through
– Log defects
 Session wrap-up
– Review defects list and align on next steps
3
Data Cleansing and Conversion

Data Enablement
Data Enablement
Data Conversion Data Identifing
model
Verifying which master data are needed

Mapping of current master data into Coke One Setup
Define how to get them into the system
4
Table of content
 Data Migration Objective

 Data Migration Scope
 Data Migration Activities
 Deployment Cycle
 Roles and Responsibilities
 Delivery Model
 Tools Overview
 Load process with using WF bypass
 Data Migration Road Map
5
Objectives of this presentation
 After this presentation, you will be able to

− Determine the scope of data migration for Coke One
− Identify key activities in the data migration cycle
− Understand how the data migration cycle is integrated in each deployment
− Have a clear understanding of the roles and responsibilities of the BSG versus
the local deployment team
− Know whom to contact for future questions
6
Data Migration Objective
 To:

Provide timely and quality data, in terms of both completeness and correctness,
to support all streams activities across the different phases of the project
 SO THAT:
Quality data is loaded to support quality processes and accurate reporting.
7
Master Data : Example Material Master
Global level
Material Number Plant level

Description Purchasing Group
BUOM Delivery time
Basic Data Purchasing Order Unit
Alternative Units
Plant level
MRP Controller
Sales organization
MRP Parameters St
Distribution channel
Lot size MRP Sales
t
Safety stock
Plant level
Plant level Production Scheduler
Price Work Production lead-time
Valuation Category Accounting Scheduling
Product Costing
Plant level
Control requirements
Storage Quality Inspection types
A
B location stocks Management Inspection intervals
Plant level
Forecasting
Stock
Forecasting Parameters
Management Plant & SL level
Stock
Global level
Storage Bin Characteristic
ABC indicator (for data not
Storage Classification defined in SAP)
8
Table of content

 Delivery Model
 Tools Overview
9
Migration & Conversion Scope – Coke One & C1DM
The Scale Coke One Migration & Conversion Scope includes:

• Defining the global conversion strategy, including global tool selection

• Provide templates for all conversion activities for the local bottler conversion team as starting
point and part of the development toolkit
• Provide global SAP data code, data values and data standards
• Create and own global Conversion Inventory
• Control the creation of we UDM for global Conversion Inventory data objects, indicating global
required, local required, and local optional attributes
• Own Design-, build- and test load routines for template data objects attributes as per global
template Conversion Inventory / UDM
• Own Design-, build- and test load routines for bottler required data objects / attributes via
change request process
The C1DM / Shared Services Team Conversion Scope includes:
• Check globally managed data objects / global data attributes provided by the bottler teams for
standard adherence and duplications against the global data repository
• Load of globally managed data objects / global data attributes into the global data repository
(global request client & book of records)
• Interfacing global data into local instances prior to local data object load
10
Data Migration Scope
 The data migration scope is defined by the following key figures:

It looks like a small road map
 UPM (Process defined in ARIS tool PPM)
 Process : Based on FDD (linked to process in PPM)
 UDM (based on the process the field set in use)
 Local CODD (based on local requirements (more fields…)
 Mapping Documents
 CGD (Config Gathering Documents) / EDD (Extraction Design Document)
 Load Template (LSMW) based on Template or Local add on
 All these figures are captured in the global conversion design document.
11
12

Inventory on Share Point
Share Point to find Load Templates & UDM & all enable
documents and processes

13
14

Share Point to UDM
15

Example for UDM
Document structure and logic

CODD FDD LSMW
(Bottler 1) (Bottler 1 ) (Bottler 1 )
UDM CODD FDD LSMW

(Scale) (Bottler 2) (Bottler 2) (Bottler 2)
CODD FDD LSMW

(Bottler 3) (Bottler 3) (Bottler 3)
FDD LSMW
(Template) (Template)
16
LSMW Standard Naming convention
Please follow the following LSMW Naming convention:

LSMW script or Load Program, which needs to be create or changed
FTD - Template Developments in

Program / Project /CCEAG/FTD/Trial Testmode
Upload Bill of Material for Production
Subproject G-UDM-O-053 Header & Detail
Object CS01_BOM_test Create BOM from Header and Item level
Naming
Convention:
R/3 Object Length Value Example
/<NAMESPACE>/<SCALE WORK /SCL/
LSMW PROJECT 15 CHARACTERS STREAM>/<SAP MODULE> MDM/AR
LSMW SUB- G-UDM-O-
PROJECT 15 CHARACTERS <GLOBAL UDM OBJECT NUMBER> 154
<TRANSACTION CODE>_<OBJECT
LSMW OBJECT 15 CHARACTERS NAME> XD01_PAYER
17

**The Recording Name should be the same as the LSMW Object and should have a
proper description**
• Abbreviations for Naming :
Abbreviations:
SCALE NamespaceDescription SCALE Work
SCL Template Developments Stream Description
CCCIL Bottler PTP Procure to Pay
CCCIL Developments OTC Order To Cash
CCBP Bottler MDM Master Data Management
CCBP Developments RTR Record To Report
CCEAG Bottler Human Resources
CCEAG Developments HRM Management
CCSM Bottler FTD Forecast To Deploy
CCSM Developments MTO Market To Order
CCSB Bottler TIN Technical Integration
CCSB Developments
18
• Abbreviations for Naming :

SAP Module Description
FI Finance
TR Treasury
CO Controlling
MM Materials Management
SD Sales and Distribution
LE Logistic Execution
PP Production Planning
PM Plant Maintenance
PS Project Systems
HR Human Resources
QM Quality Management
Customer Relationship
CRM Management
Supplier Relationship
SRM Management
SCM Supply Chain Management
FSCM FSCM
BW Business Warehouse
NW Netweaver
19
Main Rules
 All User can have full LSMW access only on DXX and MXX Systems
 Trial/Test LSMW will only be created in the trial project linked to the streams on DTX or

DCX, in specific cases also as part of double work in MTX and MCX
 For all load tool changes or creation a load tools request , containing UDM information &
load tool handling and template, is created and entered in the inventory.
 All approved Load tools will be created only on DXX or MXX systems by copying the
LSMW from Trial project to real project linked to a provided GAP and Change Request
No..
 All upload files will be stored under a predefined path.
 All approved load tools will be transported. LSMW will be transported as complete
project.
 Transports for Load tools will be created by the enablement team
 Transports will be approved by the GSL of the requesting stream and Global
Enablement team ( CR Number will be provided by the requestor )
20
Main Rules
 Only a small predefined group of Users will have permanent full LSMW access on other
clients. All other Users will have only LSMW execute access on QXX,SXX and PXX.
 Temporary Full access is possible on request to be approved by Michael Furniss and

Swen Sagawe (Filled out request needed)
 All approved load tools are linked to a global conversion id given by the global
conversion inventory and captured in it.
 For each new LSMW or modification a GAP and a CR is created.
 For already developed but not running LSMW an HPSC ticket is created
21
General Rules
 Tested and approved LSMW will only be copied from the trial project to the real project
by the enablement team on demand by submitting the filled out request form

 The SUBPROJECT will contain the linked global conversion id number
 The OBJECT will start with the SAP Transaction code which will normally drive the
function.
 All fields linked to dates will have the format DYMD Date in Year, Month, Day Format and
field length is (008) for template
 Upload files will be stored under the predefined path (with Citrix) : V:\Loadpath\
 Upload files will be stored under the predefined path (without Citrix) : C:\Loadpath\ (only
relevant for bottler projects)
 Naming convention for the upload file is : Upload SUBPROJECT - OBJECT.txt
Example : V:\Loadpath\Upload G-UDM-O-008-IL01_FLOC_CAT_E.txt (Citrix/Template)
Example : C:\Loadpath\Upload G-UDM-O-008-IL01_FLOC_CAT_E.txt (No Citrix)
22
General Rules
 File name for imported data will be : Template: SCL_Stream_SUBPROJECT_OBJECT

or for Bottler : BOTTLER_STREAM_SUBPROJECT_OBJECT

Example Template : SCL_FTD_G-UDM-O-008_IL01_FLOC_CRTE1.lsmw.read
Example Bottler : CCSM_FTD_G-UDM-O-008_IL01_FLOC_CRTE1.lsmw.read
23
General Rules
 File name for converted data will be : Template: SCL_SUBPROJECT_OBJECT or for

Bottler : BOTTLER_SUBPROJECT_OBJECT

Example Template : SCL_G-UDM-O-008_IL01_FLOC_CRTE1.lsmw.read
Example Bottler : CCSM_G-UDM-O-008_IL01_FLOC_CRTE1.lsmw.read
File name can be cut if need to reach 45 digits by deleting the SCL or Bottler
If files will be loaded by using the logical path we can keep the old logic so far.
 Successfully test trial LSMW will be copied into approved real projects and transported.
 Gap and CR number will be provided to create a transport request.
 No Export/Import of Trial LSMW is allowed to other clients
 Note: We will transport full projects, so all imported projects on other clients will be
overwritten.
24
Trial Projects
 All Load LSMW in test mode must be stored under the predefined Project linked to the
stream (Trial projects will never be transported and will be cleared every 2 months)

TEMPLATE : (These projects will be on both environments (DC/TR & MC/TR))
 /SCL/FTD/TRIAL
 /SCL/MDM/TRIAL
 /SCL/OTC/TRIAL
 /SCL/PTP/TRIAL
 /SCL/RTR/TRIAL
 /SCL/TIN/TRIAL
25
Trial Projects
 All Load LSMW in test mode must be stored under the predefined Project linked to the
stream (Trial projects will never be transported and will be cleared every 2 months)

Bottler : (example) (These projects will exist only in DCR & MCR environments)
 /CCSM/FTD/TRIAL
 /CCSM/MDM/TRIAL
 /CCSM/OTC/TRIAL
 /CCSM/PTP/TRIAL
 /CCSM/RTR/TRIAL
 /CCSM/TIN/TRIAL
26
How to get a trial project to a real project and moved to
other clients
 After doing the trial and tests (successfully) a filled out Load tools request will be raised.

 The following information are mandatory and part of the request form:
 GAP or CR number (Template Yes or No)
 Name of the object to be copied.
 Information if the UDM needs to be changed
 LSMW Structure in the format of the Load Tool Request FORM
 Filled out CDD sheet.
 Test Documents
 Global Conversion Number will be assigned to the new Load tool
27
How to get a trial project to a real project and moved to
other clients
 Linked Transport will be given by the Enablement team or C1DM and will be asked for
approval

 New test in the next client before approval for production.
 The Request form will be stored on share point and can be reused for the next request.
http://teamspaces.ko.com/kots/scale/Data%20Management/Forms/AllItems.aspx?RootFold
er=%2fkots%2fscale%2fData%20Management%2fTemplate%20LSMW&FolderCTID=&Vie
w=%7bB3D840CD%2d731A%2d45C1%2dBAE2%2dA64E4322757D%7d
28
Why All load tools are linked to a global conversion id
given by the global conversion inventory.
 This will be shown by having the global conversion id in the description or in case of
LSMW in the Subproject

 The Load tool with also be indicated in the Global Conversion Inventory
 This will help also to identify the actual template versions
 All bottlers will get copies in their own naming range to guarantee the reusability for them
 Also Coke One project will have an overview of missing load tools
 All load tools will be easily identified for the load purpose
 Each Bottler can get their own inventory and have also re useable tools.
 Link to inventory:
 http://teamspaces.ko.com/kots/scale/Data%20Management/Forms/AllItems.aspx?RootF
older=%2fkots%2fscale%2fData%20Management%2fScale%20UDM&FolderCTID=&Vie
w=%7bB3D840CD%2d731A%2d45C1%2dBAE2%2dA64E4322757D%7d
 The following structure is currently foreseen:
29
Project structure Template RTR
RTR
 /SCL/RTR/CFG

RTR - Customizing Configuration Objects
 /SCL/RTR/CO RTR - Template Developments for Controlling
 /SCL/RTR/FI RTR - Template Developments for Finance
 /SCL/RTR/FSCM RTR - Template Developments for FSCM
 /SCL/RTR/TRIAL RTR - Template Developments in Test mode
 Same structure will be available for Bottler in their own naming range
RTR
 /CCSM/RTR/CFG RTR - Customizing Configuration Objects for CCSM
 /CCSM/RTR/CO RTR - Developments for Controlling for CCSM
 /CCSM/RTR/FI RTR - Developments for Finance for CCSM
 /CCSM/RTR/FSCM RTR - Developments for FSCM for CCSM
 /CCSM/RTR/TRIAL RTR - Developments in Test mode for CCSM
30
All load tools are linked to a global conversion id given
by the global conversion inventory.

31

32

33
Load tools request
 Again: Test Load Tool will only be copied from Trial to real tool if:

 For all load tool changes or creation a load tools request , containing UDM information &
load tool handling and template, is created and entered in the inventory.
 This request must be created and delivered before the copy or creation in the approved
projects will be started.
 Based on test information decide if the load tool will be a program or an LSMW
 Based on the document decide if App Dev, Solution team or Enablement team (incl.
C1DM) will cover this Request.
 Also check document if the request becomes a template object
34
Request form
 The request form is the initial step for
custom Request Form
LSMW Obj ect Request

requesting a Loadprogram / LSMW
script creation or change.

Requestor
Requesting person or Org. Unit
 It contains a general area with

necessary contents like requesting Business case
Description of the business case

person or Org. Unit, description of the
business case, a brief description and
other contact persons.
Additional informations
Brief description, other contact persons etc...
 It contains process specific areas for the

creation and change of LSMW scripts.
In this areas, the requestor has to New LSMW Script
provide some „must have“ informations.

"must have" Atachments
Conversion design document
Conversion Object Data Definition
 A CDD , UDM , Load Tab for template LSMW Load Template
Change existing LSMW Script

 A CODD Tab on Top for Bottler "must have" LSMW informations
LSMW Project Name

Project
 Field sequence can be shown via Subproject LSMW Subproject Name
screen shots and example data Object UI Control
35
Summary
 All Load tools will be created only on DXX / MXX systems by respecting the naming convention
given in the Load Request form

 All load files will be stored under a predefined path.
 Example V:\Loadpath\Upload G-UDM-O-257-LOT_VEH01.txt
 Following information are mandatory if LSMW:
 Path will be V:\Loadpath\
 Naming of the file : Upload Conversion-ID-Object.txt
 Following information are mandatory if Load program:
 Path will be V:\Loadpath\
 Naming of the file : Upload Conversion-ID
 All tools needs to be tested before Transport can be requested. Test scripts needed !!
 Single transports for load programs
 Full project transport for LSMW projects
36
All load tools will be transported
 When the changed/created LSMW script has been tested and the test is documented by
the requestor, a copy in approved naming range will be made. It has to be transported

into all systems. These transports must be approved by the local and by the GSL &
Global Migration Lead linked to the entry in the local conversion inventory. Depending if
it is template or deployment)
 In each system a test must be performed succesfully before the final approval to
QXX/PXX systems . Changes are only allowed in the DXX or MCC with double work.
 Single transports for load programs
 Full project transport for LSMW projects
 Changes will be assigned to a transport by Global Enablement Team irrespective of

whom was in charge for the creation of the load tool.
 Transport release can only happen after Input from Enablement team (Final Data
Capture in Inventory)
37
LSMW Access
 All user will have full LSMW access on DXX and MXX

 Only a predefined limited group of user will keep the permanent full LSMW access for
error valuation and testing in QCR and SCR.
 Due to the predefined path the linkage of files will not be necessary anymore.
 Time restricted full LSMW access can be assigned on demand if needed. (Depending on
the object)
 LSMW authorization request must filled out and approved by Michael Furniss and Swen
Sagawe.
38
Table of content

 Delivery Model
 Tools Overview
39
Data Migration Activities
• Data Formatting: Checking data against data standards (ex:

leading zeros, data types, prefixes,..)
• Duplicate check: Eliminating duplicate records.
• Data enrichment: Adding missing data 04 Data

• Data conversions: Changing existing values based on pre-defined Verification
rules.
• Data validation: Cross checking data against check tables or
against business rules.
L Input Output T
06 Data Reconciliation
E Manipulation Platform A
05 Data Loading
G 02 Data
R
A
Extraction 03 Data Gathering /
Manipulation
G
C E
Y T
01 Data
Mapping
• Starts directly after process mapping

• Maps legacy data model to target data
Model
40
Data Mapping
 Data Mapping is the first activity in the data migration cycle. Its objective is to:

− Map the legacy data model to the Scale Coke One target data model
• For each field in the Scale Coke One target data model, define the legacy field
containing the same data content.
• Define value conversions if content needs be changed
• Define criteria for gathering required data, which is not maintained in the legacy
system
41
Ownership

General Principle:
– “You can only OWN what you CAN KNOW”
– Ownership is based on specialized knowledge, and access to information
42
Ownership
Deployment Partner Functional Stream

Design local CODD for data conversion Design docs/Deliverables
– Prioritize request
– Coordinate with BSL to evaluate impact
Provide input and perform mappings
and decide on next steps
Update local MDM team with
– Approve changes (add / change fields)
central/local requirements after
– Prepare localized CODD and tab for
mapping validating it together with GLS
 Based on local CODD create the Mapping Keep track on secondary Gaps for new
Document fields and load tool changes
Change log Submit requests for changes from

– Prioritize functional streams to Coke One team
– Determine next steps (central/deployment)
43
Migration deliverables
All Streams (excl. HR - Payroll)
Charlie/Swen Data Enablement. Data Enablement / App Dev. Data Enablement
GBSL / DEM
Swen Sagawe – Data Enablement Define

Load program
UDM / Load Load Template (LSMW or
Global Scale Template load file
Template ABAP)
doc
xls Process Team xls
localized
CCR
doc
Deployment Partner/ BSL BSL / BSE /Local IT MDM Team / BSL
localized
Extraction
Conversion
localized design
- Program Scale Coke One

Design
CODD document
Document
doc
BSL / BSE / Local IT. doc
Data mapping
document
xls
Local IT. Appl. Dev. Appl. Dev.
Template document
localized load
Realize
Extraction and program
Localization document conversion Localized
(LSMW or load file
program ABAP)
Global Scale responsibility
xls
Deployment responsibility
44
Ownership
Data Migration Activities (for conversion objects)

45
Getting Ready for Data Mapping: Getting the Right Participants
 To have a successful data mapping session, it is critical to have the correct participants.
The deployment partner MDM lead is responsible to coordinate and track the data

mapping activities.
 In all data mapping sessions, the following participants needs to be present:

− Data Owner: (Meeting Leader)
• A representative from the local stream, who owns the data migration execution
of the data object
− BPE/SME:
• Experienced data administrative, who knows the specifics of all fields being
maintained on the legacy system:
− Local stream member, who is up-to-date with Scale Coke One functional processes
and requirements; and the bottler identified gaps.
− The technical contact who will design the extraction programs (where possible)
− On Demand:
• For the key master data (Materials, Vendors, Customers, Finance):
Global Data Standard Experts needs to be present or involved
Classified - Internal use

46
Getting Ready for Data Mapping
Preparation
 Few tasks can be done by the local data stream prior to the data mapping sessions to
facilitate the discussions:

− Review the UDM and master data documentation provided on sharepoint to refresh
the local data stream knowledge on scale Coke one processes and data objects.
− Review the data mapping template of the specified object
− Pre-map the fields in the mapping template to the legacy fields to:
• Save the search time in the data mapping session.
• Evaluate if all required information is collected to guarantee a successful
mapping session. If not all info is available, other participants could be invited
to present the missing knowledge.
− Prepare a list of legacy allowed values for controlled fields to enable the mapping to
the new Scale Coke one values
− Prepare useful data examples to illustrate the data model in the legacy system

47
Getting Ready for Data Mapping
Preparation
 Few tasks can be done by the local data stream prior to the data mapping sessions to
facilitate the discussions:

− Review the UDM and master data documentation provided on share point to refresh
the local data stream knowledge on Scale Coke One processes and data objects.
− Review the data mapping template of the specified object
− Pre-map the fields in the mapping template to the legacy fields to:
• Save the search time in the data mapping session.
• Evaluate if all required information is collected to guarantee a successful
mapping session. If not all info is available, other participants could be invited
to present the missing knowledge.
− Prepare a list of legacy allowed values for controlled fields to enable the mapping to
the new Scale Coke one values
− Prepare useful data examples to illustrate the data model in the legacy system

48
One Pager: How to Conduct a Data Mapping Session?
For each field in the mapping template, the following question needs to be answered: Which field from the legacy
system contains the same data content?
 If the field exists:

− List the table and field from the legacy system in the legacy columns.
− Check the content and format of the field:
• If it can be moved as it is, add the text “1:1” to the column “Mapping Rule”.
• If it requires conversions and
– if the rule is simple log it in the column “Mapping Rule”
– If the rule is complex, document it on a separate tab and add the tab name to the column
“Mapping Rule”
• If it requires reformatting:
– Add a comment in the column “Remarks”
 If the field does not exist:

− Check if the field is mandatory or is required for the bottler processes:
• If no, add the comment “ignore” to the column “Remarks”
• If yes, check if default value can be used:
− If yes, log the default value in the column “Default value” (could be based on rules)
− If no, check if the value can be automatically derived from other fields:
» If yes, log the derivation rule in the column “Mapping Rule”
» If no, decide on a criteria of how this data will be gathered and where it will be entered.
List the outcome in the meeting minutes.
 Log any open point that has still awaiting information or decision in the data mapping open points

49
50

Example
Expected Outcome
 Data mapping template filled with all country specifics data model

 Manipulation template filled with all required manipulation and conversion rules
 Meeting Minutes listing all key decisions , assumptions and next Steps.
 Updated Data Mapping Open Points sheet to allow the follow-up on open discussions

51
Table of content

 Delivery Model
 Tools Overview
52
Deployment Cycle
Data Mapping Tools Set-up Data Preparation / 3 Trial Cutover

loads

Data Extract Manipulate
Mapping Extract Manipulate
Determine required fields Design and Build Extraction Load Extract Manipulate
from legacy system Tool
Load
Reconcile Verify
Extract Manipulate
Determine required Design and Configure
Manipulation rules manipulation Tool Extract Manipulate Load
Load
Load
Evaluate required
changes on loading tool Design and Configure Loading
Tool Extract Manipulate
Extract Manipulate
Load
Load
Data Quality Issue Resolution
53
MOCK 1
• a test for the Data Migration Load tools and first mapping results and

it can take place in similar than the environment like the one planned
for integration tests (small amount of data)
• is used load tool testing & data setup result from mapping (will give
a feeling for data quality)
• no satellite systems like CRM or SRM … are needed
• used to check if the load plan fits logical and sequence wise
• Can be run on an empty system
Mock 1 should not be used for integration testing.
54
MOCK 2
Mock 2 is a test ( 50% simulation) for the Data Migration Loads

system performance will be important.
It will be use for load tool fine-tuning
data setup like near production (will give a feeling for data quality)
all satellite systems are needed
Master Data clients 200/100 should be in place.
The good system performance is necessary to enable the check on schedule
and to obtain timing to fine-tune a Mock 3 load plan.
The basis x-bottler data is important because in some cases new data will be
loaded and in others we will be extending views on existing data
bottler can run integration tests.
Mock 2 can/should be used for E2E Testing
55
MOCK 3
Mock 3 is a rehearsal ( full simulation) for the Production Load and it

should take place in an environment like PCR as possible:
system performance is very important
data - needs to be a recent copy of Production
all satellite systems needs to be available on basis of the production copy
The system performance is necessary to enable the team to complete on
schedule, and to obtain realistic timings to fine-tune a Production load
plan.
The copy of production data is important because in some cases we will
be loading new data and in others we will be extending views on existing
data.
Mock 3 can be used for UAT and Data sign-off for production load.
56
Table of content

 Delivery Model
 Tools Overview
57
Roles & Responsibilities - responsibilities
01 Data 03 Data
02 Data 04 Data 05 Data 06 Data
Mapping Gathering /
Extraction Verification Loading Reconciliation
Manipulation

Deployment Perform Data Build Extraction Execute Data Coordinate with Execute Data Execute data
Mapping Tools Gathering / local Loads for Local reconciliation
Team Manipulation organization to governance
and Resolve obtain business
data quality sign-off
issues
Configure tool Configure tool

Coke One Team set for set for
deployment deployment
needs and needs
provide
consultancy on
tools usage
Execute Data
Loads for
Global
governance
Support Data
Mapping Provide Consultancy on methodologies and data related
issues
Creating local Creating Data Creating Creating/ Reconcil. Tool

One-time Activity Creating Verification Modifying Load
CODD incl. Extraction gathering Set-up
Mapping template checklist sheet
template
template
LSMW Set-Up
58
Roles & Responsibilities - roles
01 Data 03 Data
02 Data 04 Data 05 Data 06 Data
Mapping Gathering /
Extraction Verification Loading Reconciliation
Manipulation

Deploy Team Perform Data Build Extraction Execute Data Coordinate with Execute Data Execute data
Mapping Tools Gathering / local Loads reconciliation
Manipulation organization to
Local Tool Expert and Resolve obtain business
data quality sign-off
Local Data Managers issues
Localize tool Localize tool

BSG Team set for set for
deployment deployment
needs and needs
Tool Experts provide
consultancy on
tools usage
and creation
Load Executers
Data Support Provide Consultancy on methodologies and data related

Enablement Data
Mapping issues
Manager
One-time Activity
No Permanent Roles are required
59 59
Roles & Responsibilities
Summary
 BSG Group  Deployment team

− Definition of overall migration − Defining local organization
approach & organization − Create local CODD/Mapping
− Provide UDM Template.
− Definition of migration guidelines − Performing data mapping
− Coaching deployment migration − Building of specific extraction tools
teams − Execution and monitoring
− Preparation and management of • data gathering
toolset • preparatory cleansing
− Localizing toolset to deployment • data manipulation
needs on request • quality checks
− Facilitating data mapping if − Accountable for end-result
requested − Requesting changes to the load
 Global Data Migration lead tools
− Data Enablement Manager − Execution final upload
− Tools Experts  Deployment Data Migration lead
− Local Data Managers
− Local Tools Expert
− Local Load Executers
60
Table of content

 Delivery Model
 Tools Overview
61
Delivery Model

Local Data Stream BSG Team (Atlanta)
Local Tool Expert

LSMW
Tool Expert
Data Enablement Standard Master Data

Manager Expert
Local Data
Managers LOAD Executers
Local functional Central

streams* functional
streams*
Local business Central Function
62
Delivery Model
Key Master Data – Customers
 Perform data mapping with local data

stream
 Act as the single point of contact for
local data stream for questions on
 Own data mapping data content and required
 Coordinate with local business conversions
to gather and validate DataCentral
Standards Team
Expert  Follow on progress status with local
required data data managers
 Own data quality (Leuven)
 Build checklist for required data
 Execute and monitor data verification
preparation cycles  Own master data design
 Execute and monitor Customer
production data extraction and
Data Managers Master
 Coordinate requirements with central
functions, other projects and
manipulation initiatives (Commercial, telesales,...)
 Follow up with local functional  Approves changes from central
streams on functional functional streams
requirements
 Update data managers with

functional requirements  Own customization
 Update Central Functional Local Functional Global OTC &  Manage modifications requests
 Own CRM design
Streams with required data Streams MTO Stream  Update data enable manager
design modifications
with requested changes
63
Delivery Model
Key Master Data – Materials  Perform data mapping with local data
stream
local data streams for questions on
data content and required

 Own data mapping conversions
 Coordinate with local business  Follow on progress status with local
to gather and validate data managers
required data Data Standards Expert  Build checklist for required data
 Own data quality Central Team verification
 Execute and monitor data  Own master data design related to
(Leuven)
preparation cycles data model (UDM)
 Execute and monitor  Own customization
manipulation, if data are Material
Data Managers Master Data
shared with other bottlers
 Follow up with local functional
streams on functional
requirements
 Update data managers with

 Provide input required for
functional requirements
master data design
 Update Central Functional
Streams with required data
Local Functional All Global  Update data enable manager
with requested changes
design modifications Streams Streams
64
Delivery Model
Key Master Data – Vendors

stream
to gather and validate DataCentral data managers
Team
Standards Expert
required data  Build checklist for required data
verification
 Execute and monitor data  Own master data design
preparation cycles Vendor &  Coordinate requirements with central
 Execute and monitor
Data Managers Employee functions, other projects and
Data initiatives.
manipulation, if data is shared  Approves changes from central
 Follow up with local functional functional streams
requirements
Global
Local Functional
Procurement
Streams
Stream
65
Delivery Model
Key Master Data – RTR KEY Master Data

stream
to gather and validate DataCentral data managers
Team
Standards Expert
required data  Build checklist for required data
verification
 Execute and monitor data  Own master data design
preparation cycles Cost Center /
 Coordinate requirements with central
 Execute and monitor Profit Center /
Data Managers Bank keys /GL
functions, other projects and
initiatives.
manipulation, if data is shared accounts
 Approves changes from central
 Follow up with local functional functional streams
requirements
Local Functional Global RTR

Streams Stream
66
Delivery Model
Other Master Data and Transactional Data
 Own data mapping

 Coordinate with local

business to gather and
validate data  Check received data files
 Own data quality  Follow on progress status
 Execute and monitor data
preparation cycles
 Execute and monitor
Global Data Standards
production data extraction Data Managers
and manipulation Experts
 Follow up with local
functional streams on
functional requirements
 Perform data mapping with  Own master data design

local data stream  Coordinate with central
 Act as the single point of Local Functional Global Functional functions to standardize data
contact for local data stream Streams Streams design
for questions on data content  Own customization
and required conversions  Manage modifications requests
 Communicate identified data  Own new system design (CRM
design gaps to central and SRM)
functional streams  Approves changes from local
 Build checklist for required data functional streams
verification
67
Table of content

 Delivery Model
 Tools Overview
68
Tools Overview
LSMW
 What is LSMW?

− LSMW stands for Legacy System Migration Workbench
− It is a tool based on R/3
− It supports periodic and single data transfer from a non-SAP system to an SAP
System.
− It uses standard SAP interfaces.
 What LSMW can do

− Transfer data from files to the target system
− Perform data mapping (example, transactional data)
− Transport the data migration object (i.e. configuration is to be done ONLY once)
• via download and upload
• via SAP transport system
 What LSMW cannot do

− Extract data from the legacy system
− “outbound”: transfer data from SAP into another system
69
Tools Overview
LSMW
 How LSMW is to be used in data migration?

−For activity 5 : Data Loading
04 Data
Verification
Output
Input
Batch Input
processing
SAP Standard
L T
Manipulation A
05 Data Loading
E
Reconciliation
Platform R
Direct Input
06 Data
G
A
02 Data
Extraction
G Output:
C
03 Data
Manipulation
E Converted data processing
Y T
IDoc inbound
01 Data
processing
Mapping
70
Tools Overview
Load Program
 ABAP Programs

− Load Programs developed in ABAP are also available
The programs are specially created to upload Material and Customers.
You will find the details information in the Conversion inventory which will indicate
for each object if a load program or and LSMW will be used.
71
72

Example
73

Example
Table of content

 Delivery Model
 Tools Overview
74
Production load approach without WF
• Data loaded during the conversion process should be approved prior to the

load, BUSINESS DATA SIGN OFF AFTER MOCK 3 as such, the normal
maintenance workflow should not be triggered.
• Provide the data conversion team with the mechanism to by-pass WF,
without impacting existing users in the system and minimizing downtime.
• Avoid system performance impacts of large volumes of data moving across

clients and to external systems.
MDM-020 Data Enablement

MDM-020-010 Data Cleansing and Conversion
MDM-020-010-010 Cleanse and Convert data
75
Workflow Check Function flow
Regular
Process
Workflow
Event Check
Trigger
Func
workflow
Data
Load
User
Load
Table Load
Prog
New Prod
Objects
Mod
76
Client 200 (MDM)
Change Pointer Flow Load
Prog
Load
Table
Idoc
Client 100
Load
Prog
Load
Table
Obj Creation
Idoc
Badi Idoc
XI
Badi
New Send downstream
Mod XI Load File
77
User Bypass Design Details
 Scope of WF bypass:
• Customer

• Material
• Vendor
• General Ledger
• Cost Center
• Profit Center
• Bank Keys Scope of change pointer bypass:
• Customer
• Material
• Vendor
 Transactions added:
• /SCL/RUMXX_WF_USER - Workflow User Bypass
• /SCL/RUMXX_WF_PROCES - Process load data
78
System Playback
Menu item added for user bypass and load

processing program
79
System Playback
Add data conversion user IDs to WF User bypass table Per object:

80
System Playback
After data is loaded to client 200, push data to client 100.

Note: For large volumes, please work with the ALE team to transfer data (>2000)
81
System Playback
Change pointer by-pass:
 Idocs are sent from the master data client (200) to the production client (100) to

create new objects. When the new objects are created, a change pointer is created to
send the object to downstream systems .
 The downstream systems may be incapable of handling a high volume of idocs

(causing the system to crash). XI, which sends the data cannot buffer the messages
to prevent the downstream systems from crashing.
 The system load to process the high volume of change pointers may degrade the
performance of the entire system
 Coordinate availability of external systems and work with the XI team to push data
from client 100 to external system.
 Note the same transaction is used for pushing data to Client 200 > 100, and Client
100 > External systems (executed from sending client)
 Large volumes could cause performance impacts for end users in the productive
systems, so loads and sending large volumes should be performed on non-peak
hours, and coordinated with the ALE and XI teams.
82
System Playback
Object locking:

 Master Data loaded with an LSMW checks any standard or SCALE locks to ensure
the object is available for processing/update. If a lock exists, the data load for that
record will fail.
 When data loaded via conversion programs with by-pass active, a lock is created.
Data entered interactively during the normal maintenance process checks for data
load locks to ensure the object is not locked for data loads.
 Subsequent loads for objects with the same key should be permitted. This should not
be limited by the user id in the load lock table. Any user in the by-pass table for that
object will be allowed to make further updates.
83
Table of content

 Delivery Model
 Tools Overview
84
Data Migration Road Map
How to have a

successful go-live in
just 24 steps
85
The steps as an overview
1. Conversion Objects selection and creation of Local Conversion Inventory
2. Define Load approach for each object

3. UDM check on ARIS
4. Creation of localized CODD
5. Creation of Mapping documents
6. Perform mapping for conversion objects in scope
7. Creation of CGD
8. Update of mapping documents
9. Check/Modify/Create Loadtools or Programs
10. Creation of EDD
11. Creation of Extractionprograms
12. Testing Extractiontools and checking outputformat
86
Steps
13. Testing Loadtools (x-check with mapping and config)

14. Define Loadsequence based on Inventory
15. Prepare Mock 1
16. Perform Mock 1
17. Data reconsolidation and bug-fixing
18. Prepare Mock 2
19. Perform Mock 2
20. Data reconsolidation and bug-fixing (first sign off from Business)
21. Prepare Mock 3
22. Perform Mock 3 (Production Load simulation)
23. Final bug-fixing (if needed)
24. Prepare cut-over and run production load
87
Conversion Objects selection and creation of
Local Conversion Inventory
 Copy the Global Conversion Inventory into a local version (MDM)

 Store it on sharepoint (for global assistance) (MDM)
 Check if all needed objects are included and covered (x-stream)
 Flag all relevant ones as „Bottler in Scope“
 Flag all not relevant as „out of scope“ (Do not delete them !!)
 Log a GAP for missing objects
 Setup a request process for missing objects
 Add missing ones after approval by BSG team
88
Define Load approach for each object
 Review each object and make an estimation about load volume

 Assign Load approach to each object
 For all automated ones you need a mapping and a loadtool
 For all manual you need a mapping
 For all interfaces you need a input structure for interface setup
89
UDM check in ARIS
 Sort all objects by „Bottler in scope“

 Check if for each object a UDM is available
 Request missing ones
 X-check if your local added inventory items are perhaps template

ones or can become Template
 Update your Local Inventory
90
Creation of localized CODD
 Copy all UDM into a localized CODD (Deployment Partner)

 For new local required objects create a CODD based on the FDD
 Trigger the CODD delivery
91
Creation of Mapping documents
 Create mapping documents based on your CODD (DP)

 Each stream owns this activity for the object assigned to the stream
 Provide mapping guidlines as an add on for the mapping documents
 Trigger the mapping document delivery
 Post them on share point
92
Perform mapping for conversion objects in scope
 Perform the mapping activities regarding the guidelines for all

objects in scope
 If new fields are discovered, highlight them and get a confirmation

about this potential GAP from the global team
 Trigger the mapping progress
93
Creation of CGD
 Based on the mapping exercise there will be probably a need to

create Config Gathering Documents for missing config or new fields
 Each field needs to be alliged with the MDM stream
and is responsible to inform MDM
 Get an approval by the solution team and feedback on the planned

design.
 Trigger the CDG progress
94
Update of mapping documents
 Based on the config changes you need to update the mapping

documents for development input
 Enter Table names and fields
 Trigger the update progress based on approved CDG
95
Check/Modify/Create Loadtools or Programs
 Based on the config changes due to mapping results or other local

requirements you should check if the template loadtool and

programms can still be used. (DP)
 Check if quality checkrules can be added to your loads
 LSMW modification needs to be requested and documented with the

Scale LSMW Template. Based on this the Template LSMW will be
copied and modified for bottler requirements. (DP)
 All new ones follow the same process, but they will be created from
scatch in the bottler enviroment (DP)
 Trigger the update progress based on approved LSMW
 Post them on share point and update your Local Inventory
96
Creation of EDD
 Based on the mapping and Load file you should create an Extraction

Design Document.
 It will offer all field mapping rules during the extraction from the
legacy system and also the output format, which should be the same
structure as the loadstructure
 Trigger the update progress based on approved LSMW
97
Creation of Extraction programs
 Based on the EDD the Extraction progams will be developed for all

automated and other chosen objects. (DP)
98
Testing Extractiontools and checking output format
 Based on the EDD the Extractionprogams will be tested for all

automated and other chosen objects.
 Check if all mapping rules are setup properly
 Check if all automatic field derivation are okay
 Check the field format
99
Testing Loadtools (x-check with mapping and config)
 Collect 10-15 records for all objects which should be loaded

automatically (Finance Master Data should be loaded completly)
 Run a load test with each object
 MDM should coordinate this activiy
 Each stream is responsible to load their own objects
 Results from Extraction Programtest can perhaps be reused
 Testload results can be used for Integration test
 It will be the last check before MOCK 1
 Check if all security profiles are prepared
100
Define Loadsequence based on Inventory
 When all objects are identified the MDM will define the load

sequence for the data migration
 The load sequence will be tested during MOCK 1
 All objects (automated/manual/interfaces) will be in scope
 Align on security set-up
101
Data reconsolidation and bug-fixing
 All loadresults will be reviewed and checked by the streams

 Noted errors in the loadtools will be corrected and loadtool
documentation updated (DP)
 Wrong load sequences will be reviewed
 Wrong mappings will be corrected
 Wrong security set-ups will be corrected
 Missing Config added
 All streams review their dataload process and result for their
conversion objects
 All objects should be in scope.
102
Prepare Mock 2
 Extract predefiened volume of data for MOCK 2 with the Extraction

tools.
 Results must be checked by functional stream and validated before

upload
 Extracted data should be reviewd by business people also
 Based on system resources it should be 30%-60% of the data
103
Perform MOCK 2
 Load should be performed in the defined redesigned sequence to

test if the sequence is okay
 Error resolution if possible directly , if not once again note for bug-
fixing
 All streams perfom their dataload for their conversion objects
 Check all security set-ups
 Duration of load time will be collected for each object
104
Data reconsolidation and bug-fixing MOCK 2
 All loadresults will be reviewed and checked by the streams and

business resources
 Noted errors in the loadtools will be corrected and loadtool

documentation updated
 Wrong load sequences will be reviewed and finalized
 Wrong mappings will be corrected
 Missing Config added
conversion objects
105
Prepare Mock 3
 Extract / prepare complete volume of data for MOCK 3 with the

Extraction tools.
 Results must be checked by functional stream and validated before

upload
 Final validation and sign-off from business
 Check and Validation from Global Standard Team
 All objects are in scope.
106
Perform Mock 3 (Production Load simulation)
 Load should be performed in the defined final sequence

 Error resolution if possible directly , if not once again note for bug-
fixing
 Check for show-stopper cutover
 Check all security set-ups
 Duration of load time will be collected for each object to be able to

plan for cut-over
107
Data reconsolidation and bug-fixing MOCK 3
 All load results will be reviewed and checked by the streams and

business resources
 Based on this: Final sign off for cutover
 Load duration will be analysed and transfered into cutover planing
 Last chance for missing Transports
 Last chance to correct security set-ups
conversion objects (Fine tuning)
108
Perform Cut-over Load
 Load performed in the defined final sequence, after sign off

 Error resolution if needed directly ,
 Check for show-stopper cutover
 Cut over sequence have to be follow consecutively
 Start of double maintenance period
109

Coke One Data Enablement Strategy

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Coke One Data Enablement Strategy

Uploaded by

Copyright:

Available Formats

Swen Sagawe – Data Enablement - Program Scale Coke One

Swen Sagawe– Data Enablement - Program Scale

Swen Sagawe Global Data Enablement Manager, Program

 Pre-requisites for workshop attendees

Swen Sagawe – Data Enablement - Program Scale Coke One

Swen Sagawe – Data Enablement - Program Scale Coke One

Verifying which master data are needed

 Data Migration Objective

Swen Sagawe – Data Enablement - Program Scale Coke One

 Data Migration Activities

 Roles and Responsibilities

 Load process with using WF bypass

 Data Migration Road Map

 After this presentation, you will be able to

Swen Sagawe – Data Enablement - Program Scale Coke One

− Identify key activities in the data migration cycle

− Understand how the data migration cycle is integrated in each deployment

− Know whom to contact for future questions

Swen Sagawe – Data Enablement - Program Scale Coke One

Swen Sagawe – Data Enablement - Program Scale Coke One

 Data Migration Objective

Swen Sagawe – Data Enablement - Program Scale Coke One

 Data Migration Activities

 Roles and Responsibilities

 Load process with using WF bypass

 Data Migration Road Map

The Scale Coke One Migration & Conversion Scope includes:

Swen Sagawe – Data Enablement - Program Scale Coke One

 The data migration scope is defined by the following key figures:

Swen Sagawe – Data Enablement - Program Scale Coke One

 UPM (Process defined in ARIS tool PPM)

 Process : Based on FDD (linked to process in PPM)

 UDM (based on the process the field set in use)

 Local CODD (based on local requirements (more fields…)

 CGD (Config Gathering Documents) / EDD (Extraction Design Document)

 Load Template (LSMW) based on Template or Local add on

Swen Sagawe – Data Enablement - Program Scale Coke One

Swen Sagawe – Data Enablement - Program Scale Coke One

Swen Sagawe – Data Enablement - Program Scale Coke One

Swen Sagawe – Data Enablement - Program Scale Coke One

Swen Sagawe – Data Enablement - Program Scale Coke One

UDM CODD FDD LSMW

CODD FDD LSMW

Please follow the following LSMW Naming convention:

Swen Sagawe – Data Enablement - Program Scale Coke One

FTD - Template Developments in

Swen Sagawe – Data Enablement - Program Scale Coke One

• Abbreviations for Naming :

• Abbreviations for Naming :

Swen Sagawe – Data Enablement - Program Scale Coke One

Swen Sagawe – Data Enablement - Program Scale Coke One

 All upload files will be stored under a predefined path.

 Transports for Load tools will be created by the enablement team

 Temporary Full access is possible on request to be approved by Michael Furniss and

Swen Sagawe – Data Enablement - Program Scale Coke One

 For each new LSMW or modification a GAP and a CR is created.

Swen Sagawe – Data Enablement - Program Scale Coke One

 Naming convention for the upload file is : Upload SUBPROJECT - OBJECT.txt

Example : V:\Loadpath\Upload G-UDM-O-008-IL01_FLOC_CAT_E.txt (Citrix/Template)

Example : C:\Loadpath\Upload G-UDM-O-008-IL01_FLOC_CAT_E.txt (No Citrix)

 File name for imported data will be : Template: SCL_Stream_SUBPROJECT_OBJECT

Swen Sagawe – Data Enablement - Program Scale Coke One

Example Bottler : CCSM_FTD_G-UDM-O-008_IL01_FLOC_CRTE1.lsmw.read

 File name for converted data will be : Template: SCL_SUBPROJECT_OBJECT or for