I’ll cut to the chase: Most companies running ERP software are overpaying for software support and are not receiving complete or sufficient coverage.
How does this happen?
Consider Oracle’s ERP platform as a prime example. At this writing, the current version is 12.2.7. Yet according to a recent survey, nearly 40 percent of Oracle EBS licensees are in production on EBS 12.0 or earlier. The widely deployed EBS 11.5.10 release, for instance, hit general availability in 2004. Oracle pulled its premier support just six years later in 2010, then dropped extended support in 2013. That left customers, who had yet to upgrade, on what Oracle calls “sustaining support.” At each tier, the level of service declines but the price does not.
This model might not seem unreasonable from the software vendor’s perspective. However, most companies don’t immediately upgrade to a new release. It takes time to get a business ready for a major implementation or upgrade, and some companies like to wait until the riskiest bugs are worked out. Other companies don’t see the ROI in the massive costs associated with these upgrades. Makes sense.
The trouble is, many customers find that just as they are getting comfortable with a stable implementation, the ERP vendor is already reducing or eliminating support and pushing its next release. It’s a never-ending cycle.
It gets worse when you realize that Oracle’s 11.5.10 or 12.1.3, as an example, are excellent releases that do the job. Many companies judge that there are few compelling reasons to consider an expensive and disruptive “upgrade” at all.
In short, reduced and limited support is an apparent software industry technique designed to force companies to upgrade when they don’t really need to.
The High Cost and Risk of Releases Not Fully Supported
Because many companies prefer running their current releases, most ERP vendors will provide minimal levels of services indefinitely, as long as customers are willing to pay the full maintenance rate. Most of these minimal support offerings aren’t typically found to be at all useful. In reality, these incomplete offerings do not include many of the mission-critical features and services that keep your systems running smoothly and in full compliance. You may no longer receive new updates, fixes, security alerts, data fixes and critical patch updates. You miss out on tax, legal and regulatory updates and may not be entitled to new upgrade scripts, or certification with new vendor products or new third-party products or versions. Many industry experts refer to these releases in Sustaining Support as “desupported.” That is, a support contract may be available from the vendor, but as a practical matter it’s not worth much.
If you want to dive into the details of what Oracle offers its customers as Sustaining Support, check out Oracle Software Technical Support Policies. Do not miss the fine print.
Consider this section: “Sustaining Support does not include:
- New program updates, fixes, security alerts and critical patch updates
- New tax, legal and regulatory updates
- New upgrade scripts
- Certification with new third-party products/versions
- 24-hour commitment and response guidelines for Severity 1 service requests
- Previously released fixes or updates that Oracle no longer supports”
With all that factored out, what’s left?
Why Does ERP Code Break?
The main reason for paying for ERP support is to be assured of a swift recovery in the event of a system failure. No CIO wants to be in the position of explaining why the finance department couldn’t do its work at the close of the quarter or a rush of orders couldn’t be fulfilled.
The two biggest reasons for an ERP system to break down after the first couple years of GA (General Availability) once the original software bugs are worked out are:
- You change the code or
- You change the data
You see, software doesn’t wear out like a car for example. It sees new conditions that it has never been tested for before and it breaks.
One of the biggest myths out there is minimizing the use of custom code. Most enterprises find they must do some customization to get beyond the generic capabilities of their chosen software. Yet most ERP companies do not support custom code — the moment they have any hint that your problem has something to do with custom code, they will wash their hands of it.
All of this would leave a reasonable person to think, “What are we paying for?”
Since the software provider typically won’t provide the kind of support that would actually make a difference, customers often have to provide that support themselves — or spend millions of dollars with a systems integrator. They stop calling their ERP software provider because the vendor can’t — or won’t — help. In fact, when I talk to CIOs, I’m astounded at how many admit that they are essentially on a self-support model but feel locked in to paying their software vendor for a support contract anyway, “just in case.”
This is brilliant for the software vendors and provides them tremendous profits, but CIOs are getting wise to how much they have been overpaying and for how long.
Take a Closer Look
If you’re on a stable ERP software release and are paying for diminishing software maintenance and support as well as facing deadlines and poor service, take a hard look at what you’re getting for your money.
Consider everything excluded from the ERP vendor’s sustaining support — in addition to the custom code it never supported in the first place — and compare that to what’s available with the third-party support alternative.
Then ask your internal IT pros how often they call the original software vendor — like Oracle or SAP — for support. Ask how quickly the vendors respond and how often their response solves problems?
Ask them when was the last time they did an upgrade and what it cost?
Ask them what the next upgrade is going to cost and what the business case is for doing it?
Ask them when was the last time they implemented a CPU (or Critical Patch Update) from the vendor and, if so, what it cost in money, time, and effort?
The answers may not be pretty.
