Ict'ers missen communicatieve vaardigheden en komen niet klantgericht over. Dit komt doordat zij zich niet kunnen verplaatsen in de denkwereld van niet-techneuten. 'Een klant wil ook gehoord worden, in plaats van alleen een oplossing.'
Ict-bedrijven vinden het steeds belangrijker dat hun medewerkers zowel technisch onderlegd zijn als communicatieve en sociale vaardigheden hebben, merken opleiders. Konden techneuten zich vroeger achter hun computer schuilhouden, tegenwoordig wordt verwacht dat zij ook met klanten communiceren. Daarbij blijkt het voor ict'ers moeilijk om zich in anderen te verplaatsen.
"Ict'ers zijn geneigd zwartwit te denken. Zij redeneren vanuit de techniek en geven aan wat wel en niet kan, maar missen gevoel voor verhoudingen", legt Yvonne Bik van trainingsbureau Ypsilon Communicatie het probleem uit. "Dat zij iets logisch vinden, wil echter niet zeggen dat het voor iemand anders ook zo is."
Liegen
Has van den Kieboom van opleidingsinstituut Schouten en Nelissen vult aan: "Ict'ers zijn sterk gericht op de inhoud van hun werkzaamheden en hebben soms minder oog voor de rest van de organisatie. Het is ict voor en ict na. Daarom denken zij dat klanten tevreden zijn wanneer zij hun probleem oplossen. Maar een klant wil daarnaast gehoord worden. Ict'ers moeten leren om de inhoud te scheiden van de relationele kant van klantcontact."
Hoe zij dit moeten doen, vinden cursisten echter vaak lastig, merken de trainers. Volgens Miriam van de Laak van One2train zien ict'ers het verpakken van een boodschap als liegen. "Wij merken dat cursisten vaak weerstand hebben om een antwoord tactvol te brengen, zodat de klant er ook een prettig gevoel bij heeft", licht zij toe. Ook Bik merkt dat zij cursisten eerst heel duidelijk moet maken dat ict'ers niet dezelfde taal spreken als niet-techneuten. "Meestal geldt dat een bedrijf tevreden klanten wil. Maar ict'ers denken dat een klant tevreden is als hij de beste oplossing krijgt."
Ik werk voor een groot bank- en verzekeringsbedrijf op de Change afdeling. Het is juist onze kracht wat speelt bij de klant en dat we ons daarin kunnen verplaatsen. Het meerendeel van de analisten heeft ‘voorkant’ ervaring.
Wij ‘challengen’ onze opdrachtgever en brengen requirements die de opdrachtgever wel heeft maar vergeet te stellen ook boven water. Dat scheelt veel kosten in het realisatietraject.
Wat vaak fout gaat, is dat deadlines heilig zijn en dit doel alle middelen heiligt. Als requirements nog maar half bekend zijn en ‘zweven’, wil de project manager en de opdrachtgever al dat de bouwer begint met bouwen. Verschillende stadia (requirements, ontwerp en bouw) lopen dus door elkaar. Het opleveren op tijd tegen de geplande kosten is veel belangrijker dan de kwaliteit. Het testtraject is dan ook erg ….boeiend… Oplossingen zijn vaak houtje-touwtje (niet structureel) en sommige requirements worden uberhaupt niet opgeleverd. Die worden dan vaak als ‘hier valt de bank niet mee om’ afgeschilderd. Korte termijn oplossingen zijn killing voor degelijke software. Ieder project heeft oogkleppen op en focust alleen op eigen deliverables. Software wordt niet generiek maar specifiek en de ene puist na de andere puist wordt gebouwd. Software wordt niet overdraagbaar, niet transparant en dus complex (mensen met kennis worden ‘helden’ binnen de organisatie) waardoor later de meest simpele wijzigingen steeds duurder worden en soms zelfs uitvoerbaar. De software-leverancier is allang blij als een bepaalde module nog werkt en adviseert dan om er vooral niets aan te veranderen.
Juist hier zou men eens een cursus voor moeten uitschrijven en project- en programma-managers en opdrachtgevers uitnodigen.
Achja daar kan je wel op reageren maar dat heeft geen nut.
Persoonlijk vind ik het allemaal vriendjespolitiek.
maare als ze het zelf beter kunnen, dan zoek ik wel vast naar een andere manier om mijn geld te verdienen.
Tip 1: Goed eten hard werken is de sleutel tot succes
Fijne dag
Een externe kan zich wel prima verplaatsen in anderen. Die is door jarenlange ervaring getraind in verandering en aanpassingen. Dit in tegenstelling tot vastgeroeste internen, die hun eiland hebben afgebakend en de klant alleen maar lastig vallen met hun domme regeltje en procedures. Flexibel? Ho maar.
Ik vind het wat kort door de bocht, de echt techneuten zijn in de regel niet de mensen van het klantencontact dat doen anderen. Als techneut is het vaak net zo vervelend om met projecten geconfronteerd te worden die ongelukkig in elkaar steken en bijna niet waar te maken zijn. Daar heeft de techneut heel weinig in te vertellen maar krijgt het uiteindelijk wel op zijn bordje. Ik zou eerder pleiten voor een grotere rol van techneuten in de projectleiding en de beslissingen die daarin genomen worden.
Het artikel klopt in zoverre dat ICT’ers meestal typische eilandbewoners zijn, maar spreekt niet over de oplossing voor dit structurele probleem.
Nog te vaak zie ik bij bedrijven, voornamelijk kleinere, dat de ICT’er wel even iets maakt wat hij denkt dat de klant wil. Dit zal in 9 van de 10 gevallen geheid fout gaan. De klant zal het niet begrijpen en de ICT’er vindt dat de klant niet moeilijk moet doen, want “alles is toch helemaal logisch en precies wat de klant wil”?
Dit is de taak van een tussenpersoon. Een persoon die zowel de taal van de ICT’er als die van de klant begrijpt. Veel bedrijven hanteren verschillende namen voor deze duizendpoot. Informatie-analist, functioneel ontwerper of consultant, maar het komt altijd op hetzelfde neer.
FFe snel over 1 kam geschoren…. LOL
Wieksers zijn het
Ik ben het iig met chris eens, de ene klant wil anders behandeld worden dan de ander. De ene wil dat het “gewoon” opgelost wordt, de ander wil het uitgelegd hebben in jip en janneke taal zodat zij het eventueel in de toekomst zelf kunnen. En ik weet zeker dat 90% van alle ICT’ers dat prima kunnen inschatten hoe te handelen bij een oplossing.
Kim, bedankt, m’n imago is weer een stuk verbeterd. Duh.
Weet wat je schrijft, of ga eens kijken bij zo’n ‘idioot’ ICT-bedrijf.
Discussie zijn leuk, maar dit slaat echt nergens op.
Het lijkt erop dat een aantal lieden zich aardig op de tenen getrapt voelt, terwijl het eigenlijk alleen maar het constateren van een feit is.
Als doel van een systeemontwikkelproject zie ik:
Doen wat de klant (via gebruikers) nodig heeft (wat meestal niet is wat hij zegt), op het moment dat hij het nodig heeft (wat eerder of later kan zijn dan hij zegt), zodat hij tevreden is (dan wil hij betalen) en succesvoller dan voordat we het systeem leverden (als hij niet succesvol is kan hij niet betalen; als hij niet succesvoller is, waarom zou hij dan betalen).
Veel ICT systemen verplaatsen zich niet voldoende in de eigenschappen van de gebruiker. Dus niet “hoe de gebruiker zich zou moeten gedragen” maar “hoe de gebruiker zich nu eenmaal gedraagt”, ook al vind je dat om welke reden ook onjuist. De gebruikers zijn nu eenmaal onderdeel van het systeem.
Ik was gisteren op Schiphol om in te checken en het duurde veel langer dan normaal. Als reden werd door de dames gegeven: ?Sorry, we hebben een nieuw computersysteem.? Zoals je ziet, geheel in tegenspraak met het doel (succesvoller dan met het vorige systeem). Een project heeft de verantwoordelijkheid niet alleen om het ICT systeem op te leveren, maar ook om zich ervan te vergewissen dat de stakeholders tevreden zijn en dat de gebruikers succesvoller zijn dan eerder. De dames zaten te zweten achter hun beeldschermen en de klanten (reizigers) ergerden zich. De klant (in dit geval Finnair) maakte hierdoor ongewild een slechte beurt.
?Heathrow Terminal 5 was op tijd en binnen budget?, zei een van de betrokken ingenieurs. Toegegeven, een geweldige prestatie. Technisch gezien. Gebruikers voor wie de terminal gebouwd is, namelijk de reizigers, zijn echter niet ge?nteresseerd in de prachtige techniek. Zij leveren hun bagage af en verwachten op de luchthaven van aankomst hun bagage zo snel in acceptabele toestand weer terug te krijgen. Dat gebeurde niet: veel bagage kwam verkeerd terecht. Ontwikkelaars dachten dat ze en prima job hadden geleverd. Gewone mensen zien meteen dat ze gefaald hebben, al heb ik begrepen dat het inmiddels beter gaat.
Zijn er van die verontwaardigde ICTers die kunnen melden dat hun laatste project op tijd, binnen budget, foutloos is opgeleverd, waarbij de gebruikers (en via de gebruikers: de klant) meteen dik tevreden waren en succesvoller dan voor de levering van het systeem?
Dat lijkt me een betere argumentatie dan de welles-nietes discussie hierboven.
Nog een voorbeeld:
Ik schrijf eerst mijn commentaar in MS Word. Dat kopieer ik in dit vak op deze website, nadat ik met de spellingschecker er enige typo’s uit heb gehaald.
De aanhalingstekens uit Word blijken hierboven echter als vraagtekens te worden weergegeven. De i met trema in geinteresseerd wordt niet goed weergegeven. En ik kan de tekst niet editen om deze zaken te repareren en om een verkeerd woord te verwijderen.
Ik hoor de (technische) redenen al waarom dit is zoals het is. Dat doet voor mij als gebruiker echter niet ter zake.