User enterprises are becoming more aware of how software vendors' support and maintenance (S&M) agreements affect their bottom lines, and many are not particularly pleased with what they see. For a definition of the problem, please see Will User Enterprises Ever Get onto an Easy (Support and Maintenance) Street? and Support and Maintenance: No Longer the Software Industry's "Best Kept Secret"?
It might be useful at this point to explain, at a very high level, what S&M fees entitle customers to. From the first high-level group of entitlements comes continuing product development, which provides new product features and functional enhancements, regulatory updates (that is, tax table or restricted party table updates), and "bug" fixes.
From the second high-level group, maintenance fees pay for telephone and Internet-based support, and for issues resolution during those "crunch" times (critical moments) when users really need help with the system. Again, no one's intention here is to belittle the need and value of these services, even though the paradox of paying for the software, and then paying again to have the vendor fix defects in it (we earlier agreed that bugs and fixes are a way of life in the industry) is apparent. However, the bone of contention for many customers is that there has thus far been no "different strokes for different folks" (customized or personalized) approach by vendors given the likelihood that each customer has different needs, and uses different product instances for those needs.
A few years back, we reported on top-level user executives' discussions that focused on the value of the maintenance and support they received versus the amount they were paying for it (see The Old ERP Dilemma: How Long Should You Pay Maintenance?). Even then, members of the group thought that they were paying too much for the value of the S&M they were receiving. They believed that either the vendors should give them more value (their preference at the time) or that they should pay less for the vendors' support services. Another option these executives suggested was that they be allowed to pick and choose from the menu of available S&M items. This last option was, in particular, the opinion of the executives of user enterprises that had mature or heavily customized (and thus highly functional) enterprise systems in place.
Ten years ago or more, users were pushing vendors for upgrades in light of the functional immaturity of their systems at the time. Rather than waiting for those upgrades to be developed and released by the vendors, most organizations have since invested in the customization of their software to meet their unique business requirements. These mature releases can thus meet the current and future needs of many clients for up to a decade without the need for costly (and often enforced and mandatory) major upgrades, especially if these platforms are highly scalable and fully tested in the field.
Such existing enterprise platforms have also evolved over the last ten to fifteen years, gradually adding and testing support for nearly every business process in the modern enterprise. These users could now care less for the latest "whiz-bang," "techno" buzzwords thrown around by vendors and analysts as compelling reasons to continually pay for unneeded maintenance and forced upgrades.
Certainly, software applications are dependent on databases, operating systems, middleware, and hardware components. Each of these components has a specified life cycle and support time frame that requires the software to be certified again against newer releases. These components also drive the need for some laggard customers to upgrade, since these components' infrastructures and technology stacks will need to be upgraded to remain supported. Therefore, even if the software remains stable, customers still need to plan to upgrade to have access to support for their overall technical infrastructures. But customers want to do this at their own pace and in time frames of their choosing.
The roles have meanwhile also reversed, whereby now vendors try to impose the latest upgrades onto users, and users see no need for the new enhancements. Indeed, what value can a user enterprise receive from new enhancements if they are either not pertinent to them, or if the enterprise has already created its own work-arounds (that may now clash with these enhancements)? Furthermore, what is the realistic value of these upgrades when the enterprise system is "old," and therefore quite stable and functional (tailored to fit)?
Mature systems require an approach different from newer implementations to software support. The focus must be on customization, interoperability, and performance support. Yet vendors continue to offer the same one-size-fits-all models of support. Several sources tell us that users are now asking that the frequency of new releases be slowed down. As for the promises being made about service-oriented architecture (SOA), it remains to be seen whether a new SOA-based release may not mean a full upgrade, but rather a partial upgrade, meaning less time, cost, and risk for the customer.
Many customers tell us it is too expensive to maintain these "customizations," and that they would prefer to have upgrades from their vendors with their desired functionality included. Customers report that this type of upgrade is preferred so that they can get out of the business of maintaining custom code, but only if the migration would be minimally (or reasonably) painful.
To that end, some vendors, such as Oracle, seem committed to offering their customers ongoing enhancements in support to make maintaining their solutions easier, faster, and cheaper. Oracle has enhanced its Premier Support over the past year with new, automated, and proactive support tools that enable faster problem diagnosis and resolution, along with proactive issue notifications to prevent problems before they occur. It is not "support as usual" anymore. Oracle (and other vendors for that matter) also offers more customized support via enhanced support levels, such as Oracle's Advanced Customer Services. These services provide support personalization, faster problem resolution, custom solution support centers, and other services to meet customers' unique support requirements.
Examining the Maintenance Agreement
In any case, the group of executives mentioned above discussed the various items they viewed as part of the maintenance agreement.
The first item was technical support and problem resolution hotlines, whereby the vendor supplies a hotline, call center service (24x7x365, if at all possible). Users and information technology (IT) staffers can call and get answers to mission-critical questions. Business-related issues from the use of software are a daily occurrence in any business, and these issues may be the result of flaws or bugs in the software, confusion about how the software works, or both.
Regardless of the reason, software customers want to be able to contact a qualified expert to discuss the issue and resolve it in a timely fashion, with minimal impact on their businesses. The customer does not really care whether the issue was the result of a bug, or of user error or lack of knowledge. The value of the hotline is based on the quantity of calls made and the quality of the answers received. This is an essential element for resolving software operating problems, whereby service-level agreements (SLAs) for availability and response times vary by vendor, and may be increased for additional fees.
This group of executives felt that their companies had not made that many calls over the last few years, because both the users and the IT department knew the system and did not have that many questions. Use of this service will vary based on the technical competence of internal staff, and on the stability and maturity of the software release. These executives' experiences show us that change is what drives the need for the hotline.
Some example scenarios of change would be if an enterprise plans to modify how it uses or reinstalls a module, or if the enterprise installs a new release within the next year. Such changes will likely increase the enterprise's need for the hotline. However, some users might eventually begin to feel that they know more about the system than the vendor's support staff does. Indeed, some surveys show that as many as 70 percent of enterprise software customers are disappointed with current service levels.
Software vendors need to provide unlimited access to support services that includes experts that are trained in the detection and repair of design flaws in the software. These experts must also be able to explain—in layman's terms—how to get the software to perform the strategic functions that the customer requires it to. Further, while it is necessary to clearly spell out what the customer is entitled to at the time of creating contract proposals and renewals, no one wants to have to read the fine print during an emergency to check how many calls the customer is allowed free of charge.
Fixes and patches is another area covered on maintenance agreements, whereby the vendor commits to fixing system bugs. Patches can be downloaded and applied as needed to fix known bugs, or they can be consumed in bundles as service packs. The customer's need for these corrective measures is naturally at its highest within the initial year or two of the release life cycle, but that need declines as the software matures. The fact that the system is "old" means that it has relatively few bugs, that the code is stable, and that the user company is not altering how it is using the product very much. Although these executives saw the value of bug fixes, the low number of bugs in their systems had made this part of the maintenance service seem more like an insurance policy benefit. What this means is that the older the code is, the lower the value of maintenance. However, the older the code, the higher the customer's risk is if system upgrades are made that require changing the code.
New releases, upgrades, and enhancements is the next area this group discussed, whereby the vendor provides periodic new releases that offer enhanced technical and functional capabilities. If users usually adopt these software enhancements, then this section of the S&M agreement enables them to extend the business value and technical viability of the applications.
Based on the extent of modifications the user enterprise has made to the system, the cost of accepting a new release varies considerably, and this cost directly impacts the relative value of the new release (see The Old ERP Dilemma—Should We Install The New Release?, The Old ERP Dilemma—The Refresh Option, and To Upgrade, or Not To Upgrade: That Is Not The Question—But How To Upgrade Is). Many customers thus have difficulty justifying the substantial cost of implementing major upgrades, and they will resist doing so without a compelling reason (other than vendors mandating these upgrades).
The executives questioned the types of enhancements included in new releases. For many of these users, the important features that were missing for their implementations had already been added either as custom codes or with the addition of third party solutions. Therefore, the addition of those features in new releases or upgrades had little value, since, ironically or not, vendors typically assess and categorize issues and enhancements in a multi-tiered escalation process. What's more, vendors often push fixes and enhancements to future releases, thereby leaving customers to make do in their current environments.
By definition, other added features have lesser value. Understandably, it is difficult and costly for vendors to add functions to the "guts" of a product, even though these functions are the exact enhancements the users need the most. Yet when this does happen, most vendors take high-value enhancements out of maintenance upgrades included with annual support, and then enhance and package these upgrades as separate, newly licensed products (or modules). Based on this discussion, it is evident that the value of new releases is dependent on the particular situation of each company.
IT infrastructure and compliance updates, a category of bug fixes or enhancements, covers the issue of matching changes in the underlying IT infrastructure (that is, supported databases, operating systems, application servers, etc.). Depending on the infrastructure in place, this could be of significant value to some companies. Yet others may be unwilling to pay their vendors to port the software onto a new operating system (OS) or a new server platform if the value the software provides has not really changed. These companies might be willing to pay their vendors for more functionality that drives additional business value, though. But even for the value-adding enhancements, customers want to pay only when they are generally available and required, and not beforehand while these enhancements are still in development.
Further, updates to tax, legal, and regulatory aspects are essential for applications that are compliance-driven, such as human resources (HR) and payroll, or new product development and introduction (NPDI) in regulated industries. Customer requirements for this element of maintenance vary based on the application type and the stability of the regulations in the applicable legal jurisdiction. Regulatory changes, such as those mandated by the US Food & Drug Administration (FDA), Health Insurance Portability and Accountability Act (HIPAA), or Sarbanes-Oxley Act (SOX) can certainly mandate changes to business processes (see Thou Shalt Comply (and More, or Else). We believe that infrastructure and compliance are the major reasons people take out this insurance policy.
The miscellaneous part of the maintenance agreement is where vendors may offer such services as seats at user conferences, online frequently asked questions (FAQs) facilities, newsletters, etc. Online content might provide a variety of useful elements, including user and technical documentation, product enhancement and support schedules, application use and deployment best practices, online communities, and other content. If some of these services are not tied to the agreement (for example, user groups), the value received is either of a knowable value, or it is questionable. The value of other (miscellaneous) services is based on the content versus the need for that information. In other words, even though the amount and relevance of the content may be substantial, many customers use it infrequently.
Still, although software vendors understand the above market dynamics, and although new sales continue to be hard to come by, vendors are turning their attention to their maintenance business as the easiest way to increase their revenues and profits. One might begin to wonder why vendors continue to "squeeze" customers (force them to pay more) despite the common wisdom and current market catalysts that indicate otherwise. Maybe owing to a somewhat improved business climate, vendors are finding that they do not need to compromise as much as they might have when the economic climate was sluggish. Another explanation might be their addiction to these recurring revenues, as irrational behavior is usually associated with any addiction.
But more important, vendors are increasing the price of maintenance to gain higher revenues simply because they think they can. Given that implementing an enterprise-wide system is a huge undertaking for most companies (see The Joy' of Enterprise Systems Implementations), the logic is that few customers are likely to "jump ship" (abandon their old systems), find new systems, and go through the pain, risk, and expense of another implementation just because they are paying slightly more in maintenance fees than they had planned to.
It was indeed interesting to note that some IT executives within the surveyed group indicated that they view maintenance agreements as insurance policies. Because it is hard to predict what and when something could go wrong with a system, these executives felt that paying the maintenance bill lowered the IT risk for their companies. Clearly, this value is a function of how any one company looks at risk—as in how much it is willing to accept. Vendors will continue to play the insurance angle ("would a responsible person drive a car without an insurance policy?"), but they had best have another "trump card up their sleeves" (a more compelling reason for customers to pay for their maintenance agreements).
One-Size-Fits-All Approach No Longer Works
Although many of today's stable software platforms require less support and a different approach, most software vendors continue to offer a one-size-fits-all approach to increase maintenance fees (and to consequently report record profits). Major software vendors view maintenance revenue as a birthright, enforcing burdensome contract terms to preserve revenue without regard for customer cost containment needs.
As indicated earlier, the major contention of some users with mature, heavily customized, and highly functional enterprise systems is that support costs are too high, whereby vendors require customers to pay for costly upgrades. These upgrades are often merely composed of new, "nice to have" features that are not needed or desired by many customers. Extended and lifetime vendor support programs force customers to pay more for less service over time (that is, they force users to undergo costly upgrades, or defectors might pay penalty fees to be reinstated into the current, stable releases).
To address this issue, Lawson Software now offers four levels of support contracts—namely, bronze, silver, gold, and platinum—whereas SAP's tiered approach can be seen at No Yawn Intended: Enterprise Applications Giant Introduces a Mid-tier Support Choice. Some vendors are beginning to see a trend of "outsourcing" modification support, hosting, etc. as an extension of maintenance. Oracle offers customers five years of Premier Support. For specified releases, the vendor offers the option of Extended Support for an additional fee. Alternatively, if the customer does not choose Extended Support, or if the support is not offered, the customer may migrate to Sustaining Support.
Possibly the most feared notion of a vendor's existing users is the one of funding the vendor's new product developments. Specifically, more and more customers bemoan covering the future developments of a few early adopter customers if they themselves will not likely need any additional functionality or the latest technological "bells and whistles" any time soon. This is akin to the way health insurance plans operate, whereby a majority of fairly healthy folks have to pay for a few kidney transplants or for cancer patient treatments. Another example is car insurance, whereby a majority of decent drivers have to pay for a few trespassing road hogs.
To be fair, some vendors that focus on only a few related industries, whereby the close-knit install base largely benefits from most product enhancements, do not have such issues. For instance, IQMS claims a coveted 98 percent customer retention rate, and has hardly any issues with the value of its S&M programs.
It is quite the opposite for many upper tier vendors that attempt to cover even thirty disparate industries while at the same time fiercely competing over the next generation of software platforms. These vendors use maintenance fees to fund new developments. Many customers realize that market battles over application architectures, new middleware, and SOA technology standards will take at least a decade to play out (see Architecture Evolution: From Web-based to Service-oriented Architecture). Last but not least, many customers are concerned that if they align with one vendor now, they will be left with a weak or unviable solution in the coming shakeout.
Thus, although customers with existing enterprise systems are a "locked-up" audience, they can remain as such only to a point. If vendors continue with the practice of playing hardball, there will likely be repercussions (in terms of defections). Again, there has to be a limit to what the market will bear, and in the not too distant future, something will have to give. A study by AMR Research in 2004 found that because of unsatisfactory vendor maintenance policies, 22 percent of customers were considering switching vendors, 21 percent intended to stop taking upgrades, and 12 percent would discontinue paying maintenance.
A more recent survey, however, shows a sharp change in attitude, with 40 percent of respondents having no issues with their vendors, as compared to only 12 percent in 2004. This shows that vendors might be doing something right or something better, although 5 percent of companies stated their intentions to switch to third party service providers. This option was never really available to customers earlier. In a similar survey taken in 2005, when asked for a preference for maintenance and support, 18 percent of respondents said they would like to buy it (support, bug fixes, regulatory updates, and even enhancements) from a third party. The majority of respondents though (75 percent) still preferred to stay with their current vendors.
This is part three of the series Will User Enterprises Ever Get onto an Easy (Support and Maintenance) Street? In part four, alternatives to the traditional vendor support and maintenance agreements that are now available to user enterprises will be looked at.