Master Data Management in SAP APO | Part 1

June 5th, 2013 plan4demand
Master Data Leadership Exchange
presents:
The web event will begin momentarily
with your host:

Proven SAP Partner
 More than 500 successful SCP
engagements in the past decade.
 We’re known for driving measurable
results in tools that are adopted across
our client organizations.
 Our experts have a minimum of 10 years
supply chain experience.
 Our SAP team is deep in both technology
and supply chain planning expertise; have
managed multiple implementations; have
a functional specialty.
“Plan4Demand has consistently put
in extra effort to ensure our Griffin
plant consolidation and demand
planning projects were successful.”
-Scott Strickland, VP Information Systems
Black & Decker

1. Unit of Measure (UOM) - Why UOM needs to be defined, understood, and
common across your data
2. Data Definitions - What information & assumptions are used to create
Master and Transactional data?
3. Data Scrubbing – When should data scrubbing and cleansing be done?
4. Data Validation & Tools – How do you get business users involved with data
quality validation and how do you provide data exception tools to assist?
5. Data Latency – Why is Transactional data timing important?
6. Master Data Source – Where should master data should be pulled from?
7. Planning Data Storage – Where should scrubbed master / transactional
planning data be stored?
8. Data Maintenance – How can Users maintain?
9. Data Ownership – Who should own the process?
3

• While Master Data may seem like a jungle to be
successful you need to think of it as a garden instead.
• Easier to manage
• Tamed and pruned
• Tended to
4
a
*Plan4Demand is in no way an advocate of deforestation

1. Unit of Measure (UOM) - Why UOM needs to be defined,
understood, and common across your data
2. Data Definitions - What information & assumptions are used to
create Master and Transactional data?
3. Data Scrubbing – When should data scrubbing and cleansing
be done?
4. Data Validation & Tools – How do you get business users
involved with data quality validation and how do you provide
data exception tools to assist?
5

UOM needs to be defined, understood, and common across your data
Businesses deal with multiple units of measure (UOM) from raw materials, work in
processes, finished goods, and saleable goods.
From an APO Planning perspective, a common UOM is required to
communicate the operating plan across all business functions.
 Businesses typically have multiple units of measure for the products they sell,
distribute, procure, and manufacture
 Too many planning units of measure lead to inaccurate planning results
 Integrated SAP APO solutions are nullified by manually updated conversion tables
6

A base unit of measure (UOM) must be established
for APO Planning purposes
The unit of measure must be applicable from a sold to customer standpoint such
that projected business requirements can be passed along to all planning
functions.
 Usually the selling product UOM is used as the planning base unit of measure
 Establish a common base UOM for planning purposes
 If other business areas operate with a different UOM, conversions factors must be
maintained to tie back to the planning base unit of measure
7

APO Planning UOM failures
are symptoms of bigger issues
Example:
A Major CPG Company’s APO implementation
came to a stand still when multiple UOM
conversions took place with in the APO-SNP
planning engine
Questions To Ask:
 Why are so many UOM conversions
required ?
 Are we using the correct APO Application
for the desired planning function ?
 Are we maximizing the overall business
efficiency or a specific planning area
efficiency ?
Designing a Master Data Management
Solution is like planting a garden to
feed your APO Planning Solution
Keep the Master Data Garden
simple and easy to maintain
8

be done?
9

Understand what information and assumptions
are used to create master and transactional data
During many APO implementations, project teams are in such a hurry to pull
master and transactional data from ECC (or legacy applications) they fail to
clearly understand how the data is defined and IF the mapped data fully
meets the business requirements.
 One of the major reasons APO projects fail to go-live as planned is because master
and transactional data requirements were not clearly defined up front
 Each data element must have a clear definition of what characteristics are included
in the definition
 Project teams are too quick to locate an ECC field name by a key word instead of
locating the master / transactional data source
10

Approach APO data definition requirements like business requirements.
Clearly define the base data requirements (focus on what should be included and
excluded) map the data elements available (documenting all characteristics associated
with the data) and perform a GAP analysis between data requirements and data
available.
11
 Clearly document each data element required
to support your APO solution (baseline data
requirements)
 Once the APO data requirement source
mapping to ECC (or legacy application) is
complete, perform a thorough analysis on
source data definitions and characteristics
 Conduct a GAP analysis between the APO
baseline data requirements and available ECC
source data to determine data scrubbing effort

Questions to Ask
 What data characteristics are
required for APO Planning ?
 Is my APO data mapped to the ECC
data origin source ?
 What are all the data characteristics
of the ECC origin source data ?
When planning your Data Management
Garden (Solution), make sure you
select the plants that meet the needs
of your garden.
12
Example:
An Industrial Goods company was pulling Order
History to drive their APO-DP solution. After Go-
Live they noticed their forecasts were consistently
off by 1-2 periods. Turns out their Order History
was pulling Order Creation Date and not Customer
Requested Date
Data is not defined equally from business to
business: Details Matter!
Once you have selected your
“master data plants”,
understand each plant’s
(Data Set’s) characteristics
to ensure a bountiful garden

be done?
13

When in the Implementation Process did Data
Scrubbing Occur?
Answer on your screen – Select all that Apply
A. Before the Project Started
B. After Data Mapping was Completed
C. During Integration Testing
D. During UAT Testing
E. None of the Above
14

