This is also true for other vertical standards such as HR-XML.
The HR-XML specifications were mostly triggered by software providers and big corporate HR IT departments aiming at reducing their costs of integrating proprietary systems. They realized that there was a better way and created this Consortium. Their goal: create a standard language for HR transactions so to (1) lower the costs of integrating with new partners, (2) speed-up the development of such integrations and (3) lower the error rate of what is lost in translation.

As the data is now flowing between these recruiting, on-boarding, competency management, HRIS (Human Resource Information Systems), payroll, benefits, and background check systems, we are realizing that there is unexpected value that is created in the process. (Note: there are actually many more systems, but that would make too long a list)

Before those systems start to be interoperable, data that was passed from one system to another was limited to the strict minimum. Systems (and departments) were behaving as silos. Thus you had a recruiting system that knew a lot about candidates (you can’t imagine the amount of data that is collected during the recruiting process), and a central HR system that knew very little about its employees. Everything you told about your skills, your motivation, your achievements were lost from a corporate perspective!

Now when you arrive in your new position, your HR department knows about you, and that allows managers and HR teams to do a better job at following your career and your assignments. Of course, interoperability does not it all. There are plenty of HR departments who decide not to use these new capabilities. But the point remains: they have a new tool for collaborating with the recruiters, and later on with the managers that is available to them.

The second source of value is that this data can be enriched. For each transaction, I now know who initiated it, what day, what time, what system did it come from, …. and I can use this data to better collaborate with my partners.

For instance, knowing that my best software developers candidates came through Techcrunch blog but not the software architect allows me to collaborate better with Techcrunch. By providing this feedback, they have a better understanding of their readership and thus can decide whether they should stop articles targeting architects or rather developing better content for these architects.

Again, interoperability does not automatically generate collaboration: nothing forces the company to provide this feedback, but without interoperability there is no feedback to provide.