The Week After the Celebration
At an Australian aviation maintenance company (names and operating details changed to protect identities), the SAP S/4HANA go-live was treated as a success. The board had seen the usual signs of reassurance before approval. UAT completion was above 95%, integration status was reported green, cutover tasks were signed off, and executive demos showed a complete maintenance flow from work order to parts issue to settlement. The implementation partner declared the transition stable, and the leadership team moved from programme governance to hypercare mode with the confidence that the difficult part was over.
The difficult part had not even begun. Within the second week, the company’s Perth base was already dealing with grounded aircraft, delayed maintenance releases, and a finance team that could not reconcile the operational consequences with what SAP was recording. In the board deck, go-live had been a milestone. In the hangar, it had become an exposure event.
What the System Had Proven
From a SAP programme standpoint, the design looked sound. PM work orders were created correctly, MM reservations were generated, EWM stock was visible by bin, and FI postings flowed through settlement logic in line with the configured design. Attachments for maintenance certificates had been migrated, integrations with the legacy MRO application and warehouse systems had passed interface testing, and role-based workflows appeared stable in pre-go-live validation.
In SAP language, this meant that transactional logic had been proven in controlled scenarios. PM could talk to MM, MM could trigger warehouse movements, and settlement to FI behaved correctly in test conditions.
In plain business English, the software had been taught how to behave during rehearsal.
What Happened in Real Operations
Reality arrived with volume, urgency, and weather. A cyclone-related surge in unscheduled maintenance activity pushed up parts demand across multiple sites at once. Engineers created urgent maintenance notifications, planners converted them into work orders, and stores teams attempted to reserve rotables and consumables against those orders. This is where the system began to break in a way that no green dashboard had anticipated.
Reservations that had worked in testing started lagging under live concurrency. Some parts were visible in EWM but not released correctly to the work order. Some certificate documents that were supposed to sit behind serialised parts existed only as broken ArchiveLink references after migration. On paper, the company had parts, maintenance demand, and technical records. In practice, engineers were standing next to grounded aircraft without usable stock visibility and without the documentation required to release components into service.
In Lydian speak, this is what “post-go-live failure” usually means. The system does not collapse dramatically. It simply stops being dependable at the exact moment the business needs speed.
Why Testing Did Not Catch It
The board later asked the standard question. How did this not show up earlier? The answer was uncomfortable but simple. Testing had proven sequence, not stress. UAT confirmed that a maintenance flow worked when executed in a stable environment with known data, manageable transaction volumes, and consultants standing nearby to resolve edge cases. It did not prove that the same flow would hold during concurrent AOG events, remote site pressure, warehouse timing delays, and live API throttling across systems.
This is a common SAP illusion. A successful test case proves that the configuration can execute a scenario. It does not prove that the enterprise can survive when multiple scenarios collide under operational pressure. In aviation MRO, that distinction is brutal because maintenance, inventory, compliance, and finance are tied together in real time. If a part cannot be reserved, fitted, certified, and settled properly, the issue is not confined to one module. The aircraft waits, the schedule slips, and the commercial damage begins immediately.
What the Business Actually Paid For
The financial cost emerged within days. Aircraft remained on ground longer than planned, flight schedules were disrupted, billing against maintenance events lagged, and the finance team saw unsettled postings stacking up behind operational confusion. The direct cost of delay was measurable in lost utilisation, overtime, emergency sourcing, and rework. The indirect cost was worse. Leadership confidence in programme reporting evaporated, and every subsequent issue was treated as evidence that the go-live decision had been premature.
This is the cost of discovering failure after go-live. You are no longer diagnosing risk in a workshop. You are paying for it in live operations. In a sector like aviation, where compliance records and asset availability are inseparable, the price of late discovery is not just technical embarrassment. It is grounded assets, delayed revenue, regulator anxiety, and management attention consumed by recovery instead of control.
What Leadership Should Have Understood Earlier
The leadership mistake was not approving go-live. The deeper mistake was assuming that “system ready” meant “operationally resilient.” The programme had proven that the system could perform under designed conditions. It had not proven that the business could absorb live variability through that system without breaking at the seams between PM, MM, EWM, compliance documentation, and FI.
That is the question leadership should have asked before the applause. Not whether the scenarios had passed, but whether the business had been validated under the conditions in which it actually lives.
Go-live does not reveal success.
It reveals what the programme failed to test.
