In the first post in this series, I provided some background, context and a few initial impressions of Ariba's services procurement tool, especially in the areas outside of contingent labor. I'll continue this analysis today as well as provide a set of recommendations as to what types of organizations might be a good fit for it. Picking up where I left off in the first post, I'd suggest the Services Procurement module is of interest to at least 50% of Ariba On-Demand P2P prospects based on what I've heard from Ariba as well as companies looking at their options from Ariba and others (though ultimately fewer end up implementing it). At this stage, Ariba's success with the module usually depends as much on what a prospect's pain point is as how much they're willing to commit to a broad Ariba source-to-pay relationship.
If prospects are looking at services procurement holistically, outside of just contingent labor, then Ariba has a reasonable chance at winning the business, especially in cases where an organization is looking to minimize the number of different platforms it works with. However, I do know of some organizations that decided on Ariba for P2P and chose Fieldglass for both contingent labor and non-contingent labor services spend because of the analytical and reporting capabilities of Fieldglass.
Still, many of the capabilities resident in Ariba are impressive, especially the collaboration features that let internal business users and suppliers -- not just procurement -- work together throughout the services spend lifecycle. Like a handful of some of the other top-notch Spend Management tools, Ariba provides a robust workflow definition and management capability for internal stakeholder collaboration, procurement/supplier collaboration and for financial approvals and payment.
As with some of the other solutions I've looked at recently, I was struck at how easy it has become to configure different fields and requirements on the fly (e.g., specific line-item detail requirements, due dates, spending limits, etc.). But one of the advantages that Ariba Services Procurement clearly has over the competition is its tight integration to the Ariba Supplier Network for supplier enablement, supplier management, document/PO exchange and overall payment and collaboration capabilities.
Having looked at how the module and the network work together, I'd observe that it's about as seamless an integration as possible and has distinct advantages over other non-network -- or non-virtual network, as is the case with Vinimaya for catalog items -- supplier enablement and management approaches. And rest assured, the collaboration, document exchange and overall supplier management requirements in the services arena can be just as big and hairy as those for indirect materials.
Having reviewed Ariba Services Procurement on a fairly high-level (an hour demonstration is never enough time for these sorts of things), it would be difficult to make a number of in-depth generalizations when it comes to recommendations for and against the solution. However, I have also spoken to a number of Ariba customers who have looked at the services procurement capabilities and hearing what they've had to say has contributed significantly to shaping my thinking in this area. Because of this, I feel comfortable suggesting that it's a good choice for many companies going down the Ariba On-Demand P2P path, and that Ariba Services procurement would be a completely logical solution extension for non-contingent labor spend in the majority of cases.
However, for organizations with significant contingent labor spend that want to aggressively pursue programs to not only reduce costs but improve how they buy, I'd probably take a close look at both MSP and non-MSP best of breed platforms to see how they compare to Ariba based on unique requirements (e.g., the level of granularity in reporting required). I'd probably also let my primary MSP make suggestions based on what they're comfortable and experienced working with (if an MSP can't provide an objective answer, part of which may or may not include their own toolset, they're probably not a good partner anyway).
- Jason Busch