Een recruitmentdatamodel ontwerpen

Een recruitmentdatamodel beschrijft welke soorten gegevens je bureau vastlegt en hoe die samenhangen. Denk aan een kandidaat, een bedrijf en de sollicitatie die iemand aan een vacature verbindt. Een goed begin is niet een lange lijst velden. Eerst spreek je af waar een gegeven thuishoort en wie het mag veranderen.

Dat wordt tastbaar zodra één kandidaat voor meerdere opdrachten in beeld is. Het telefoonnummer hoort bij de persoon. De gespreksfase hoort bij een specifieke sollicitatie. Zet je beide op hetzelfde niveau, dan lijkt iemand in alle procedures tegelijk te zijn afgewezen.

In het kort

• Scheid gegevens over een persoon van gegevens over diens sollicitatie.
• Geef relaties een eigen record wanneer ze een status, datum of verantwoordelijke nodig hebben.
• Leg bij ieder veld de betekenis, bron en eigenaar vast.
• Test het model met wijzigingen, dubbele invoer en beperkte toegangsrechten voordat je gegevens importeert.

Welke records heb je nodig?

Begin bij de zaken die zelfstandig kunnen bestaan: een kandidaat zonder lopende sollicitatie, een klant zonder open vacature of een contactpersoon die van werkgever verandert. Geef zulke zaken een eigen record. Verbind ze vervolgens via relaties, zodat je niet voor iedere nieuwe opdracht dezelfde gegevens hoeft over te typen.

Onderstaand model is een ontwerpoefening voor een fictief werving-en-selectiebureau. Het is geen verplichte inrichting van ieder ATS.

Record	Betekenis	Voorbeeld van een gegeven dat hier hoort
Kandidaat	Persoon met wie het bureau een kandidaatrelatie onderhoudt	Contactgegevens en afgesproken bereikbaarheid
Bedrijf	Organisatie waarvoor je werft of waarmee je contact onderhoudt	Bedrijfsnaam en verantwoordelijk accountteam
Contactpersoon	Persoon aan de klantkant	Zakelijk contactadres
Vacature	Concrete wervingsopdracht	Functie-eisen en verantwoordelijke recruiter
Sollicitatie	Deelname van één kandidaat aan één vacature	Procedurefase, feedback en vervolgafspraak

Een contactpersoon kan ook kandidaat worden. Bepaal of je systeem één persoonsrecord met verschillende rollen gebruikt of aparte records met een gecontroleerde koppeling. Twee rollen rechtvaardigen niet automatisch twee onafhankelijke versies van hetzelfde telefoonnummer.

Wanneer verdient een relatie een eigen record?

Een relatie verdient meer dan een eenvoudige verwijzing zodra je iets over die verbinding moet vastleggen. Een kandidaat kan bij meerdere vacatures horen en een vacature kan meerdere kandidaten hebben. De sollicitatie bewaart wat alleen voor die combinatie geldt: bijvoorbeeld de uitnodiging, feedback en datum van terugtrekking.

Microsoft beschrijft één-op-veel- en veel-op-veelrelaties als manieren om records te verbinden. Voor recruitment is de praktische vervolgvraag welke informatie de relatie zelf nodig heeft. Alleen twee records verbinden vertelt nog niet hoe ver de procedure is.

Ook contactpersonen kunnen meerdere bedrijven vertegenwoordigen. Bij een enkel veld ‘werkgever’ verdwijnt mogelijk de vorige relatie wanneer iemand overstapt. Wil je historische afspraken kunnen begrijpen, dan kan een relatie met begin- en einddatum nuttiger zijn. Dat is een ontwerpkeuze; maak niet voor iedere denkbare uitzondering een nieuw object.

Hoe geef je velden een betekenis die collega’s delen?

Schrijf een korte definitie voordat je een veld maakt. ‘Beschikbaar’ is te vaag als de ene recruiter bedoelt dat iemand interesse heeft en de andere dat iemand volgende week kan starten. Splits die begrippen alleen wanneer het team ze werkelijk afzonderlijk gebruikt.

Een klein gegevenswoordenboek kan er zo uitzien:

Veld	Betekenis	Bron en verantwoordelijkheid
Beschikbaar vanaf	Door de kandidaat genoemde mogelijke startdatum	Recruiter bevestigt datum en noteert wanneer
Sollicitatiefase	Huidige stap voor deze kandidaat bij deze vacature	Recruiter die de procedure beheert
Klantfeedback	Terugkoppeling over deze sollicitatie, met datum	Ontvanger legt de bron vast
Volgende actie	Concrete handeling met eigenaar en vervaldatum	Degene die de afspraak aanneemt

