The Old ERP Dilemma: How Long Should You Pay Maintenance?

  • Written By: Olin Thompson
  • Published On: February 8 2002



Introduction

I recently had the privilege to sit with a group of about a dozen IT executives. What they shared was a common ERP system. Most people would think their ERP system was old" (it was introduced in the 80's and the average length of time that these companies had been using the product was approximately eight years). Over the last few years, most of the individuals in the group had faced the issue of replacing their existing ERP system (see The "Old ERP" Dilemma: Replace or Add-on) and each had decided to keep their existing system. These individuals were now facing a new decision, how long should they continue to pay the vendor for maintenance?

Although our group of IT executives was discussing their individual but common situation, their discussion can provide some valuable insight to others facing the same question.

What's the Value Proposition?

The discussion centered on the value they received versus the amount they were paying. The group thought that as of today, they were paying too much for the value they received either the vendor should give them more value (their preference) or they should pay less. What is the value you receive when you pay maintenance and what is the realistic value when the ERP system is "old"? The group talked through the various items they see as part of the maintenance agreement.

If you are questioning the value proposition of maintenance, an early step is to call in your vendor. Ask the vendor to justify the amount of money you pay versus the value you receive.

Hot line The vendor supplies a hot line service where users and IT can call and get answers to questions. The value of the hot line is a function of the quantity of calls made and the quality of the answers received. The members of this group felt that their companies had not made many calls over the last twelve months because both the users and IT knew the system and they did not have a lot of questions.

The vendor's tell us that the event that drives the need for the hot line is change. If you plan to change how you use or reinstall a module or go to a new release in the next twelve months, this will increase your need for the hot line. One CIO commented, "I am not impressed with the quality of the answers we get, I think we know more about the system than they do." The majority of the group concurred with this comment.

Fixes The vendor fixes bugs as part of the maintenance agreement. The fact that the system is "old" means that bugs are relatively rare. The code is stable and any one company is not changing the way they are using the product that much. Although the group saw value in bug fixes, the low volume of bugs made this part of the maintenance service more of an insurance policy benefit.

New Releases The vendor is providing periodic new releases. Based upon how extensively the individual company has modified the system (see Should You Modify an Application Product?) the cost of accepting a new release ranged from a small effort to a very large effort which has a direct impact on the relative value of the new release. The group questioned the types of enhancements that were part of the new release. For most, the important features missing for their implementation had already been added as custom code or the addition of a third party solution. Therefore, the addition of those features had little value. By definition, other added features had lesser value. One IT executive added that it is understandably difficult and expensive for the vendor to add functions "in the guts" of the product, but that was exactly the enhancements she needed most. It was clear from the discussion that the value of new releases is very dependent on the individual situation of the company in question.

IT Infrastructure A category of bug fix or enhancement that they group did not spend time on was the issue of matching changes in the underlying IT infrastructure (databases, operating systems, etc.) For this group, they shared a stable platform. Depending on the infrastructure in place, this could be a significant value to some companies.

Insurance policy One IT executive stated that she saw the maintenance agreement as an insurance policy. She did not know what could happen, but she felt that paying the maintenance bill lowered the IT risk for her company. Clearly, this value is a function of how any one company looks at risk — how much are they willing to accept?

Other Some vendors offer seats at user conferences, on-line FAQ's, newsletters, etc. as part of their maintenance agreements. If some of this is not really tied to the agreement (user groups for example) the value received is either questionable or of a knowable value. The value of other services is a function of the content versus the need for that information.

What are the options?

Three options exist for any company contemplating discontinuing maintenance of an application product. In all cases, you need to talk to the vendor to fully understand your options.

Continue A company can continue to pay the maintenance, in effect deferring the decision on a yearly basis.

Renegotiate If you are not satisfied with the value proposition, try to change it. Will the vendor give you more value or reduce the price?

Discontinue If either of the above options are acceptable or fail to provide an acceptable value proposition, you can always discontinue the maintenance agreement. A key question, that vendors typically do not like to discuss, is how expensive it will be to go back on maintenance if you decide to drop it. Some will say that you cannot go back on maintenance, but the phrase "money talks" is a key one to remember. Most vendors will allow you to go back on maintenance if you pay a penalty and come up to a supportable release level. Understand this option before you make a final decision to drop maintenance.

If you drop maintenance, what then?

Your software will still require some maintenance. Questions will need answering, modifications and core code will need both bug fixes and enhancements. How will you provide for what you need?

Some companies decide to go it alone, providing for what they need from internal resources. This has proven to work, but places a risk of losing the normally few IT people who understand the software. It is also true that IT professionals often like to work on newer technology versus supporting older technology, can you give the internal resources the job satisfaction they need to continue providing the support required?

Some companies go to a third party to get the support they need. These are typically consulting companies who have a critical mass of individuals with strong backgrounds in the product. The risk in this relationship is the retention by the third party of the individuals in question.

For some application products, options exist to outsource this support to a company that actually focuses on the support of the product. Since these companies tend to have both more customers with the specific application product and access to a greater pool of talent experienced in the product, the risk is usually lower and the level of customer satisfaction higher.

Summary

How Long Should You Pay Maintenance? No one answer is right for all situations. You need to consider the value you receive from the various components of your maintenance agreement, the cost of the agreement and what alternatives are available to you. Call in the vendor and tell them what you are considering, give them the chance to explain their side of the story or fix your value proposition. Only then can you answer the question for yourself.

About the Author

Olin Thompson, a principal of Process ERP Partners, has over 25 years experience as an executive in the software industry with the last 17 in process industry related ERP, SCP, and e-business related segments. Olin has been called "the Father of Process ERP." He is a frequent author and an award-winning speaker on topics of gaining value from ERP, SCP, e-commerce and the impact of technology on industry.

He can be reached at Olin@ProcessERP.com.

 
comments powered by Disqus