Customization Costs Drive Most ERP Deals

> ...40 per cent seemed to prefer paying consultants to cut code by default to avoid making adjustments to the way they work...

Selecting and implementing an ERP package is primarily a political process -- the IT considerations are secondary. Companies want their cross-department functions tightly integrated, but that always means one or more constituent groups have their needs met through significant customization. APIs and web services help, but the real issue is development costs for coding and orchestrating integrations and extensions.

ERP implementation costs should -- before custom work -- be equal to or less than the license costs. That's arguably a clue the package can be tailored inexpensively in the first place. Second, make sure the package has a patch and upgrade process that fully preserves custom work. Third, a solid ERP packages generally produces a good online user community, which is also a customization resource center. Live users and independent consultants participating together in online discussions is a great asset for determining what kind of customizations to pursue and how.

ERP deniers their own worst enemy?

Are you kidding? I have spent years on an implementations. Most recently retireing an MRP system that was highly customized. A .NET ERP system with no customizations was put in its place. Now, using basic ERP processes, productivity is about 70% of what it once was. This is after being live for one year.

The new ERP packages deliver inflexible middle-of-the-road functionality.

They also are favorable only to a certain type and scale of transaction.

ERP works OK out of the box if you have similar types of transactions in high volumes.

A wide variety of transactions in small volumes will choke the system and its users.

The "modern" ERP systems just don't scale in this direction.

The old MRP system ran on unix and the source code was available.

We could at least figure out why something was working (or not).

We could find and fix things incrementally if necessary.

The new system is .NET, no source code and poorly documented.

If there is a bug, you are at the mercy of the software supplier to fix it in a new release.

Bug fixes are then only supplied as part of an upgrade package.

We are expected to upgrade our system every three months????

Do you want to know haw many "upgrades" have introduced new bugs?

MRP packages used to be designed and supported by business people who knew the processes. ERP packages on the other hand appear to be built by software programmers that have no idea how a business really runs. ERP support staff increasing runs off of scripts.

And what about "successful" implementations?

I've looked pretty hard in my area for them.

I have not found one business that is even close to being satisfied.

None would put in the new ERP software again if they had a second chance.

I'm sorry but I think the author of this article must have some connection with an ERP software vendor. If I'm wrong, I'd really like to speak with this person. I can't imagine what experience could lead someone to say that ERP deniers are the problem. I'd really like to hear the details of their personal experience.

Erotic Roll Playing?

In the office? Here in the USA, it'd probably get your arrested, alas ... Probably why FreeformDynamics only got 48 respondents, it's not all that common ;-)