Vendor lock-in bij ATS-integraties ontstaat wanneer een organisatie technisch, contractueel of operationeel zo afhankelijk wordt van één leverancier dat overstappen naar een ander recruitmentsysteem duur, traag of risicovol wordt. Je voorkomt dit niet door alle maatwerk te vermijden, maar door vooraf eisen te stellen aan data-export, API’s, documentatie, eigenaarschap van koppelingen, open standaarden en exit-afspraken. Ook is het verstandig om integratielogica zo veel mogelijk buiten één leverancier te houden als meerdere systemen ervan afhankelijk zijn.
Vendor lock-in begint vaak bij integraties
Een ATS staat zelden op zichzelf. Het is verbonden met een werken-bij-site, HR-systeem, agenda, assessmentsoftware, onboarding, e-signing en rapportagetools. Hoe meer koppelingen rondom één ATS worden gebouwd, hoe groter de impact van een toekomstige vervanging.
In het kennisartikel over essentiële ATS-koppelingen staat daarom centraal welk systeem voor welke gegevens leidend is. Die keuze is ook belangrijk voor het beperken van afhankelijkheid. Als het ATS onnodig de enige bron wordt voor gegevens die elders thuishoren, wordt migratie ingewikkelder.
Breng afhankelijkheden vooraf in kaart
Maak vóór een selectie of integratieproject een overzicht van alle verbindingen rond het ATS. Noteer per koppeling welke gegevens worden uitgewisseld, welke richting de data op gaat, wie eigenaar is van de koppeling en welke partij de technische logica beheert.
Let vooral op koppelingen die alleen door de ATS-leverancier kunnen worden aangepast. Dat hoeft geen probleem te zijn, maar het vergroot wel de afhankelijkheid. Vraag daarom wat er gebeurt wanneer de organisatie het ATS wil vervangen of wanneer een gekoppeld systeem verandert.
Een eenvoudige afhankelijkheidskaart maakt zichtbaar welke onderdelen later opnieuw gebouwd moeten worden.
Geef voorkeur aan gedocumenteerde API’s
Een goed gedocumenteerde API maakt het eenvoudiger om gegevens uit te wisselen zonder volledig afhankelijk te zijn van maatwerk van één leverancier. In Hoe werkt een API-koppeling met een ATS? wordt uitgelegd dat documentatie, authenticatie, foutafhandeling en versiebeheer onderdeel van een volwassen integratie zijn.
Vraag bij een ATS-selectie niet alleen of er een API bestaat. Controleer ook welke onderdelen van het systeem via die API toegankelijk zijn. Een API die alleen vacatures kan uitlezen, maar geen kandidaten, statussen of configuratie kan exporteren, biedt weinig flexibiliteit bij een toekomstige migratie.
Controleer daarnaast of de API een stabiele versie heeft en hoe wijzigingen worden aangekondigd.
Open standaarden verkleinen maatwerk
Hoe meer een integratie gebruikmaakt van gangbare standaarden en machineleesbare formaten, hoe kleiner de kans dat gegevens alleen via leveranciersspecifieke oplossingen kunnen worden gebruikt.
De OpenAPI Specification biedt bijvoorbeeld een leveranciersneutrale manier om HTTP-API’s te beschrijven. Dat betekent niet dat ieder ATS dezelfde API heeft, maar wel dat documentatie en technische afspraken in een herkenbaar formaat kunnen worden vastgelegd.
Vraag ook bij exports om gangbare formaten en een duidelijke beschrijving van velden en relaties. Een bestand met data is pas bruikbaar als duidelijk is wat de gegevens betekenen en hoe records met elkaar samenhangen.
Maak dataportabiliteit concreet
Dataportabiliteit is meer dan de mogelijkheid om een CSV-bestand te downloaden. Bij een ATS moet duidelijk zijn welke gegevens bij vertrek kunnen worden meegenomen.
Denk aan:
- kandidaatgegevens en sollicitaties;
- vacatures en historische statussen;
- talentpools;
- notities en beoordelingen voor zover overdracht is toegestaan;
- documenten;
- broninformatie;
- proceshistorie en tijdstempels;
- configuratiegegevens die nodig zijn om processen opnieuw op te bouwen.
Leg ook vast in welk formaat de export beschikbaar is en of relaties tussen records behouden blijven.
De Data Act legt nadruk op overstappen
De Europese Data Act bevat regels die obstakels bij het wisselen tussen data processing services moeten verminderen. De verordening bevat onder meer bepalingen over effectieve overstapmogelijkheden en over de export van gegevens in een gestructureerd, gangbaar en machineleesbaar formaat wanneer voor vergelijkbare diensten nog geen geharmoniseerde interoperabiliteitsstandaard beschikbaar is.
Of en hoe specifieke bepalingen op een concrete ATS-dienst van toepassing zijn, hangt af van de juridische en technische situatie. Voor inkoopteams is de richting wel relevant: organisaties moeten vooraf nadenken over overstappen, overdraagbaarheid en technische belemmeringen.
Neem die onderwerpen daarom op in selectiecriteria en contractonderhandelingen in plaats van ze pas te bespreken wanneer de overeenkomst wordt beëindigd.
Leg exit-afspraken vast in het contract
Technische flexibiliteit helpt weinig als contractuele afspraken ontbreken. Maak daarom vóór ondertekening duidelijk wat de leverancier bij beëindiging levert.
Leg bijvoorbeeld vast:
- welke gegevens worden geëxporteerd;
- binnen welke termijn de export beschikbaar is;
- welke formaten worden gebruikt;
- welke ondersteuning beschikbaar is tijdens migratie;
- welke kosten daarvoor gelden;
- hoe lang het oude systeem nog toegankelijk blijft;
- wanneer gegevens definitief worden verwijderd.
Door deze afspraken vooraf te maken, voorkom je dat de organisatie tijdens een migratie moet onderhandelen terwijl de tijdsdruk hoog is.
Houd integratielogica zo veel mogelijk los
Wanneer veel systemen met elkaar verbonden zijn, kan middleware of een centrale integratielaag helpen om afhankelijkheid te verminderen. In het kennisartikel over native integraties en middleware staat dat een centrale laag gegevens kan transformeren, routeren en monitoren.
Dat betekent niet dat middleware altijd nodig is. Voor een organisatie met enkele eenvoudige koppelingen kan een directe integratie overzichtelijker zijn. Bij een complex landschap kan het wel voorkomen dat alle logica opnieuw moet worden gebouwd zodra het ATS verandert.
De keuze moet daarom worden gemaakt op basis van het totale landschap en niet alleen op basis van de goedkoopste afzonderlijke koppeling.
Voorkom maatwerk zonder documentatie
Maatwerk is soms nodig, maar ongedocumenteerd maatwerk vergroot de lock-in. Zorg daarom dat duidelijk is welke businessregels in een koppeling zitten, welke velden worden gemapt en welke uitzonderingen bestaan.
Leg vast wie eigenaar is van de documentatie en wie wijzigingen mag doorvoeren. Wanneer alleen één externe ontwikkelaar begrijpt hoe een koppeling werkt, ontstaat een extra afhankelijkheid naast de afhankelijkheid van de softwareleverancier.
Test bovendien of een andere technische partij de documentatie kan begrijpen zonder mondelinge uitleg van de oorspronkelijke bouwer.
Denk al bij implementatie aan een toekomstige migratie
Een exitstrategie hoeft niet te betekenen dat een organisatie verwacht snel weg te gaan. Het is vooral een manier om te voorkomen dat keuzes uit de implementatiefase later onnodige beperkingen veroorzaken.
Bij een toekomstige overstap moet bijvoorbeeld duidelijk zijn welke data wordt meegenomen, welke historische informatie nodig blijft en hoe lang beide systemen naast elkaar functioneren. Het artikel Hoe migreer je naar een nieuw ATS? beschrijft dat datamapping en opschoning belangrijke onderdelen van zo’n overgang zijn.
Hoe beter de structuur en documentatie van het bestaande landschap, hoe kleiner de kans dat een migratie verandert in een technisch herstelproject.
Controleer lock-in periodiek
Vendor lock-in ontstaat niet alleen bij de eerste aanschaf. Nieuwe modules, extra koppelingen en maatwerk kunnen de afhankelijkheid ieder jaar vergroten.
Neem daarom periodiek een aantal vragen door: kunnen we onze gegevens volledig exporteren, zijn de koppelingen gedocumenteerd, gebruiken we gangbare standaarden, kunnen andere partijen de integraties onderhouden en zijn de exit-afspraken nog passend?
Zo wordt afhankelijkheid een beheersbaar architectuur- en inkoopvraagstuk in plaats van een probleem dat pas zichtbaar wordt wanneer de organisatie wil overstappen.
