Human Capital Management Blog Posts by SAP
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Read only

Why Unified Data Model Career Site?

Christopher_Nickel-Felton
Associate
Associate
3 weeks ago
332

Unified Data Model (UDM) Career Site is a platform not a feature.

There has been a lot confusion about Career Site Builder on UDM. 

  • What is it?
  • Should I be on it?
  • What does it do?
  • Why did SAP build it?

To answer these questions, we need to travel back in time to 2012, the year both SuccessFactors and Jobs2Web were acquired by SAP.

Jobs2Web was an early startup that helped define the Recruiting Marketing and Candidate Relationship Management space. The core idea was “Candidates should be able to find your jobs on the internet”. Obvious today, but not always. Jobs posting used to be hidden away in Applicant Tracking Systems (ATS) such as the SuccessFactors Recruiting ATS. So, in 2012 SAP acquired an ATS and a Career Site and Job Distribution system. Two separate systems in the Recruiting space, with two very different internal data models.

Clearly the applicant tracking system was the system of record. This is where the Requisition model is defined, this is where the Requisition can relate to position and other core HR business objects. Your foundational HR data. So how did Jobs2web and the Career Site relate to this core business data? Through a field mapping. Using this mapping the primary requisition data was mapped to Jobs2web text values. So, what are the problems here?

  • Data Redundancy: data is synched and managed in multiple repositories, creating operational overhead and engineering complexity, and possible synchronization failures.
  • Data Fidelity is Reduced: complex rich data is mapped to text fields. Pick-lists and objects lose their structure, organization and localization is lost.
  • Data Limitations: The number of fields which can be mapped is limited
  • Data and System Fragmentation: When business data and capabilities are expanded, with Skills for example, how should this core HR data relate to the legacy Jobs2Web data model? Do we need to build for skills twice, in both Jobs2Web and the core ATS?

Christopher_NickelFelton_0-1749747344575.png

Fine, I see the architectural issues, but what are the business values for me?

Our platform shift is beginning bear fruit in the key areas of Job Discovery and Job Presentation.

  • AI powered resume analysis and job recommendations
  • AI powered similar jobs component for job detail page
  • AI powered skills component for job detail page
  • Significantly improved keyword search in non-English languages
  • Improved Search Facets and Filters are using pick list and object data directly
  • Job Map integrated with Search 
  • New standardized business objects for representing job posting locations
  • Simplified administrative experiences directly incorporating primary HR data

Christopher_NickelFelton_1-1749747344577.png

Could these features have been delivered without this platform shift? Not easily, and not without increasing the business data fragmentation issues. Well integrated systems of record are SAP’s stock and trade. Stable, logical, systems of record always pay for themselves in the long run. 

Right, so what do I need to do to get on this new platform?

The good news is we are continuing to invest in migration helper tools. We recently released a fully automated Job Location Migration tool. The bad news is our new features are all being delivered on UDM. Keeping up with the shift to AI/ML driven job discovery will require getting on the UDM platform.

 I cannot outline all the migration steps here, but I can offer some perspectives and advice.

  • Setting up the new search is very easy, chose the fields from your Requisition that you want to use as filters, chose the fields for the result cards, set a few styles, done!
  • Job Location Migration is also now very easy. Before we built the migrator this was the highest effort activity to shift to the platform.
  • Job Layouts should be reconfigured to take advantage of the new components and data available. Depending on how complex your layouts are and how many you have this will probably be the highest-level effort area. We have improved the job layout selection rules capabilities, previously you may have needed to create more layouts than you needed due to the limitations with the single selection rule. Multiple rules using object and pick list fields are now supported. You will probably want to incorporate some of the new components, such as skills and similar jobs. With new data available and new components, reexamining your layouts is a worthwhile effort.
  • Job Category rules are auto migrated, but the accuracy is not 100%. You may want to review your category rules. A perspective here: Category pages were originally designed to assist with Search Engine Optimization. The more category pages you had, the better your chances on the search engines. This is not true anymore. We are not living in the 2008 SEO world! Category pages should be focused on key areas of your business to aid in job promotion and discovery for human visitors, as opposed to Search Engine bots. If you have a thousand categories, consider significant reducing. 

Thanks for your time, good luck, and happy head hunting.