# Data Foundations

Every IBP implementation hits the same question early on: "Do we have the data to do this?" The answer is almost always "yes, enough to start" — but knowing what "enough" means requires a clear view of what data IBP actually needs.

This page lays out the data requirements in three tiers, from Day 1 essentials through advanced maturity, and addresses the granularity, frequency, and quality questions that trip up most implementations.

---

# What data does IBP need?

Not everything at once. Think of data requirements in three tiers that map to implementation maturity:

# Tier 1 — Must-Have (Day 1)

These are non-negotiable for running even a basic IBP cycle:

• Historical shipments or sales — 12-24 months minimum, at product family level. This drives the statistical baseline forecast.
• Product hierarchy — How items roll up from SKU to family to category. Doesn't need to be perfect, but must be agreed upon.
• Customer hierarchy — At least channel or segment level for demand segmentation.
• Basic capacity — Hours or units per period per plant or line. Even rough estimates enable meaningful supply/demand balancing.

# Tier 2 — Should-Have (within 3 months)

These data sets improve plan quality and enable more meaningful discussions:

• Bill of materials (BOM) — Component dependencies for make-to-stock and assemble-to-order products.
• Lead times — Procurement, manufacturing, and distribution lead times by item or family.
• Inventory positions — Current on-hand, in-transit, and committed stock by location.
• Cost data — Standard costs at minimum; purchase prices and freight costs for better financial projections.
• Open orders and backlog — Current demand pipeline for the near-term horizon.

# Tier 3 — Nice-to-Have (maturity)

These distinguish advanced IBP implementations:

• POS / point-of-sale data — Enables demand sensing and sell-through visibility.
• Market and competitor data — External signals for market-driven demand shaping.
• Supplier capacity data — Constraint visibility beyond your own four walls.
• Detailed routings — Work center-level capacity for CRP-level planning.
• Promotional lift models — Quantified promotional impact for demand planning accuracy.

---

# Data granularity: what level should you plan at?

Granularity is one of the most consequential decisions in IBP design. Plan too high and you miss important signals. Plan too low and you drown in noise.

The rule of thumb: start at the level where decisions are made. If your supply review makes decisions at the plant level, plan at the plant level. Don't build a SKU-location plan if nobody uses it for decisions.

---

# Data frequency: how often should data refresh?

The monthly IBP cycle sets the minimum cadence. Most organizations refresh data in the first week of the month, run the statistical forecast in week 1, and enter the demand review in week 2 with a current baseline. See Planning Horizons for how the IBP calendar drives data timing.

---

# Data quality: common issues and how to address them

Bad data doesn't just produce bad plans — it erodes trust in the process. These are the issues that surface most often:

# Missing history

Causes: New products with no demand history, acquisitions bringing incompatible data, system migrations that truncated history.

What to do:

• For new products, use analogous item history or market sizing estimates and flag the forecast as judgmental.
• For acquisitions, map legacy data to the new hierarchy even if imperfect — directional history beats no history.
• For migrations, export history from the old system before cutover. If that ship has sailed, reconstruct from financial records.

# Dirty master data

Causes: Duplicate items created across plants, incorrect hierarchy assignments, orphaned SKUs still generating demand signals.

What to do:

• Run a deduplication exercise before the first IBP cycle.
• Assign hierarchy ownership to product management and enforce a change process.
• Archive or flag discontinued items so they don't pollute forecasts.
• See Master Data for Planning for governance fundamentals.

# Inconsistent units

Causes: Revenue tracked in different currencies across regions, volumes in cases vs. eaches vs. kilograms, capacity in hours vs. units.

What to do:

• Define the IBP planning unit of measure for each data domain and convert at the source.
• Revenue: plan in a single reporting currency; hold FX assumptions centrally.
• Volume: pick one primary UoM per product family and convert consistently.

---

# Data readiness checklist

Use this checklist when preparing for an IBP implementation or diagnosing why the process isn't gaining traction:

• 12-24 months of demand history available and loaded
• Product hierarchy defined and agreed across functions
• Customer hierarchy defined (at least channel/segment level)
• Capacity data available at the planning level (plant or line)
• Data owner identified for each domain (product, customer, supplier, cost)
• Data refresh process defined (who loads what, by when, each cycle)
• Known data quality issues documented with remediation plan
• Planning unit of measure agreed for volume, revenue, and capacity
• Historical outliers identified and cleansed or flagged

---

# Further Reading

• Master Data for Planning — The reference data elements that support IBP and how to structure them.
• Planning Horizons — How data granularity and refresh frequency connect to planning timeframes.
• Demand Planning — Where demand data feeds into the planning process.