Lions and Tigers and Bears - SAP and Ariba and Fieldglass, Oh My!

What happened?

Last week, SAP bought the farm, or at least they bought Fieldglass.  In my last post, I talked about different approaches to linking purchasing systems like Ariba to VMS processes and technology and Ariba’s aggressive move in expanding into Contingent and Services procurement.

What does this acquisition mean?

I might spend less time integrating Fieldglass and Ariba than in the past since SAP, Ariba and Fieldglass need to have a consistent and well articulated strategy for current and prospective customers.

For other VMS competitors (e.g. IQN, Provade, Emptoris, PeopleFluent, etc.), they need tread carefully as the Fieldglass and Ariba combination with the sponsorship of SAP have formidable assets and a large installed base to tap into.  The competition needs to dance and dance fast to stay relevant!

Existing Fieldglass and Ariba customers need to plan a strategy as to what fits their situation.  Ariba, Fieldglass, SAP and SuccessFactors are a big extended family.  If you’re a SAP true believer, common systems, common architecture, common neck to choke, this blanket all things SAP approach has merits.  But as part of your extended family, you don’t necessarily want to move in with your Aunt Phyllis, just because you share one fourth of your DNA with her.  Or do you?   Big can be good but it can be unwieldy too.  Think and plan first.

How are Ariba and Fieldglass integrated now?

There are really two and three methods Ariba and Fieldglass are integrated today….  Or at least two approaches that I have integrated and then the Aunt Phyllis, old fashioned method.

Ariba punchout to Fieldglass

The first and probably most common approach is Ariba Punchout to Fieldglass Work Orders, Job Postings, SOWs and/or SOW Responses.  In the case of punching out to a Work Order, initially a Job Posting is created, followed by sourcing and then selecting the Worker.  Then somebody in Ariba Punches out from an Ariba Purchase Requisition to the Fieldglass Work Order.  Once the PO is approved, it releases the Work Order to the Supplier. 

Work Order Revisions can be punched out from Ariba Change Orders too in this model.  The problem with this serial process is it takes time to get the PO approved after the worker has already been sourced.  Or cycle times go and you can lose workers. Ditto for SOWs and SOW Revisions.

Fieldglass to Ariba Purchase Requisition

The second approach is using something called “Requisition Import” where a Work Order, Job Posting or SOW is formatted into a common Ariba upload format and then loaded into Ariba from a Fieldglass interface or what becomes three interfaces into Ariba since the Ariba header, line and cost details are split into three file components loaded in sequence.  This means the manager doing the hiring starts in Fieldglass and Ariba becomes an approval tool only.  Once the PO is approved or denied, it’s sent back to the VMS to release the Work Order or SOW.

This approach works great because it provides a mechanism where the worker procures contingent labor or services in Fieldglass, while retaining the approval hierarchy typically loaded with spending authority limits, unique cost center rules, and other industry leading Ariba controls.  Fieldglass is a great contingent purchasing tool, but you need all the master data, managers and rules to make it work and this takes time and requires support.  Since they usually already exist in Ariba already, this Req Import integration makes a lot of sense.

The consideration for Fieldglass being the starting point for entry is now your contingent data has to be clean or things like cost centers, business units, hiring managers all need to be map into Ariba without errors.  Otherwise, you’re fixing draft or composing Purchase Requisitions in Ariba.

Don’t forget the Swivel chair (Aunt Phyllis)

Last, but not least, is the swivel chair where Job Posting and Purchase Requisition data is manually entered into both Fieldglass and Ariba, respectively. Once the PO is approved, the PO number is keyed into Fieldglass on the Work Order or SOW.  Typically a workflow step is in place so that the program office holds the Work Order and keys in the Purchase Order once approved in Ariba.

What about SuccessFactors?

I expect to see Worker integration from Fieldglass to SuccessFactors and maybe a direct integration of user data from either SuccessFactors or SAP into Fieldglass.  Rather than rolling your own, expect the SAP/SuccessFactors/Fieldglass team to build something in the coming years. Customers want to have their entire workforce tracked in one location and with contingent in Fieldglass and permanent populations in SuccessFactors, it’s nice to merge key attributes of each population merged together to get a total picture of the workforce, commonly referred to as Talent Supply Chain Management (TSCM). 

Frequently, both contingent and permanent data is linked into ID Management (IDM) systems for security and provisioning of badges and assets.  Expect to see a marriage of contingent and permanent between applications and probably a Business Object fronted data warehouses.  The SAP umbrella is getting larger and for an enterprise customer, things will get knitted together in time.

