Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Communicatie gaat fout tussen ICT en business

 

Computable Expert

Andre Salomons
Directeur/CIO, Smart SharePoint Solutions. Expert van Computable voor de topics Cloud Computing en Loopbaan.

Nu business en ict steeds meer samen groeien naar consumerization of it, is het van belang om te weten waarom het zo vaak misgaat tussen de business en ict. En hoe je met deze kennis op zak betere resultaten kunt behalen.

Zestig jaar geleden werd over 'automation' voor het eerst gepubliceerd. Voordat ik het daar dieper op in ga, wil ik toch weer terug in de tijd om het heden te kunnen verklaren. Het jaar 1947 wordt soms geduid als het jaar waarin de automatisering begon, toen de Ford Motor Co. en Del Harder, vice president productie, het concept 'machinale productie' voor het eerst toepasten in de autoproductie. Ford introduceerde daarvoor de term 'automation'. Die term werd in die dagen uitsluitend intern gebruikt om het 'automatische proces' te beschrijven. De term werd vanaf 1953 op bredere schaal gebruikt na het verschijnen van John Diebold's boek, Automation. In het boek werd gerefereerd aan de informatie uit het proces en aan het proces zelf. Dat is dus dit jaar zestig jaar geleden!

Automation groeide later uit tot wat we nu software noemen. Software om processen te ondersteunen. Om software te ontwikkelen, had je programmeurs nodig. In het begin waren dit mensen met wiskundige aanleg die van nullen en enen door middel van het programmeren iets begrijpelijks konden maken. Later zijn daar tal van functies bijgekomen en zijn deze functies onder de verzamelnaam 'ict'ers' bekend.

Tolkfunctie is architectenrol

Kan de business met de programmeur praten? Niet verstandig, ze gebruiken dezelfde woorden, maar spreken absoluut niet dezelfde taal. Daardoor maken veel organisaties een basisfout. Er wordt vergeten dat er tussen 'business' en ict een tolk moet zijn om de vertaling van de 'business' naar de programmeur te maken, de vertaling van wens naar technisch ontwerp. Als een vraag of wens direct van 'business' naar de programmeur gaat, wordt de tolkfunctie (architectenrol) overgeslagen en ontstaan de eerste problemen. Denkpatronen en karakterverschillen bepalen vervolgens dat het hier mis moet lopen.

Vertegenwoordigers van business en ict zijn vaak hoog opgeleid en hebben verantwoordelijkheidsgevoel. Een programmeur is opgeleid om logisch te denken, maar in zijn opleiding komt het sociale aspect als communiceren met anderen nauwelijks voor. Als gevolg van karaktereigenschappen van het type mens dat programmeur is, is het logisch dat hij tekortschiet in contacten met anderen. Als een programmeur met een vraag zit, zal/wil hij die vraag oplossen in plaats van het antwoord te vragen. Daarna vergeet hij vaak dat hij het had moeten vragen of dat hij zijn eigen antwoord had moeten laten bevestigen. Als de business erachter komt dat een verkeerde beslissing is genomen is het vaak al te laat.

Cloud- en out of the box-toepassingen

Bij de aanschaf van cloud- of out of the box-toepassingen, niet per definitie hetzelfde, verklein je de foutkansen. In dit geval schaf je een kant-en-klare oplossing voor een bestaand probleem aan. De processen zijn uitgewerkt door de leverende partij en programeerbeslissingen zijn al genomen. Dat risico is door de leverende partij dus afgedekt. Het is daarom aantrekkelijk voor de business deze software in de cloud te huren en direct in te zetten zonder daarover te overleggen met ict. Dan is er sprake van consumerization van software, men heeft immers een direct werkende oplossing, zoals men met de apps van Apple etc. ook gewend is. Een oplossing kan direct ingezet worden.

Vaak gaat het fout doordat de business vindt dat er geen gebruik gemaakt hoeft te worden van de kennis van de ict-afdeling. Daarbij gaat de business er aan voorbij dat ze per definitie ict-kennis ontbeert. Indien een cloudoplossing zonder voorafgaand overleg wordt ingezet en later blijkt dat het beter had gekund, komt het vaak voor dat partijen elkaar zullen tegenwerken. Een voorbeeld van toegevoegde waarde van een ict-afdeling kan zijn dat zij de business er op attent kan maken dat bij gebruik van verschillende abonnementen voor cloudtoepassingen, een single-sign-on niet automatisch geregeld is.

Communicatie

Samenwerking compenseert elkaars zwakheden en maken het bedrijf sterker. De c in ict'er staat voor communicatie. Waarom die er staat is niet altijd duidelijk, omdat in de praktijk dit niet de sterke kant van ict'ers blijkt te zijn. Dus, daar waar de ict'er van nature zwak is in de communicatie en de business daar ook niet in uitblinkt, is het handig om de gebieden waar ze wel sterk in zijn beter te benutten.

Zo kunnen financials de aanvragen voor software vanuit de business ondersteunen door deze beter te documenteren. Hierdoor kan vertaling in een technisch ontwerp door een architect gedaan kan worden, kan de programmeur beter programmeren en worden de uitkomsten beter voorspelbaar. Ook door de aanschaf van softwareoplossingen out of the box (cloud) kunnen in een aantal gevallen betere resultaten bereikt worden dan door programmeerwerk van eigen ict'ers.

Daarnaast moet er niet, om later geld te kunnen besparen, geschrapt worden in een functie van architect, de tolk, te laten vervallen. De laatste tijd gebeurt dit om financiële redenen. Zorg daarom in alle gevallen voor overleg vooraf, want dat geeft de beste kans van slagen. De business komt van Venus en ict'ers van Mars, zal de oorzaak wel zijn. Want wezens van Mars communiceren niet en mensen van Venus ook niet.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4752483). © Jaarbeurs IT Media.

