Behind Every Great Planning System Is Bulletproof SIT and Integration

Sharing is Caring

“You don’t fail at go-live.
You fail silently during SIT — and discover it only at go-live.”

In every advanced planning implementation I’ve been a part of — especially in complex environments like FMCG, multi-plant networks, or multi-market operations — one pattern repeats itself:

The planning system never fails for technical reasons.
It fails because SIT and data integration are not taken seriously enough.

Everyone loves the solver demo.
Everyone gets excited about dashboards.
Everyone imagines the future state: scenario planning, digital twins, automated projections, decision intelligence.

But the real engine — the part that determines whether all of that will work or fall flat — is not the solver.

It is the data, and the pipeline that brings that data into the model.

A planning system is not like an ERP. It does not “own” the data. It may although be a stepping stone in improving data from ERP.
It is a consumer system, dependent on dozens of upstream truths:

  • Forecasts
  • BOMs
  • Routings
  • Material hierarchies
  • Inventory
  • Production orders
  • Purchase orders
  • Lane lead times
  • Sourcing priorities
  • Safety stock policies
  • Shelf-life rules
  • Network structure

If any one of these inputs is wrong, late, incomplete, or misinterpreted, the entire plan becomes unreliable.

This is why SIT (System Integration Testing) and data integration are the backbone — the spine — the central nervous system — of every planning implementation.

And yet, they are the most neglected phases.

This article is a brutally honest, experience-backed walkthrough of:

  • Why SIT matters even more than UAT
  • Why data logic is the only thing planners should care about during implementation
  • The specific mistakes we saw (and suffered from) in real projects
  • How to build a gold-standard SIT process
  • How to think about “data meaning” (not just data mapping)
  • The best practices every planning leader should enforce

Let’s get into it.

1. SIT Is Not About Testing the System — It’s About Testing the Organization

Most companies misunderstand SIT.

They assume SIT is:

  • A technical testing phase
  • A quality check before UAT
  • A step to confirm integrations run

This is wrong.

SIT is actually:

  • The first time the organization sees its own data through the logic of the new planning system
  • The first time hidden inconsistencies surface
  • The first time data definitions collide
  • The first time automated logic replaces human patchwork

During SIT, you are not testing the tool.

👉 You are testing the organization’s readiness to feed data to the tool.

And the difference is enormous.

A planning system is not a calculator.
You are not “running numbers.”
You are operating a digital twin whose entire worldview depends on the clarity and structure of your inputs.

SIT reveals that worldview — and its cracks.

2. SIT Always Reveals the Same Painful Truths

Across different implementations, the exact same themes show up during SIT.

Not sometimes — always.

Painful Truth #1:

Your ERP data is less consistent than you think

During SIT, you discover:

  • MOQs differ across locations
  • Lead times differ across plants
  • Shelf life is entered incorrectly for certain SKUs
  • Material statuses do not reflect reality
  • BOM components don’t match manufacturing usage
  • Routings are incomplete
  • Lot size constraints are missing

Planners rarely see these issues because they work around them manually.

A planning system can’t.

Painful Truth #2:

Data “shapes” vary every day

One day an attribute is 30 characters long.
Next day, a special character appears.
Another day, the column order changes.

Excel doesn’t complain.
Planning systems do.

Painful Truth #3:

Different teams use the same terms differently

Some examples from real projects:

  • “On-hand” means usable stock for planners, but total stock including blocked for ERP.
  • “Transit time” means shipment lead time for logistics, but customer promise time for sales.
  • “Open orders” means unfulfilled POs for procurement but customer commitments for demand planning.
  • “Capacity” means machine hours for manufacturing but FTL load for logistics.

SIT forces these differences into the light.

Painful Truth #4:

SIT shows that logic and data definitions are not aligned

Companies often enter SIT without answering basic but critical questions like:

  • What does “expiry date” mean in planning — MRP expiry or shippable expiry?
  • If ERP gives production orders at sub-SKU level, should planning aggregate them?
  • If a BOM has multiple alternates, which one should planning prefer?
  • Does “in-transit” mean shipped or dispatched?
  • What if ERP sends a future-dated stock posting — should planning consider it?

