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 1-7 rating scale ranging from "very much easier" through "about the same" to "much harder"--the average response was 2.75. In other words, the average response indicated that ERP systems are perceived to be easy to change. It would appear, at least based on the answers to this question, that ERP maintenance may not be a barrier to making system change happen.
The final two questions were forward-looking. We asked the respondents if they believed that they would be able to use their ERP system (including any vendor updates) indefinitely without requiring any (further) extensions or modifications. Answers could range from "yes, absolutely" through "perhaps" to "no, something must be done." The responses averaged 4.5, indicating that respondents generally felt that more changes would need to be made to their ERP system. (Note: Users were more prone to say "something must be done" than information systems personnel.)
The final question asked "To what extent do you believe that making changes is a serious problem of ERPs?" The range of suggested responses went from "no problem" to "a problem to be worked on" to "a serious problem (either now or in the future)." Responses averaged 2.8, and thus, closer to "no problem." (Note: Information systems people were more likely to see change as a serious problem than users.)
In spite of the fact that the respondents to this survey have been using their system for a fairly long time, there still seems to be ambivalence about the difficulty of making business-driven change to an ERP. That ambivalence persisted even when we differentiated between information systems respondents and users.
But the bottom line of our findings is this: ERP enhancements at the user level do happen, and, at least at this time, the ERP change mechanisms seem adequate to handle it. That's good news for companies using ERP systems.
Editor's note: If you're interested in the full research study results, contact the author at [email protected] for a copy.
Glass, Robert L., and Vessey, Iris. "Enterprise Resource Planning Systems: Can They Handle the Enhancement Changes Most Enterprises Require?" The Software Practitioner, Sept. 1999.