Base vs. the Customization Dilemma

You’ve heard: “We want it the way we want it when we want it.” This statement requires prudence when undertaking an ERP implementation. There are pros and cons along with sound methodologies of “getting what we want”. This takes discipline and some business process change. Some would argue there are no pros to customization. I would agree -- in a perfect world -- or in an environment where a plug and play vendor satisfies your requirements. Perfect world aside…

Often, businesses get in the habit of throwing a modification at a problem rather than analyzing how a process could flex to work within the base system design. Businesses also start making modifications without fully understanding the application of the system to their business. This practice makes moving to the vendor’s next release very difficult. You want to take advantage of new releases as they reflect functionality driven by customer’s input giving you even more functionality to positively influence the bottom line.

There are times when a specific functionality is needed. As is feasible, make every effort to design the functionality such that the modification can be as much outside the base system as possible. Unless and even if you own the source code, the vendor may have ultimate control over making the modification but you certainly need to assert your input, after all, you are paying the vendor. Writing a process, whether an interactive screen or batch process, as a standalone can be to your long-term advantage over base modifications. While the disadvantage may be the user interface, you need to determine if the advantages outweigh the disadvantages. The advantages being:

  • An easier upgrade path thus giving you the ability to take advantage of the vendor’s upgrades

  • Less costly upgrade path, reducing retrofitting modifications

PROs to Customization

  • Resolving specific required functionality not native to the system; these should be minimal

CONS to Customization

  • Typically the modifications are not documented leaving you vulnerable

  • Quality assurance testing must be done to every affected module

  • Moving to next release is more costly and time consuming to test the retrofitted mod again

  • Help desk typically does not support modifications

  • If not properly designed, potential of interfering with a module to be implemented in the future

« Go Back