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%).
Comments
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?
Are we colleagues, by any chance?
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
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.
Unfortunately, it's all hogwash.
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%).