?


Lees meer over


Partnerinformatie
 

Reacties

Je zet een enorm stereo type developer neer. Tegenwoordig proberen developers just veel dichter tegen de business aan te leunen door agile technieken (oa scrum) te gebruiken. Hierdoor is er veel meer directe communicatie tussen de stakholders en de developers. Dit geeft allerlei voordelen;
- bouwen wat nodig is
- inzicht geven waar een project staat en de business de mogelijkheid geven om te sturen.

Verder zie je ook steeds meer dat de rol van 'architect' door dit soort teams opgepakt worden. De testers beheren de requirements (dus veel interactie met de eindgebruiker) en de traditionele software architecten rol zal door meerdere mensen in het team opgepakt worden. Er is wel vaak een tech lead aanwezig, maar dit is gewoon een teamlid. Het is niet de bedoeling dat hij alleen maar gaat ontwerpen en het team alleen maar gaat coderen.. maw.. geen ivoren toren architect meer (dat is zo ouderwets).

Door zoveel mogelijk lagen uit het systeem weg te halen, i.p.v. toe te voegen, krijg je juist meer voorspelbaarheid.

Aardig stukje van dhr. Salomons, en ik wens hem natuurlijk alle zakelijke voorspoed.

Wat duidelijk naar voren komt uit het artikel is het communicateve gat tussen twee werelden. IT en non IT. Het is dhr. Salomons niet aan te rekenen dat hij niet helemaal begrijpt wat nou dat communacatieve gat veroorzaakt tussen deze twee werelden.

Lineairiteit van IT als materie
IT is een lineaire materie. Ook hier gaat de wetmatigheid op,"Waar je mee werkt wordt je mee besmet.." Dat betekend dat je eerst zult moeten willen begrijpen en accepteren dat IT nu eenmaal een lineaire materie is. Welke lappendeken je er als methode over heen wilt leggen, de essentie blijft hetzelfde.

IT professionals, en je hebt dat helemaal niet eens door vaak, worden non communicatiever naarmate ze ergens in gespecialiseerder worden. De echte nerds en specialisten zijn vaak de grootste non-communicatisten. Dat ligt niet aan de persoon, neen dat ligt aan de lineairiteit van de materie.

Neem dit feit even aan, hoef je er verder ook niet zo over na te denken.

Dynamiek vs Statisch
U ziet het al, er zijn een groot aantal verschillen tussen dynamisch en statisch. En juist dat is de grootste contributerende factor van dingen die mis en fout gaan in IT en de communicatie die IT betreft.

Dit gegeven is helemaal niet zo ernstig, wanneer men maar wil aannemen dat dat zo is en wil aannemen dat daar een zeer eenvoudige oplossing voor bestaat. een oplossing die overigens nog eens volkomen gratis is ook.

De C staat voor....
De C in ICT staat overigens voor Computer. ( ;O) )
IT als materie namelijk maakt communicatie mogelijk op een bepaalde manier. En die wijze van communiceren is anders dan de hele grote meerderheid van gebruikers gebruikt in denken, doen en spraak.

Rollen en verantwoordelijkheden
Het is nu eenmaal zo dat een zeer aanzienlijk deel van hen die in en met IT werkzaam zijn, zich helemaal niet eens bewust zijn van die wetmatigheden maar jammer dgenoeg ook niet dat materie IT zich beweegt zoals die zich beweegt. Want dat valt helaas niet te veranderen.

Dat betekend dus ook dat het feitelijk niets uit maakt welke rol je welke verantwoordelijkheden toe wil dichten. Als namelijk de manier van acteren en communiceren contra de werking en loop van IT als materie is, dan loopt die, heel voorspelbaar, tegen weerstand of tegenstellingenaan.

Geen enkele methodiek die.....
Men heeft de prachtigste methodieken bedacht. E3D, Prince, ITIL, TMAP, ISEB, Scrum, Football, Tennis, Karting, Panorama en Nieuwe Revue, u zegt het maar..... maar.....

Geen van al die methoden beginnen met .... ,'Er was eens.... een lineair principe van werking, die men later IT is gaan noemen. En dat principe is onderheving aan eenvoudige wetmatigheden.

Enfin, een lang verhaal kort, als uw basis voor een ieder, IT en Non IT, niet helder is, blijf je te maken krijgen met dit soort artikelen. Aan wie ga je nou welke rol en verantwoordelijkheden koppelen.

en dat is jammer, want die brug ligt er al lang. Alleen is iedereen nog steeds zo druk bezig om steeds weer andere bruggen, bootjes, kano's, kabels, touwen, of weet ik wat te bedenken voor één en hetzelfde.

Hoe kom je samen nou op de gelijke manier aan de overkant?

Mail me even en ik stuur je met plezier HET antwoord. Gewoon, gratis. Geen verkoop verhaal maar gewoon omdat het een universeel ding is.

Prettig weekend alvast. :O)

Een goed leesbaar artikel met een vergrootglas op de typische IT-er.

Overigens kan ik de titel toch echt wel onderstrepen. De communicatie gaat veel fout, alleen denk ik niet dat de nadruk op de niet communicerende IT-er gaat, maar meer de business die zich eigenlijk niet met IT wil bezig houden. Gewoon zoals de consument het internet en zijn tablet en smartphone gebruikt, in diens ogen is IT simpel en werkt het gewoon. Dat het niet simpel is maakt een gebruiker en dus ook de business niet uit, zolang het maar simpel lijkt en werkt.