What about the Technology?

Ariba On Demand and Fieldglass both are cloud based so it’s a matter of connecting them behind the Cloud curtain.  On the back end they are both J2EE (java) engines. 

Ariba’s been bolstering Ariba Contingent buyer to look more web 2.0 and to compete more effectively with VMS technologies.  They can learn a lot from the Fieldglass user interface which is more mature than Ariba’s relatively utilitarian front end.  I’m not sure how the UI will be merged but Ariba had been working to enhance their UI to encompass get more of a Web 2.0 feel.

Toss in SuccessFactors and SAP and there is not a clear or at least straight path. Make them look alike, consistent, adopt common taxonomy and they will eventually look like cousins. 

Also, because Fieldglass lives in a different database (MS SQL Server), it will keep a lot of guys at both companies coming up with a strategy to let disparate databases talk.  I don’t think we’ll see databases being merged for a long time.

What should potential Ariba and Fieldglass customers do when thinking about putting these together?

Plan on having the application workflow and possibly key pieces of master data (users, cost centers, sites/ship to, business units, etc.) as shared entities in the future.  If you are integrated, leave it alone or finish the integration in process.  I don’t think you will have to load cost centers or users into both systems, just one.  If you are an SAP customer, you’re fortunate in that we should expect to see easier access between applications under the SAP umbrella.

We’ll see what merged pricing models look like, but I’m thinking that this could be a win-win.  Instead of writing checks (or markups) to two vendors, customers should be able to leverage the relationships and merge their contracts.

And then there was Workday

I’m curious what Workday does.  They have been disciplined about each move they have taken.  They have quickly surpassed the VMS technologies in building an open platform.   I think they will purse the contingent business once they realize how many clients have integrated Fieldglass or IQN with their suite.  Disclaimer:  I have integrated Workday and Fieldglass.  Once again, stay tuned. 

About the Author Bruce Hubbell has project managed, architected, tested and served as a subject matter expert for many VMS (vendor management systems) integration to Ariba and other systems such as ERP, IDM, SSO. He has an extensive background in ERP, VMS, Financial, HR, Procurement, Integration and Analytic technology and business processes with extensive knowledge in integrating Ariba and Fieldglass.  He lived through the Oracle/PeopleSoft merger and created the original PeopleSoft Fusion team at Oracle.

#Ariba #Fieldglass #SuccessFactors #SAP #Punchout #Workday #Cloud

Purchasing and VMS (Vendor Management System) Integration – Successes, Best Practices and Gotchas on Integrating two important systems

Why do VMS (Vendor Management System) and Purchasing integration?

Most any large or medium sized VMS implementation has some integration between the VMS system and a clients back office systems such as ERP or HR systems; ID management systems; and often a Single Sign On (SSO) link with a clients security directory. Many clients link all sourcing to Purchase Orders.  Why?

VMS integration links a lean, cost efficient sourcing, selecting, on-boarding processes within the VMS application with other core systems. It's a great structured environment to procure labor and services. Contingent worker hired using a VMS tool can be hired, extended and terminated in the HR, ID and Security systems; master data on the Order is linked to valid cost centers, company, system users or other key elements. This adds greater control.

On the back end, invoices are usually processed automatically to client Accounts Payable systems or an MSP’s parallel billing and supplier payment systems for rebilling back to clients. At the end of the day, integration makes life easier by providing easier access; consistent simple easy to follow user processes; strong controls and audits; and accurate master data to avoid rework.

But why does purchasing and VMS make sense or note?  

Purchasing Integration - What about it?

When VMS is linked to purchasing systems, we are linking two systems used to acquire services (e.g. people) and this sometimes causes challenges with purchasing systems that were originally designed with widgets in mind. Or this takes two approval process driven applications and ties them together. 

In low volume VMS programs, a swivel chair or dual entry approach is best.  Typically, a VMS specialist monitors requisitions and POs against VMS Orders and only releases the approved VMS Assignment once a PO is created. In higher volume purchasing driven organizations where everything has a PO, the process of linking VMS and Purchasing systems can follow different paths with different strengths and weaknesses.

With purchasing integration, it’s good to keep in mind that leading VMS tools are configurable with management approval hierarchies and financial authority spending limits found in purchasing applications – or VMS is really just labor or service focused purchasing system, better tailored to procuring contingent workers and services than your typical PO system. VMS approval processes can enforce purchasing approval rules as long as they are configured with the same data as your purchase app. Financial approval authority for system users; cost centers or other accounting fields such as IO/WBS; and business unit or company driven rules; can be done in the VMS.   In order to treat your VMS as a true purchasing system, the VMS must have some sort of User update or integration process and contain master data on company hierarchies, spending authorities, management hierarchies or the same attributes found in purchasing systems that drive approvals.  So that means master data integations.

