Data Migration Material Master

Methodology Workshop

The ground rules

1. Start by understanding SAP... Than see what is to be taken from the legacy system
2. The migration must be integrated with the functional analysis... As most migration issues are
linked to functional choices
3. Key Users may not be familiar, or comfortable, at writing conversion rules or specifications...
The format used to write rules is kept simple, clear and easy
4. Business Object Material Master must be owned by a Key User(supported by a business
analyst)... Who is responsible for writing the conversion rules and accountable for their
accuracy
5. Define which fields you need in SAP before going into any conversion rules... As Key Users must
first understand the fields purpose and impacts on the SAP process
6. Conversion rules must be written... So everyone involved in the project can read them and
agree on it
7. Do not start any programming for a Business Object before you have a complete set of clear
rules for all fields... A clear understanding between the functional and the technical teams will
avoid many time consuming issues.
 Data Migration Material Master
Methodology Workshop

The rules in action

In order to clearly document the conversion rules, the functional team must question and understand
the purpose of each SAP field, thus requiring them to better understand the SAP process itself.
Since most of the conversion issues are linked to customizing and functional choices(or omissions),
some questions raised while digging to document the conversion rules will reveal these pitfalls, which
might otherwise come up only toward the end of the project.
This synergy of conversion rules and functional analysis, permitting to identify and resolve potential
issues before they occur, will yield a much faster and stable conversion AND functional/customizing
process for the following steps.
The “AND” is key here, conversion will boost functional/customizing and vice-versa, this is where we
get added value.
How to make it work?
The whole process of this methodology is designed as building blocks, were each step if the
foundation on which the next one is built. “Lean” approach, so everything that is not necessary is
removed, everything that is left is necessary. What makes it work is the systematic application, of
each step of the methodology, for MM Business Object.
 Data Migration Material Master
Methodology Workshop
INTRODUCTION TO DATA CONVERSION.
The data conversion requires Key Users, business analysts and technical resources from most departments. These same resources will
most probably be involved in other parts of the project. For this reason, the risk of conflicting task is high and can quickly lead to a
bottle neck, where key peoples are overloaded. For this reason, it should consider the data conversion as a project within the project.
The main steps of the data conversion are:
Organization of the data conversion
Data conversion plan
The WBS with workload estimates
The calendar planning with resources loading
Going on with the Business Objects data conversion
Data purging and cleansing
Mapping and conversion rules
Extract and load programs from rules
Data and rules adaptation
Load unit testing
Extract and load full size testing
Full data loading and validation into ACCEPTANCE SYSTEM
Full data loading and validation into PRE-PRODUCTION SYSTEM
Full conversion and signoff into PRODUCTION SYSTEM
 
 Data Migration Material Master
Methodology Workshop
DATA CONVERSION PLAN
 Business Objects
A Business Object is a general category for data that defines something like material master, vendor
master, stocks, orders, purchase requisitions, organizational units, etc. The first step is identifying
which Business Objects are required for your SAP implementation.
Data type
There are three types of data involved in the migration: Master Data, transactional data, and
historical data.
Master Data. Application Master Data tends to be static. Most Master Data can be driven by the
legacy applications. Examples: vendors, customers, charts of accounts, assets, bills of materials,
material masters, info records.
Transactional Data. Transactional data is current and outstanding transaction data that needs to be
captured from the legacy system and defined to the SAP R/3 applications for business process
completion. Examples: accounting documents, open purchase orders, open sales orders, back orders.
Historical Data. Historical data needs to be brought over from the legacy system to the SAP R/3
System for reference purposes. Examples: closed purchase orders, closed sales orders, summary
general ledger information, etc.  
Data Migration Material Master
Methodology Workshop
 

Required information to complete the conversion plan

What Which Business Objectswill be converted from the legacy system into SAP.
Where Where are the data, which Legacy System's are involved for the extraction.
How much Estimate the number of records to be ultimately loaded into SAP.
How There are two aspects to be considered:
The way data is extracted from the Legacy System
Automatically extracted from the Legacy system without manual intervention.
Manually filled spreadsheet
Combination of an automatic Legacy System extraction + manual entry into a spreadsheet
The way data is injected into SAP:
Automatic data transfer from a flat file into SAP
Manually entering data with online transactions into SAP
Combination of both
The data transfer method you choose will determine the types of resources you need. For example, you may need temporary
employees for the manual data entry and programmers for writing the extraction programs.

Who Who is involve on each Business Object:

Key User(Functional responsible of BO conversion :Rules, manual data corrections, test, validations)
Legacy system technical staff
Functional consultants
Resources for of data cleansing and purging in the Legacy System
Programmer for the extractionProgrammer for loading data in SAP
Business Object Stakeholder
Knowing where the data is in the Legacy System, and which is accurate, requires the implication of different resources from your
organisation. They will need work closely together and you have to plan and secure their availability
 
Data Migration Material Master
CONVERTING A BUSINESS OBJECT
 Data Migration Material Master
Methodology Workshop
DATA PURGING AND CLEANSING
The purging and cleansing of the Legacy System will save you time and
efforts. Start as soon as possible and do as much as possible. This can be
done without specific knowledge of SAP.
• Data Purging
Before transferring data from your legacy system, delete old and obsolete
data. For example : You can also delete unused materials.
• Data Cleansing
This process correct data inconsistencies and ensures the integrity of the
existing data in the Legacy System. For example, there are often lots of
inconsistencies in Customer and Vendor address fields. You will quickly find
that SAP will not let you load address fields unless you cleaned them
 
 Data Migration Material Master
