Norwegian Society

...

-

Options for extension and modification

The term modification, which is used in [25], appears more often in literature (e.g. in [21; 24; 33]). It always refers to changes in the ERP source code. Interconnecting ERP systems to other systems is also considered as a form of modification by several authors (e.g. [6; 24]). In our view, such interconnections should not be seen as a change of the ERP system but as acknowledgement that the ERP system is part of a larger enterprise information system. Such interconnecting is by itself not causing the ERP system to change, except for the effort to build an interface. Accordingly, the term extension will be used here.

Table 2 below (based on [6]) gives a number of frequently encountered situations of extension and/or modification. All these extensions require documentation, testing and user training. In case of upgrades, at least inspection is needed to investigate if the extension has to be retested and/or redone. The latter case may result in renewed documentation, testing and training. Note that extensions to third party software may lead to interfaces outside the company, which may add a security risk.

The options available for modification are quite simple: either there is no modification, which is generally called vanilla, or there is modification via programming in the standard 4GL language of the ERP system [3; 4; 24]. In the latter case, the aim is to replace existing functionality of the standard system by new functionality which may also affect the data model and parameters. This form of modification shown in the last row of Table 2.

Obviously, there is a range from very light modification to very heavy modification, corresponding to replacements of just a few lines of code at one place in the source to millions lines of code changing across all modules. However, literature claims that modification often cannot be avoided [14] or determines the success of the implementation [17; 19].

As mentioned, all the above options for interconnection require interfaces. Programming of interfaces between an ERP package and another component is dependent on the version of both products and therefore sensitive to upgrades from both sides. Interfaces are costly and require substantial testing. New technologies like web services reduce the effort, but do not eliminate the burden completely [30].

Options for extension

User exits (using APIs)

This form of extension is used to create additional logic on top of the vendor logic at specific places in the software. This is foreseen by the vendor, using APIs. This additional logic does not change the vendor’s source code. No data model changes can be made via APIs. This extension is meaningful if there is large variation between implementations as to what kind of logic should be executed.

ERP programming for additional functionality

This form of extension is used to create additional functions in the ERP software without changing the vendor’s source code or data model. This new code is comparable to APIs but may lead to new sessions. It requires substantial testing of the additional source code, but does not require re-testing of the vendor’s code.

This additional programming is often used to create new reports based on existing ERP data. It should be distinguished from configuring standard reports (see above in this table) and from creating reports outside ERP (see below). However, it may also be used to create completely new applications in the ERP system.

Commercial Off-The-Shelf (COTS)

products added - “bolt on”

Implemented ERP systems are often used in combination with (COTS) systems. This requires an interface. Moreover, reconfigurations and even modifications at both sides of the interface may be needed to provide the organization with a meaningful enterprise information system. In particular, ERP functionality may have to be disabled if other COTS packages have overlapping functionality (see e.g. [21]). Packages from the same vendor may have less problems if data models and releases are synchronized. The same holds if vendors collaborate intensively.

Custom built (bespoke) products added

- “bolt on”

Similar to the previous extension option. Again, this requires an interface, and again, reconfigurations and even modifications at both sides may be needed, in order to provide the organization with a meaningful enterprise information system.

External data- warehousing and reporting added

Similar to option one, but here the bolt-on package is used for further enrichment of the ERP data. In contrast to reporting within the ERP system, based on 4GL programming, this is an interconnection to a third party program, which requires an interface. As indicated in [6], the effort may vary. Depending on the nature of the data warehousing and reporting software, this may be a straightforward or a complex process.

Workflow

Programming

Because workflow technology is a different technology than classical 4GL ERP programming language (see [31]), a change in the workflow may require interfacing and require modification of ERP [6].

Options for modification

Changing vendor’s software

Modification implies a change in the standard software via programming in the standard 4GL language of the ERP system [3; 4; 24]. It implies extensive initial documentation and testing effort. Moreover, the vendor’s commitment to support and maintenance will decrease and the costs of these will increase. Finally, testing of the changed code has to be repeated when the standard has a minor upgrade, and the software development process has to be redone in case of a major upgrade.

Table 2. Options for extension and modification.

-

Options for scope

An important issue in implementing ERP systems has to do with scope: an ERP implementation covers some part of an organization’s activities, varying from the whole organization to some smaller or larger organizational unit or function [16]. The scope of an implementation determines which functionality