How Vendors Get Customers To Buy Immature Applications

Executive Summary

• Vendors consistently push their customers to purchase immature applications.
• Considering the implications of implementing immature applications.

Introduction

IT buyers often fall into the lab rat trap. They adopt new technology too early and end up with a test lab for vendors and a training course for consultants.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Lack of Financial Bias Notice: The vast majority of content available on the Internet about Oracle is marketing fiddle-faddle published by Oracle, Oracle partners, or media entities paid by Oracle to run their marketing on the media website. Each one of these entities tries to hide its financial bias from readers. The article below is very different.

• This is published by a research entity, not some dishonest entity that is part of the Oracle ecosystem. 
• Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on Oracle is provided by Oracle, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, Oracle pays off all IT analysts -- who have the same concern for accuracy as Oracle. Not one of these entities will disclose their pro-Oracle financial bias to their readers. 
•  

Innovative Versus Commercial Grade Products

There is a TITANIC difference between innovation and commercial grade products. New enterprise products need years of field testing to reach a stable release.

In the early stages of the technology adoption lifecycle, early adopters have to deal with an endless stream of:

• Software bugs
• Unstable code libraries
• Poor system performance
• Too many patches and updates
• Too many functional changes
• No roadmap

The Technology Adoption Curve

When “innovation” is deployed in an experimental area of the business, the risk of disruption is minimal. However, when applied to a business-critical function, the disruption to business continuity is often devastating.

The bigger problem is when the technology is offered as an implementation project. Projects are bound with time and cost constraints. When a new product is being functionally updated every other month, implementation rework never ends. After each vendor update, everything from requirement analysis to testing must be re-implemented.

Moreover, a project based on new products runs the risk of hiring consultants with no prior field experience. In effect, the consultants are learning how to implement the technology for the first time at the client’s expense. This often leads to cost overruns, poor quality, and higher failure rates. By their very nature, new product implementations offer no budget overrun protection.

Many “cloud vendors,” for instance, are themselves very late adopters of cloud technology. They are late adopters because, as a business, they’re very risk-averse. They expect their customers to be early adopters. In fact, it is well known that Oracle is quite backward technologically internally. Their approach is to push disruption onto customers but not to do so themselves. This is odd, considering Larry Ellison’s famous quote is that one needs to..

“Eat our own dog food.”

Championing disruption is an easy target to set for outside entities. That is when the vendor doesn’t have to bear the cost of business disruption.

Customers Views on New Applications

Customers are often of two minds of applications. The new advertised capabilities entice them, but the vast majority of IT buyers are not internally configured to deal with immature applications in our experience. The mistake that vendors and consultants frequently make is that buyers of software are typically far less interested in software than in their own business problems and opportunities. They look at software as an enabler, not something they want to spend a lot of time tinkering with to get to work properly. In fact, the common complaint within IT departments is that they spend so much time managing existing investments that they have little time to evaluate new investments. If one looks at the staffing of IT departments, one sees the limitations in terms of companies’ willingness to invest in problematic applications.

Understanding the Immaturity of Applications

So many immature applications get into companies because their immaturity and maintenance are understated to customers as a natural course of the sales process. Once the implementation begins, the consultants are told not to let the customer know the application’s actual maturity level, as it will undercut the confidence in the project.

Who Tends to Push Their Customers to the Most Immature Applications?

Application maturity is a lesser discussed topic but is probably the most important factor to implementation success. Implementing an immature product is like riding a partially built motorcycle. However, unlike the example of a partially built motorcycle, it is more difficult to determine when the software is incomplete.

The largest vendors tend to get away with introducing the least mature applications. SAP commonly introduces immature applications with great fanfare, and they make no apologies when the application does not work properly. The largest software vendors can do this in part because they have an army of consulting firms that will support the vendor’s views on immature applications and will be the first to blame the client for failures, no matter how immature the application. That is part of their job. To pimp their application brand, regardless of what is true — and to do otherwise is considered disloyal.

The Immature of a Well Known SAP Application

For example, Brightwork Research and Analysis covered the numerous maturity issues with S/4HANA in the Study into S/4HANA Implementations. This was while all the SAP consulting partners were telling their clients why they should migrate to S/4HANA. It also came out that not only was S/4HANA immature, so were other components that supported S/4HANA.

Immaturity of Oracle Applications

Another major vendor that has a habit of pushing customers to immature products is Oracle. Oracle has been pushing its customers to use its barely functional cloud products for over ten years. Oracle’s successful applications are their old and acquired, and Oracle has a challenging time developing any new applications of any maturity or uptake on the part of customers. This is one reason we have been recommending migrating Oracle applications to the cloud and not using Oracle Cloud in any way. This was one of our book’s themes, How to Leverage AWS and Google Cloud for SAP and Oracle Environments. One can migrate Oracle applications to the cloud without Oracle’s involvement. No need to use Oracle Cloud and accept Oracle’s immature applications.

How Executive Compensation Helps Drive Immature Product Introduction

It should also be understood that a major motivator to get immature applications into customers is the stock market. The primary reason Oracle wants its customers to use immature cloud offerings is that Wall Street wants to see cloud sales. SAP works the same way. The strategy is optimized around the stock options of the people at the very tippy-top of these companies. These types of people don’t care if an application is immature or has implementation issues — those are issues for little people. The critical issue that consumes SAP is Rob Enslin getting to sell his options at the right price. When looked at through a person’s eyes with many millions of dollars in stock options, one can begin to see why the largest vendors introduce such immature products to their customers.

The Brightwork Approach

When we support IT procurements, we frequently have to move the discussion back to the topic of application and database maturity. SAP and Oracle will pivot the discussion to the roadmap and away from the application’s maturity. Statements around..

“XYZ is the future,”

..and that

“our support for the current product will be dropped.”

These pivoting statements are designed to get the customer to only think of the plans rather than what can be implemented. We already know the maturity of SAP and Oracle’s products as we do research full time. However, new items are being introduced all the time, and that causes us to go back and analyze a new product.

Maturity must be investigated before any negotiation on items to be purchased can begin.