Methodology Workshop
MAPPING AND CONVERSION RULES
The documentation of each Business Object will contain the data conversion rules,
which include:
• Legacy sources:
From which Legacy system(s) are we extracting the data.
• Extraction procedures:
Document the specific steps required to extract data from the LS.
• Purging and cleansing rules:
What are the cleansing steps to be taken and extraction filters to be used.
• General Conversion rules:
Guide lines and generic rules.
• Fields Specific rules:
Conversion rules for each SAP fields.
 Data Migration Material Master
Methodology Workshop
About the rules
Getting the conversion rules to be written by Key Users is essential to
this methodology.
• Key Users must understand SAP fields usage.
• Key Users must question their Legacy System values and integrity.
• Documented rules permit a clear statement of what a Key User think.
Thus permitting to identify conflicts and misunderstandings between
domains.
• Rules documents must be versioned, making change management
easier.
• The rules will provide a common language between functional and
technical teams.
 Data Migration Material Master
Methodology Workshop
The Material Master challenge
Material Master involves all the domains and may require any where from 20 fields to a few hundreds,
depending on the complexity of your implementation. Some fields will be used by different domains while
others will be used by only one domain, but its value will have an impact on functionality used by another
domain. This is the most complex Business Object to document, and, at the same time, it is the one you
must start with in your conversion process. Material Master is key to all domains and many fields must be
discovered and understood. To get that understanding from Key Users proceed as follow:
1st step: Selection of the fields by each domain
Get each domain with their consultants to go through the mapping file and look at the fields for each
material type.
The goal here is to find which fields will be needed, requiring from the Key Users to ask questions and
understand their purpose. This is done separately by each domain and documented in different mapping
files.
At this point, we are not interested about where the values will come from and how to convert them. Each
time a domain select a field for a specific material type, they
Data Migration Material Master
Methodology Workshop
 Data Migration Material Master
Methodology Workshop
What to do when the same field is found in different views
In Material Master, some fields can be entered and modified in different views. For example, the field “Goods
receipt processing time in days (MARC-WEBAZ)” exists in views Purchasing, MRP2and Quality management.
When doing the rules and the load program, the same field can’t be in different views. To solve this, proceed as
follow:
See with all implicated domains and decide who will be the owner of the field.
For example, of the field “Goods receipt processing time in days (MARC-WEBAZ)”,it can be decided among the
domains to put it in the Purchasing view (and nowhere else). This means the Purchasing Key User is the field
owner. Other domains still can use it and have their own specific rules for it. However, it is the Purchasing Key
User role to make sure this field is used correctly and validate if there are conflicts among the different
domain's rules
SPECIAL MULTI VIEWS
In can however happen that no specific domain can be identified as the lead or main user of a field.
Let’s take for example, “MM/PP status (MARC-MMSTA)” which is in views: Purchasing, MRP1, Work scheduling,
Costing 1, Quality Management.
If no one can be clearly identified as the lead for that field, then we put it in a dummy view called “SPECIAL
multi views”. This is used to put all the fields which exists in different views and for which we can’t assign a
specific owner.
 Data Migration Material Master
Methodology Workshop
2ndstep: Regroup selection of all domains in a single document
Once this is done for each domain, the DC manager put all domains mappings in a single document.
It will show all the fields/domain dependencies and identify fields which will have conversion rules from
different domains (put the field owner first).
3rd step: Build the data conversion rules template with all the selected fields.
In the previous step, we established which fields of the Material Master will be use in SAP. Now we build the
data conversion rules template, which we will use to write the conversion rules.
There is one line for each field/type combination. Specify, for each field/type, which domain selected it. If more
than one domain selected the same field/type, put the name of all concerned domains (put the owner first)
4thstep: Get the rules from each domain, independently
Ask each domain to specify the conversion rules for all the fields they are concerned with. This is purposely
done independently for each domain, so that misunderstanding or conflicting rules between domains may be
put in evidence in the next step.
5thstep:Merge the rules from all domains.
Make a single document containing all the functional domain's rules and specify, for each rule, which domain
wrote it.
6thstep:Analyse the results and start building the Issues list.
Data Migration Material Master
Methodology Workshop
Data Migration Material Master
Methodology Workshop
Data Migration Material Master
Methodology Workshop
 Data Migration Material Master
Methodology Workshop
EXTRACT AND LOAD PROGRAMS
What to extract and how to proceed. If there is ambiguity or incomplete information in
the specs, solve them before you do any programming. This will prove to be a time
saver later.
TRANSFORMATION BETWEEN THE EXTRACTIONAND LOAD
Most data need transformation between the extraction from the Legacy System and
the load in SAP. These can be done at extraction time, as an intermediary step or at
load time. There is no good or wrong here and any combination is valid. What you
must avoid is to spread the transformation in too many places, which makes debugging
and finding the sources of issues more difficult. General preference is as follow:
• Cleansing and filters are applied at extraction
• Data transformations are made at load time.
• Exceptionally, for very complex transformations, it is done as an intermediary step
between the extraction and the load. However, try to avoid this as much as possible
 Data Migration Material Master
Methodology Workshop
CONCLUSION
The methodology itself is mainly a mix of good old common sense and management .
Each step is the foundation of the next one. Complete each step at 100% and the next
one will be easier. The result is a snowball effect, permitting you to gain more speed from
step to step. Not following this rule will also have a snowball effect, but in the opposite
direction, reaching a point where the conversion process becomes out of control.
Although it may sometimes look to others like you are taking the long route to get there,
remember that the objective is not to finish a specific step ASAP. The goal it is to
complete the whole process in the best time possible and to deliver a complete set of
Master Data, which will not need rework once in production.
The main challenge you will face it is to overcome:
• Pressure to show rapid results (any results)
• Tendencies to push forward issues so we can keep progressing
• Resistance to follow the versioning process and associated work in batch mode
• Refusal to slow down when the process begin to get out of hands.