866.P4D.INFO | Plan4Demand.com | Info@plan4demand.com
Master Data is critical to successful advanced planning and optimization. Having a master data management strategy is just a start. HOW it gets to a point where it is ready for analytics is where most of the work needs to be done.
APO Expert, Jerry Sanderson, for Part 2 as he lays out the foundation for successful Master Data Management and highlights practical tips to weed through the big data jungle and grow for long-term success.
We’ll provide insights into:
5. Data Latency – Why Transactional data timing is important
6. Master Data Source – Where master data should be pulled from
7. Planning Data Storage – Where scrubbed master / transactional planning data be stored
8. Data Maintenance – How Users can maintain, simply
9. Data Ownership – Who should own the process
Check out this webinar on-demand at http://www.plan4demand.com/Video-Webinar-SAP-APO-Master-Data-Management-Tips
Talent Management research intelligence_13 paradigm shifts_20 March 2024.pdf
Master Data Management in SAP APO | Part 2
1. June 12th, 2013 plan4demand
Master Data Leadership Exchange
presents:
The web event will begin momentarily
with your host:
2. 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
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
3
a
*Plan4Demand is in no way an advocate of deforestation
4. 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?
4
5. Transactional data timing must be consistent across data streams
and honor any sequence dependencies
APO planning solutions are sensitive to transactional data load timing. When
key transactional data is loaded after nightly or weekend planning runs, the
APO Planning results are no longer accurate, resulting in Data Latency issues.
If the overnight APO net requirements planning run is executed before the new sales
orders are loaded into APO, the plan does not consider the lasted demand resulting
in as much as 24 hour demand latency issue
Any time transactional data loads are limited to daily or weekly increments, the
APO solution is subjected to potential data latency issues
When the APO Planning solution is complex with lots of information flowing in and
out of the system from outside systems, information timing and coordination becomes
critical to maintain plan synchronization
5
6. The best defense against potential transactional Data Latency issues is to
design multiple legacy data updates to APO.
This limits the APO solution exposure to data latency. However, the ultimate
goal is to have real time data updates between SAP-ECC and APO
The best defense against data latency issues is to secure APO transactional data in
real time via the CIF (Core Interface) from SAP ECC
Make sure to review key job run times, schedule start times and actual completion
times to ensure the design is feasible for collecting update information and
completing planning runs accordingly
Finally, establish contingency plans for getting data back in sync when needed
6
7. APO-DP requires timely updates of
causal data, future and historic sales
orders before the statistical forecast
models are run
APO-SNP requires timely updates to
the master supply planning data to
ensure the appropriate planning
rules are applied to the supply plan
APO-SNP requires timely inventory
updates to ensure the Supply and
Distribution Plans are providing the
right signals to the business
7
To keep your APO Data Garden healthy and
strong enough to serve your Planning needs,
timely watering and feeding is required
8. 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?
8
9. Do you feel your APO Master Data
is pulling from the correct Source?
Answer on your screen
A. Yes
B. No
C. Maybe?
9
10. Which of the following Sources is
APO Input Data pulled from?
(This includes Transactional & Master)
Answer on your screen – Select all that Apply
A. SAP-ECC
B. Non-ECC, Legacy, Other ERP
C. Custom Tables in SAP-ECC
D. Custom Tables in SAP-APO
E. No Clue!
10
11. Pull master data from the data mapping source to ensure clean data
Too many times during an APO solution review we find that master /
transactional data is not mapped to the primary data source. It is discovered
that the APO solution is pulling data from a secondary data source.
11
When master / transactional data is pulled from
areas other than the primary data source (where
data was originally created or initially stored) the
APO solution is at risk of having their data
compromised at any time
These issues usually arise post go-live when
secondary data modifications are made with out
realizing the APO solution is also pulling this data
for Planning
12. Always map APO master and transactional data inputs
to original source data where existing
This will ensure the APO solution remains robust and data risks are minimized
Use APO standard data mapping structures to protect your data source and APO
Plan integrity
Map all master and transactional data to the standard ECC data fields
When custom or modified master / transactional data is required to support the
APO solution, create a dedicated source location for APO use only
The objective is to create a APO protected source location that is not shared with any other
functional applications
12
13. If custom APO input data is required,
try to incorporate the data using the
designed ECC / APO interface structure
Utilize custom Z-tables in ECC as needed
Continue to maintain APO master data in ECC
Utilizes CIF for APO-SNP
Utilizes BI interfaces for APO-DP
Keys To Success
Designing a robust architecture is key for getting
the most out our your solution
The solution is robust enough to support the growth
of your business
13
APO-DP works best when APO input data is mapped to
target SAP-ECC data fields and design interfaces are used
14. 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?
14
15. Keep raw master / transactional data storage separate
from scrubbed master / transactional planning data
When APO Planning data is not stored in a separate location for the sole
use of APO, the data runs the risk of being modified, corrupted, or deleted
by non planning users.
APO planning master and transactional data is pulled from multiple business areas
like sales, marketing, finance, manufacturing, procurement, etc.
All parts of the business have ongoing process improvement and system change
activities taking place, resulting in system data and data processing changes
The APO planning team is not always aware or consulted to investigate the APO
solution impact when changes are made
15
16. When defining the APO Architecture Solution Strategy
there are two key types of APO master / transactional data
Common Data shared across APO and ECC
Should be mapped from the defined ECC data fields
If APO requires manipulation or customization of this data then this data should be staged
to maintain the changes required by APO
Custom (stand alone) Data used only by APO Planning not found in ECC
Often critical to the quality of the APO Demand and Supply Plans and must be stored in a
secure location to minimize the risk to the Plan
Once the input data has been transformed and stored, only net change new transactional
data must be transformed
16
17. APO-DP works best with a
dedicated data staging area where data
cleansing and modifications can be stored
once changes have been made
Data cleansing and modifications can be
stored once changes have been made
Outlier Corrections
Re-alignments
Historical Forecasts
Etc.
Now that you have taken the time
to build a dedicated “Data” garden
to support APO, protect the garden
from outside influences
17
18. 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?
18
19. What is your biggest Pain Point when it
comes to APO Master Data Maintenance?
Answer on your screen
A. Inaccuracy – Pulling from right source, but the
data is not maintained properly
B. Configuration – pulling from the wrong source
C. Accessibility/Authority Level – I know what the
data should look like but cannot change it
myself
D. Training – Feels like the wrong people/team
assigned to maintain due to lack business
knowledge or proper training
E. None - Our Master Data Maintenance is easy
and flawless!
19
20. Must be simplistic and easy for users to maintain
When APO data maintenance is overly complex, difficult to maintain, or
requires frequent user updates, the data is seldom correct and results in
poor APO Plans.
When designing an APO solution dependent on multiple and complex APO input
data fields that require diligent maintenance, the overall APO solution is doom to
fail
The APO architecture becomes overly complex and too sensitive to provide accurate
plans
When a good balance between data maintenance and usability is not maintained,
the planning results will degrade and planners will spend more time manually
overriding their APO Planning results
20
21. When designing the APO Planning solution, constantly challenge the design,
especially data maintenance inputs.
Always ask the question, “How much data maintenance is required for each
data field and determine what scenarios will drive data maintenance activities.”
During the data mapping and requirements definition phase, identify data
maintenance activities and quantify maintenance time estimates
Keep reviewing the data maintenance effort throughout the testing phases, especially
during UAT and Day in the Life (Parallel) Testing
Finally, make sure to review the data value add, to ensure the required data
maintenance is driving significant business benefit
21
22. 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?
22
23. Who “owns” the APO Master Data Management
responsibility within your Organization?
Answer on your screen – Select all that Apply
A. APO (SNP/DP) Planners
B. MDM Specialists
C. IT Department
D. Center of Excellence Team
E. Executive Team
23
24. Assign to the primary users of the planning data
When APO data maintenance is owned by areas other than the
responsible Planning team, conflicts of interest will arise around
timely maintenance updates.
When the APO DP forecast run is dependent on a custom master
data field maintained by a separate functional area, the accuracy of
the final forecast becomes dependent on custom master data updates
Because of the criticality of APO input data, only the planning team
responsible for the quality of the APO Plan will be focused on
ensuring data is updated timely
24
25. Assign APO input data ownership to the team
responsible for the quality of the APO Plan
The responsible APO Planning team will make sure the data is accurate and
updated prior to their planning runs.
When determining which APO Planning team should be responsible for input data
ownership, determine which team has the most to lose if the APO Plan is incorrect
To pass a final forecast from APO Demand Planning to Supply Network Planning, the forecast
must be disaggregated to a distribution center level for APO-SNP to generate a Master
Production Schedule and Distribution Requirements Plan
Demand Planners are focused on generating an accurate customer final forecast and Supply
Network Planners are focused on supplying products to distribution centers
Disaggregating the final forecast at the distribution center level is most critical for the APO-SNP
Planners in order to generate the best supply plan possible
Therefore, assign bill of distribution master data ownership to the APO-SNP team, because data
is more critical to the quality of the SNP Plan, even though the actual disaggregation occurs in
the APO-DP application
25
26. 26
a
*Plan4Demand is in no way an advocate of deforestation
Transform the Jungle into a Garden
27. 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
6. Data Latency: Transactional data timing must be consistent across data streams and honor
any sequence dependencies
7. Master Data Source: Pull master data from the data mapping source to ensure clean data
8. Planning Data Storage: Keep raw master/transactional data storage separate from
scrubbed master/transactional planning data
9. Data Maintenance: Must be simplistic and easy for users to maintain
10. Data Ownership: Assign to the primary users of the planning data
27
29. 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 29
30. For Additional Information or a PDF Copy
Contact:
Jaime Reints
412.733.5011
jaime.reints@plan4demand.com