Er staan heerlijke niet onderbouwde waarheden in zoals "Dus, daar waar de ict'er van nature zwak is in de communicatie"

Maar goed, leuk, en dan lees ik zo'n reactie van Numoquest. Wat een onzin! "De C in ICT staat overigens voor Computer.", dan ben ik heel benieuwd naar de bron daarvan.

"IT als materie" Pff, cloud computing is nog tastbaarder dan dat.

"Neem dit feit even aan, hoef je er verder ook niet zo over na te denken." -- Dat klinkt in mijn oren nogal arrogant, belerend en als het dan een feit is, dan zou ik graag de onderbouwing daarvan zien.

En dan nog roepen dat je het antwoord weet en hebt, dat is echt een gevalletje (en ik herhaal Reza in antwoord op mijn reactie in een ander artikel) "Ben ik nou degene die zo slim is, of ben jij nou zo dom?"

Want in mijn ogen is er geen sluitend eenduidig antwoord en oplossing, anders had iedereen die echt wel aangehangen en was het probleem er niet geweest.

Toch kan ik het nooit laten je reactie te lezen.

Dus de ict'ers kunnen niet communiceren en de business (klant) eigenlijk ook niet? Eigenlijk kan niemand goed communiceren?

De mannen komen van Mars en vrouwen komen van Venus referentie geeft mij ook vreemde hersensspinsels. De klant is per definitie altijd vrouwelijk?

De 'c' uit de ict komt voort uit de telematica en telefonie. Naast servers en databases houdt het zich ook bezig met netwerken en verbindingen.

Andre,

Ik moest even in mijn archief duiken omdat ik me herinnerde hier jaren geleden ook al eens wat over geschreven te hebben voor NetOpus, de problemen met Business-IT alignment. En nu jaren later moet ik spijtig constateren dat het gat hier zeker nog niet kleiner is geworden. Misschien wel omdat ict aan business verklaren vergelijkbaar is met de relativiteitstheorie uitleggen aan leken waarna alleen idee van sneller dan het licht reizen blijft hangen. Als architect kun je dan een heel betoog gaan houden dat de kosten kwadratisch toenemen als je de massa vergroot maar als de zon gratis lijkt te schijnen is dat toch aan dovemans oren gericht.

uit het artikel: De c in ict'er staat voor communicatie. Waarom die er staat is niet altijd duidelijk, omdat in de praktijk dit niet de sterke kant van ict'ers blijkt te zijn.

@Andre: iCt=informatie en Communicatietechnologie

op zich leuk gevonden om de c op de intermenselijke communicatie te betrekken, dat wel, maar de C in iCt is daar niet voor bedoeld.

@Henri: Wat die reactie van NumoQuest "C staat voor computer" betreft. Daar staat een vreemde smiley achter en ik denk dat hij het als grap bedoelde. Over communiceren gesproken ;-)

Ondanks dat ik het nu een tweede keer opneem voor Civile, moet ik bekennen dat ik zijn reacties niet altijd volledig lees. Het zijn te lange wollige teksten die naar mijn idee te veel indruisen tegen het KISS-principe.

Duidelijk is dat dit artikel wat oproept, dat wil je toch graag als je een stuk schrijft.

Volgens mij is de architect ook niet de sleutel voor de oplossing. Vaak kom ik architecten tegen ik na 5 minuten praten helemaal kwijt ben. En daar gaat het fout. We praten en vinden een oplossing maar het gaat op twee vlakken fout.

Het eerste wat fout gaat is luisteren naar het antwoord. Vaak krijg je iets te horen maar is dat eigenlijk niet wat je wil/moet weten. Je krijgt vaak een doel maar niet het probleem te horen. Als ICT'er moet je verstand hebben van de business want dan kan je achter het echte antwoord komen. Begrijp je klant.

Het tweede is dat tekst meervoudig uitlegbaar is. Als ik een tafel wil kan ik 923 soorten tafels verzinnen. Vergeet die tekst en visualiseer hetgeen je wilt bespreken. Dus niet een discussie van hoe de data van frontend naar backend gaat maar een simulatie van wat de oplossingsrichtingen zijn. Dan voel je de juiste oplossing en kan je dan dus ook meten.

Kortom, verstand van de business hebben en daardoor het doel/probleem begrijpen. En niet opschrijven of bespreken maar tastbaar maken via beeld/simulatie.

Businesscommunicatie: 'We willen het goed, snel en goedkoop.'
Antwoord techniek: 'Kan niet tegelijk, kies er maximaal twee.'
Businesscommunicatie: 'Ok, doe die twee maar en die andere ook.'

Dank voor jullie reacties. @PeterV.ik heb idd gekozen voor het stereotype.

@Numoquest, je hoeft geen meneer tegen mij te zeggen ;) Gewoon André is goed hoor. Het blijkt dat de Donald Duck in kringen van hoger opgeleiden ook goed wordt gelezen. Als die brug er ligt, waarom gebruikt niemand hem dan? Had het misschien een tunnel moeten zijn waar een trein door heen rijdt? De kern zit hem in samenwerken.

@Henri, bedankt. Feit is dat waarheden die iedereen onderschrijft niet onderbouwd behoeven te worden.Er is wel een eenduidig antwoord naar mijn idee en dat is samenwerken en elkaars zwakheden compenseren.

Zoals Marcel Kouwenberg terecht opmerkt zijn goed luisteren en beeldend weergeven, aangevuld met herhalen wat de ander heeft gezegd, zaken die daarbij horen. Door deze herhaling kan ontvanger weergeven wat hij meent begrepen te hebben en de zender toetsen of dat is wat hij beoogd heeft.

