Sydney, Melbourne, Brisbane, Perth, Adelaide, SE Asia, Europe, S America, North America, Canada
Contact Atko Global Now!
+61 2 43655074
  Experience Worth Listening To
Independent Business Systems & ERP Advisors
to transform your business - Guaranteed
.
ERP
HOW TO KILL YOUR ERP PROJECT
Click Here To Return To Blogs
How to Kill your ERP Project
Thursday, April 10, 2014

A 2014 global survey on Enterprise Resource Planning (ERP) has quite clearly shown that software customisation has the potential for totally derailing an ERP project. Asking for software to be customised during implementation is a major source of project delay and budget blow-outs. Software houses are more than obliging to undertake the customisation, at a cost!
The lack of an effective internal system for logging customisation requests, post purchase, and determining “what is essential” as opposed to “wouldn’t it be nice” can very quickly lead to massive changes to the software far beyond the original scope of software requirements.

Surveys are showing 60% of ERP projects are undertaking significant customisation or purchasing additional software as it is perceived they cannot do without it. I am not referring to simple configuration of the software but changes that impact functionality or process.

With all of these changes going on and the negative impact the changes have on ERP projects the question is “Why”?

The great majority of companies we speak to go to great lengths to define their ERP requirements by engaging users and all stakeholders to ensure they cover all of the business requirements. These requirements are documented and put into a request for quote that is sent to potential vendors for their response. Given the effort that goes into defining the requirements and the fact that 60% of ERP
projects undergo significant software customisation/modification and or require additional software, the process for defining requirements must be floored.

It has long been known that the best way to implement ERP software is to define clearly, up front, what the requirements are and implement the software with minimum or no changes. The key here is to get it right at the software requirements stage and ensure it is very clear what the requirement is and tested against the software prior to purchase. Any shortcomings in software should be identified in the pre-purchase demonstration stage of
the project and negotiations made to correct the shortcomings or look for an alternate package that better fits the requirements.

The changes that organisations are making to ERP software during the implementation stage of the ERP project causes significant cost and schedule blow-outs to the project. In many cases the costs far exceed the budget for the project resulting in shortcuts being made to the project, affecting the systems performance during live running or causing the project to be abandoned.

The method of defining ERP software requirements needs to be closely examined to ensure the ongoing disasters in ERP failures is not due to poor definition of software requirements.

Experience Worth Listening to!

Ray Atkinson