The Oracle of SRM (Part 2)

If you took a financially driven portfolio perspective to product development in overlapping business areas, how would you allocate R&D dollars, not to mention funding and choosing platforms and initiatives? Chances are that you'd create an approach that looked at how to maximize potential returns while creating the minimum amount of risk to the business, investing only the bare minimum necessary to keep the installed base happy and to attract new customers.

The biggest problem with this model is that it is conservative and assumes market maturity will trump innovation. In other words, it sacrifices (or delays) functional leadership and advancement at the expense of security and cash flow. If you guessed that this is how the Oracle private equity fund (my name for the Oracle applications business) is allocating development dollars in the procurement and sourcing areas, you'd be correct. They are in fact allocating R&D dollars across four separate product lines which each have separate product management and development organizations. To wit, Oracle eBusiness Suite Advanced Procurement (R12), PeopleSoft SRM (9.0), and JD Edwards Supply Management, and the Procurement and Sourcing Fusion suite are all being developed independently.

Now, in the financial world if you're looking to diversify returns, this strategy might make sense. But if you're competing against an applications giant (i.e., SAP) that has centralized development efforts on a single platform --or is at least moving in that direction -- you'll be at a functional disadvantage, at least at some point in the future, given the traditional applications paradigm (SOA could change this, but don't bank on it in this decade or next).

Today, given this development strategy, Oracle essentially has three products with different functional footprints. Oracle R12 has a lead on the rest in terms of procurement and sourcing capability. PeopleSoft has solid integration with the rest of ERP package, a good UI and finally (with 9.0) moderately acceptable core procure-to-pay and contract management capability (that would not cause an eBusiness Suite developer to laugh). JD Edwards functionality is generally rudimentary, but appears easy to use, and would most likely be fine for many middle market companies.

All of these eProcurement modules lag best of breed vendors in general (see Forrester's upcoming report next week on eProcurement if you're interested in why, or call me for my opinion), but Oracle R12 is really a decent package, although you can't upgrade to it alone -- you need to upgrade the entire Oracle eBusiness suite (and if you need to take down HR or financials to do maintenance, guess what else is coming down as well, thanks to that great "single instance" invention).

Relative to where SAP is headed this year, Oracle is especially vulnerable in one major area where they're exposed to their opponent: spend visibility. SAP has been scouring the earth in the past couple of months, talking to virtually every independent spend visibility provider left to mesh together a new capability that will work in a heterogeneous environment. Look for them to announce this Frankenstein's spend monster at Sapphire (with either acquired or OEM components -- I'm not sure which). Oracle, in contrast, has great spend visibility capability already ... that is, if you're running a single instance of Oracle, your P-Card is Oracle, and your data is perfectly clean and already classified. Then Daily Business Intelligence is a perfect solution to all your spend visibility ailments.

Outside of spend visibility, Oracle and SAP both have come a long way in core procurement capability (though both lag best of breeds here, still). I give SAP the nod in sourcing (given the Frictionless move), but this is still a beast with many heads from an architectural perspective (at least Oracle Sourcing is developed on a single, integrated platform today).

Jason Busch

Discuss this:

Your email address will not be published. Required fields are marked *