Waarom er altijd misverstanden zijn tussen ICT en de business
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. De eenvoudigste verklaring van de misverstanden is in de titel al opgenomen. Het antwoord is simpel, het zit opgesloten in de karakters van het typen mensen dat deze rollen bekleden in een organisatie. Maar hoe kun je daar het beste mee omgaan?
Voordat ik daar dieper op in ga, is het belangrijk om iets meer over de historie van de ICT te weten. Terug naar het stenen tijdperk van de automatisering toen het software wiel werd uitgevonden.
60 jaar geleden verscheen het eerste boek over automation.
Veel mensen zien het jaar 1947 als het jaar waarin de automatisering begon, toen de Ford Motor Co. en Del Harder, vice president productie, het concept “machinale productie” gingen toepassen in de autoproductie. Ford gebruikte 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. Dit jaar dus 60 jaar geleden!
In de loop der tijd zijn er steeds meer automatiseringstoepassingen gekomen, welke voornamelijk werden gemaakt door programmeurs. Dit waren in het begin mensen met wiskundige aanleg die van nullen en enen door middel van het programmeren iets begrijpelijks konden maken.
Met de groei van het gebruik van software en de talloze applicaties zijn er, naast de functie van programmeur, meerdere ICT functies ontstaan. Zo zijn er naast de programmeur, onder andere de architect, de consultant, de systeembeheerder en de applicatiebeheerder gekomen. Allemaal ondergebracht onder de noemer van ICT-ers.
Het waren zeker niet de financials, die hier voorop liepen. Mensen met een financiële achtergrond waren wel de personen die delen van de automatisering konden doorgronden en er het nut van in zagen. Sommigen dachten ten onrechte dat zij konden programmeren.
Door de vele ontwikkelingen in de programmatuur om software te maken, zoals de grafische interface in Dotnet, C+ etc., is programmeren bereikbaarder geworden voor mensen zonder wiskundige achtergrond. Maar het blijft programmeren en dat vereist van de programmeur een andere skillset dan die je als financial nodig hebt.
We kunnen er dus eerlijk over zijn, software is uitgevonden door oer It-ers en niet door Financials. 1-0 voor de ICt-ers.
Waar gaat het mis bij in house ICT, maatsoftware en projecten?
De programmeur werkt het beste met een kant en klaar concept, waarin alle eisen van de business op een voor hem in aparte delen en voor hem begrijpelijke wijze zijn uitgewerkt, het zogenaamde technisch ontwerp. Daarmee kan hij gaan programmeren.
Basis fout: Vaak 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 tolk functie (architecten rol) overgeslagen en ontstaan de eerste problemen.
Denkpatronen en karakterverschillen bepalen vervolgens dat het hier mis moet lopen.
Beide partijen 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 tekort schiet 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.
Waarom kan het met Cloud en/of out of the box oplossingen beter gaan?
In dit geval schaf je een kant en klare oplossing voor een bestaand probleem aan. De processen zijn al uitgewerkt door de
leverende partij en programeer beslissingen zijn al genomen. Dat risico is door de leverende partij dus afgedekt. Het is daarom
aantrekkelijk voor de “business” en in het kader van consumerization van software, deze software in de Cloud te huren en direct in te zetten zonder daarover te overleggen met ICT. Men heeft immers een direct werkende oplossing.
Waarom kan het met Out of the Box oplossingen toch mis gaan
Het kan flink fout gaan, doordat de “business” kan vinden dat er geen gebruik gemaakt hoeft te worden van de kennis van de ICT afdeling. Daarbij gaat de “business” er aan voorbij dat ze ICT kennis per definitie ontbeert. Indien geen overleg vooraf wordt gepleegd en later blijkt dat het beter had gekund, komt het vaak voor dat partijen elkaar zullen tegenwerken.
Een voorbeeld is dat een ICT afdeling de “business” er op attent kan maken dat in het geval dat er verschillende abonnementen voor Cloud toepassingen worden afgesloten, een single sign on – het inloggen met 1 wachtwoord voor alle applicaties- niet automatisch geregeld is.
Conclusie
Samenwerking compenseert elkaars zwakheden en maken het bedrijf sterker. De C in ICT-er staat voor communicatie, waarom die er staat is niet duidelijk, omdat in de praktijk dit niet de sterke kant van ICT-er blijkt te zijn.
Dus, daar waar de ICt-er van nature zwak is in de communicatie en Financials daar ook niet in uit blinken is het handig om de gebieden waar ze wel sterk in zijn beter te benutten. Zo kunnen financials hun aanvragen beter documenteren, waardoor vertaling in een technisch ontwerp door een architect gedaan kan worden, de programmeur beter kan programmeren en de uitkomsten beter voorspelbaar worden. Ook door de aanschaf van software oplossingen out of the box kunnen in een aantal gevallen betere resultaten bereikt worden dan door programmeerwerk van eigen ICTers. Daarnaast moet er, om later geld te kunnen besparen, bijvoorbeeld niet geschrapt worden bij de ontwikkeling van software door een functie van architect – de tolk- te laten vervallen.
Zorg daarom in alle gevallen voor overleg vooraf, want dat geeft de beste kans van slagen.
Oh ja mensen van Mars communiceren niet en mensen van Venus ook niet.
Per 22-06-2013 Computable.nl 
(709)
Deze post is ook beschikbaar in/Also available in: Engels
