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