@Ewout, het is, zoals je schrijft, een probleem van alle tijden, dat alleen gestopt kan worden als opdrachtgevers betalen voor de tijd die met communiceren gemoeid is en alle partijen ook echt investeren in kwalitatief goed communiceren.

@Maarten je hebt gelijk, volgens mij is die C er ergens eind jaren 80 begin jaren 90 bijgekomen.

@technicus, ict-ers kunnen ook best van Mars komen, daar bestaat nog geen zekerheid over ;)

Zo dat was bijna een heel artikel erbij...

Andre,
Je kiest in het stuk bewust voor een vreselijk stereotype programmeur, maar ik maak nergens uit op dat je dit grappig bedoelt. Sterker nog, als ik het stuk zo lees krijg ik de indruk dat je daadwerkelijk denkt dat een programmeur een volstrekt acommunicatieve (en stinkend, kalend met staartje, zwart t-shirt met autistische trekken??) medewerker is die je het liefst in een hok in de kelder wilt opsluiten en de business niet bij mag. Tsja...

@Andre Een grappig en wonderlijk artikel en inderdaad zet je een stereotype programmeur neer. Net zoals Friso Schutte miste ik nog een paar kwalificaties: een tikje stinkend, t-shirt en autistisch. Maar het artikel gaat ook over de soms moeizame communicatie tussen programmeur en gebruiker/business/klant en het onbegrip tussen de twee.

Het zal per situatie verschillen maar in een grote organisatie zit er tussen de programmeur en de gebruiker vaak een heel groot gat. In een beetje project zitten daar veel mensen tussen en ik denk dat er zelden sprake is van directe communicatie. Dit helpt naar mijn mening niet. Ben het eens met Marcel Kouwenberg, het is aan de ICT-ers om het vakgebied van de klant te begrijpen en mee te denken maar ik denk wel dat het belangrijk is dat je het vastlegt in documentatie. Al dan niet met plaatjes. Laat de ICT-er (architect, analist, iig technische achtergrond vereist) de requirements en functionele specificaties opstellen in overleg met de klant. Het maakt voor de klant duidelijk wat hij kan verwachten en voor de ICT-er is het de manier om het probleemgebied eigen te maken en het is een referentiepunt voor de klant en de uitvoerende ict-ers.

Nou ja, toch nog een duit in het zakje van mij.

Ik ben 41 en op mijn 11e maakte ik mijn eerste stukje software. Daarna heb ik voor grote en kleine organisaties software gemaakt, als eenling/freelancer, maar ook in teams met project managers, et cetera.

De drie dingen die mij altijd erg belangrijk leken is dit:

1) Praat in verhaaltjes en scenario's waarin het resultaat (output) centraal staat
2) Zorg voor een goed en begrijpbaar data model die lijkt op hoe de echte wereld werkt (domein kennis)
3) Zorg voor een simpel werkend principe (Zoek op Gall's Law)

Welke rol de programmeur heeft maakt dan niet zo uit.

In mijn eerste reactie gaf ik een referentie naar Einstein, de man die ook een quote had: “Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid."

Dat er architecten zijn als Escher die plaatjes maken waar je verschil niet meer ziet tussen vissen en vogels is leuk maar een optisch bedrog. En dat leidt tot verrassingen achteraf als bij oplevering het verwachte resultaat niet behaald wordt. Mauwerd kon dat niet beter verwoorden want het zit niet in de communicatie maar het managen van de verwachting.

Die verwachtingen proberen we wel vast te leggen in requirements maar dat is een heel andere discussie. En zolang de ene in het plaatje een vogel ziet en de ander een vis blijft er een patstelling.

De schrijver is cio en staat dus tussen business en techniek. Hij schrijft een artikel over communicatie en haalt daarbij het verleden aan, het begin van de mechanische automatisering. Indrukwekkend.

Toch leert de schrijver nu pas dat de CT in ICT voor Communicatie Technologie staat.
Dat is maar bijzaak vindt hij. Was ooit toegevoegd ergens eind jaren tachtig.

Volgens mij geeft dit precies aan waar het misgaat. De business geeft graag grof geld uit aan mensen die niet weten waar ze over praten, maar zeggen wat men graag wil horen.

Als ik uit op vakantie uit het vliegtuig stap maak ik iets dergelijks mee. Meteen komen er allerlei engels spreekende babbelfiguren op me af die me vertellen wat goed voor mij is en waar ik naar toe moet. Het klinkt allemaal erg goed. Achteraf blijkt de taxidriver zelf een prima kerel, die met gezond verstand en een paar woordejs tv Engels, veel beter en goedkoper mij op de juiste plek wilde brengen. Mijn eigen mening respecteert hij, hij heeft er tenslotte zelf ook een.

De taxivertegenwoordiger moest ik echter flink betalen als mijn rugzak in notime al achterin de auto van de native taxidriver ligt. Meestal meer dan was afgesproken.
De vertegenwoordiger kan lekker babbelen, praat zijn klanten graag naar de mond, heeft stereotype beeld van diegenen die het werk doen en heeft er belang bij dat dat beeld gehandhaafd blijft.
Men noemt ze daar oplichters ;-)

Het grappige is dat ik pas geleden nog opgevangen heb dat SAP autisten in dienst wil nemen als programmeurs. Nog meer afstand tussen business en techniek. Net als het outsourcen naar India. Als communicatie zo'n groot probleem is waarom ga je dan proberen te praten met slecht Engels brabbelende Indiers.

