"Still, there are lots of lessons from history that future ERP projects can learn from"
But PHB's never bother spending time on studying past, when they could going toward (their) bright shiny future.
I've worked for various companies who were industry leaders in their sectors.
A bespoke SW system was often a key part of that. It let them play a tighter game than their competitors. OTOH you have all the support costs of a one of a kind bespoke system and a PITA if it's badly documented and the Subject Matter Expert (or "Archie the archive as I like to think of them generically) retires or gets hit by a bus.
Here's the thing.
If you want to leverage the benefits of a standard OTS you've got to
1) Do a detailed mapping of your business processes (not just the software bits, all the peripheral stuff). How it really works.
2) What you want to keep of them and what you want to change (and to what?)
3) Map as much of that onto your chosen ERP using configuration settings (which you'll need to document and update as needed) which you should be able to transfer to later versions (because it will go end of life and you will be without support, which is one of the reasons you went for an external solution in the first place, wasn't it)
4) That leaves the nub of processes you want to retain but your chosen ERP won't handle (possibly because it was chosen for you by some PHB in an office far far away....). Now you have to write actual code, and document it to allow it to be ported when the next (inevitable) upgrade happens without fuss.
I've never done this. The reason is simple. It needs a better person than I am, leading a better team than I've ever worked with, to pull it off.
For those who are doing this I will wish you good luck.
You're going to need it.