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.
Goed geschreven artikel, kan me vinden in de inhoud. Zo zie je dat er bij bijna alles complexiteit bij komt kijken.
Want hoe zorg je ervoor dat de juiste vacature geplaatst wordt? Daar komt dus veel inzicht bij kijken en de vacature verantwoordelijke is vaak niet diegene die het project of de baan echt kent. Je moet dus samenwerken en conceptueel goed begrijpen *wie* je nodig hebt.
‘met goede sociale- en communicatieve vaardigheden’ is inderdaad iets wat je in de staart vind, maar uiteindelijk het hart raakt van wat je werkelijk zoekt.
Er is alleen het probleem dat er niet genoeg mensen zijn die aan al die eisen voldoen en er sprake is van schaarste. Techneuten zijn immers personen die voornamelijk in techniek geïnteresseerd zijn en op het vlak van sociale vaardigheden vaak minder dan gemiddeld ervaring hebben. Dan zul je of meer moeten betalen of met minder genoegen nemen.
Grotendeels eens met de schrijver als het gaat om consultancy gerelateerde rollen. overigens, certificeringen worden niet altijd “cadeau” gegeven. Je mag echt wel een verschil in kennis verwachten tussen Cisco engineer niveau CCNA of CCIE of tussen een HP Networking engineer niveau AIS of MASE. De middenweg lijkt ook hier weer het meest optimaal. Dwz. technische basis kennis is toch noodzakelijk (lees hier de theoretische certificeringen), de andere helft zijn capaciteiten als analytisch vermogen maar zeker ook communicatieve vaardigheden (zowel mondeling als schriftelijk).
Een absoluut te propageren en distribueren artikel. Men kampt hier in de velden met een aantal problemen.
Commercieel
Vanuit commercieel oogpunt zie je vacatures opduiken met een inhoud waarbij je je werkelijk af moet vragen wat men nu precies zoekt. Het is een volkomen dolle markt en men meent nog steeds op zoek te kunnen naar die niche die van twee of drie disciplines moet zijn voorzien. We zullen het dan maar even niet hebben over de tariefstelling.
Het vreemde is dat men dan ook rustig durft te zeggen de geschikte kandidaat maar niet te kunnen vinden. Ik vraag me overigens van Recruitment en W&S zijde af wat daar de kennis en kunde is want als je geen neen kunt zeggen tegen dergelijke aanvragen, hou je mede een probleem in stand.
Certificering.
Dank Bart voor dit artikel. Ik roep dit namelijk al sedert de implementatie van de MS certificaten. Ik heb vele malen, vooral in de beginfase, mensen ’twee sporen’ aangeboden. Want wat gebeurde er namelijk, juist wat beschreven word. Men ging zich prepareren met alle gevolgen van dien. Je haalde wel dat certificaat maar mist het noodzakelijke inzicht.
Ik wil daarnaast graag ook even aantekenen dat dit ook heden ten dage speelt. IT is een lineaire materie die analytisch vermogen en inzicht vraagt. Dit overigens van begin tot eind van de disciplines.
IT zou, dat is de pretentie en verkooppraatje, moeten besparen. Juist dat is nu precies wat er steeds minder gebeurd. Men bedenkt er van alles bij zonder zich af te vragen of het een toegevoegde waarde heeft of besparingen levert. Gevolg? Dat IT juist aanzienlijk kost i.p.v. dat het bespaart.
HR en Recruitment
Beiden hebben niet de kennis en kunde om in te kunnen schatten of iemand de noodzakelijke kennis en ervaring bevat op de juiste plaat terecht te komen en komen dan niet verder dan het vervullen van een loketfunctie. Geen wonder dat men dan de werkelijke IT specialist niet weet te bereiken.
Ik ben bang dat men werving en selectie over een andere boeg zal moeten gooien. Dat betekend dat zal moeten worden gekeken of het in de persoon en persoonlijkheid zit een bepaalde rol te kunnen vervullen en in tweede moet worden gekeken naar CV en certificering.
Ik denk dat de kans op match vele malen groter zal zijn ook als je bedenk dat heel veel goede professionals soms erg slecht zijn in het opmaken van een consistent cv.
Een heel goed artikel.
Goed stuk! De analyse is volledig en de kanttekeningen zijn geplaatst.
In feite is die uitvoerige lijst met producten (en inderdaad met sub-sub versies) een blijk van onwetendheid, het noemt de elementen (steentjes) maar verteld niet wat voor soort verzameling (bouwwerk) het moet worden.
En dan heb ik het nog niet over vacatures met een omschijving als “je houdt je bezig met …” alsof men (wederom) geen weet heeft van het beoogde resultaat.
Het lastige van certificeringen is de ballast die je moet leren. Maar ja, onlangs kreeg ik tijdens een intake dit te horen: “Weten wat je niet gebruikt is beter dan niet weten wat je kunt gebruiken.” Hier sprak een in mijn beleving overgecertificeerde programmamanager, meer het studie-type. En hoewel het plausibel klinkt, ben ik het niet met hem eens. De praktijk betekent in de meeste gevallen een beperking van de ruimte die je in theorie hebt om de dingen te doen die nodig zijn om tot een resultaat te komen. Uitgebreide best practices, technische verhandelingen of theoretisch concepten blijken in de praktijk vaak maar beperkt toepasbaar. Daar waar men krampachtig probeert het hele scala toe te passen, uit te voeren of te benutten loopt men al snel tegen allerlei beperkingen aan. En dan komt het toch weer aan op creatief zoeken naar nieuwe wegen, het benutten van ervaring, inzicht en gezond verstand. Daarbij kan (moet) je gebruik maken van de kennis van anderen en bovendien kennis opzoeken op het moment dat je het nodig hebt, want het is tegenwoordig volop beschikbaar en vaak vrij toegankelijk.
Maar hoe weet je dan dat iemand geschikt is om de klus bij jouw organisatie op te pakken?
De wijze waarop certificaten kunnen worden behaald, zoals in dit artikel beschreven, is goed beschouwd schokkend. Het zegt niets over competenties, begrip of het vermogen e.e.a. toe te kunnen passen in de praktijk. Waar we eigenlijk naar toe zouden moeten is een manier om resultaten in of vanuit de praktijk te certificeren. Hoe heeft iemand in de praktijk gepresteerd? Waren de resultaten conform, of zelfs boven verwachting? Welke competenties heeft hij/zij laten zien? Waar heeft hij speciale (extra) aandacht aan geschonken? En zo nog wat vragen.
Een stap verder is het idee dat we wellicht meer hebben aan een gecertificeerde wijze van beoordelen. Een beoordelingsmethodiek die een resultaat geeft dat als referentie kan dienen bij het CV. Ideaal voor autodidacten die liever (en beter) leren in de praktijk en voor hen die niet goed kunnen studeren, maar zich wel keer op keer bewijzen.
Ik vind het bijzonder denigrerend hoe er wordt gesproken over het behalen van certificaten.
Alsof alle certificaten eenvoudig te behalen zijn door een boek te lezen. Ik wens iedereen die CCNP uit een boek wilt leren veel succes, maar je zal het niet halen.
Iedereen die gestolen examens gebruikt om een certificaat te behalen, komt zichzelf vanzelf tegen, bijvoorbeeld doordat je niet voldoet aan de eisen die de klant stelt of doordat je levenslang verbannen wordt door de leverancier.
Certificaten behaal ik door een combinatie van:
– Studeren
– Oefenen
– Praktijkervaring
Het gebruiken van braindumps behoort er in ieder geval niet bij.
Beste mensen,
Zeer veel dank voor jullie goed onderbouwde feedback. Een genot om jullie reacties te lezen (en niet alleen omdat jullie het grotendeels met me eens zijn). Ik heb het stuk geschreven vanuit mijn ruim 12 jaar praktijkervaring als Netwerkspecialist. Ik doe veel ’techneuten’ werk, maar ben ook zorgvuldig bezig met communicatie, documentatie,etc… Het schrijven van dit stuk is daar o.a. een uitvloeisel van…
nogmaals dank!
@Guido: spijtig dat je het gedeelte over certificering als denigrerend hebt opgevat; in ieder geval was het zo niet bedoeld. Ikzelf heb vele Cisco examens gedaan en ben vaak geslaagd maar ook een paar keer gezakt. Over het algemeen vind ik het niveau van het studiemateriaal en van de vragen van het examen vaak ondermaats. Met name de vele weetjes vragen die toch nog steeds veel terugkomen. Deze vragen kan je uiit je hoofd stampen door middel van Testking achtige oefenexamens. (Ik heb overigens netjes en officieel betaald voor de Testking software). Overigens zijn de scenario/lab vragen wel een goede manier om de kennis te testen. Laat de kandidaten maar stukjes configuratie maken en iets werkend maken; wat mij betreft mogen er veel meer van dat soort vragen in komen te staan..
Maar blijft staan dat er in het wervingsproces een te zwaar gewicht wordt gehangen aan certificering. Ik heb daar zelf de volgende ervaring mee: In 2001, net na “nine-eleven” zat ik een halfjaar op de bank bij CMG. Ik heb toen achter elkaar mijn Routing, Switching, Remote Access en Troubleshooting gehaald en ik was rond de Kerst CCNP’er. In januari kwam ik op mijn eerste opdracht maar ik kon toen nog eigenlijk bar weinig. Het heeft zeg maar nog zo’n 4 a 5 jaar geduurd voordat mijn praktijkervaring in balans was met mijn status als CCNP’er..
Guido, ik snap dat je je aangesproken voelt als je het vuur uit je sloffen hebt gelopen om jouw certificering te behalen.
Maar… niet elke certificering is daadwerkelijk moeilijk om te halen. En Bart plaatst daaronder ook een kanttekening.
Het is niet zo dat een certificering nooit iets zegt, alleen dat een certificering geen enkele garantie of zekerheid biedt en als je personeels advertenties leest certificering wel is waar primair om wordt gevraagd.
De gevraagde match en de gewenste match sluiten daardoor zijn daardoor niet in balans en zal dus tot verkeerde matches leiden.