VMS and Services Procurement Integrations: Considerations and Approaches

integration alphaspirit/Adobe Stock

All too often, procurement, HR and IT organizations look at the vendor management system (VMS) as a standalone solution, separate from other procurement and financial systems. This view holds that the VMS is an island, designed to automate buying, management and compliance for contingent labor.

Granted, even functionally, a full-featured VMS can do far more than just this. But such a functionally narrow — or even expanded — definition alone does not begin to do justice to the role that the VMS can ideally serve, working as a hub that interconnects external talent pools with internal systems and processes to enable better business outcomes. This was the most important argument (along with integration examples and more) that I tried to make in an article in the first installment of this series, Integration Matters! The Vendor Management System as Hub, not Island.

Overcoming one of the challenges in shifting our thinking from looking at a VMS as just another enterprise application that supports procurement and HR requirements to a more strategic hub that can help deliver on the promise of services procurement savings and control, as well as total talent management for the extended workforce, requires stepping back and looking at how each organization's integration requirements are different. Just as no two talent pools are ever the same — whether internal or external — integration approaches and models will vary considerably between companies. Doing this exercise yourself, for your organization, will help you think about the broader role of the VMS as the central nervous system for managing all forms of external talent.

Foundational VMS Integration Considerations

There are many foundational considerations when it comes to thinking through the types and approaches to VMS integration (reference the “Integration Approaches” section of this brief for specific integration types) that we should consider. These include:

  • General company demographic information such as industry, company size and geographies supported. A financial services firm with locations throughout North America hiring thousands of contractors to support IT requirements throughout a year will look very different from an integration needs perspective than a French CPG manufacturer needing to support local blue collar staffing requirements and global sales/marketing support needs, increasingly coming from third-party creative resources working through specialized talent/freelancer marketplaces
  • Risk tolerances and risk management priorities are an important consideration, especially in industries that require different levels of compliance (which can require different levels of integration to support). Financial services and aerospace and defense firms, for example, will need to integrate additional levels of background screening for certain levels types of hires
  • IT environment (systems) are important for consideration when it comes to VMS integration. But it’s not just ERP/financial systems integration that matter. It’s also integration into other IT systems that is a key consideration (e.g., e-procurement, e-invoicing, supplier management, supplier portal, HR/human capital solutions)
  • The philosophy of an IT organization toward systems and integration can be as important as the actual systems that it already manages or provisions via the cloud. For example, is the organization centrally led and managed? Or does it rely on central governance but decentralized and even outsourced execution and management? The degree of centralization and historical approaches to integration, internal data security, privacy, compliance and new cyber considerations will be important factors that drive specific integration approaches
  • Outsourced IT partners (if applicable) can also be a factor in VMS integration considerations. Depending on the systems managed and delivered by third parties — or the processes, such as an applications help desk — VMS integration approaches may shift as well
  • Experience with different integration models — the degree to which an IT organization has experience with (or requires) different integration models (see below) will be a key consideration in VMS integration approaches
  • Experience with large-scale cloud applications (and linkages with enterprise systems) is also an important factor for VMS integration consideration. An IT organization that is treating a VMS as one of the first large-scale cloud applications that it will need to vet and oversee will think very differently about integration than an IT shop that is already working with numerous cloud application or even cloud ERP vendors

All of these factors together will help drive core VMS integration considerations — and the ultimate approaches an organization takes.

Integration Models: APIs and More

In late October 2016, I presented on a webinar with Andrew Wright, vice president of solutions at SAP Fieldglass. The topic, which provided some of the input fodder for this series, was titled, Strategic VMS Integration: ERP, Procurement Systems, HR Systems and Beyond. Andrew did a great job explaining specific VMS integration models, so rather than reinvent the wheel, I’ll share the three models that he explained during the webinar.

The first model Andrew shared is API-supported integration, in which data and transactions are enabled through the API frameworks within a VMS. This model is “ideally suited for customers with tightly controlled or mitigated third-party data integration architecture.” Regarding this approach, Andrew observes that the “APIs offered [through a specific VMS and third-party solutions] use a flexible API framework that requires minimal data extractions.” There is however, “customer effort required to develop data import and export routines.” The interfaces through this approach will natively support multiple transfer formats (e.g., web services, SFTP, etc.).

The second approach Andrew notes takes APIs further by offering an accelerator-supported model, in which data and transaction integration is enabled via a specifically defined integration toolkit from the vendor. These “pre-built routines support both master data and transactional interfaces” and “no customer effort is required to leverage existing data import and export routines.” The actual integration tools “sit in customer environment or the cloud and can be used with single or multiple ERP landscapes.” They can also “be leveraged as both web services or mitigated interfaces.”

Finally, we come to what Andrew describes as truly native ERP support for integration. In the case of Fieldglass specifically, this involves a new 2016 capability that includes an out-of-the-box data and transaction interface through SAP-provided routines that support master and transactional data interfaces, including purchase requests, purchase orders, invoicing and worker on/offboarding. Andrew notes that with this approach, “customer effort is required to enable/define schedules for provided data import and export routines.”

The Future of VMS Integration

As I conclude this series in the coming days, I’ll turn my attention to where VMS integration is headed and key themes we should keep in mind. I’ll also summarize VMS integration best practices. Stay tuned!

Share on Procurious

Discuss this:

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.