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.
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.
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.
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.
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…