In his column, Bob Glass takes what he thinks is a short step to the edge of the arena of software testing and quality. He's talking about software maintenance, and the maintenance of a particular kind of software. Why? Because maintenance involves a great deal of testing and quality work, and because maintenance is arguably the most important consumer of software dollars.
Maintenance, as you know, is about changes to existing software products. Most such changes are enhancements--improvements to the functionality of the software, as opposed to repair work to fix errors. There is a sort of 60/60 rule for software maintenance and enhancements--roughly 60 percent of the software dollar for a given product is spent on its maintenance (the figure varies from 40 to 80 percent), and 60 percent of the maintenance dollar is spent on enhancement (as opposed, for example, to 17 percent being spent on correction).
Now we enter the ERP revolution.
For the past few years, it has been possible to buy most so-called "back office" business applications--largely, transaction processing systems for such tasks as accounting, manufacturing, or human resources--off the shelf as packaged products. Packages to do this collection of work are generally referred to as Enterprise Resource Planning (ERP) systems, or sometimes, Enterprise systems. Most ERP systems are huge because of the diversity of tasks they must perform, the fact that they integrate those tasks, and the flexibility they must have to perform those tasks at enterprises with vastly varying needs.
Let's take a look at where maintenance and ERP intersect.
A colleague and I conducted a study of ERP users and their maintenance processes and problems (Glass and Vessey 1999). As preparation for asking the respondents questions about their ERP maintenance, we presented them with some key definitions. First, we offered definitions for traditional business systems maintenance. We defined maintenance of a traditional business system as consisting of (at least) enhancement (changes to the functionality/requirements of the system) and correction (changes made to correct errors in the system).
Then we offered comparable definitions for the ERP setting. We defined maintenance of an ERP system as consisting of (at least) the following:
Customization (changes made to ERP functionality via internal configuration switches)
Extension: changes made via ERP system "exits" to...
Custom-code "add-ons" (often coded in a vendor-provided language such as SAP's ABAP/4)
Third-party vendor "bolt-ons"
Modification (changes made to the code of the ERP itself--either by the user or the vendor)
The underlying concern here was that, with the large level of maintenance/enhancement needed by traditional information systems, it might not be possible to perform comparable changes to an ERP. If that were the case, the longevity of use of an ERP could be severely compromised.
We asked whether the respondents had made changes to their ERP's functionality since implementation (that is, during the maintenance/operational process). Every respondent answered the question with a "yes!" Clearly, at least at a superficial level, the maintenance of an ERP can and will involve change.
The next question was concerned with how those changes were made. The answers showed that a broad spectrum of change approaches had been used. Everyone had done "customization" (using configuration switches); all but one had done "extensions" (half of those had done "add-ons" and/or "bolt-ons" and/or linking to legacy code); a third of the total had used the vendor-supplied language to build extensions. Two-thirds of the respondents had had modification performed (changes to the ERP code itself), largely done by the users themselves or (to an extent half that for user changes) by the vendor of the ERP. (Note: User package software modification is generally considered to be a very bad practice.)
We then asked the respondents to compare the ease of ERP changes with comparable changes to a traditional, custom-built information system. A third of the respondents chose not to express an opinion on this matter (likely coming from the user community instead of a traditional IS background). Of the remainder--on a