Page 189 -

Chapter 5 • Implementation Strategies 165

the new code, creating a potentially costly modification from a time and budget perspective.
If a major business requirement needs to be met, a bolt-on is the preferred approach.
Table 5-3 lists the development platforms that could be cloned and modified in the major
ERP packages to create an extension.
An extension retains the delivered vendor’s code in the database, but the original
code is no longer used. Subsequent ERP upgrades will update the delivered code, and the
modified code can be integrated into the upgraded application if the underlying technology
remains the same. The following must also be considered:

•The upgrade process for a customized ERP implementation is more time consuming
than an upgrade of an ERP implementation with no customizations.
•The time frame and cost of upgrades increase exponentially with the number of
customizations due to validation and testing.
•Customizations are not supported by the vendor and must be maintained and updated
by army or contractor staff.
•If the army’s customization is one used by multiple clients, there is the possibility
that the ERP vendor can be persuaded to include this customization in their next
product release, but this could require significant negotiating leverage and is
uncertain.
•Depending upon the magnitude of the required customization, a bolt-on can be
more cost-effective, less susceptible to defects, and enable the team to meet project
timelines.

The measurement of the level of customization of a particular installation of an ERP
system is difficult to judge. There is currently no industry measurement baseline or metric
for this type of analysis. Objective measurements would ideally involve a determination of
the amount of customized code as a percentage of the vendor’s delivered code. In order for
this measurement to be meaningful across industries, and even within the army, there
would need to be a common metric for delivered code and a common method for determin-
ing the means to parse and quantify the amount of customized code. These measurements
would be further complicated by the fact that implementing an ERP product often does not
include implementing full functionality. ERP modules are often implemented over a period
of time in a phased approach that leads to the need to refine further the definition of the
baseline delivered code versus customized code. Finally, this analysis also presumes that a
common baseline would be applicable across ERP packages, leading to a comparable
assessment of the levels of customization of, for example, a SAP versus an Oracle imple-
mentation. This task is not without merit, but it will require industry and organizational
alignment to reach fruition.
A final consideration related to this discussion is the configuration of ERP software.
Configuration is not customization or modification; it is the entry of customer-specific data
into the tables delivered in ERP software. A standard, simple or pre-configuration, however,
may allow faster processing speeds and easier queries. A more complex configuration may
cost more in terms of user training, processing speed, and data access. Complex
configurations may better support current or legacy business processes. They may not,
however, represent best practices or changed business processes. Table 5-4 provides a sum-
mary of the configuration and customization approaches along with some pros and cons.