Allow plenty of time for data scrubbing and cleansing!
Often times “data scrubbing” or “data cleansing” activities are performed
multiple times on the same master / transactional data elements.
These additional scrubbing activities are reactive and unplanned actions that
eat into project delivery time.
 When data issues are discovered during testing activities, it usually means not
enough time was spent on clearly defining the APO data requirements
 Multiple data cleaning activities are time consuming, expensive, and waste valuable
project resources
 If the APO Project fails to allocate enough data scrubbing time during data
validation, project testing costs increase by 2x – 3x!
15

Do not rush through or over look the
Data Requirements / Data Validation APO Project stage.
This critical project stage creates a solid Master and Transactional Data
foundation for the APO Planning Solution.
16
 Data Scrubbing activities must be well planned
with a specific set of instructions
 Specific Data Cleansing actions are driven by
GAPs identified during the data requirements
process
 Data scrubbing is not complete until the APO
input data is verified and determined fit for use

Data Scrubbing requires detail instructions
driven by data GAP analysis
Keys to Success
 Develop robust data definitions with
business user input
 Document source data logic and
assumptions
 Document and develop test criteria for
all data scrubbing elements
 Create a robust data scrubbing
algorithm with verifiable results
The APO input “data garden”
requires weeding and attention to
achieve the desired results
APO data must be pristine to properly
support the high demands on the
Integrated Planning Solution
17

be done?
18

Get business users involved with data quality validation
Many APO Projects create a false sense of security during Data Validation.
Project teams either use an unqualified resource to sign-off on Data
Validation or fail to provide validation instructions and tools.
 APO Data Validation is not a rubber stamp process where someone reviews a
report, a spreadsheet of data, or a database file and then provides an “OK The
Data Looks Good”
 When APO teams fail to allocate enough data validation time, the burden is pushed
to integration / user acceptance testing
 In many cases, APO data validation is performed by someone who is not familiar
with the data and how it will be used to Demand or Supply Plan the business
19

A robust APO Data Validation testing strategy is required to successfully
deliver a reliable planning solution, on time, and on budget.
20
 Before APO Data Validation can begin, a
business planning resource must be held
responsible for validating the APO planning data
 By re-using the APO Master and Transactional
Date Requirements Definition documents, the
Validation Team can ensure testing scenarios
contain the appropriate data characteristics
 Repeat APO Data Validation and scrubbing
iterations until master and transactional data is
validated 100%

APO Data Validation starts during
implementation and continues through
the life of the APO Planning Solution
Keys to Success
 Develop robust data validation
methodology
 Re-use Data Requirements Definition
Document to script Validation
scenarios
 Re-use Data Scrubbing logs to assist
with Data Validation
 Cross Check Validation Results
 Establish ongoing automated
validation checks
APO data requires constant
monitoring and attention to
maintain quality beyond Go-Live
Data Validation is required to ensure the APO
input data garden is healthy and strong
21

Provide data exception tools to assist business users with data quality validation
22
 Many times APO Project teams do not
provide data validation tools for the
business users
 Business planners are left to use their own
personal skills, knowledge and expertise
to determine how to validate the APO
data provided by the project team
 In many cases, business users are provided
with a data dump and asked to validate
the data as they see fit
Another area where APO Projects fail to deliver is when proper Data Validation Tools are
not provided to validation team members. Either validation tools are not provided or
Testers are not properly trained to use data validation tools.

Data Validation Tools are enablers to the overall Data Validation Methodology
APO data validators must have proper Data Validation Tool training, access to the
base test data, and a place to document the results.
 In order to select the appropriate Data Validation Tools, clearly document the APO
Project Data Validation methodology strategy
 Next, ensure the business validators have access to the baseline and scrubbed data
 The validation team must be trained how to use the selected validation tools
 Finally, clearly define the acceptance criteria and documentation requirements for
validated data
23

Once the appropriate tool is chosen, it is
important to know how to use it
Selecting the right tool for the job
is only half of the solution
If you do not know how to use the tools
to tend to the APO data garden you will
do more harm than good
24
Keys to Success
There are many data validation tools
available, choose the one that best fits
your testing needs
 HPQC
 SQL Queries
 Access
 Excel

1. Unit of Measure (UOM): UOM needs to be defined, understood, and
common across your data
2. Data Definition: Understand what information and assumptions are
used to create master and transactional data
3. Data Scrubbing: Allow plenty of time for data scrubbing and
cleansing
4. Data Validation: Get business users involved with data quality
validation
5. Data Validation Tools: Provide data exception tools to assist business
users with data quality validation
25

If you use SAP to Plan… Think

SAP, R/3, mySAP, mySAP.com, SAP NetWeaver®, Duet®,
PartnerEdge, and other SAP products and services
mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP AG in
Germany and in several other countries all over the
world. All other product and service names mentioned
are the trademarks of their respective companies.
Plan4Demand is neither owned nor controlled by SAP.
Page 27

For Additional Information or a PDF Copy
Contact:
Jaime Reints
412.733.5011
jaime.reints@plan4demand.com

Master Data Management in SAP APO | Part 1

Recommandé

Recommandé

Contenu connexe

Plus de Plan4Demand

Plus de Plan4Demand (12)

Dernier

Dernier (20)

Master Data Management in SAP APO | Part 1