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
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%).