The Illusion of Stability
At AutoForge Global (name and details changed to protect identities), a multi-plant automotive components manufacturer running high-volume stamping, machining, and final assembly across Europe and Asia, the SAP S/4HANA programme looked stable by every conventional measure. PP/DS heuristics were generating feasible schedules, MRP Live runs were completing inside the batch window, PMR creation from PP into EWM staging looked clean, MES confirmations were flowing back into CO11N, and FI/CO variance reports showed no dramatic surprises. Hypercare ticket volumes were low, pilot plants were reporting acceptable OEE, and the SI had already started using the phrase everyone loves to hear. “The system has stabilised.”
That phrase is dangerous because it often means the system has behaved well under conditions that are too polite to be useful. A factory does not live inside polite conditions. It lives inside material substitutions, line stoppages, shift changes, asynchronous MES updates, backflush reversals, scrap spikes, urgent customer pull-ins, and overloaded MRP controllers trying to reconcile what the plan said with what the shop floor actually did. In other words, stability is not the absence of visible defects. Stability is the ability of the enterprise system to remain coherent when real manufacturing behaves like manufacturing.
What Stability Actually Means
In SAP terms, system stability in a high-volume manufacturing landscape is not just application uptime, successful background jobs, or clean ST22 and SMQ2 logs. It means the integrity of the plan-to-produce and procure-to-produce loops holds under concurrency and variability. MRP Live must generate relevant procurement and production proposals without distorting supply priorities. PP/DS sequencing must remain executable when capacity assumptions meet real resource constraints. EWM staging must reflect the same material reality that production consumes. MES confirmations, yield postings, scrap declarations, and backflush movements must land with the right timing, quantity, batch, and cost consequence. FI/CO must then inherit that truth, not some cosmetically corrected version of it.
Now let us translate that into normal business language. The system “holds” only if the factory can trust it while the day is going badly. If a line goes down, if one plant steals supply from another, if a substitute component is introduced, if operators confirm late, or if inventory is physically in one place and logically in another, the system should still help the business make good decisions rather than multiplying confusion. If every disruption forces planners into spreadsheets, warehouse teams into manual overrides, and finance into after-the-fact reconciliation, then the system was never stable. It was merely calm.
Where the Hidden Instability Lives
At AutoForge, the apparent calm broke during a quarter-end production surge driven by customer pull-ins and delayed upstream supply recovery. MRP Live completed on time, but the concurrency profile changed dramatically once multiple plants began re-running planning, re-prioritising component allocations, and releasing orders in overlapping windows. PMR generation into EWM staging started lagging just enough to remain technically successful while operationally becoming unreliable. MES confirmations arrived late in bursts rather than in the smoother sequence seen during testing. Backflush consumption posted against the order, but with timing gaps that created phantom WIP, stock drift in PSA staging areas, and misleading availability signals for downstream orders.
This is where SAP jargon can seduce the wrong people. “The CO11N posting is successful.” “The PMR got created.” “The HANA job completed without dump.” Fine. Lovely. But in Lydian language, this may simply mean the system recorded a sequence of technically valid events that no longer represented the live factory. If EWM thinks a component was staged, production thinks it was consumed, MES thinks the yield was posted, and finance thinks variance is within threshold, but the planner still cannot answer whether Plant B can build tomorrow’s order without stealing stock from Plant A, then your system has not held. It has merely produced documentation for confusion.
The Moment You Know
The strongest sign that an enterprise system will not hold is not a crash. It is the emergence of soft distrust. The scheduler starts calling the shop supervisor instead of trusting PP/DS. The warehouse stops relying on EWM staging signals and sends someone to physically check bins. The production controller exports data before accepting variance reports. Finance delays settlement because the inventory story feels too neat. These are not user-training issues. These are behavioural indicators that the digital model and the operational model are diverging.
Leadership usually misses this because dashboards stay respectable for longer than the truth does. Fiori tiles can show acceptable OEE, on-time MRP completion, low critical-ticket counts, and manageable exception volumes. None of that proves resilience. A system holds when the enterprise can absorb stress without losing coherence across planning, execution, inventory, and financial consequence. That requires production-volume validation, concurrency testing, integration monitoring, drift controls, and an honest view of how real plants misbehave when incentives, urgency, and material constraints collide. In Lydian speak, if the system only works when everyone is on their best behaviour, then it does not work.
