Oracle Fusion Runs Into Oracle Apps Unlimited

Oracle is not taking well to a recent Forrester Research report, entitled, "Oracle Dilemma: Applications Unlimited Versus Oracle Fusion Applications."

Forrester's argument in a nutshell is this: based on its survey of  139 Oracle customers, Forrester contends that Fusion has had "low levels of adoption by existing Oracle customers, in part, because Oracle's Applications Unlimited policy has provided them with little incentive to migrate."

Oracle's rebuttal is difficult to put in a nutshell. Oracle goes into great detail, taking issue with Forrester's research methodology, specific survey questions, and the sample size/composition. But in my opinion, Oracle's strongest argument is against Forrester's report title. In Oracle's view, there is no "versus." Customers do not need to make a choice between Apps Unlimited and Fusion. Rather, Oracle points out that it has a co-existence strategy between Fusion Apps and Oracle's existing applications, such as E-Business Suite, Peoplesoft, J.D. Edwards, and Siebel.

I'll leave it to Forrester to defend its own report. However, it is hard to argue with Forrester's conclusion: that Fusion adoption has been slow, in part, because of the success of  Oracle's Applications Unlimited program. To better understand why, it is helpful to review some history. 

The Original Strategy

When Oracle completed its acquisition of PeopleSoft in late 2004, it had two strategic decisions to make.

1. For new customers, would it continue to actively market PeopleSoft and J.D. Edwards (which PeopleSoft had acquired) in addition to its E-Business Suite? 
2. For existing customers of PeopleSoft and J.D. Edwards, would it continue to invest in and support those products indefinitely? 

Interestingly, at the time, the answer to both of these questions was no. As I reported in January 2005,  Larry Ellison held a press conference in which he said that Oracle would not actively market PeopleSoft and J.D. Edwards but would try to push new prospects to E-Business Suite. In addition, he promised to support existing PeopleSoft and J.D. Edwards products only until 2013. "Circle that date 2013 on your calendar," Ellison said.

In the same press conference, Ellison announced Project Fusion, which would be a massive development effort by 8,000 developers to develop a new suite of back-office software products, based on the best features of PeopleSoft, J.D. Edwards, and E-Business Suite. At this point, Fusion Applications were positioned as the successor to Oracle's existing suites. "We expect people to at some point between now and 2013—sometime before that—to upgrade to Project Fusion," Ellison said.

A Mid-Course Correction

By 2006, however, Oracle realized that its strategy was not in its own best interests. By only marketing E-Business Suite, it was missing sales opportunities where PeopleSoft and J.D. Edwards were a better fit than E-Business Suite.

Moreover, Oracle's announcement that it would not support PeopleSoft and J.D. Edwards beyond 2013 took Oracle off short lists where it could PeopleSoft or JDE were good fits. In my own software vendor selection consulting, during the 2005 time-frame, I didn't short list J.D. Edwards and PeopleSoft, for this very reason.

Finally, Oracle's policy put J.D. Edwards and PeopleSoft customers on notice that they might want to consider a migration to products other than Oracle's. With software maintenance fees pulling in over 90% profit, that was the last thing Oracle wanted.

Give Oracle credit for correcting its mistakes. In 2006, Oracle announced its Applications Unlimited program, to provide ongoing enhancements to all Oracle apps beyond the delivery of Fusion. (Siebel, which Oracle acquired in January 2006, was also put under this program.) In addition, Fusion would not be a successor to Oracle's other suites: it would not be functionally equivalent to E-Business Suite, for example. Rather, it would comprise a series of applications, such as CRM and Human Capital Management (HCM) that could be implement alongside E-Business Suite.

The Tradeoffs

Oracle's decision to continue support for its existing applications, while developing Fusion as a set of complementary next-generation applications, was the right decision.

• Replacing Oracle's existing applications suites with Fusion was too ambitious a goal. Thousands of developer man years had been invested in developing E-Business Suite, JDE, and PeopleSoft, which would need to be repeated by Fusion developers. Furthermore, since 2005, Oracle has been continuing enhancement of these products, meaning that functional parity is a moving target. Finally, during the course of Fusion development, Oracle continued making other acquisitions, such as Siebel and Hyperion, further moving the target.
• Customers retain the value of their prior investments. Oracle's existing business suites are not dead-end platforms. The Apps Unlimited program preserves customer investments and keeps maintenance dollars continuing to roll in, which Oracle needs to fund Fusion development. 

But Oracle's strategy comes with a price. In a sense, Oracle's Application Unlimited program has been too successful. By continuing investment in its existing application suites, Oracle gives customers little incentive to move aggressively to Fusion. There is no burning reason for customers to change. To be sure, if Oracle customers are in the market for CRM or HCM, for example, they will have a reason to consider Fusion. But in any given year, this will be a small percentage of Oracle customers.