When a PO is mandatory and volumes, it makes sense to integrate the VMS with the Purchasing application. By linking VMS ordering and procurement, the inherent advantage of Purchasing-VMS integration approval rules are managed in one system (i.e. purchasing).  Accounting data such as cost centers, GL accounts, company and other accounting fields are managed entirely by another system.

Punchout Approach- cXML

Linking a VMS and Purchasing approval process can be a done a few different ways. The most common approach in my experience is a punchout of cXML (often Ariba) punchout from a Requisition to the Order in VMS. Once the Purchase Order is approved it releases the VMS Order and allows the worker to come onsite. This is a serial process where activities in one system wait on the other. For example, the Requisition isn't raised in purchasing until the VMS requisition or order is created and approved.  The VMS Order is held until the PO is approved.  In the professional, technical staffing universe, workers get stuck waiting for POs to be approved or may bail on the assignment. Another challenge is the manager is working in two systems (purchasing and VMS) to accomplish a task so if there is any linkage issue or out of synch situation, a manager punching out encounters and error.  The advantage is the PO system manages financial approvals and accounting. 

Requisition Import to Purchasing from VMS - file approach

A second approach with VMS and purchasing process integration is a file based integration approach, where work begins in the VMS and then is sent over to the Purchasing system.

Ariba has something called Requisition Import that I’ve implemented with positive success. This integration also follows a serial process where the data is sent from VMS to the Purchasing systems. The upside with this approach is that data is only being entered in one system, the VMS tool. The purchasing system becomes an approval button for the user. One downside of this file batch approach is it’s typically done non-real time. This integration also requires two other pieces: a revision or PO update process; and an interface back from the PO system that passes the PO information back to the VMS and releases the VMS order or worker assignment.  You also need to make sure your VMS system maps in key data accurately such as Purchasing Org, Cost Centers, users with the proper access, etc.

But what about Goods Receipts? - Argghh

One control that comes into play with purchasing (and the widget modeL) and is typically a redundant process “goods receipt-ing” (GR) or receiving (GR). In the purchasing world, this is the process where something is received on the dock as a shipment that somebody signs off on. Goods can’t be invoiced in excess of the goods received. 

In the VMS world, the nearest equivalent of a GR is an approved timesheet, an approved expense report or even a completed milestone on a SOW.  I’ve talked clients off the GR ledge, but I’ve also had to implement with it when clients are not using Service based POs but are stuck in the goods/widget model which is kind of silly when procuring labor. Big companies have rules that are not bendable which is why I have lost that argument. If possible GR processes should be avoided for services as long as somebody is approving the service (e.g. timesheet) in the VMS tool.

Parallel Sourcing and Purchasing approval

Currently, I’m redoing an existing Punchout based serial integration to parallel approach. Taking a serial process to a parallel process is expected to cut down overall fulfillment or what we call cycle time by following two parallels paths: 
1. VMS ordering and sourcing
2. Parallel the purchasing Req to PO approval.  

With this approach we will create a job requisition in the VMS tool. Once we have a job requisition approved, the purchasing requisition is created from this VMS requsition. The purchasing Requisition to PO process is occurring in parallel with candidate sourcing, approval, and screening.  Before the worker walks in the door, a PO has to be received back in the VMS tool.  Or we source the labor at the same time we are getting a PO approved.  

On the back end, we will probably need to revise PO since the initial ask is an estimate.  We are building an an automated approach once the worker is assigned and final spend amounts are more accurately quantified via a PO update process done systematically.

And then there is Ariba Services Procurement

Ariba hasn't been able to compete with the VMS systems because it's lacked the advantages you see in VMS tools.  But under SAP they continue to enhance their product to deal directly with VMS head on.  If you can marry Ariba strengths with VMS strength, then his entire discussion becomes moot.  You don't need punchout between two sysetms or integration.  Stay tuned for what Ariba is working on.

About the Author Bruce Hubbell has project managed, architected, tested and served as a subject matter expert for many VMS (vendor management systems) integrations. He has an extensive background in ERP, VMS, Financial, HR, Procurement, Integration and related Analytic technology and business processes. He is an Enterprise Architect at Kelly OCG.