Integration Matters! The Vendor Management System as Hub, Not Island

island Musicman80/Adobe Stock

The humble vendor management system (VMS) started out as a technology to manage basic sourcing, invoicing, payment and tracking for contingent/contract workers – and the staffing firms they were employed by. Yet the VMS of today does far more from a functional perspective, including managing the broader lifecycle of contingent workforce activities and enabling both basic and complex statements of work (SOWs). The VMS of 2016 must also integrate with other procurement technologies, supplier systems, access/credentialing systems, IT environments, HR Systems and ERP/AP tools as just a start.

Yet on many levels, we still tend to look at a VMS as a procurement, IT and HR island — stuck by itself somewhere deep in a spend ocean, surrounded not by the other services spend categories, systems and users, but rather stuck thousands of miles away in a blue ocean of only partially tapped human capital. (Keeping with this analogy, consider it a “Hawaii” to the Continental U.S.)

Bad metaphors aside, without question, the VMS is not an island — even if a company wants to put it into a tidy cloud technology box. Indeed, how a VMS integrates with other IT, procurement and HR systems and third-party services will largely dictate how effective it is in driving contingent workforce and service management value beyond just ensuring regulatory/statutory compliance and capturing and controlling spending activity.

From reducing ongoing IT costs to maximizing savings to improving overall talent management to reducing business risk, the level of integration a VMS has with the broader organization, its systems and its suppliers is a directional guide to the value an overall deployment will bring.

Getting Started: Building the Case for VMS Integration

It’s all too tempting to pursue an initial VMS deployment that prioritizes showing rapid initial results, capturing and managing spending activity, without designing an integration architecture and related business plan.

But if you heed our words of caution, before any deployment (or even plan) takes place, one of the first steps that procurement should take following a technology selection is to work closely with the selected technology vendor and IT to build a business case for integration, which should include quantifying the cost of non-integration including manual work. This should be followed by a living architecture document that business users and IT can use as a blueprint for integration.

Integration business case elements can range from the basic to the advanced. But good places to start include:

  • Quantifying the cost of manual work (including data inputs) in terms of FTE and other hard/soft costs
  • Showing the cost of incorrectly entered information (and poor contingent workforce master data)
  • Quantifying the risk of incorrect, missing or lost data (e.g., regulatory fines in the case of an audit)

With a basic business case in place, the next step is to understand the level of integration that an organization wants to pursue. While no two cases will be the same, we can tier common integration approaches into three levels:

  • Basic integration with ERP and procurement systems involve basic master data, invoice information and similar fields
  • Intermediate integration models incorporate purchase requests, purchase order, budget allocation, encumbrance and related data and fields
  • Mature integration approaches factor into account more detailed on-boarding, off-boarding, tracking, asset management, talent/workforce management applications and procurement system scenarios and mappings (e.g., to other fields in e-procurement/e-invoicing, supplier management and contract management systems)

While the technical “know how” matters (such as an application protocol interface (API) for integration approaches) what is even more important is how users will interact with the integrated data as a result. I like to call this a “functional integration outcome” and it involves, as an example, the ability to track budgets and accruals at both the line-item level and in aggregate.

This is an important tip to remember: Prioritize the business use case and scenario for each integration, not just functional field mapping. You’ll often find that for each integration, there are multiple scenarios that benefit from it, and multiple integrations beget more valuable scenarios based on the combination of data visibility.

Beyond the Basics

As I’ve written about before, more mature integration models even tie together variable approvals processes. This can include fields and data ranging from roles, budgets, ERP/allocation codes, geographies, categories and suppliers to rules-based workflows that may query not just defined steps within the defined services procurement architecture and hierarchy but external systems as well.

From a procure-to-pay (P2P) perspective involving e-procurement systems, mature approaches can involve integrating various purchasing and finance approval workflows (e.g., matching an approvals). These might include purchase order, non-PO requisition requests, invoices and discounting/payment options for suppliers. Certain integration models may even tie indirect materials procurement buying activities (e.g., safety equipment for a warehouse environment) that a contingent worker may require directly into their record. And from a more mature HR system perspective, an advanced integration approach may take the form of queries that look at approval limits and hierarchies in real-time.

Third-party integrations for a VMS may range from the typical (e.g., background screening, drug/substance testing) to more advanced requirements (e.g., security clearances). Finally, as contingent workforce programs mature and involve an increasingly complex set of labor (and outcome-driven) options, real-time integrations with benchmarking data sources (e.g., rate data), alumni pool information, talent and freelancer marketplaces, as well as other work intermediation platforms (such as crowdsourcing), can extend the role and value of a VMS even further.

As this series looking at VMS integration continues, we will look at lessons learned from VMS integration approaches, how to get data out of systems to drive analytics and a checklist for overcoming resistance and pushback from other stakeholders that do not want to invest the time or cost to get an integration architecture right from the start.

Share on Procurious

Voices (2)

  1. Eyal Katz:

    Are you familiar with Zapier? It’s an integration hub that has over 500 apps (mostly in the realm of marketing and sales) that you can integrate through their service with the click of a button.

    Is there something similar for the operations side of things?

  2. Brian Hoffmeyer:

    One of my favorite topics! I’m an #integrationgeek! Looking forward to the series and really want you to delve into what your thoughts are regarding POs, PO integration, and VMS. We, of course, can do them but also think they add complexity and that the VMS can replicate what a PO does via our 4-way match.

Discuss this:

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