Een ATS koppel je aan Power BI of een datawarehouse door recruitmentdata gecontroleerd uit het ATS te halen, de gegevens te structureren en vervolgens beschikbaar te maken voor analyse. Een directe koppeling met een BI-tool kan voldoende zijn voor beperkte dashboards. Een datawarehouse is logischer wanneer recruitmentdata gecombineerd moet worden met HR-, finance- of workforcegegevens, wanneer historie belangrijk is of wanneer meerdere rapportages dezelfde gegevensbron moeten gebruiken. De kern is dat je vooraf bepaalt welke data nodig is, hoe vaak die wordt vernieuwd en hoe persoonsgegevens worden beperkt.
Begin bij de rapportagevraag
Een technische koppeling heeft pas waarde als duidelijk is welke vragen ermee beantwoord moeten worden. Begin daarom niet met alle beschikbare ATS-data te exporteren.
Veelvoorkomende vragen zijn:
- hoeveel sollicitaties komen per vacature binnen;
- welke bronnen leveren kandidaten op;
- hoe lang duren procesfasen;
- waar vallen kandidaten uit;
- hoeveel vacatures staan open;
- hoeveel kandidaten worden aangenomen;
- hoe verschilt recruitmentprestatie per afdeling of locatie.
Recruitmenttech.nl beschrijft in Welke functionaliteiten moet een ATS hebben? dat rapportage en inzicht in het recruitmentproces belangrijke functies van een ATS zijn. Externe BI wordt vooral interessant wanneer de standaardrapportage niet voldoende is of data uit meerdere systemen nodig is.
Wanneer is een directe BI-koppeling voldoende?
Een directe verbinding tussen ATS en een BI-tool kan praktisch zijn wanneer:
- de rapportages voornamelijk ATS-data gebruiken;
- het aantal datasets beperkt is;
- de gegevensstructuur stabiel is;
- weinig transformaties nodig zijn;
- de dashboards voor een beperkte groep gebruikers bedoeld zijn.
De BI-tool leest dan bijvoorbeeld dagelijks vacatures, sollicitaties en processtatussen uit.
Het voordeel is eenvoud. Er zijn minder tussenlagen en een dashboard kan relatief snel worden gebouwd. Het nadeel is dat de rapportage sterker afhankelijk wordt van de structuur en beschikbaarheid van het ATS.
Wanneer is een datawarehouse logischer?
Een datawarehouse vormt een centrale omgeving waarin gegevens uit verschillende bronnen worden samengebracht en geschikt gemaakt voor analyse.
Dat is nuttig wanneer recruitmentdata moet worden gecombineerd met bijvoorbeeld:
- medewerkergegevens uit het HRIS;
- formatie en budgetten;
- verloopgegevens;
- organisatiehiërarchie;
- financegegevens;
- arbeidsmarkt- of capaciteitsinformatie.
De NIST Big Data Reference Architecture beschrijft een leveranciersneutrale architectuur met rollen voor onder meer databronnen, dataverwerking en dataconsumptie. Dat principe helpt om recruitmentrapportage niet te zien als één dashboard, maar als een keten waarin brondata gecontroleerd naar een analyseomgeving gaat.
Bepaal welke ATS-data je nodig hebt
Niet ieder veld uit het ATS hoort in een datawarehouse. Begin met een datamodel dat aansluit op de KPI’s.
Veel gebruikte gegevens zijn:
- vacature-ID;
- openings- en sluitingsdatum;
- afdeling, locatie en functie;
- sollicitatie-ID;
- bron van de sollicitatie;
- datum per procesfase;
- eindstatus;
- aanname- of afwijsdatum.
Voor veel analyses is de naam van een kandidaat niet nodig. Gebruik waar mogelijk technische sleutels of gepseudonimiseerde identificatie.
Dat beperkt de hoeveelheid persoonsgegevens in de rapportageomgeving en verkleint de kans dat dashboards onbedoeld individuele dossiers tonen.
Historie vraagt extra aandacht
Een ATS toont vaak de huidige status van een kandidaat of vacature. Voor analyse wil je juist weten hoe die status in de tijd veranderde.
Als een kandidaat vandaag in ‘interview’ staat, zegt dat nog niet wanneer die kandidaat de eerdere fasen heeft doorlopen. Voor time-to-stage en funnelanalyse zijn tijdstempels of gebeurtenisgegevens nodig.
Een datawarehouse kan deze historie bewaren, ook wanneer het ATS vooral de actuele situatie laat zien. Leg daarom vast welke gebeurtenissen worden opgeslagen en hoe lang.
Gebruik een API of geplande export
Data kan op verschillende manieren uit het ATS komen. Een API is een veelgebruikte route. In Hoe werkt een API-koppeling met een ATS? staat dat authenticatie, foutafhandeling, logging en versiebeheer onderdeel van het ontwerp moeten zijn.
De OpenAPI Specification biedt een leveranciersneutrale manier om HTTP-API’s te beschrijven. Dat helpt data-engineers te begrijpen welke objecten, velden en filters beschikbaar zijn.
Een andere mogelijkheid is een geplande bestandsexport. Dat kan voldoende zijn voor dagelijkse rapportage, maar vraagt eveneens om controles op volledigheid en fouten.
Kies de juiste verversingsfrequentie
Niet ieder dashboard heeft realtime data nodig. Een dagelijkse verversing kan ruim voldoende zijn voor managementrapportages. Operationele dashboards kunnen vaker moeten worden bijgewerkt.
Meer verversen betekent ook meer API-verkeer, verwerking en monitoring. Bepaal daarom per rapportage hoe actueel de data werkelijk moet zijn.
Een dashboard over kwartaalprestaties hoeft niet iedere minuut te worden vernieuwd. Een operationeel overzicht van interviews of openstaande acties kan andere eisen hebben.
Maak definities centraal
Een van de grootste risico’s bij BI is dat verschillende teams dezelfde KPI anders berekenen.
Leg daarom definities vast voor begrippen zoals:
- sollicitatie;
- gekwalificeerde kandidaat;
- aanname;
- time-to-hire;
- time-to-fill;
- source of hire;
- doorlooptijd per fase.
Wanneer iedere analist een eigen berekening maakt, kunnen dashboards verschillende uitkomsten tonen terwijl ze dezelfde bron gebruiken.
Een centrale datalaag kan helpen om berekeningen één keer vast te leggen en in meerdere rapportages te hergebruiken.
Controleer datakwaliteit vóór het dashboard
Een aantrekkelijk dashboard maakt slechte brondata niet betrouwbaar.
Controleer daarom:
- of statussen consequent worden gebruikt;
- of bronnen correct worden geregistreerd;
- of vacatures dezelfde organisatiestructuur gebruiken;
- of datums compleet zijn;
- of testrecords worden uitgesloten;
- of dubbele sollicitaties herkenbaar zijn.
De kennisbank over ATS-datamigratie benadrukt eveneens dat opschoning en mapping nodig zijn om data betrouwbaar te gebruiken.
Beperk toegang tot gevoelige data
Een datawarehouse en BI-tool maken gegevens vaak beschikbaar voor een grotere groep dan het recruitmentteam. Dat vraagt om duidelijke rollen.
Een manager heeft bijvoorbeeld aggregaten nodig over doorlooptijd en aantallen, maar geen toegang tot individuele cv’s, beoordelingen of contactgegevens.
Maak daarom verschillende datalagen of rapportagerollen. Deel op managementniveau zo veel mogelijk samengevoegde gegevens en beperk toegang tot kandidaatniveau tot gebruikers die dat daadwerkelijk nodig hebben.
Monitor de dataketen
Een rapportage kan fout zijn zonder dat het dashboard zelf een technische fout toont. Als de laatste data-extractie is mislukt, ziet een gebruiker misschien gewoon oude cijfers.
Controleer daarom:
- wanneer de laatste succesvolle verwerking plaatsvond;
- hoeveel records zijn geladen;
- of velden plotseling leeg zijn;
- of API-versies zijn gewijzigd;
- of afwijkingen automatisch worden gemeld.
Een betrouwbare koppeling bevat dus niet alleen datatransport, maar ook kwaliteitscontrole en monitoring.