Daarnaast zijn architecten vaak ook techneuten die het ingewikkelder maken dan nodig. De functie Architect is overigens altijd erg discutabel. Iedereen heeft een mening over wat een architect moet doen en die is altijd verschillend. Een tolk-functie heb ik er overigens ook nog nooit in gezien omdat architecten zich bezig moeten houden met de moeilijke onderdelen die invloed hebben op de onderliggende techniek zoals de non-functional requirements. Maar dat is mijn visie die ook natuurlijk weer discutabel is.

Volgens mij kunnen de informatie-analisten prima functioneren als tolk tussen business en ICT zoals dat vroeger in mijn ervaring ook altijd prima werkte. De IA'ers zaten ook altijd op dezelfde afdeling als de bouwers dus er was veel overleg.

Alles begint met een goed ontwerp. De valkuilen waar tegenwoordig in gestapt wordt betreft met name de drang naar moderne ontwikkelprocessen alsof deze een doel op zich zijn. En de leveranciers van tooling die alleen maar randzaken oplossen wordt veel belangrijker gemaakt dan nodig. Het is toch niet te geloven dat het aan de praat krijgen van een WebSphere portal applicatie langer duurt aan de operationskant (configuratie/deployment) dan het daadwerkelijk bouwen van de business logica? Daarnaast is iedere expertise een eiland geworden, dus de keten bestaat uit tig eilandjes die alleen maar hun straatje schoonvegen. Vervolgens is degene die de keten moet integreren en in de gaten moet houden (vaak de architect) alweer vertrokken naar het volgende project.

Andre,
Leuk artikel, met naar mijn mening een wat eenzijdige kijk op sommige onderwerpen die voor discussie en soms miscommunicatie in de reacties heeft gezorgd.
Na het lezen van dit artikel kreeg ik het gevoel dat de ict'ers stelletjes bosmongolen zijn die niks van communicaties en inlevingsvermogen weten of geleerd hebben.
Ligt dit alleen aan ict'ers? Natuurlijk niet, hoe vaak heb ik projecten meegemaakt waarin veel zaken vanuit business keer op keer veranderd werden omdat ze wisten ook niet waar ze het over hadden en wat ze echt nodig hadden.

Los je dat op door alleen het toevoegen van een rol zoals 'architect' aan het team? Nee zeker niet. Je moet dit vraagstuk vanuit verschillende hoeken aanpakken/aanvliegen.

Bovendien de rol, speelveld en ruimte van een architect in een sofwareontwikkelingsproject zijn heel anders dan bij een infra project. De bouwstenen van een infra project kun je niet zomaar of makkelijk veranderen zoals misschien die bij een softwareontwikkelingstraject.

Waarom business en IT elkaar niet altijd kunnen begrijpen heeft met veel zaken te maken. Of deze twee ooit goed bevriend worden.....dat betwijfel ik. Vanuit business wordt meestal gedacht dat ict 'alleen' geld kost en vanuit IT wordt gezien dat de gebruikers/klanten steeds meer veeleisend en mondiger worden.

Pas als ze beiden aan wat wederzijds begrip werken dan zullen we zeker andere resultaten zien.

Kijkend naar mijn eigen ervaringen, komen die vooral door de in het artikel en enkele reacties gebruikte kreet 'de business'.

De business als kreet is al weinig zeggend, en nog erger zijn in mijn ervaringen de 'businessvertegenwoordigers'. Ik heb ondertussen meerder projecten en uitbestedingstrajecten meegemaakt waarbij deze rol bestond.
In zowel het geval waar deze persoon onze afdeling vertegenwoordigde, alsook het geval waar deze persoon een andere afdeling vertegenwoordigde waarvoor ik ict- diensten moest ontwikkelen kwam hetzelfde probleem naar boven: de businessvertegenwoordiger had zijn verhaal vooral gebaseerd op processen en mooie flowcharts, en nooit met de eindgebruikers gepraat.
Hierdoor zijn tools ontwikkeld die op papier perfect voldeden, maar in praktijk absoluut onbruikbaar waren.
Voorbeeldje:
- op papier hadden we een tool nodig waarin we componenten konden selecteren die vervolgens gedistribueerd werden. Hiervoor had men een drop-down menu bedacht, waaraan we desgewenst nieuwe componenten toe konden voegen.
- de praktijk: als we alle componenten toegevoegd hadden, was deze lijst >3500 componenten. Niet echt handig voor een drop-down menu. Ook konden we maar één component per keer selecteren en distrubueren. Best vervelend als je, door bijv. een update, 500 componenten moest distribueren.

Oorzaak: noch de businessvertegenwoordiger, noch de ict'ers, hadden ooit contact gehad met de eindgebruikers en gekeken / geïnformeerd naar hun manier van werken in de praktijk....

Ander voorbeeld:
"onze" (geen idee wie de persoon in kwestie is) business vertegenwoordiger heeft bedacht bij het uitbesteden van het data-beheer dat we per keer max. 50 GB aan capaciteitsuitbreiding aan kunnen vragen. Best vervelend als je dan als afdeling ineens 75 GB nodig hebt, helemaal als een deel van je productiefaciliteiten hierdoor stil dreigt komen te vallen.
Ook hier weer dezelfde oorzaak. Degene die 'de business' vertegenwoordigt heeft nog nooit met de eindgebruikers gesproken, maar alleen via drie of meer lagen ruis-veroorzakende en als filter werkende managers.

