ERP deniers their own worst enemy As new ideas and technologies emerge and develop in IT, we typically go through a maturity curve. Lots of problems are reported in the early days as a result of unproven products and lack of market ‘know how’ which gradually disappear over time as offerings become more robust, experience is gained, and best practices are defined …
The massive amount of customizing is normally there because what many companies believe is that their own processes is what make them successful. That's why the software has to be bent to fit the processes.
In my life as an SAP consultant I have met only 1 customer who bent their business processes to fit SAP 100%. They need only 1 FT SAP service person for the whole country (it was Belgium).
With many consultancies offering packages that can easily be imported to kick-start the SAP prototype, the implementation time has been reduced to minimum nowadays.
I am working 60-70% as a technical consultant. What I noticed is that a lot of time is spent in the recording of the business process in a coherent form, sometimes longer than the calendar days needed to complete the implementation. That is actually the bottleneck in any ERP implementation I assume.
Another issue is that often is believed that a project manager who is an expert of project management can handle an SAP project without prior SAP knowledge. That's a mistake and produces frictions inside the teams. This type of PM's are normally those that go over budget :). The only case where this can work, is if that person is the topmost project manager who has part project manager reporting to him/her who have SAP knowledge.
> ...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.
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.
Interesting comments. Sounds like there was a big shift away from *nix to Windows
However you seem to be saying the *bigger* issue is the limited (nonexistent?) customization allowed by the package. Would you have been OK if it was a .Net system with the source code available?
The backup issue with *all* customization is the extent to which they will preserved when you *upgrade* the package. Other posters have described situations when the package radically changes (making a fair portion of their mods redundant) or where the the package has poor support for this and require applying the changes to the next generation by hand.
I believe there are *very* few commercial businesses (if any) which rate a completely bespoke system (usually interfaced to an accounts package) in the way that systems a decade ago might be built. However I also believe different ERP systems favor specific types of companies or market sectors. The better the fit to xx Corps business the lower the customization
Just my $0.02.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
