Van theorie naar praktijk – functioneel ontwerp van een recruitmentsysteem

Recruitmentsystemen zijn niet meer weg te denken in het hele proces van werving en selectie. Er is ook steeds meer goede informatie over beschikbaar, zoals bijvoorbeeld op de site Recruitmentsystemen. Het staat voor mij als een paal boven water dat je – of je nu vijf of vijfhonderd of vijfduizend sollicitanten in een jaar verwerkt – op z’n minst iets nodig hebt waar je je informatie in vastlegt. Dat kan een zelfgebouwd Excel-blad zijn of een state-of-the-art recruitmentsysteem, maakt niet uit; als je het maar vastlegt! Maar op het  moment dat je voor de keuze staat – en geconfronteerd wordt met vragen als: wat voor systeem heb ik nodig, welke processen wil ik wel en niet automatiseren, koop ik een bestaand systeem of ontwikkel ik zelf iets – is een goede aanpak nog niet één-twee-drie gevonden.

De basis wordt echter altijd gevormd door de vraag: hoe ziet mijn recruitmentproces eruit? Want al is het een relatief simpel proces – er ontstaat een vacature, we maken de vacature bekend, er reageren kandidaten, we kiezen de beste – zijn er grote verschillen in uiteindelijke aanpak. Je moet dus je eigen aanpak kennen. Als je dat weet – op z’n minst in grote lijnen – is de eerste stap een beschrijving ervan en de afstemming met de toekomstige gebruikers. Op deze punten wil ik – aan de hand van een concreet voorbeeld – hier ingaan.

In 2009 is voor de gemeente Den Haag het systeem Den Haag Connect ontwikkeld. Intussen – zoals je ook kunt lezen in de bijdragen van Stefan van Aken – wordt de eerste versie van Connect op dit moment doorontwikkeld naar Connect II.

Het maken van het functioneel ontwerp

Een functioneel ontwerp – of FO – is volgens een officiële definitie: de fase in de systeemontwikkeling waarin de benodigde functies in hun onderling verband worden beschreven. Wat moet het systeem precies doen? Op welk moment? Met welke gegevens? Op zich een eenvoudige vraag, maar in Den Haag kwam daar bij dat iedere dienst een eigen invulling gaf aan het recruitmentproces, o.a. afhankelijk van de wervingsvraag en het type medewerkers dat gezocht wordt. De basiseis aan het systeem was dus: flexibiliteit. Op grond van een inventarisatie van de processen (in gesprekken) is vervolgens een eerste beschrijving gemaakt. Deze beschrijving onderscheidde vacatures, kandidaten en sollicitaties. Vacatures hebben hun eigen gang door het proces: van interne openstelling – al dan niet voor herplaatsing – tot externe openstelling via de eigen website of externe media. Al naar gelang het proces voortgaat, komt er informatie in de database bij. Dat geldt in iets mindere mate voor kandidaten: van deze groep moeten vooral de persoons- en contactgegevens bekend én correct zijn. De ‘ motor’ van het systeem wordt gevormd door de sollicitaties: een koppeling van één vacature aan één kandidaat. De status van zo’n sollicitatie verandert gedurende het recruitmenttraject en ‘trekt’ zodoende zowel de vacature, als de kandidaat erdoorheen.

Draagvlak

Een belangrijke vraag bij het ontwikkelen was: ondersteunt dit proces met deze stappen de gebruikers optimaal? Is dit voor hun eigen praktijk bruikbaar, c.q. een verbetering? Kan het systeem op draagvlak rekenen? Om dit zo goed mogelijk te doen, werd de ontwikkeling begeleid door een projectgroep van gebruikers. De verschillende stappen werden telkens met hen besproken en zo konden ze feedback geven. Ook zijn al relatief vroeg in het proces tests uitgevoerd; wat een risico bleek te zijn, toen zich op de allereerste testdag al na tien minuten een heuse ‘showstopper’  voordeed. Maar door in de laatste fase van de ontwikkeling telkens te testen, bleef input van de gebruikers mogelijk. Tot het moment dat aan de meeste wensen voldaan was en de afronding nabij was; toen werd de projectgroep omgevormd tot gebruikersgroep en alle wensen en wijzigingen werden genoteerd voor de – toen al op de planning staande – doorontwikkeling. Maar het feit dat gebruikers vanaf het eerste  moment inspraak hebben gehad in de functionaliteiten van ‘hun’ systeem, heeft in hoge mate bijgedragen aan de acceptatie ervan.

Efficiëntie

Hoewel er in dit geval meer met de eigen processen rekening gehouden kon worden dan met een ‘standaardsysteem’, ontkomt geen enkele organisatie eraan om – als gevolg van het toch noodzakelijk stroomlijnen – kritisch naar die processen te kijken: waar kan het beter, sneller, efficiënter? Het mooie is: door gebruikers zo direct bij de ontwikkeling te betrekken, gebeurt dat bijna automatisch; de vraag “Waarom doen we het eigenlijk zo?” is regelmatig gesteld. Én aanleiding geweest om het bestaande proces op sommige punten aan te passen. Bijvoorbeeld toen we er achterkwamen dat er wel eens door twee mensen contact wordt opgenomen met een kandidaat, als één voldoende is.

De conclusie? Een goed FO, rechtstreekse betrokkenheid van de gebruikers bij de aanschaf of ontwikkeling van een recruitmentsysteem en de mogelijkheid om met elkaar naar het eindproduct toe te ‘groeien’, zijn kanjers van succesfactoren.