Perhaps this is the reason that nearly 18 months after Oracle announced general availability of Fusion Apps, Oracle has sold it to only 400+ customers, with only 100+ in production. Oracle refuses to disclose a breakdown of these 400+ customers, but word on the street is that they are heavily weighted toward Fusion HCM.

But there are other reasons that Fusion is not selling as well as one might expect for a product that is 18 months in general availability.

• Fusion is not a complete ERP solution. It lacks core functionality for manufacturing and operational support in other industries. Fusion Apps are, for the most part, really a replacement for pieces of an enterprise suite, a collection of complementary modules. 
• Fusion has functionality gaps. For this reason, Fusion is often sold to new prospects in conjunction with older Oracle products, if at all. For example, in a recent CRM deal, Oracle proposed a solution that comprised pieces of Oracle CRM On-Demand, Siebel, and RightNow. Fusion CRM was not even part of the solution, as apparently it did not satisfy certain industry requirements.
• Fusion is difficult to implement. Anecdotal reports of early adopters indicate that Fusion Apps have a fat footprint. They have complex infrastructure requirements, and as a result, Oracle says that two-thirds of customers are choosing to have Oracle host their systems.

Nevertheless, the success of Oracle's Apps Unlimited policy is the primary inhibitor of Oracle Fusion Applications adoption. Enterprise applications are sticky. It is difficult enough for vendors to get customers make a change, even when vendors announce end of support for an existing product. Imagine how hard it is to get customers to take action when you are promising them continued investment in their existing products. Oracle's Applications Unlimited program--though good for Oracle and Oracle's customers--has served to slow adoption of Fusion. 

Chris Kanaracus at Infoworld has a summary of the two sides of the debate. As usual, Dennis Howlett has his own point of view. Holger Mueller actually thinks it's good that Oracle customers don't know about Fusion.

Update, Feb 19: Floyd Teter has an incredibly informative post on customer options for deploying Oracle Fusion Apps, confirming and going beyond some of my points here. 

Related Posts

Oracle to Steer New Customers Away from PeopleSoft Products
Fusion to Build on Oracle's E-Business Suite
More on Oracle's Fusion Strategy
Oracle's Secrecy on Fusion Specifics
Oracle's Roadmap for Fusion Apps

SAP Goes Back to the Well for a Maintenance Fee Hike

Jarret Pazahanick alerted me to an email that went out this morning to SAP partners, announcing a unilateral price increase on standard support, for new maintenance contracts signed after July 15, 2013.

The email reads, in part,

To be able to provide the same level of support in the future, we will change the maintenance rate for new maintenance contracts with SAP Standard Support from 18% to 19%, effective July 15, 2013.

This moderate adjustment does not apply to any existing maintenance contracts for SAP Standard Support closed before July 15, 2013. We also want to be respectful about budgets being planned for 2013. Therefore, we encourage you to take advantage of the opportunity to place purchase orders with SAP Standard Support ahead of this change at the existing 18% rate until July 14, 2013.

I would point out that this is not a 1% increase in maintenance fees: it is a 5.5% increase (1/18 = 5.5%).

If I were an SAP customer, I would have four questions for SAP:

1. What improvements in SAP support will SAP deliver to justify this 5.5% price increase? Can we expect our internal costs to drop by at least 5.5% as a result of SAP's improvements in its support program?
    
2. What is the gross margin on SAP's maintenance business today, and how will that change after this increase is in effect? Maintenance is the most profitable segment in SAP's financial performance. Why should it become even more profitable? 
    
3. How have SAP's cost of support increased to justify this increase in my maintenance fees? Normally the cost to support mature products decreases over time, as issues with the program code are resolved. Offshoring of application support and deflection of support activities to SAP's user and partner network also have introduced support efficiencies. Shouldn't SAP be considering a reduction in maintenance fees rather than an increase?
    
4. Since SAP uses some of its maintenance revenue to fund development of new products as well as make acquisitions, will SAP provide these new products to customers at no charge? It seems SAP charges customers for new products twice: once, when it charges maintenance fees, and again when existing customers buy those new products. 

Several years ago, SAP customers fought back SAP's attempts to impose a maintenance fee increase by forcing all customers to move from standard support (at 18%) to enterprise support (at 22%). After a great deal of public outcry, SAP backed down.  Now SAP appears to be trying to impose a smaller price increase, with no apparent improvement in service, in hopes customers will not notice.

The only good news in this announcement is for providers of SAP third-party maintenance, such as Rimini Street.

Update: Chris Kanaracus at IDG News Service reports on the SAP maintenance fee hike. Larry Dignan at ZDnet also chimes in.

Update, Feb 5: Dennis Howlett has a deeper dive, and he gets clarification from SAP on several issues. 

Related Posts

SAP backs down on 22% maintenance fees
Mad as hell: backlash brewing against SAP maintenance fee hike