If these are left vague, SIT becomes chaos.

3. The Most Underrated Part of SIT: Building “Data Meaning” Not Just Mapping Fields

This is the section planners never get taught but desperately need:
Data mapping is not about matching fields — it’s about defining what the data means.

Let me give some practical, real-world examples.

Example 1: On-hand inventory

ERP sends:

Material   Location   Quantity   Status
SHAM001    PLANT-A       100     Unrestricted
SHAM001    PLANT-A        20     Blocked

In planning, the question is:

  • Do we count blocked stock or not?
  • If not, do we need a separate blocked field?
  • Should blocked stock contribute to expiry risk?
  • Should DRP consider blocked stock when calculating net available?

This is logic, not mapping.

Example 2: Production Orders

ERP may send:

PO1234   SHAM001.01   Qty 500   Due 25 Jan

But planning works at item level, not sub-SKU.

So what does the “.01” mean?

  • Is sub-SKU relevant?
  • Should we aggregate automatically?
  • Should we store both sub-SKU and item?
  • Will aggregating distort expiry profiles?

This isn’t a mapping issue.
It’s a business rule disguised as data.

Example 3: Lead Times

ERP fields:

  • GR Processing Time
  • Planned Delivery Time
  • Transportation Time
  • Handling Time
  • Quality Inspection Time

Which one should planning use?

In many cases:

  • Logistics assumes “planned delivery time”
  • Planning assumes “transportation time”
  • ERP users maintain “GR time” as a buffer
  • Sales expects “customer promise time”

SIT is where the organization realizes it never aligned on which lead-time field is the source of truth.

And until you define that truth, no solver logic will work properly.

Example 4: Shelf Life

ERP might send:

  • Total shelf life: 365 days
  • Minimum remaining shelf life at dispatch: 60 days

Planning must interpret:

  • Should it use total shelf life to block expired stock?
  • Or the minimum remaining shelf life to trigger allocations?
  • Should slow-moving stock be rebalanced earlier?

Different planning teams interpret shelf life differently.
If SIT doesn’t enforce a unified definition, planning becomes inconsistent.

Example 5: Customer Priority

ERP may not even have a field for customer priority.
Sales might maintain it offline.
DRP might need it for prioritization.
Finance might not use it at all.

So SIT must decide:

  • Where should the priority live?
  • How does planning consume it?
  • How often should it refresh?
  • Who owns updates? Marketing or sales?

This is data meaning, not mapping.

4. The Real Job of SIT: Aligning Business Logic Hidden Beneath Data Fields

In every planning implementation, we eventually realize:

👉 Data fields are symptoms.
Business logic is the disease.

It is not enough to say:

  • “Map field X to field Y.”

We must answer:

  • “What does field X represent in the business process?”
  • “How does planning interpret it?”
  • “How do planners transform this value manually today?”
  • “Does this field require cleansing?”
  • “Does it need transformation logic?”

SIT forces these conversations to happen — conversations that, frankly, should have happened years earlier.

Some examples of logic that must be aligned during SIT:

  • Should expired stock still count towards inventory norms?
  • Should demand be netted by open orders or allocations?
  • Should the solver consider subcontractors?
  • Should partial trucks in DRP be allowed?
  • Should MOQ logic override safety stock?
  • Should the solver prefer direct plant-to-CFA lanes or go through RWH first?
  • Should DRP respect customer class priority or demand type priority?

These are business decisions.
But they surface only when data meets the solver during SIT.

5. Why Most SIT Failures Are Not Technical — They Are Behavioral

A secret no one says out loud:

👉 Most SIT failures come from human habits — not system defects.

Here are the behavioral truths we uncovered:

1. Planners trust Excel, not integration

Because Excel shows exactly what they entered.
Integration shows exactly what ERP thinks happened.

2. People hide data inconsistencies

Legacy workarounds break in automated models — and some stakeholders resist having them exposed.

3. No one wants to own bad data

SIT forces data ownership.
And ownership is uncomfortable.

4. Business teams underestimate the time needed for SIT

They treat it like “IT work” and join too late.

5. Leadership underestimates the consequences

They assume the system will magically “adjust” to bad data.

