Page 188 -

164 Chapter 5 • Implementation Strategies

The common argument for customizing ERP software is that it is not possible to run
the army using commercial processes because army processes are too dissimilar and vary
due to specific mission or organizational objectives. Even though that can be a true state-
ment based upon statutory and regulatory constraints, this is not usually the case. The
statement is usually made by stakeholders or team members who either do not think they
are empowered to make decisions about process changes or want to avert change to main-
tain the status quo.
If the organization is committed to changing business processes to match those inherent
to the software package, customization of ERP software should be rare. The effort involved to
reengineer business processes to fulfill this commitment cannot be understated. There are
various DoD statutory and regulatory rules that are not accommodated by ERP software;
however, this does not have to be a barrier to using the delivered ERP functionality.
Sometimes these regulations can be changed to accomplish the same goal using the delivered
software. Blueprinting, which includes comprehensive pilots on a live system of proposed
business processes using delivered ERP functionality, is key to developing an effective
and accurate process. The result of these rigorous pilots should be a list of valid customizations
mainly based upon statutory and regulatory rules that cannot be changed in the foreseeable
future or cannot be accommodated by changing a current business process.
The first line of defense if major business requirements cannot be met by delivered ERP
software functionality is acquisition of a bolt-on, whether it’s a product of the same
ERP vendor or a third-party software vendor. Bolt-on provides similar benefits to those of ERP
software. It can also provide process innovations necessary for specialized industry needs.
The additional cost of support and maintenance of an additional software license would need
to be evaluated versus the magnitude of the customization required to meet the necessary
business requirements. Table 5-3 contains the type of customizations that could be candidates
for bolt-on versus minor customizations to meet a requirement that cannot be met by the ERP
software or a process change. If a requirement is historically too industry specific, even bolt-
ons may not meet the need. The next priority should be changing a business process or, as a
last resort, customization of ERP software.
There are two potential methods for customizing ERP software, but only one method
should ever be used. The method that should be prohibited by project leadership is modifica-
tion of delivered software code from the vendor. The accepted method is the creation of a
new code base, also called an extension, which is derived from a clone of a delivered
software routine. The modified code is then referenced by core application components.
This approach requires that all the references to the delivered code be changed to reference

TABLE 5-3 ERP Approach to Meet Requirement Gaps

Major Customizations Minor Customizations
Approach Bolt-on product Clone and modify ERP
code
Description Processing engines Simple processing routines
End-to-end processes Reports
Security structure Web pages
Menus