System of Record: What is it?

Why Is a System of Record Important?

When you are implementing a VMS tool, you will invariably need to build integrations with other systems. Sometimes those will be inbound feeds, like users and cost   centers. Other times they will be outbound feeds, like invoicing and worker feeds. If you pick the wrong source, you could be using out of date or inaccurate information. Furthermore, if you confuse or designate multiple sources, then you are in for a reconciliation nightmare.

A Case Study – Where is The System of Record?

I have worked with a number of clients that have struggled to understand this concept, so let me give an example.

If you create new cost centers in your financial system, and those are then fed to your HR system and associated with people, then fed from the HR system to a procurement system to be used to buy things, what is this system of record for cost centers? If you guessed “financial system,” you win. The financial system is where the cost centers start.

The origin point is very important when designing system integrations. As often as possible, you want to be going to the system of record for information rather than downstream systems that may not be current. This way you can be assured of having the most accurate information.

Another example: you use a VMS tool to requisition, source, contract and manage contingent labor. The VMS feeds contractor information to an HR system: name, start date, engagement manager, end date, etc. The HR system then feeds the data to various onboarding systems, like background checking, access control, and badging platforms. What is the system of record for contingent workers? If you’re following along at home, you should have said “the VMS system.”

Syncing and the System of Record

Like I said before, I have worked with a lot of clients who struggled with the concept of system of record, or forgot to consider it as they build out ever more complex processes. It is especially important if you are trying to keep your HR system with the VMS for contractor data like end dates and engagement managers/supervisors.

Forget about the system of record, and problems are bound to pop up. You’ll see the

problem when you either try to update contractor records in both systems, or only allow updates through the HR system.

In the first scenario, you will either need to continually update and sync both systems manually or build two-way integrations between the systems. These options are expensive and inefficient, and you still could end up with inaccurate information.

In the second scenario, you will again need to either update the systems manually or through two-way integrations (rather than one-way from the VMS to the HR system). You get the added downside of using a system that is not built for the purpose and does not have the fiduciary controls offered by a VMS (plus other features like assignment versioning, effective dating of rate changes, historical tracking of supervisor changes, etc.).

The flow of information for a single data point should always be from the system of record to the recipient system, with updates to that data point only allowed in the system of record.

Designing Process Around the System of Record

Below are three examples of integrations of a single data point, such as end date for a Contractor:

The Ideal Design

The Less than Ideal Design*

*Sometimes this design is used because the system of record is too difficult to interface with. It may also be used because the intermediate system combines the original data with other data, such as combining user data with approval hierarchy data. This system can also be used  because the intermediate system sends information to multiple recipient systems and it is most efficient to leverage that existing infrastructure.

The Poor Design

To recap, when you are implementing a VMS (or any third party tool) and determining where to go for data, remember the following:

• Always use the system of record whenever technically feasible
• The system of record is the source of truth
• Only allow updates in the system of record