6. Everyone wants perfect outputs but ignores input quality

Inputs are boring.
Outputs are glamorous.
SIT reverses this equation.

6. The 10 Best Practices for Rock-Solid SIT (Expanded + Example-Based)

These are NOT theoretical — they come from experience.

1. Freeze a Unified Data Dictionary Before SIT Begins

Define what each data field means across departments.

For example:

  • “On-hand stock” = unrestricted + QA released
  • “Transit time” = shipping time + unloading time
  • “Open orders” = only confirmed orders, not pending allocations

If these definitions are not frozen, SIT becomes meaningless.

2. Test with Real, Dirty, Imperfect Data

Instead of using sanitized sample files, use:

  • Peak season data
  • Historical promotions
  • High-churn categories
  • Master data with nulls

If SIT does not break during dirty data testing, it never will.

3. Build an Automated Validation Layer

Example validations:

  • Missing SKU–location combinations
  • Negative stock
  • Zero lead times
  • BOMs missing components
  • Expired inventory without expiry flags
  • Duplicate transaction IDs

This reduces SIT firefighting drastically.

4. Create a SIT Control Tower Dashboard

Your SIT dashboard should show:

  • % of files received
  • File size variations
  • Number of validation failures
  • Lag time between ERP → Integration → Planning system
  • Error trends over time

This visualizes reliability.

5. Define Clear Ownership for Every Data Field

One person should own:

  • SKU master
  • Location master
  • BOM master
  • Category mapping
  • Safety stock norms
  • Lead times
  • Customer priority

If everything belongs to “everyone,” nothing gets fixed.

6. Conduct Cross-Functional SIT Daily Standups

Agenda:

  • What data failed yesterday?
  • What logic didn’t map?
  • What is blocking today’s run?
  • Which mapping assumptions broke?
  • Who needs to fix what?

This accelerates alignment.

7. Run Multiple Full Cycles of SIT (Not One)

One SIT cycle reveals issues.
Two SIT cycles confirm fixes.
Three SIT cycles stabilize integration.

Skipping SIT Round 2 guarantees post–go-live chaos.

8. Train Planners on How to Validate Inputs BEFORE the Solver Runs

Planners must learn:

  • How to review input dashboards
  • How to interpret warnings
  • How to check data freshness
  • How to compare ERP vs planning
  • How to flag anomalies

This builds adoption.

9. Start UAT ONLY After SIT Is Stable

UAT should test:

  • Process logic
  • User flows
  • Decision-making effectiveness
  • Practical usability

UAT should NOT test:

  • Missing data
  • Integration errors
  • Dirty master data

Do not mix the two phases.

10. Document Every Logic Decision — Not Just Mapping

This is the most important point.

Every mapping decision should be accompanied by a logic note, e.g.:

Mapping:
ERP field “Planned Delivery Time” → Transit Time

Logic:
Logistics team reviewed and confirmed that “Planned Delivery Time” reflects combined shipping + receiving times. GR processing time is excluded because it is redundant for planning.

This avoids ambiguity later.

7. The Final Word: Planning Success Is Not About Algorithms — It’s About Truth

After months of working through integrations, data mapping, business logic alignment, and painful SIT cycles, one truth stands out above all:

You don’t go live when the UI works.
You go live when the data works.

And data only works when:

  • Definitions are clear
  • Ownership is assigned
  • Logic is aligned
  • Integrations are reliable
  • SIT is thorough
  • Planners trust the inputs

When your data is right, the system becomes intelligent.
When your data is wrong, the system becomes embarrassing.

SIT is not a technical milestone.
It is an organizational maturity milestone.

It is where:

  • truth is exposed
  • definitions are negotiated
  • governance is born
  • trust is built
  • confidence is earned
  • planning becomes real

If you get SIT right, everything else flows smoothly:
scenario planning, solver stability, DRP logic, PP–DRP handshakes, adoption, and planner confidence.

If you get SIT wrong, nothing else works — not even the best AI.

SIT + Data Integration = the real heart of digital planning.
Everything else is just optics.


Sharing is Caring

Leave a Comment

Your email address will not be published. Required fields are marked *