Attempting to Be the Oracle of Oracle Spend Management (Part 4)
The R12 Purchasing module forms the core of the R12 procurement suite. Here, the application serves, in Oracle's words, as the "primary interface to set and enforce procurement policy." Central to R12 Purchasing is a "Professional Buyer's Work Center" concept that brings improvements in the area of UI, hierarchy and process management. The new HTML-based UI within Purchasing provides tighter linkages to other R12 procurement modules and capabilities including surveys, scorecards, daily business intelligence, sourcing, etc. Some of the more important enhancements in R12 Purchasing include multi-organizational support for companies running a shared-services environment -- or one that requires centralized administration with decentralized execution. Integration with Oracle's e-Business tax module also now ties current tax codes and group computations within the procure-to-pay workflow, potentially eliminating manual rework. Perhaps the largest enhancement to R12 purchasing are new services procurement capabilities. But these warrant another post entirely. While I would not yet run out and recommend Oracle R12 services procurement over Fieldglass, IQNavigator, Click or ProcureStaff, it's a novel effort -- especially for an eProcurement vendor. Even SAP SRM 7.0, which will not go G/A until next year, does not quite match the capabilities in R12 that Oracle developed nearly five years before.
I briefly mentioned Oracles new optimization capabilities in a previous post, and it's worth quickly revisiting here. Based on an ILOG solver -- as are virtually all of the other sourcing optimization capabilities in the market -- R12 sourcing allows users (who have licensed the optimization package separately) to create scenarios and define basic buyer/supplier constraints at the item level. It also lets users perform what-if analyses across basic scenarios (e.g., split of business). All in all, not a bad little optimization feature set.
So how do all of these enhancements stack up to the competition? First and foremost, it's worth reiterating that R12 is a giant leap forward, but all of these capabilities are only available if you're running the same version of Oracle financials. Also, there are some challenges of the mythical single instance. By example, if you need to take down accounting, HR and procurement are going to come down as well. This approach also makes acquisition integration challenging -- unless of course, your target company happens to be an Oracle shop running the same version of the applications. But having said this, Oracle R12 procurement does compare favorably to SAP across the board -- and is superior to SAP SRM 5.0 in a range of areas. SRM 7.0 is a more difficult comparison because the final version is not out yet. I suspect in SRM 7.0 SAP will finally bridge much of the gap in the area of services procurement, but from what I've been able to glean, Oracle will remain ahead in this area. But I would give SAP the nod from an operational procurement perspective in its latest release.
What about Ariba, Ketera, Coupa, Global eProcure, Enporion, BasWare and other eProcurement competitors? I'd suggest that in each case, companies do some serious comparative work to understand the relative strengths and weaknesses of Oracle R12 compared to the others. Still, it's worth calling out that Oracle has done a noteworthy job bringing together a catalog-based shopping environment with the concept of helping the professional buyer spend less time managing the everyday transactional details while retaining the capacity to intervene when necessary. And a final thought -- if you like the look, feel and general capabilities of R12, but you're on a budget (and are willing to forgo some flexibility and functional breadth and depth), then it's worth taking a specific look at Coupa, considering that its entire management team was the development brainchild behind R12. Coupa represents their latest thinking.
- Jason Busch
So, what I'd like to see a discussion on is where the Portal approach makes sense. Seriously, please argue me off my high horse. If we consider the P2P process success as dependent on adoption by suppliers, then why would we advocate for independent buying organizations to build portals one-by-one? If that happens, don't suppliers then have to deal with each of their buyers' portals individually?
I understand that the portal approach made sense before some Networks got to a critical mass, but now that at least a couple Networks are standing on their own, isn't it time to jump in?
(I ask because I want to water down the kool-aid I've been drinking, I guess).
A strong supplier portal infrastructure is still required - i.e., who gets access to what types of info, what roles exist, what apps per roles, what data types, how is it accessed, based on what context/activity, etc. You still need that even if you use a supplier network to do hosted document exchange with trading partners. Now, if included mulit-tenant hosted apps or set of content services as part of this, ok, but then it's more than a network.
The discussion is more about whether point-to-point is better than hub-and-spoke. Until standards are really defined and adopted by the trading partners - allowing plug and play tranding partner connectivity (aka a very long time from now) - hub-and-spoke will be a more useful model.
Thanks for the thoughtful response. The Kool-aid is a little less sugary to be sure.
I guess I am thinking more of the value-added network when I'm speaking (where, as you say, hosted apps and content services with collaboration too, are included). So there's that.
And by standards, aren't we talking about cXML, PIDEX, xCBL and things like that? Ultimately, some of these touchpoints are relatively easily mapped because the docs that are traded are so well defined by centuries of evolution, no? We're talking quotes, catalogs, requisitions, P.O.s, receipts, invoices and remittances, right?
I agree you need a hub-and-spoke network with standards to be able to allow Supplier A to get a common interface to multiple of his customers, but we'll wait forever if its standards that are holding us back, I think. At least with the easy stuff like P.O.s and Invoices many of the "recently large enough to matter" networks are there already, aren't they?
Supplier collaboration is much more than document exchange, first. But for document exchange, will your supply base invest in the extra effort to work in a network mode? Your local marketing service provider probably won't be excited to log into any portal or network to pick up their orders and send invoices. They'll tell you just to email/fax the order and they'll do the same on the invoice. Unless you've got the muscle (ie., you are big), that probably won't happen. For those big suppliers that already support an XML standard, is the value of the network there when machines can talk without the intermediary? The best networks seem to provide significant services to help their trading partners write to a common format and have invested in building a large community of enabled members.
Then for other points of supplier collaboration, the common standards aren't there. And more importantly, you see buying organizations that have unique needs and business processes that won't fit well into a common denominator network. An example is Aravo's signing of GE where GE has their 500K suppliers log into their portal to enter information, but still gives GE the workflow control they need on the back-end. My opinion is that portals tend to win out in other collaboration forms.