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.