Vendor managers in companies with Oracle applications may have heard a lot of talk about its next-generation applications over the last five years. Well, the news from Oracle’s customer event in San Francisco is that Fusion is almost here. Oracle is extensively demonstrating the product here at the event, early adopter customers are already in the implementation process, and Oracle intends to generally release it in the first quarter of next year.
Oracle hasn’t announced final pricing yet, but Steve Miranda, SVP of Oracle Application Development, confirmed that customers on maintenance will get a 1:1 exchange when they swap the product they own now for the Fusion equivalent. That is good news, although to be fair, my Oracle contacts had indicated this, off the record, all along.
The packaging into SKUs will mimic that of the current product set, to make the swap easier. I.e., the price list for HR will look like the PeopleSoft price list, CRM like Siebel, and so on. That makes some sense, but I wish Oracle had taken the opportunity to simplify the pricing so that there are fewer SKUs. For instance, Siebel's price list is over 20 pages long, and there's no clear link between the the items in the price list and the functionality you want to use. As a result, some customers buy modules by mistake, while others fail to buy ones they really need. Hopefully Fusion will provide a clearer audit trail between functionality and SKU.
Some invited analysts got the chance to quiz the early adopters at a special session. Oracle also invited some representatives of the major services firms, who are all training teams of consultants ready to start work on customizing Fusion implementations. They looked very uncomfortable as the customers’ program managers answered my question, “How are you going to avoid past application implementation mistakes, especially over-customization?” I was delighted to hear all of the customers cite this as a stated goal of their projects and describe what they are doing to limit the partners' involvement.
One key theme was the need for governance, to filter out user requests for nonessential tweaking. As an example, a large European conglomerate (an SAP shop) is implementing Fusion CRM at a software subsidiary. A previous CRM implementation ended up with 80% of the code being their own IP. Now they have a Demand Manager who stands between the users, with their wish list, and the development service provider. Another customer, Eaton Electrical, does a formal risk evaluation of any proposed change. GE Healthcare monitors and reports on the number of customizations. All of them intend to prevent the direct link between user and developer (whether in-house or outsourced) that leads to unnecessary development work.
There’s also a commitment by Oracle to prevent version-locking. An Oracle Fusion insider told me “We’re not going to let the SI’s turn Fusion into multiple unique, custom-developed applications. If the customer needs to do tailoring, we’re ensuring they can do it via code extensions rather than invasive modifications.” This is bad news for those services firms that want to continue "tailoring the system to your unique business needs" (i.e., cementing in the sub-optimal legacy process).
Bottom line: If you're at an Oracle customer, you'll want to find out how Fusion applications figures in your IT road map. And you'll also want to be checking which of your service providers are gearing up to use it to drive transformation, and which merely to drive a new wave of custom development.