Will Fusion Be In Your Oracle Applications Road Map?

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.

http://www.oracle.com/us/corporate/press/173456

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.

Comments

Hi, Thank you for sharing

Hi,

Thank you for sharing information on Fusion apps.

Can you please provide some information on how do code extensions differ from modificatinos. Can tailoring really be avoided. Do different businesses not have different needs which require different types and levels of modifications. How are Fusion applications different from other applications like Siebel in terms of process of customizing the vanilla application.

Best Regards,
Girish

Avoiding customization

Good questions Girish. I'm afraid I don't have the technical knowledge to answer them fully. From my perspective there is a very fine line between customization, extension and configuration. Any of them can involve altering a business process or writing rules in a rules engine that need the same analysis and testing discipline as coding. One key question is whether the change impacts future upgrades or patch implementations.

Yes, different types of business need different functionality, so a generalist set of products like Fusion will need a lot of extending to fit any specific customer. That might come more effectively from a kind of AppStore of extension products than from each customer reinventing the wheel. Also, it doesnt mean that business users should get every change they think they want. It just makes it even more important to have strong governance over the system implementation partner's activities.

Few points

Thanks for the write up. I was in this analyst session and had good opportunity to extensively browse through Fusion Apps. The pitch on extensibility is actually good. If you look at the current Ramp up and Co-development partners, none practices invasive code modification. The middleware architecture of Fusion allows enough interoperability to communicate with a bolt on apps. That does not modify the inherent logic of Fusion Apps and application sanity is not disturbed.

The entire co-existence positioning will not be successful if this is not allowed. This will help customers adopt the best of Fusion Apps on top their existing legacy apps which may be a bolt on custom developed.

See also Andrew's further analysis

Good points Hirak. My colleague Andrew Bartels develops similar points in his own blog, here:

http://blogs.forrester.com/andrew_bartels/10-09-27-confusion_fusion_apps...

Duncan, Unfortunately, it

Duncan,

Unfortunately, it appears that the link to Andrew Bartels' blog that you've posted above is broken..

Rgds,
Rakesh

Blog link

Try this URL, Rakesh:
http://blogs.forrester.com/andrew_bartels/10-09-27-confusion_fusion_apps...

or use the search facility.

Oracle Fusion Apps ...view point

Following are few of my observations on Oracle Fusion Applications (OFA)

OFAs are built to work both in on-premise and on-demand envrionments. Its multitenant architecture would allow big enterprises to use single code base and database for many business units. Any changes to business processes/workflow to suit to diffrent business units could be done through business rules and configurations rather code modifications/customizations. This needs standardization of Business Processess to the extent possible across business units.

Most of the customers have complaints on user interface of Oracle native Applications like eBusiness. Oracle has changed the UI of OFAs to bring delight to end users

The business processes developed in OFAs are derived from best practices/processes of various products acquired by Oracle and also with other inputs

OFAs are built from ground level as a new product line, they are compliant with many open standards too. OFAs are built on Java and availability of skills is also easy as against proprietary languages

Enteprise 2.0 (Web 2.0) features are integrated as part of Business process which improves productivity and connect with partners, colleagues etc

There is improved business intelligence and seems it is integrated with business processes rather having separate BI applications

Whether Oracle Fusion Applications or any other enterprise applications, Customers and Service Providers have to bring discipline on the following:

1. Change Management Board, Governance and strict adherence to change management process

2. Customizations to forcefit legacy business processes rather implementing innovative new business processes - to change this, needs cultural shift and executive sponsorship

3. Business process standardization for most common processes like HR, Finance etc across different units by breaking the walls between unit/departments. Organizations have to leverage the power of Multi tenant architecture of Fusion Applications

Conclusion:

Rapid adoption of Oracle Fusion Applications might take 3 - 4 years. Till that time, customers might use co-existence strategy.

It is important for customers to devise a road map now with the help of Service Providers/System Integrators to start building the Proof of Concepts and prepare themselves for future

Thanks,
VSR

change at no cost ?

Duncan,
we are considering update. It's great to hear that there will be a 1:1 conversion, but will this also be the case for the technology stack ? We have some experiences with oracle changing technology around ERP modules and we really have the feeling Oracle may use a upgrade to fusion to get new money in ...
Second thought : we are on R11 and our users have got through a change management process, some education effort, business helpdesk support and coaching, .. and they are happy with R11. It's not fancy, it's not the best interface ever... but it works. And changing to Fusion will introduce not only new interfaces but also new concepts ... and this frightens me .