Overigens geldt dit beeld ongetwijfeld ook aan de andere kant van de communicatie-keten. De vertegenwoordiger vanuit de ict zegt dingen toe die de ict'er dan maar weer waar moet zien te maken. Tussen deze persoon en degene die het moet implementeren zit vaak evenzoveel ruis en filtering in de vorm van architecten, projectleiders, teamleiders enz. enz.
Zeker als een deel van het werk dan ook nog uitbesteedt wordt aan 3e partijen, liefst nog in verweggistan, dan wordt deze afstand alleen nog maar groter.

Praktisch helaas vaak niet mogelijk, maar eigenlijk zou je degene die de implementatie uitvoert gewoon eens een week mee moeten laten lopen met degene die het eindproduct moet gaan gebruiken.
Alhoewel niet mogelijk... als je dit doet, heb je minder (geen) businessverkopers, ict-vertegenwoordigers en allerhande andere overhead meer nodig. Misschien is dit dan nog wel goedkoper ook?!?

Beetje jammer Andre. Had je zo'n mooie kans om een brug te bouwen maar laat die jammerlijk ontglippen.

Communicatie begint bij het willen begrijpen wat de ander wil zeggen. Niet door te verwachten wat je wil horen. En zeker niet door te stigmatiseren met je eigen vooroordelen.

Duidelijk verhaal. En ook een bekend verhaal ook al willen vele betrokkenen het vaak niet graag toegeven. Doch de oplossing is simpel, omdat het simpel moet zijn. Juist door het simpel te maken kunnen de betrokkenen dezelfde taal spreken. Zelf heb ik voor een opdrachtgever een methodiek ontwikkeld die simpel een functionele wens weergeeft. Beschreven door key-users en functioneel beheerder en in samenwerking met de ontwikkelaar. Dit "ontwerp" was weer op een dusdanige wijze beschreven dat de vertaling naar testscripts eenvoudig was. De key-user en de functioneel beheerder kunnen namelijk de testscripts schrijven op basis van de ontwerpen en tevens meteen de testdekking bepalen. Simpele communicatie is "the magic word"..... Oke, 2 words dan!

Tijd voor een (tussentijdse?) samenvatting naar aanleiding van de vele reacties.
Eigenlijk vindt iedere deelnemer aan de discussie dat er meer ruimte voor verbetering in de communicatie tussen opdrachtgever en maker moet zijn, om de eindgebruiker het product te kunnen geven dat hij nodig heeft.
Er zijn veel momenten in de keten waar het misgaat, zo denkt een opdrachtgever een goede job te doen voor de eindgebruiker, zonder dat hij de eindgebruiker heeft geraadpleegd. Vindt kwaliteitscontrole en matching van het geleverde met de klant behoeften tussentijds onvoldoende plaats. En is de tijd tussen de voortgangsrapportages teveel opgelopen. Of heeft projectmanagement gefaald om alle partijen te informeren.
Feit blijft echter dat de zender van een bericht dit altijd doet vanuit zijn optiek, gevormd door studie, karakter en ervaring. De ontvanger heeft een heel andere achtergrond en zal dit nooit zelfstandig kunnen begrijpen. Recentelijk heb ik deel mogen nemen aan een analyse over de karaktereigenschappen van een bepaald type mens uit de business. Hieruit kwam naar voren dat de match tussen functie en karaktereigenschappen bepalend is voor het succes van de uitvoering van een functie. Ik kan me die invulling van functies bij SAP door autisten dan ook voorstellen.
Eerder was er al een testbedrijf dat deze weg insloeg.
Sterk vereenvoudigd voorbeeld, als ik in het Nederlands over een aanpassing praat in een boekhoudpakket van Duitse makelij en de ontvanger spreekt alleen Duits, dan zullen we elkaar nooit begrijpen. Een tolk is dan nodig. Zo is het in 9 van de 10 gevallen in de praktijk ook tussen, wat we met zijn allen business zijn gaan noemen en ICT.
Het probleem is in de kern niet oplosbaar, tenzij beide partijen bereid zijn te investeren in de mogelijkheid om elkaar te begrijpen.
Misschien dat de redactie van Computable eens een aantal mensen uit de business met een aantal ict'ers bij elkaar kan brengen om uit te vinden of hier verbeteringen zijn te realiseren.
Tot slot van deze samenvatting, de aanvullingen als stinkend, bosmongolen etc, zijn kwalificaties die ik niet aan dit type mensen heb gegeven. Eveneens deel ik de mening dat dé business niet bestaat, maar wel een prettige common denominator is.
En hoe simpeler hoe beter, en als woorden niet genoeg zijn, helpen de plaatjes.

Tja..

Je ontwerpt je nieuwe huis samen met je vrouw en... Een architect.
Je zoekt vervolgens een aannemer en geeft hem het bestek en alle technische beschrijvingen, bespreekt het een en ander met elkaar. Vervolgens monitor jij en de architect de bouw regelmatig met als eind resultaat een huis dat behoorlijk overeenkomt met je verwachtingen en doelstellingen.

In de IT doen we dat vaak anders.
We beginnen veelal met een boterzachte omschrijving van de manier waarop de business doelstellingen gerealiseerd gaan worden. Een technische onderbouwing van de risico's is vaak van zeer bedenkelijke kwaliteit.

Vervolgens denderen we door en vragen een architect om een technisch en functioneel ontwerp te maken.

Hier gaan al wat zaken mis, aangezien de architect met de boterzachte requirements genoodzaakt is flexibiliteit boven effectiviteit te stellen en daardoor niet anders kan dan een weinig specifiek ontwerp te maken.

Vervolgens starten we een project om dit sub optimale ontwerp te realiseren. Dan volgt een periode van aanpassen (hardware wordt goedkoper/of niet langer beschikbaar, omgevingen zijn veranderd, regulerings eisen veranderen)

