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.

Skipping releases can be a Catch-22. Companies think that by skipping a release, they are saving themselves the time, expense, and aggravation of an implementation project. This is probably not the case. As stated above, new releases include new data elements and new functionality. A company would have to run the conversion routines to go from release 1.0 to release 2.0, from release 2.0 to release 3.0, and so on. The jobs have to set up, tested, and run. There are no time savings here. New functionality still has to piloted, tested, and verified. When catchweight (pricing meat and poultry, for example, by actual weight, not container size) was introduced for the food industry, many vendors implemented this functionality in phases in their rush to market. The first phase (probably in release 2.0 for our example) was to capture catchweight as new data element. The second phase (release 3.0) was to incorporate catchweight in the cost accounting routines for production material. The final phase—release 4.0—was to incorporate the supply chain links. In our food industry example, it would be extremely prudent to verify the accuracy of catchweight in each release, since heavy reliance and forecasting decisions would be placed on this new functionality. Again, there are no time savings here. Similar arguments could be made for enhancements and technology changes.

Surely certain phases, particularly training, can be eliminated or significantly reduced. However, a company would be concentrating significant manpower for a prolonged period of time by dealing simultaneously with multiple releases. There may be overwhelming factors, such as new product development or advanced marketing programs, that fall outside the bounds of an ERP package. These factors may necessitate a delay in implementing a new release. However, foregoing these factors, the tradeoffs offered by skipping new releases do not warrant this tactical approach.

Findings and Recommendations

When undertaking the purchase and implementation of enterprise-wide package solutions, the project extends well beyond the go-live date. Even if the initial implementation takes nine months, a company needs to commit to personnel and project plans stretching several years into the future.

Assuming that enhancements are non-existent or minor, service packs should be dealt with as they are released. Companies should be able to install service packs with minimal testing and user training. Service packs should fix problems, not create new ones. If this is not the case, companies should seriously consider what the annual maintenance fees are for, and have a heart-to-heart meeting with their software vendors. If enhancements are significant, they might want to question their choice of software package. Furthermore, the degree of difficulty and amount of time for implementing service packs under this scenario will be more closely aligned with that of new releases.

By their nature and scope, an implementation of a new release involves a more complex project, timeline, and use of resources than the service pack. Given the absence of competing and compelling business conditions, new releases should be budgeted for no more than one a year. If the rapidity of new releases is greater than one a year, the user group needs to meet with and rectify this condition with the software vendor. Companies should not be a continual state of implementation, even if they have formed a project team for this purpose. If new functionality is packaged properly, new releases can be scheduled in intervals of eighteen months, with the concurrence of the user group.

As has been discussed, skipping and combining releases may not deliver the expected benefits. Essentially, the time saved may not be significant. In addition, a project to accommodate multiple releases will have a greater degree of difficulty. This fact is illustrated in the chart below.

Managing enterprise applications and corresponding new releases is no "walk in the park." Just implementing new releases is a complex and time-consuming part of an IT department's scope of responsibilities. Many IT departments are not staffed for this scope, and forget to budget and manage for it in the future. As a result, companies are taking a strong look at outsourcing new ERP release management so they can refocus their efforts on revenue-enhancing initiatives.

As vendors have begun componentizing their software suites, the appealing paradigm of free upgrades is being revaluated. Moving away from all-inclusive suites of software, enterprise software vendors are starting to charge new license fees for the new components (or SOA functionality) as they are developed. How these components are to be integrated with existing software suites is giving chief information officers (CIOs) more gray hair (of what little they have left). Many companies cannot afford to upgrade to the newer, componentized version of the vendors' software solutions, and if they could, they would have to pay a new license fees for their difficulty. This transition may force more companies to go off maintenance, via the simple reasoning, "Why pay for something that we can never get to use?" But that's another story for another day.

The bottom line is that managing new releases and implementation of enterprise-wide software must be considered when reviewing the cost justification of the initial purchase of the software. This consideration will not necessarily alter your decision to pursue an ERP solution, but it will definitely alter the calculations of your return on investment (ROI) and payback years.

The chart below helps you gauge the level of effort required by upgrade type, and provides an overall summary of this research note. It reflects the time needed for retrofitting enhancements, since this is directly proportional to the difficulty and scope of the enhancements. The as-is, to-be, and gap analysis phases should be completed by reviewing the release notes and then making a determination if a more in-depth analysis is required.

The implementation tasks have been assigned a degree of activity of low, moderate, or high. We can make these general assignments of effort:

• Low activity requires a labor-week or less of effort.
• Moderate activity requires a half labor-month or less of effort.
• High activity requires a labor-month or more of effort.

Based on these assignments, at the low end for a service pack upgrade in an environment of no or minimal enhancement, the project can be completed in a month or less. Conversely, at the high end, for a new release in a heavily enhanced package solution, the project can take as long as four months. But remember you must add in the effort to retrofit the enhancements, which more than doubles the project timeline. Use these estimates as a guide to perform a reasonable test of your project. Finally, some of you may say that the concepts discussed in this research note are easier said then done. We are in total agreement. However, if you set the expectations of the user community beforehand, that an enterprise-wide package implementation is not a "one and done" project, and clearly outline the pitfalls of not implementing or skipping future releases, you may find yourself closer to the desired target.

SOURCE :http://www.technologyevaluation.com/research/articles/to-upgrade-or-not-to-upgrade-that-is-not-the-question-but-how-to-upgrade-is-18816/