Anyone else notice that ERP failures almost never happen for the reasons listed in the post-mortem?

Been involved in a few implementations across different industries. Something I keep seeing:

The official post-mortem always says things like 'scope creep,' 'inadequate training,' 'unrealistic timeline.' And those things are true. But they're not the reason it failed.

The actual reason, almost every time, is that nobody knew who owned the processes being automated. Like actually owning them. Not on paper, in real life. Who has authority to say 'this is the approved workflow'? Who resolves it when two departments have been doing the same thing differently for 10 years and neither wants to change?

There's also this thing I've started calling the 'shadow process problem.' Every company I've worked with has processes that exist nowhere in their documentation. Workarounds that evolved over years. Informal exceptions. Excel files that are the actual system of record for some critical function.

ERP gets configured against the documented processes. Go-live hits. Users immediately start recreating the workarounds because the system can't handle what they actually do. Adoption dies. Blame lands on the software or the PM.

I've also noticed the requirements problem that someone described recently as 'Experiential Discovery' when you ask users what they need in a workshop, they describe their ideal process, not what they actually do. You only find out what they actually do when you show them a live demo environment and watch what questions they ask. By then it's usually 3 months before go-live and too late to fix the configuration.

Does anyone else see this pattern? Curious whether it holds across different ERP platforms or if it's more of a company culture thing.

Also wondering for those who've been through a failed implementation that eventually got turned around, what actually fixed it? Not what the vendor said fixed it, but what you actually observed.