Big ERP project failures always make the news because ERP is so expensive and the victim orgs are often public bodies with no in-house IT expertise, whose procurement process involves senior managers getting hypnotized on a golf course, with no engineers in sight.
The orgs themselves are not always blameless. ERP is expensive because the orgs are complex, and usually don’t understand themselves. The kind of end-to-end processes that ERP implements cross organizational boundaries, which is to say departments that don’t have good communication behaviors between themselves and therefore don’t fully understand why they do things. This is the seed of disaster for any project.
And then Oracle specifically make this difficult situation worse by having supremely opaque product documentation, names, versioning, licensing, and a constellation of internal support teams (which are no different to the client orgs in that they don’t communicate well with each other either).
All these big failures are fundamentally failures to communicate the right information throughout the project. Nobody is willing to do the hard yards of understanding and mapping out end-to-end processes and integration points, and fitting them to technology components. They all think they can shortcut the process by starting with the technology and working backwards from there, because that’s what Oracle sales told them they could do.
I’m not trying to excuse Oracle’s actions here, but ERP failure is normally a two-player game.
ERP projects are more business process projects than they are IT projects. Throw in the wrong implementation partner, and all you get is a non-working system and tons of consultant and development fees.
At least they tried and brought in an implementation partner. I've been (still am) watching one where the teams were left to figure out the new processes pretty much by themselves. And because each enterprise software comes with new processes, new data models and new stakeholders, because team A has different ideas than team B and the 10000ft view ignores by definition all "trivial" details, guess what's going down in flames?
Add in the hidden ugly truth about ERP projects: they're more about the organisation changing to fit the ERP rather than the software serving the organisation
> they're more about the organisation changing to fit the ERP
that's because the ERP has been sold as the solution to the domain complexity of the organization. It's been sold as a way to make your org's business processes work in "industry standard" ways, following "best practice", because the ERP vendor has "experience" with other orgs in similar businesses, which you can leverage the expertise/knowledge off. They'll customize the process a bit, to make it suite your "unique" circumstances.
Again, the 80/20 rule applies: keep 80% standard (because the standard is actually good enough, and yes, it includes all the best practices distilled into it) and customize max 20% to your needs (hard to accept, but no business is special enough to need more than those 20%).
Yeah this happens all the time. Architects sell a 'Fusion Middleware' pile of nonsense that will magically solve all problems, and it doesn't work. One notable case is the Cover Oregon website, which literally never worked. Read section C of this for some big laughs:
deja vu: 20 years ago, I was always hearing people in IT at Stanford bitch about Oracle Financials. They'd been struggling through a 2-year migration to it that was mandated by top management. Some things never change.
Reminds me, we're currently migrating from Oracle SQL to Postgres because it seems they simply stopped maintenance. They only have official releases for the ROracle package until R 3.6 [0], the latest R version is 4.2. You can still get it to work, but it's getting increasingly harder, and at some point we drew a line (for multiple reasons).
I don't really know what has happened lately, but 20-25 years ago as a Sun vendor I was involved in or had knowledge of at least 10 large ERP projects, and in all of them SAP won. I don't have the details, but I got the feeling that all those customers discarded Oracle because it barely scored 2 or 3 points in the evaluation matrix. All of those SAP projects were a success. All of them.
It might also be that after the first big failure, the definition of success got heavily redacted to something like "exhausting, double the price and barely made it after 2 years of delay"
Interesting - 20 years ago we had a client who was a big publisher implementing SAP - it ran 2 years over the original timeline, finally went live in peak Christmas purchasing cycle. The system broke down, meaning they weren’t able to fulfil orders, and they went into administration in the following year…
The orgs themselves are not always blameless. ERP is expensive because the orgs are complex, and usually don’t understand themselves. The kind of end-to-end processes that ERP implements cross organizational boundaries, which is to say departments that don’t have good communication behaviors between themselves and therefore don’t fully understand why they do things. This is the seed of disaster for any project.
And then Oracle specifically make this difficult situation worse by having supremely opaque product documentation, names, versioning, licensing, and a constellation of internal support teams (which are no different to the client orgs in that they don’t communicate well with each other either).
All these big failures are fundamentally failures to communicate the right information throughout the project. Nobody is willing to do the hard yards of understanding and mapping out end-to-end processes and integration points, and fitting them to technology components. They all think they can shortcut the process by starting with the technology and working backwards from there, because that’s what Oracle sales told them they could do.
I’m not trying to excuse Oracle’s actions here, but ERP failure is normally a two-player game.