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