Het meeste werk in de ict speelt zich af op het koppelvlak tussen klantbehoeften enerzijds en productenaanbod anderzijds. In dit veld spelen persoonlijke kwaliteiten op het gebied van communicatie en intermenselijke verhoudingen een sleutelrol. Echter in het recruitment proces komen deze skills pas in de eindfase voldoende aan bod; in de functie-omschrijving wordt er te veel nadruk gelegd op certificering en kennis van specifieke producten.
Heel veel banen en opdrachten in de hedendaagse ict-sector bevinden zich in het veld van advies, implementatie en integratie. Het is eigenlijk vrij logisch dat hier voortdurend veel werk te doen is. Aan de aanbod kant heb je een waaier van min of meer standaardprodukten en oplossingen, die worden ontwikkeld door een handjevol bekende en meestal internationale, leveranciers. Aan de vraagzijde heb je de individuele organisaties die in meer of mindere mate uniek zijn door een mix van omvang, bedrijfstak, aantal vestigingen, soort mensen dat er werkt, historie, publiek of privaat, interne processen, et cetera. Er is altijd een gat te overbruggen om een standaard product geschikt te maken om het te laten aansluiten op de organisatie.
Andersom is ook mogelijk, het aanpassen van een organisatie aan het product maar komt minder voor. In beide gevallen moet er maatwerk worden verricht om de twee elementen aan elkaar te koppelen en om ze samen te laten werken. In deze tussenlaag vinden product- en systeemimplementaties en integraties plaats. Als je goed gaat kijken zijn dit soort trajecten technisch inhoudelijk helemaal niet zo spannend. De wensen van de klant wijken in de praktijk niet eens zo heel ver af van de standaardfunctionaliteiten van een product of systeem. Het meeste werk zit hem dan ook in het grote aantal kleine afwijkende details waarop de implementatie moet worden aangepast om het op de specifieke organisatie te laten aansluiten. Deze details op zich zijn ook al niet spannend; het zijn er gewoon veel en er zijn wat onderlinge afhankelijkheden. In de praktijk ben je als technisch it-specialist dus heel veel bezig met overleg, lijstjes bijhouden, vertalen van requirements en technische actiepunten, afstemmen met productleveranciers, regelen van testsystemen, het voorbereiden van changes, het maken en bijwerken van kennis en documentatie en het overdragen aan de beheerorganisatie.
Het zijn allemaal wel dingen die moeten gebeuren. Het is geen uitzondering dat een project een week of twee vertraging loopt omdat er gewacht moet worden op de uitgifte van ip-adressen. Of wat te denken van de lange levertijden van hardware; als je in het begin niet zorgvuldig aandacht geeft aan het completeren van je boodschappenlijstje dan kan je flinke vertraging oplopen verder in het traject. Een gedeelte van dit soort regelwerk wordt gedaan door een project manager of een technisch projectleider, maar in de praktijk wordt veel regelwerk rondom een technisch domein (netwerk, Unix, Windows, Citrix, ..) volledig gedelegeerd naar de technisch specialist/consultant. Dat is begrijpelijk omdat de project manager geen of weinig technische achtergrond heeft en ook niet in staat is om vragen te stellen en te beantwoorden die een technische inhoud hebben.
Als technisch specialist is het daarom noodzakelijk dat je beschikt over de nodige 'consultancy skills' om jouw deel van het project tot een goed einde te brengen binnen de gestelde tijdslijnen.
Certificering overschat
Desondanks wordt er in de werving vooral ingezoomd op de technische inhoudelijk kennis en bagage van een technisch specialist. Hij moet verder op hoog niveau gecertificeerd zijn een ruime en aantoonbare ervaring hebben met specifieke typen hard- en software.
Certificering is een makkelijk en meetbaar criterium om op te selecteren. Echter naar mijn mening wordt er een te zwaar gewicht aan gehangen. In theorie zou je bijvoorbeeld een Microsoft of een Cisco certificering kunnen halen zonder dat je ooit aan de knoppen hebt gezeten. De cursusboeken zijn doorgaans niet van een hoog intellectueel niveau en behandelen de stof op een manier zodat een gemiddelde Amerikaanse college 'dude' dit kan volgen. Nadat je het boek hebt gelezen, schaf je een Boson- of Testking-oefenexamen aan en oefen je gedurende twee dagen eindeloos de vele oefenvragen. Op vrijdagmiddag doe je examen en het merendeel van de vragen click je moeiteloos door omdat je ze diezelfde ochtend nog als oefenvraag hebt zien langskomen. Een grote kans dat je in één keer slaagt.
Je kan certificering overigens wel benaderen vanuit een sociaal-psychologische invalshoek: een kandidaat heeft laten zien dat hij de moeite heeft genomen om naast het werk een studie op te pakken en om met vlijt, toewijding en uithoudingsvermogen zijn diploma te halen.
Praktijkervaring
Praktijkervaring is in dat opzicht veel belangrijker. Als technisch specialist moet je je deel hebben gehad aan urenlang, dag en nacht doorbrengen in een serverroom of datacenter waarbij je een stuk hardware probeert werkend te krijgen. 'Volgens de documentatie zou hij werken op deze versie'; en toch krijg je het in eerste instantie niet in één keer voor elkaar. Het is op die momenten en gedurende die vele lange uren dat je een beroep moet doen op je inventiviteit en je een bagage opbouwt van weetjes, 'tips & tricks' en 'do's en don't's'; zaken die je nooit uit de boeken kan halen. Hierbij is het minder relevant met welke exacte merken, platformen en software versies hebt gewerkt. Het gaat om de creativiteit, benadering en methodiek van probleemoplossen, binnen de randvoorwaarden van beperkte middelen en beperkte tijd. Overigens zijn de problemen van bepaalde typen hard- en software vaak vergelijkbaar met die van andere dus die kennis en ervaring is vaak weer goed bruikbaar om in nieuwe situaties tot de juiste oplosrichting te komen.
Toch zie ik nog steeds teveel vacatures en functie-omschrijvingen langskomen met daarin een opsomming van vereiste certificeringen en een lijst van producten en platformen compleet met versie- en subversie nummers, waarmee een kandidaat ervaring zou moeten hebben. Onderaan de tekst staat er vervolgens nog obligaat bij 'met goede sociale- en communicatieve vaardigheden'.
Voor de meeste IT functies waarvoor technische kennis is vereist zouden vooral de sociale- en communicatieve vaardigheiden nader moeten worden uitgewerkt en dienen ze bovenaan te staan.
Het zijn dan vooral de productervaringen die kunnen worden samengevat in termen als 'een ruime hands-on ervaring met diverse platformen en besturingssystemen op het gebied van..'. De lijst eindigt tot slot met 'certificering is een pré', om toch recht te doen aan de extra inspanningen die een kandidaat heeft gedaan om zich theoretisch te verdiepen.
Ik pleit ervoor dat men zich voorafgaand aan het wervingsproces expliciet de vraag stelt 'willen we een techneut of een technisch consultant' en dat men dan vervolgens zorgvuldig de criteria en de formulering van de vacature of opdrachtomschrijving daarop afstemt. Pas dan maak je een goede kans dat je de juiste mensen aantrekt.
@Bart
Mag jij drie keer raden welk bedrijf er op dat visitekaartje stond van die jongen die ik op dat feestje tegenkwam…..
Bart, goed geschreven artikel. Bedankt voor de tips.
Ik werk als Corporate Recruiter bij PQR en richt mij voornamelijk op de zoektocht naar Netwerk/Infra Technici. Wij maken onderscheid tussen Engineers en Consultants. Net als Engineers ontwerpen en bouwen de Consultants. Het verschil is dat de Consultants daarnaast workshops houden en advies geven aan onze klanten.
In het artikel komen meerdere punten aan de orde waarop ik graag wil reageren. Ten eerste certificering. Zoals door Reza wordt aangegeven is certificering niet doorslaggevend om op gesprek te mogen komen. Voor mij geldt certificering als een theoretisch bewijs van eagerness, kennis en ervaring (zoals ook Bart in zijn artikel aangeeft). Uiteraard zijn er situaties waarbij de praktijk anders is, maar daar komen onze Consultants in een gesprek snel achter. Zij checken dan ook of een kandidaat in staat is om binnen de projectscope de gewenste resultaten te boeken (ook door Bart genoemd in zijn artikel). Ik staar mij dan ook niet blind op certificaten, maar zoem in op praktijkervaring (voor zowel Consultants als Engineers).
Ten tweede schreef Bart over communicatieve vaardigheden. Verduidelijking is inderdaad nodig, aangezien het een veelomvattend begrip betreft. Zelf vind ik de intermenselijke vaardigheden van een kandidaat erg belangrijk. Ik versta hieronder: het begrijpen van de ander, het inleven in de ander. Ook vind ik het belangrijk dat een Consultant technische kennis kan vertalen in ‘lekentaal’.
De aanwezigheid van een combinatie tussen een hoger werk- en denkniveau, relevante praktijkervaring/-kennis en intermenselijke vaardigheden vind ik erg belangrijk.
Beste Bart,
GEEN werkgever kijkt in de eerste instantie naar je certificering, maar naar je diploma’s en je ervaring. Als je de waarde van de certificering wilt onderschatten is dat een andere verhaal.
Met de certificering bewijs je dat ea iets meer interesse voor de werk hebt en je gaat in je eigen tijd leren.