Uiteindelijk gaan we de bouwvakkers (programmeurs) vanuit dit project onder druk zetten om de boel binnen de vooraf vastgestelde (niet onderbouwde) planning af te ronden.

Resultaat zijn natuurlijk:
Lage kwaliteit
Lage betrouwbaarheid
Lage gebruikers tevredenheid
De software is waarschijnlijk niet heel goed geschikt om de business doelen te helpen realiseren.

De oorzaak van dit moois is niet een gebrek aan communicatie, de oorzaak is te vinden in het begin.
Zorg voor een gedegen en technisch onderbouwde risico analyse in je business case en je zult zien dat je projecten een stuk prettiger verlopen.

In “de business” lopen net zo goed autisten rond, of minstens lui niet kunnen of willen communiceren, en al helemaal niet met ICT-ers. Niet omdat ze die ICT-ers niet begrijpen, maar omdat ze de ICT niet begrijpen.
ICT wordt gezien als een commodity. Alsof je in de auto stapt: starten en lopen. Zo moet ICT ook functioneren, maar in de praktijk gaat dat wel eens mis. Dat ICT in veel gevallen maatwerk is gaat er bij het gemiddelde management niet of nauwelijks in. En dat maakt de communicatie erg lastig. Naar mijn mening zit daar het echte probleem.
Dit wordt versterkt door het gegeven dat juist datgene wat ICT moet ondersteunen onvoldoende in beeld is. Men verwacht soepel werkende functionaliteit, maar men kent de eigen primaire processen niet of heeft daar onvoldoende grip op (of op haar uitvoerders). Het sturen van ICT op het leveren van de juiste functionaliteit wordt dan wel een hele lastige zaak. Het is dan verleidelijk de ICT de communicatieve schuld te geven van systemen die niet doen wat je ervan verwacht.

Het communicatie issue is inmiddels een eigen leven gaan leiden. Ter bevestiging van het zogenaamde communicatieve onvermogen van ICT-ers verschijnen er artikeltjes dat bedrijven autisten in dienst gaan nemen om hogere kwaliteit te kunnen leveren. Welja. Wie de context niet kent wordt dan alleen maar banger van ICT-ers.
Overigens heeft de ‘C’ in ICT niets met dit issue te maken.

Communicatie begint vooral met luisteren.

Dat luisteren moet ook nog eens van twee kanten komen.

Voortst zijn er ook grote belanghebbende groepen die de ruis en de mist in de lucht wil houden.

Om met de auto analogie van Hans Kroon door te gaan, in de auto garage staan er per auto ook niet vijf man extra mee te kijken hoe de auto onderhoud krijgt. In de ict binnen de grotere organisaties is dit echter erg gangbaar en dat is jammer, want het zijn zware extra kosten.

Best Andre, Beste allemaal,

Twee zaken blijven me bij als ik het artikel van Andre en de reacties daarop lees:
- er bestaan stereotypen over zowel ICT en de ICT-ers als over de Business (en de Business-ers?)
- het lijkt erop dat er weinig positieve ervaringen zijn in de samenwerking

Op dit moment zie je een verschuiving in de besteding van budget tbv ICT-middelen. Steeds meer niet-ICT afdelingen besteden geld aan producten en projecten die een grote component ICT bevatten. Deze bestedingen vinden vaak direct plaats vanuit de Business aan een externe leverancier.

Mijn voorzichtige conclusie is dat er blijkbaar vanuit die externe leverancier een heel aantrekkelijk aanbod gedaan wordt:
- de Business hoeft nergens om te vragen, het product komt naar HEM toe
- de Business kan een goed geinformeerd besluit nemen, het product is aantrekkelijk gepresenteerd
- de Business kan makkelijk een intentie omzetten in een handeling die direct iets oplevert, één druk op een knop / een transactie levert direct resultaat

Er is geen sprake van:
- Business en ICT die elkaar niet begrijpen / verzanden in discussie, het is allemaal heel duidelijk wat het product inhoudt en oplevert
- een moeizaam migratieproces met Change Request Procedures, Prioretisering in een Global Steering Committee, gevolgd door een bureaucratische documentenstrijd
- een late levering, off-scope, veranderingen in randvoorwaarden en aannames

Wat is het verschil? Naar mijn mening is de kern van de zaak als volgt:
- de kenmerken van het product zijn bekend en worden als randvoorwaarde geaccepteerd; waar afgeweken wordt, accepteert de Koper deze verantwoordelijkheid (en wordt derhalve: Eigenaar)
- er van de zijde van de gebruikers een wens tot verbetering maar ook een bereidheid zélf aanpassingen in werkwijzen door te willen voeren
- het geleverde product (of: de geleverde dienst) voldoet aan hoge kwaliteitsstandaarden, is zeer uitgebreid getest en het proces van afnemen en gebruiken van het product is Excellent, de leverancier is er op gespitst voortdurend de gebruikerservaring te verbeteren (en derhalve de klant te begrijpen)
- als het niet voldoet, kun je het met de druk op de knop weggooien, sterker nog: er is een abonnementsmodel -- de klant heeft dus niet betaalt voor de volledige ontwikkeling om er dan achter te komen dat iets niet is wat ervan verwacht wordt

