There’s a hard truth about master data preparation, that almost no one tells companies before they implement an advanced planning tool like o9, Kinaxis, SAP IBP, or Blue Yonder:
Your SAP master data is NOT your planning master data.
And if you assume it is, your entire APS program is at risk.
On paper, SAP (or any ERP) contains all the master data needed for planning:
- Materials
- Locations
- BOM
- Routing
- Lead times
- Customer data
- Vendor data
- Transportation lanes
But in reality, ERP master data is not sufficient for a constraint-based or scenario-driven planning engine.
ERP master data is designed for execution.
APS master data is designed for decision-making.
They are not the same.
The Hidden Master Data Layer: Why APS Implementations Fail When Companies Don’t Build “Planning Master Data”
The fact that there is a master data layer beyond ERP is hard to understand in the begining for many companies. And the dangerous part is this:
Most of the data APS actually needs is not sitting in SAP — it is sitting in planners’ heads, in Excel files, in tribal workarounds, in SharePoint folders, and in unspoken “business logic.”
This article explains:
- What new planning master data APS requires
- Why SAP data alone cannot support advanced planning
- The most common blind spots and pitfalls
- How companies should prepare
- How planners’ roles must evolve to steward this new data layer
Based on firsthand experience, this is the truth companies need before beginning any APS journey.
The Myth: “Our SAP Master Data Is Clean, So Planning Will Work.”
The Reality: APS Exposes Hidden Chaos SAP Never Had to Deal With.**
ERP systems like SAP are built for transactional accuracy, compliance, and execution.
They assume:
- Deterministic behavior
- Clean, hierarchical structures
- Stable lead times
- Static routings
- Fixed sourcing
But advanced planning systems operate differently. They need:
- Real constraints
- Real alternatives
- Real priorities
- Real capacity fluctuations
- Real network behavior
- Real what-if flexibility
As soon as APS ingests data, it immediately reveals the truth:
**Your business has two data sets:
- the one in SAP
- and the one planners actually use to run the business.**
Here’s what APS exposes almost instantly.
The “Alternative Master Data” Planners Use (That SAP Knows Nothing About)
During every APS implementation, we find a second universe of master data — never documented, never governed, but absolutely critical to planning.
It exists in:
- personal Excel files
- macros that only one planner understands
- tribal knowledge (“we don’t ever send this SKU through that plant”)
- undocumented lane preferences
- manual adjustments
- offline DRP redeployment rules
- customer or region-specific exceptions
Companies never realize how critical this hidden layer is until APS asks for it.
Here’s what APS projects almost always uncover:
DRP Network: The Hidden Chaos Layer That APS Forces You to Confront
This is the BIG one — the graveyard of planning transformations.
Every APS project uncovers:
1) Lanes in SAP that are technically “open” but never used
Because planners know they don’t work in reality.
SAP doesn’t know that — APS will use them unless told otherwise.
2) Lanes that planners rely on but are missing from SAP
Because they were temporary workarounds that became permanent “shadow lanes.”
3) Incorrect or unrealistic lead times
We’ve seen this repeatedly:
- SAP lead times: 1 day
- Actual movement: 3–5 days
- Planning expectation: “we buffer manually in Excel”
APS cannot buffer magically. You must tell it the truth.
4) Lane priorities that exist only in people’s minds
Ask planners: “Why do we source this SKU from Plant A and not Plant B?”
They answer: “That’s just how we do it.”
APS asks: “Where is this rule documented?”
Silence.
5) Lanes defined at a granularity that is too generic
E.g., SAP has a lead time for the route but not:
- seasonality
- carrier variability
- multi-leg routes
- capacity variability
- service-level asymmetry
APS requires explicit logic — not tribal nuance.
Lead Times: The Silent Killer of APS Logic
Every APS project suffers from lead-time shocks.
Because planners don’t use SAP lead times.
They use real lead times — the ones they built and refined mentally or in Excel.
We’ve seen:
- Inbound lead times for critical RM off by 40–70%
- Lane lead times missing unloading time
- Interplant transfer lead times not accounting for vehicle shortages
- Customer ship-to lead times totally misaligned with service targets
- Promotional or seasonal variability never reflected in SAP
APS behaves mathematically.
If SAP says:
“Transit time = 2 days,”
APS assumes 2 days.
If reality says 5 days,
APS will create a plan that looks wrong, late, or even impossible.
But APS is simply following the data you gave it.
Lane Priorities: Where APS and Reality Collide
Lane priorities are rarely maintained in SAP.
But in planning, they are everything.
Ask planners:
“Why does Region West get supply from Plant X unless Plant X is overloaded?”
They respond:
“That’s how we’ve always done it.”
APS cannot work with oral tradition.
It needs explicit logic:
- Primary lanes
- Backup lanes
- Proportional splits
- Season-specific routing
- Cost vs service trade-offs
- Penalty weights
- Alternative flows
If this is not defined, APS will choose paths that appear random — but are mathematically optimal given incomplete data.
We once saw APS sending 30% of SKUs through a lane no one had used for five years.
Turned out that lane had a lower cost in SAP and no constraints defined.
APS wasn’t wrong.
The data was incomplete.
The New Master Data Layer: “Planning Master Data”
APS introduces a new class of master data that your ERP won’t manage.
This includes:
1. Feasible Planning Network (vs. Theoretical Network)
APS needs the real network you use — not the one SAP believes exists.
2. True Lead Times (vs. SAP Lead Times)
Including variability, operational delays, seasonality.
3. Prioritization Logic
- Customer class
- Region class
- Channel rules
- Demand types
- Exceptions
None of this is in SAP.
4. Solver-Relevant Parameters
- Penalty weights
- Service prioritization
- Max/min inventory levels
- Build-ahead logic
- Allocation sequencing
APS cannot guess these.
They must be built consciously.
5. Constraint Calendars
- Line-level shutdown
- Shift efficiency
- Plant holidays
- Resource-level exceptions
These are typically missing from ERP.
6. Scenario Framework Rules
- What-if inputs
- Parameter switches
- Constraint toggles
- Response playbooks
This is APS-native master data.
5 Biggest Blindspots Companies Face
Based on real-life implementations, here are the blindspots that hurt the most.
Blindspot 1: “SAP will be the golden source for everything.”
It won’t.
APS will need more than SAP has ever captured.
Blindspot 2: “Our planners know the master data, so we don’t need to document it.”
Planners know it — but don’t formalize it.
When APS asks for:
- lane priority logic
- norm exception rules
- substitution pathways
- sourcing shifts
Planners often say:
“It depends.”
APS doesn’t understand “it depends.”
Blindspot 3: “Network updates are rare.”
Actually, networks evolve weekly:
- lane closures
- lane reliability changes
- new pack sizes
- BOM shifts
- vendor performance changes
APS needs real-time updates or your plan becomes stale.
Blindspot 4: “Lead time is static.”
This is false in 100% of real ecosystems.
Lead time is:
- geographical
- logistical
- seasonal
- vendor-dependent
- mode-dependent
- capacity-dependent
APS cannot function with one-size-fits-all lead time.
Blindspot 5: “The system will figure out business logic automatically.”
APS is not AI magic.
It is a mathematical engine.
It mirrors only the rules you give it —
not the rules your organization assumes it follows.
The Pitfalls When Companies Don’t Prepare Planning Master Data
Here’s what goes wrong (and we’ve seen all of this):
Pitfall 1: APS Recommendations Look “Wrong”
Because the data guiding it is incomplete.
Pitfall 2: Planners Reject the Model
“Why is it planning through this lane?”
Because it thinks the lane is open, cheap, and unconstrained.
Pitfall 3: Adoption collapses
If APS outputs surprise planners, trust collapses in days.
Pitfall 4: Rework explodes
Teams create Excel “patches” — the beginning of APS decay.
Pitfall 5: Control Tower becomes unusable
Control Tower gets fed untrustworthy from APS. Any wrong signals will make it unusable.
Pitfall 6: The organization mistakenly blames the tool
When the real issue is planning master data readiness.
The Organizational Shift: New Roles Needed to Manage Planning Master Data
A modern planning organization lives or dies by planning master data.
The change management for a new APS is big and demands new roles — not old ones stretched thin.
Here are the roles leading companies are adopting.
1. Planning Data Steward
Owns:
- lane priorities
- sourcing rules
- MTO/MTS parameters
- attribute hierarchies
This role replaces “Excel intuition” with governance.
2. Constraint Librarian
Yes — a real role.
Manages:
- resource calendars
- bottleneck metadata
- constraint versions
- seasonal capacity switches
No planner used to manage this officially — APS needs it.
3. Network Data Owner
Owns:
- BOD
- feasible lanes
- lane attributes
- effective dates
- real lead times
This role didn’t exist before APS.
It must now.
4. Scenario Framework Lead
Defines:
- what-if templates
- macro scenarios
- disruption playbooks
- parameter toggles
The Control Tower heavily relies on this.
5. Planner as Data Curator
The job evolves from:
Old:
“Run numbers in Excel.”
New:
“Shape the master data that runs the numbers.”
APS frees planners from manual firefighting —
so they can finally do the intellectual work of modeling the truth of the business.
How Companies Should Prepare for Planning Master Data: A Practical Checklist
Here is the APS readiness checklist every company should follow:
1. Identify the hidden Excel-based business rules.
Convert them into governed data sets.
2. Build a Planning Master Data Model.
Different from SAP’s — richer and more dynamic.
3. Assign ownership for every data domain.
If everyone owns planning master data, no one does.
4. Build a data governance council.
APS must have monthly governance.
5. Audit your network.
Clean, validate, rationalize, document.
6. Challenge your lead time assumptions.
Test them against reality.
7. Convert heuristics into rules.
If planners do it repeatedly, it must be parameterized.
8. Communicate the shift.
Planners will spend less time reconciling, more time shaping logic.
Final Word: APS Success Is Not About Technology — It Is About Planning Master Data Maturity
The success of any APS — o9, Kinaxis, SAP IBP, BY, anything — depends not on code, not on UI, not on the solver, not on dashboards.
It depends on one thing:
Whether your organization can define, govern, and own “planning master data” — the data that actually drives decisions.
ERP master data is not enough.
Excel tribal logic is not scalable.
APS requires a formalized brain — and that brain is planning master data.
Companies that understand this build planning systems that run for a decade.
Companies that ignore it spend a decade fixing planning.
This is the truth no one tells you.
But APS will reveal it anyway — brutally and fast.