Een lege waarde is niet altijd een fout. Je kunt een startdatum nog niet hebben gevraagd. Maak onderscheid tussen ‘onbekend’, ‘niet van toepassing’ en een bevestigde waarde wanneer dat verschil gevolgen heeft voor je werk. Laat een AI-parser een ontbrekende datum niet aanvullen met een aannemelijke gok.

Vermijd ook een verplicht veld zonder verantwoordelijke. Dan vraag je collega’s om iets in te vullen waarvoor niemand een betrouwbare bron heeft. Een formulier kan compleet ogen terwijl de inhoud niets meer zegt.

Hoe voorkom je dat kopieën elkaar tegenspreken?

Gebruik vaste record-ID’s voor verwijzingen en spreek af welke plek de bron is voor ieder gegeven. Een naam is geen betrouwbare sleutel: mensen kunnen dezelfde naam hebben of hun naam veranderen. Een e-mailadres kan wijzigen of door meerdere contactpersonen worden gebruikt.

Spreek af wie een mogelijke dubbeling beoordeelt voordat iemand records samenvoegt. Vergelijk naast de naam ook de relevante contactgegevens en sollicitaties. Behoud één bron voor actuele gegevens en zorg dat bestaande relaties naar het juiste record blijven verwijzen.

Maak ook een keuze over historische relaties. Een beëindigde sollicitatie kan nog uitleggen waarom iemand eerder afviel; het verwijderen van een verwijzing is daarom iets anders dan het wissen van een heel dossier. Stem die keuze af op jullie bewaarbeleid.

Wie mag welke informatie wijzigen?

Maak toegang onderdeel van het ontwerp. Een recruiter kan verantwoordelijk zijn voor een procedure zonder alle gegevens van iedere collega nodig te hebben. Bespreek toegang per soort record en, waar nodig, per veld. Test met een gewone gebruikersrol, niet alleen met het beheerdersaccount.

In Simply kun je een veld als gevoelig markeren en toegang beperken tot de juiste rollen. Denk aan een salarisverwachting die niet iedere collega hoeft te lezen. Laat het beheer van velddefinities bij een beheerder, zodat een nieuwe naam of betekenis eerst met het team wordt afgestemd.

In Simply’s ATS en CRM maakt een beheerder objecten, velden en relaties aan en stelt die de toegangsrechten in. Neem ‘beschikbaar vanaf’: geef het een datumveld op de kandidaat en leg de betekenis vast in je gegevenswoordenboek. Simply Ask kan ook een modelvoorstel voorbereiden dat de beheerder beoordeelt voordat het wordt toegepast.

Wat leer je van één kandidaat met twee vacatures?

Neem deze fictieve test. Kandidaat Noor heeft één profiel. Zij spreekt voor vacature A met een klant, terwijl ze zich uit vacature B terugtrekt. Het team registreert twee sollicitaties en wijzigt alleen de fase bij B. De afspraak bij A blijft staan.

Daarna geeft Noor een nieuw telefoonnummer door. Een collega past het persoonsgegeven aan en controleert of beide procedures naar hetzelfde actuele profiel verwijzen. De historische terugtrekking bij B verandert niet. De collega bekijkt vervolgens met een beperkte rol welke notities zichtbaar zijn.

Bespreek het voorbeeld met de collega die de gegevens invoert. Is duidelijk waar de nieuwe afspraak hoort en welk gegeven de andere procedure deelt? Werk het model bij als die keuze nog niet helder is.

Bewaar de verwachte en werkelijke uitkomst naast elkaar. Als een verschil een ontwerpbeslissing blootlegt, werk je eerst het model bij. Pas daarna volgen imports en automatische extractie.

Hoe begin je zonder een groot dataproject?

Kies een lopende werkwijze en teken de records die daarin voorkomen. Loop met een recruiter door een wijziging die jullie echt tegenkomen, zoals een andere contactpersoon of een tweede sollicitatie. Schrap velden waarvoor niemand een gebruiksdoel kan aanwijzen.

Neem die tekening mee naar een Simply-demo. Vraag om de kandidaat, beide sollicitaties en de toegangscontrole in dezelfde omgeving te doorlopen. Een bruikbaar datamodel herken je aan de antwoorden die collega’s terugvinden nadat de situatie is veranderd.