Volgens mij valt er veel te leren van deze verschuiving in het bestedingsgedrag. Zo maar voor de vuist weg een aantal interessante onderwerpen in dat kader:
- time-to-market: als je als Business manager garanties wil, kun je dan beter intern of extern gaan winkelen?
- technical debt & legacy: wat zijn de mogelijkheden en onmogelijkheden van het huidige interne platform, welke prijs moet je betalen voor het doorvoeren van een wijziging?
- standaardisatie en architectuur: de wens van de business past niet op efficiente wijze in de manier waarop ICT is ingericht, wat nu? Dan maar geen business? Of business met minder marge?
- schaalbaarheid en localisatie van je business: een deel van je Business loopt zó goed dat je wilt opschalen of template-based wilt uitrollen / lokale instanties van processen nodig hebt, hoe snel realiseer je dat? En hoe zorg je dat je bestaande eigen ICT systemen nog steeds over de juiste data beschikken?

Ben benieuwd naar jullie inzichten op dit gebied.

@Ben
De verschuiving die je beschrijft is een gevaarlijke. Mijn ervaring is dat de business wel verwacht dat wat zij bestelt buiten haar IT afdeling om evengoed door deze afdeling geïmplementeerd, aan de praat en onderhouden moet worden. Daarover blijken dan slechte of zelfs geen afspraken te zijn gemaakt en is men achteraf verontwaardigd over de slecht werkende spullen en de oplopende kosten.

De aantrekkelijkheid van aanbiedingen zit hem maar al te vaak in kleine lettertjes die als addertjes onder het gras liggen en niet gezien of gelezen worden. Extern uitbestede callregistratie en –afhandeling bijvoorbeeld blijkt dan in de praktijk twee tot drie keer zo duur.
In sommige branches wordt nog steeds weinig tot niets gedaan aan IT awareness, noch aan fatsoenlijke gebruikerstraining, noch aan enige vorm van het kweken van inzicht in de door ICT geboden ondersteunende functionaliteit op de uitvoering van de primaire processen. Ook directies zien vaak nauwelijks een verband en bezuinigen op ICT zonder te beseffen dat ze daarmee feitelijk op hun primaire proces bezuinigen en dus op de realisatie van hun doelstellingen.

In de door jou gegeven setting zou er geen sprake meer zijn van business en ICT die elkaar niet begrijpen. Ook gevaarlijk, zie hierboven. Des te meer omdat de bij propositie van externe partijen het bijna altijd lijkt alsof zij de business uitstekend begrijpen. Dit is maar al te vaak slechts schijn en wat men verkoopt werkt alleen als het management van de business de consequenties van haar keuze volledig doorziet en aanvaard en bereid is strak te sturen op de onvermijdelijke veranderingen en aanpassingen die nodig zij om nieuwe spullen en functionaliteit optimaal tot hun recht te laten komen. In de praktijk gebeurt dat veel te weinig.
Het lijkt mij ook te veel op het principe van best practises. In de praktijk blijken de meeste bedrijven met die best practises niet goed uit de voeten te kunnen en spenderen vervolgens veel tijd en geld aan schaven en schuren, soms tot er niets meer over is en feitelijk opnieuw begonnen moet worden.

Natuurlijk zullen er situaties zijn waar bedrijven van gestandaardiseerde functionaliteit gebruik kunnen maken, dat gebeurt al bij veel secundaire, bedrijfsondersteunende processen (FEZ, P&O, FB, Inkoop etc.). Het inrichten en onderhouden van een KA omgeving is dan ook de meeste ICT-ers wel toevertrouwd. Maar daar hoort niet het zwaartepunt te liggen; dat ligt naar mijn mening in het leveren van functionaliteit via een betrouwbare en beheersbare infrastructuur welke in dienst staat van de levering van de dienst of het product dat de organisatie haar bestaansrecht geeft.

Wow, dat zijn twee reacties die ik niet zou willen missen! Scherp! Al hoewel met genoeg haakjes om boeken mee te vullen.. ("... dat ligt naar mijn mening in het leveren van functionaliteit via een betrouwbare en beheersbare infrastructuur welke in dienst staat van de levering van de dienst of het product dat de organisatie haar bestaansrecht geeft.")

@Hans, als ik het goed begrijp dan beschrijft Ben de verschuiving naar de Cloud. Dat hoeft niet gevaarlijk te zijn als ICT en Business maar bereid zijn om samen te werken.

Wat ik ook vaak zie is dat de business, op basis van het uitblijven van een aangereikte oplossing door ICT zelf het heft in handen neemt. Heell vaak gaat het goed, maar het kan ook flink mis gaan doordat business en ICT lijnrecht tegen over elkaar komen te staan.

In dat geval moet management(nog zo'n heerlijk vage kreet)ingrijpen. Ik bedoel hier eigenlijk de directie mee...

@Ben, de verschuiving in de besteding van het ICT budget is een signalering die wij delen. Ook al blijkt uit een recent onderzoek van de SharePoint community Europe dat er nog niet structureel wordt gedacht aan kant en klare oplossingen van derden op het SharePoint platform.


Ik ben het eens met Hans als je zegt dat finance (FEZ is in overhead en zorg gangbaar)en andere afdelingen hier minder risico lopen, omdat, voorzover dat de Cloud betreft, al meer mature oplossingen te krijgen zijn.
Voor zover de software kant. Infrastructure moet voor zowel Cloud keuze als on premises voorbehouden blijven aan ICT.

@ André
Wat die brug, of tunnel, betreft ligt die er wat mijn beleving en ervaring betreft er al lang. Dat velen hem klaarblijkelijk niet zien liggen, kan ik niet over oordelen natuurlijk. Dat moet een ieder voor zich maar bepalen.

Maar het is nu net wel de kern van jouw betoog. Het leggen van die brug is helemaal niet ingewikkeld, me dunkt, maar wel dat er vaak heel ingewikkeld over word gedaan.

Jammer genoeg.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×