“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.