Why data is almost never the real problem

Take a common shop-floor case: a supplier lead time of 21 days, entered into the system three years ago. For the past year, that same supplier has actually been delivering in 35 days — but no one touched the parameter. The result: the APS keeps planning against a reality that no longer exists, produces dates no one can hit, and the team ends up padding everything by hand because they've stopped trusting the system.

It's the kind of situation that almost always leads to the same conclusion:

"Our planning doesn't work because our data isn't good."

That's sometimes true. But it's usually not the whole story.

An APS can't work miracles: feed it bad data and it will produce a bad plan. Lead times, capacities, schedules, inventory, bills of materials, and planning parameters all need to represent reality closely enough for the output to mean anything.

But the real problem is often somewhere else: how is that data actually maintained?

Correct data today can be wrong tomorrow

Take a 5-day manufacturing lead time. It can be perfectly accurate the day it's set. But what happens if demand increases; a machine becomes a bottleneck; changeover times grow; a supplier becomes less reliable; the team changes; a new quality constraint appears?

If parameters are only reviewed once a year, the system inevitably ends up planning against a reality that no longer exists. An annual update isn't necessarily a sign of rigor. It can be a symptom of a process that isn't connected closely enough to operations.

Critical data should evolve almost in real time as reality changes. That's exactly what an APS like DELMIA Ortems enables, once properly connected to the ERP and to operations: detecting the gap and triggering the correction, instead of waiting for the annual review.

Why data goes stale

If a supplier lead time is consistently missed, why keep the old number? If a machine's real capacity regularly differs from its theoretical capacity, why does the system keep using the wrong value? If actual inventory keeps diverging from system inventory, why doesn't the process allow for a quick correction?

These are questions of process, ownership, and operational discipline — not just of systems.

Who owns the data? Who detects that it no longer reflects reality? Who updates it? And above all, when?

Beware of "buffers"

Faced with imperfect data, some organizations pad safety margins everywhere: a 10-day lead time becomes 15, a 100-hour capacity drops to 80, safety stock keeps growing, a transport lead time gets inflated "just to be safe."

That can protect the plan against some uncertainty. But there's a limit. Protect the system against uncertainty too aggressively, and you end up planning for a reality that doesn't exist. The plan looks more robust, but it's actually less optimal — you build up inventory, stretch out lead times, create unused capacity, and lose optimization opportunities.

An APS needs to work with the best available representation of reality, not with a reality artificially inflated to compensate for weak data.

Closing the gap between the system and reality

Data quality isn't a one-time IT project. It should be a built-in feature of the planning process. When reality changes, the data needs to be able to change quickly. When actual performance drifts from the parameters, the system needs to be able to catch it. When parameters change, planners need to understand why.

That loop is what makes an APS genuinely effective: reality feeds the data, the data feeds the plan, the plan drives execution, execution gets measured, and the measurement adjusts the data — then the cycle starts again. The faster that loop runs, the more the plan stays representative of what's actually happening on the floor.

Before blaming the ERP or the APS

Next time someone says "our data isn't good enough to use an APS," that's worth taking seriously. But it's also worth asking a second question: why aren't we able to keep our data representative of reality?

A good APS with bad data will produce a bad plan. But an excellent data-management process paired with a poorly used system will also produce bad results. The right goal isn't perfect data — it's data that reflects reality quickly enough to support good decisions.

And that's not just an IT problem. It's a business problem.

Does this sound familiar? The good news is that an honest diagnostic of your data lifecycle usually takes a few weeks, not months. At Stragmatic, it's often the first thing we look at before we even talk about implementation — because an APS starved of good data will never fix a process problem.