alphaspirit - Fotolia


Hard truths you need to know about customized ERP

It's true that companies sometimes believe packaged ERP doesn't fully support every business process. But here's why you might want to just say no to modification.

Companies are often warned not to customize packaged ERP software. The most common reason they do so -- and the most valid reason -- is that they believe that the packaged software does not support an important business need of theirs, and can't be adapted to meet that need through tailoring or altered workarounds.

However, there are several very good reasons that customized ERP is a bad idea. For starters, modifying packaged ERP software is difficult and expensive, extending the time to benefit for the new ERP system. In addition, since ERP is complex due to the many interconnections across multiple applications, custom ERP development could have unpredictable effects on areas of the system far removed from where the modification is made. Moreover, modifications may also destroy any certifications or assurances of system integrity or auditability.

There's another reason to avoid custom ERP development that is worth exploring further: Modifications make it difficult, time-consuming and expensive to keep up with releases or updates provided by the package developer.

Customized ERP makes staying up to date difficult

When a company modifies vendor-provided programs or databases, even a little bit, then those modifications must be evaluated in light of any new release or update from the software package developer. The modifications then often have to be reapplied on top of the update (which may replace the modified programs), and then rechecked for adverse effects and functionality.

This process takes time, of course, preventing the company from reaping the benefits of the update in terms of fixes and new functionality until the remodification, update installation and testing is all completed. It is a time-consuming and costly undertaking.

Updates typically come once or twice per year for most packaged ERP systems. And there's always the possibility of an unscheduled additional update to correct a newly discovered problem or security vulnerability.

Many [developers] will simply refuse to respond to support requests from customers that they know are using modified code.

It's such an onerous process, in fact, that many companies with significant modifications to their packaged software will opt out of the update process completely, or decide to only install every other update or every third update. Companies that forego updates quickly fall behind the evolution of the software, and they miss out on new functionality, bug fixes and the opportunity for support from the developer.

The developer is limited in its ability to respond to user questions or issues when they do not know what the user's modifications are or how they affect the system. Many will simply refuse to respond to support requests from customers that they know are using modified code.

Updating choices for those with customized ERP

A company that has customized ERP packaged software must decide on a strategy for updating and maintaining their system. The choices include the following:

  • Budget and staff up for update evaluation, modification and installation, no matter the interval (annual, every other year, or however frequently updates will be accepted). It would be a good strategy to scrutinize updates for new functionality that could eliminate the need for the modifications; that is, new functionality that could reduce or eliminate the need for the modification.
  • Budget and staff up for maintaining the software package on your own. This maintenance may include adding additional functionality with custom code that would have been provided by the developer to keep up with new technologies, industry trends or competitive capabilities.
  • Stay down level -- do not install updates -- and only minimally maintain the system to keep it running. The result of this strategy is likely to trigger a need to replace the system with a better ERP package relatively soon, before the lack of improved functionality causes harm to the business.

There is a substantial cost associated with each of these alternatives. In the long run, the first alternative might actually be the lower cost option, and it will provide better, more up-to-date functionality for users. Of course, avoiding custom ERP development to begin with is the best approach.

Note that ERP developers continue to build more flexibility and adaptability, along with new functionality, into their products with every new release.

Also note that some cloud-based ERP systems are architected in a multi-tenant model that deploys a single instance of the software that is centrally maintained. Some of these developers use a continuous update process that eliminates the traditional periodic release. Fixes and updates are applied as soon as they are ready, any time, any day. User companies must coordinate any modifications with the developer's support organization to ensure compatibility as the updates are applied and as the system changes over time.

Next Steps

ERP showdown: Comparing SAP and Oracle

Hybrid cloud ERP is no easy matter

Why ERP prospects for small and medium-sized businesses are looking up

Dig Deeper on ERP integration