COST ACCOUNTING

A company acquires software to solve a business problem or gain a competitive advantage. A package solution is most often considered, in order to avoid the "reinventing the wheel" syndrome, and to leverage the experience and expertise of others. A package solution presupposes that the software vendor will keep current with the latest technology improvements in hardware and operating systems, and ensure that current trends in the industry are reflected and supported by the package. However, a company does not obtain these benefits through osmosis, mental telepathy, or the laying on of hands. These benefits are in the form of software releases, service packs, and patches. A company electing not to deploy these vendor offerings may find itself on an island of software isolation, or in an unsupported wasteland. This research note looks into the thought process that typically goes into the decision to upgrade, not to upgrade, or to skip over new releases.

Before getting into the upgrade discussion, certain terms need to be defined. As illustrated in the upgrade hierarchy pyramid, a new release typically offers new functionality (such as web-enabled components, radio frequency identification [RFID] support, or service-oriented architecture [SOA]); provides new data elements and data capture (as in drug pedigrees or bio-terrorism awareness); or takes advantage of hardware and software technology (for instance, blade servers, or the Linux operating system). Typically, a new release will require piloting and testing, user training, and data conversion. A service pack, on the other hand, is intended to correct inherent bugs in the vendor's software. As such, new data elements are not introduced, and extensive testing should not be required. Let's face it: the vendor is supposed to be correcting existing problems, not introducing new ones. A patch is a more localized fix or upgrade, and like service packs, should be transparent to the user community. A pyramid is an appropriate figure for representing the upgrade hierarchy, since new releases can include past service packs and patches, and likewise, service packs can include patches. Our discussion will center on new releases and service packs, with patches being included under the latter umbrella.

Setting Expectations Beforehand

Being on the project manager side of the table and typically representing the information technology (IT) factions, the user is not adequately prepared for new releases. Enterprise resource planning (ERP) implementation projects can last from nine to twelve months. You probably know of projects that have gone on for years. During the project, many users pull double duty. While undergoing training, entering data and creating tables, and piloting the new software, users must still accomplish their normal 9 A.M. to 5 P.M. responsibilities. But they perform this work because they have been told that the ERP software can provide a competitive advantage—bring in new customers, increase order sizes, reduce manufacturing inefficiencies, speed up deliveries, and so on. We have all "drunk the same Kool-Aid" and bought into this line of thinking.

The problem is that, while in the midst of a nine-month ERP project, new releases are rolling off developers' workstations. So just when you thought it was safe to return to your normal job, you are told to get ready for the new release. Too often users are led to believe that implementation is a one-time event. Nothing could be further from the truth. An ERP project is never totally completed.

The user community must be made to understand this fact of life. While this will not immediately put smiles on their faces, at least they will not feel misled. If said often enough by the right company executives, over time users accept the fact, perhaps begrudgingly. Some organizations even create smaller subsets of the implementation team that remain in place to handle new releases. Just make sure these new personnel costs are accurately reflected in the cost justification process.

Upgrading Rationale

The most obvious answer to the upgrade dilemma is that if you've already paid for the new release, why not use it? You do the math. ERP software selling conservatively for $250,000 comes with an annual maintenance price tag of $50,000 to $60,000. If you don't upgrade, you may be throwing money down the software drain. Now let's look at some the less obvious considerations.

Service Packs

The decision to apply service packs should be fairly simple if you've picked a software vendor with an effective quality assurance program. Service packs are targeted at fixing software problems by modifying code. As such, testing should be minimal, and training may not even be required. The only possible flaw or monkey wrench in this thought process is if the package has been heavily modified or enhanced.

In the case of enhancements, first you must determine if the service pack impacts the enhancements. Secondly, you must retrofit the enhancements over the service pack. Testing should no longer be considered minimal. Testing must ensure that the enhancements works as intended, and that they do not negate the service pack fix. A rule of thumb: for each service pack, budget 20 percent of the original cost of the enhancement for retrofitting. So for an enhancement that was initially installed for $50,000 (and assuming four service packs are issued during the year—not an unreasonable release rate for some vendors), you are looking at a cost of $40,000. This figure does not take into consideration the time of company employees involved in testing. While chief executive officers (CEOs) like to cater to the needs of their users and bring the software beast into line, many fail to foresee future repercussions.

New Releases

The decision to implement a new release of a package is much more complicated, due to higher costs and a longer timeline. To a large extent, new releases should be treated as new implementations, to include data conversion, pilot testing, integrated testing, and user acceptance. Unless there are significant changes in functionality, the as is, to be, and gap analysis phases should not be required. Having navigated through the learning curve once, users should need less training than in the initial implementation.

This being said, at the high end, implementing a new release should be budgeted at 50 percent of the original project. If major enhancements have been made to the baseline software, the estimate could increase to 70 percent or more, as all of the enhancements have to be retrofitted to the new release and tested.

New releases, however, are not like new models of cars, where you want to be the first on the block to have one. Unless there is an overwhelming need for functionality or unless the vendor has committed to a major enhancement as part of the sales agreement, most companies will remain one release behind. No one wants to be on the bleeding edge of technology or become a test subject for new functionality. A good rule of thumb for companies who want to deploy the current release is to wait until after the first service pack of the software is issued. Even after a new release is made available, vendor testing continues. While not showing a high degree of confidence in the software developers, this plan of action is based on the state of software development and the typical vendor rush to market.

Continuing Maintenance

No discussion on upgrading to a new release would be complete without some mention of ongoing maintenance and related fees. Consider that, for valid reasons, your company continually passes on implementing new releases. You need to ask yourself, "Why stay on maintenance?" Companies should debate this question each time a decision is made not to implement a new release, even after several service packs are issued. For large companies with adequate IT resources, access to the source code, and knowledge in the use of development tools, a logical answer could be to drop maintenance. Keep in mind that even with these advantages, such matters as proprietary fourth-generation languages and database technologies can present obstacles to a goal of self-sufficiency.

Small and medium enterprises (SMEs) typically do not have these advantages. Furthermore, SMEs are often told by the package vendors that they do not need an IT staff ("We'll be your IT staff"). Assuming that SMEs stay on the straight and narrow path outlined by the vendor, this can be true. But this allegiance requires annual payment for maintenance and support. Consequently, going off maintenance can be a much more gut-wrenching decision for SMEs. Ignoring the fact that new functionality will be unlikely, managing the technological environment could be an even greater concern. While some SMEs may look at a maintenance license as an insurance policy, a more realistic view may be to see it as a warranty. An insurance policy can give you money for your pain and suffering. A warranty includes parts and labor from a knowledgeable source. Without a warranty, you must either constantly negotiate a time and material deal with the software vendor, or find a third party outlet. Depending on the popularity of your package, this latter option could be extremely difficult.

Rationale for Skipping Over Releases

Companies may defer implementing a new release of an ERP package if no new, perceived functionality is being provided. This deference may go through several releases. For example, a company may still be on release 1.0 when release 4.0 (three releases removed) becomes available. A common and contractual practice among software vendors is to support the current release, and the previous release. For our example company, release 1.0 is no longer supported. Further compounding the problem is that our hypothetical company is probably still paying maintenance, yet not taking advantage of it.