One major advantage of ERP, at least in some of the market leader products, is in its structuring: the features of product can be divorced from particular choices made by target organization, the configuration. Product can be upgraded on ongoing bases (like virus protection or operating system software updates) as one domain, while still keeping the organizations configuration intact and consistent, as a separate domain.

Before modern ERP era, those two domains were coupled so tightly that the separating them was practically impossible. The vendor usually copied their generic product (or source code) and modified it to each customer, effectively “burning the bridges behind” for easy upgrades. Upgrades for features were possible but required considerable effort each.


The regularly updating nature of ERP packages enables some external changes in environment to be adopted (IT-system-wise) quite easily by customer organizations. Such events as conversion to euros, new yearly changing accounting principles required by national organizations (or IFRS), reporting requirements to authorities (intrastat reporting, electronic customs declarations) simply cause new features or programs to appear in the system with related documentation. 

It should be emphasized, that the distinction between vendor/product dependent domain (the programs) and customer domain (configuration) is not necessarily based on program/configuration aspect. The programs, as well, can be customer specific without getting overridden by product updates, if those enhancements are done in specific way as proposed by ERP vendors. 

Gaps and how to fill them

Among the first phases of typical ERP implementation is listing and modeling of the processes or features required by target company and then comparing them with those available in the package. The gap-analysis! General finding in literature is that around 20% of the required processed cannot be found in templates of the ERP package. To deal with the process gaps several options are present, which in generic level could be handled using following options, reflecting the usual order of preference from upper management viewpoint

  1. customer organization can re-plan its processes (BPR) to fit the functionality of ERP. So business is adjusted to fit ERP
  2. custom processes can be built, or system functionality enhanced, using ERP standard programs and their parameters as building blocks. So ERP is adjusted to fit business, within the configuration options provided by ERP package
  3. programs or functionalities in the package can be replaced by programming alternatives. So ERP is adjusted to fit business, beyond the configurations options of the package, entering the domain of IT-development
  4. specialized (external) software can be procured to handle the problematic or critical process, usually integrating them with the main ERP package. So ERP is complemented with external systems to fit business. Usually this requires some IT-development to actually build the integration, unless the 3rd party vendor has pre-built integration features. This kind of “ecosystem based” development, where small vendors provide easy-to-add apps to one of the bigger ERP products,  is one of the most recent trends

Implementation approach

If one of the goals is to avoid implementation-vendor dependency and IT technicalities, then option 3 is not favorable. If avoiding extra systems is of high priority then option 4 is not desirable. Those would usually be the views of upper management and CIO office. Local business (or middle management) often opts for critical processes to be implemented using option 3 or 4, which generally bring better fit with business requirements. Then the “packaged software” is actually not such ready package after all, but some minor (or major) software development efforts are usually made.