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 separating them was practically impossible. The vendor usually copied its 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.
Updateablity
The regularly updating nature of ERP packages enables some external changes in environment to be adopted (IT-system-wise) quite easily by customer organisations. Such events as conversion to euros, new yearly changing accounting principles required by national or other organisations, for instance (maybe 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 emphasised, 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 modelling 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
customer organization can re-plan its processes (BPR) to fit the functionality of ERP. So business is adjusted to fit ERP "out-of-the-box" style. Also called vanilla approach.
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 and limited by ERP package
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
specialised (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. If this external application is separate stand-alone capable entity, then sometimes this approach is called "best-of-breed" , and it can involve a whole bundle of other applications. Traditionally this requires major IT-development to actually build the integrations. In some cases, with a bit of luck, there could be standard interface available.
a special case of external software is "plugin" or 3rd party app, which is clearly an addition to main package. It wouldn't work alone, it requires the main package as back bone. In these cases the software vendor has normally pre-built the needed integrations. This kind of “ecosystem based” development, where small (or bigger) vendors provide easy-to-add apps to one of the bigger ERP products, is one of the most recent trends. So organisation can go beyond ERP-package normal functional restriction without any major IT development effort.
Implementation approach
If one of the goals is to avoid implementation-vendor dependency and IT technicalities, then option 3 is not favourable. If avoiding extra systems is of high priority then options 4 and 5 are 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 options 3 to 5 , which generally bring better fit with business requirements. Then the “packaged software” is actually not such ready package after all, but it still serves as the "default" way of working. If entering the IT-development is not an obstacle to organisation, the ERP package also allows the method of cherry picking processes from the standard and enhancing only the critical ones. Maybe take the bulk from the standard, those 80% of business functionality which was close fit to begin with, and enhance then the remaining 20%. Or start enhancing the critical 10% before first go-live, and then over the years tune the rest if it still seems the way to go.
