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 Channelweb.nl (https://www.channelweb.nl/artikel/4752483). © Jaarbeurs IT Media.

?

 

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

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.