Bedrijven willen dat ict beter bij de business aansluit. In mijn eerste bijdrage (10 februari 2010) is uiteengezet dat voor solide oplossingen begrip van de fundamentele oorzaak van de complexiteitsproblematiek essentieel is. De fundamentele oorzaak is uitgelegd en daarmee zouden de eerste projecten kunnen worden gestart. Dit alléén is echter gedoemd te mislukken. Voor solide oplossingen is meer nodig.
Aan Einstein wordt de volgende uitspraak toegeschreven: 'De wereld die we door ons denken hebben gecreëerd heeft te kampen met problemen die niet kunnen worden opgelost door op dezelfde wijze te blijven denken als toen we die problemen creëerden'. Wat betekent dit voor de wereld van ict?
Logica huidige denken
Het ligt voor de hand dat iedere manager zijn eigen ‘toko' zo eenvoudig mogelijk maakt. Vereenvoudigen betekent wijzigingen of ‘changes'. In complexe systemen zijn de directe en indirecte afhankelijkheden echter zo ingewikkeld, dat de gevolgen niet meer kunnen worden overzien. Wat voor de ene organisatie een vereenvoudiging is, kan voor andere organisaties verlies van belangrijke functionaliteit betekenen. Vervolgens zijn deze organisaties genoodzaakt de kwijtgeraakte functionaliteit te compenseren. Dit betekent nieuwe wijzigingen, waarvan de gevolgen weer niet kunnen worden overzien. Het is het begin van een sneeuwbal die steeds groter wordt. Wat een op zich zelf logische en doeltreffende vereenvoudiging leek, leidt tot meerdere ‘oplossingen' en extra werkzaamheden, kortom tot meer complexiteit en hogere totale kosten.
Een andere ‘logische' gedachtegang is eerst in een kleine organisatie de goede werking van een oplossing vast te stellen, om deze daarna in de hele ict-organisatie toe te passen. Met de Critical Threshold (zie grafiek), die wordt behandeld in mijn eerste bijdrage 'ICT moet beter bij de business aansluiten' op het netvlies wordt begrijpelijk waarom exacte/lineaire oplossingen in een eenvoudige omgeving wel en in een complexe omgeving niet werken. Sterker nog, het is een recept voor falen (complexiteit verhogend).
Conclusie: de complexiteitsproblematiek kan niet met dezelfde lineaire/exacte denktrant worden opgelost als waarmee die problematiek is gecreëerd. Ook is duidelijk dat in complexe omgevingen andere spelregels van toepassing zijn. Wat helpt dan wel?
De fundamentele aanpak
De aanpak van grote denkers als Einstein en Darwin is complexe systemen als geheel te onderzoeken (‘holistisch' heet dat tegenwoordig), om deze vervolgens terug te brengen tot hun meest essentiële kern en van daaruit een totaalvisie te ontwikkelen. Dit betekent dat men niet alleen kennis van de ‘bits and pieces' en hun vele afhankelijkheden dient te hebben, maar ook het complexe systeem als één geheel moet benaderen. Wat dit voor de complexiteitsproblematiek betekent?
Een eerste stap is gezet als je accepteert dat je de complete ict organisatie als één systeem moet benaderen en dat er andere spelregels gelden. De tweede stap volgt uit de grafiek Critical Threshold: aangezien exacte/lineaire technieken voorbij de 'kritieke drempel' niet werken, moet je daarmee dus stoppen (=aanzienlijke bezuinigingen). Voor de benodigde functionaliteit zijn non-lineaire/open technieken beschikbaar, die hun waarde bij complexe uitdagingen hebben bewezen maar de laatste 15 jaar zijn ‘vergeten'. Denk aan patroonherkenning, intuïtie, kennis en ervaring, netwerk, flexibiliteit en zelforganisatie.
Ook nu ontbreekt er nog iets. De exacte/lineaire technieken zijn zo diep in de huidige denk- en werkwijzen verankerd (incl. de best practices/methodieken), dat ‘klakkeloos' invoeren van niet-lineaire/open technieken tot teveel conflicten zal leiden en dus weinig kans van slagen heeft. Er is sturing nodig: zo veel sturing als nodig en zo weinig als mogelijk. Om het geheel -dus exacte/lineaire én niet-lineaire/open technieken- te laten werken, is sturing én zelforganisatie nodig (zie grafiek ‘Guided Self-Organisation').
Business case
Een typisch voorbeeld van ‘Guided Self-Organisation' is de rotonde op de weg: betere doorstroming, veiliger en goedkoper dan stoplichten. Voor de ict betekent dit rigide stoplichten in de processen vervangen door voor iedereen begrijpelijke regels, en wel binnen een helder en gebruikersvriendelijk systeem dat uitnodigt ‘compliant‘ te zijn. Ook moeten beslissingen op het optimale niveau én slagvaardig genomen kunnen worden. Sturing en toch voldoende vrijheid voor slagvaardig beslissen zijn dan ook de eerste randvoorwaarden voor betere aansluiting van de ict bij de business.
Ook hier is het zaak de exacte/lineaire denkwijze los te laten. Nu complexiteit zelf het probleem is, is de vraag niet hoeveel euro het oplevert, maar of die complexiteit afneemt (met zowel drastische verlaging van kosten/faalkans als verhoging van flexibiliteit), waardoor er betere aansluiting bij de business ontstaat. Is dat het geval, dan is dát de business case.
Vandaag lijkt een business case zonder harde € geen business case. Rond 1990 lag dat anders. Ik herinner mij een project dat onontkoombaar was omdat anders de storage niet meer te beheren was (nu is de ict niet meer te beheren). Niet alleen werd toen een onwerkbare situatie voorkomen, ook bleek sprake van grote besparingen. Deze denkwijze over business cases lijkt terug te komen: in april 2008 zei Jerry Luftman op een seminar dat voor het bereiken van de hoogste niveaus in het door hem ontwikkelde business en it-alignment model de business case zonder € wordt gemaakt: waar het om gaat is dat de business gaat groeien.
De ‘pathway’
Na de fundamentele oorzaak, de fundamentele aanpak en de business case komen er nog twee belangrijke componenten bij. Om de aanpak op de specifieke organisatie toe te snijden en te implementeren is een klein team van grotendeels niet-lineaire denkers nodig. Hun taak is top-down sturen en implementeren opdat cruciaal beleid ook op termijn wordt nageleefd.
Benodigd is verder één centraal beleidsproces, dat voorziet in voor iedereen begrijpelijke regels (inclusief de ict-standaarden), compliance aantrekkelijk maakt en structuren invoert waardoor slagvaardig beslissen op het optimale niveau mogelijk wordt. Voor zover bekend is nergens een dergelijk proces in gebruik. Voor de hand ligt waarom: benodigd zijn niet-lineaire/open technieken (voor het gebied voorbij de Threshold) terwijl tegenwoordig louter exacte/lineaire technieken ingezet worden. Bij mijn weten bestaat op dit moment slechts één niet-lineair/open beleidsproces dat aan deze criteria voldoet: het IT Strategy Management Process.
Conclusies
De hoofdoorzaak van de ict problemen (vastlopen) is complexiteit. Oorzaak is een eenzijdige lineair/exacte denktrant voorbij de Critical Threshold met fragmentarische aanpak (deeloplossingen), die steeds meer complexiteit creëert. Het goede nieuws is dat ter vervanging van de contraproductieve technieken beproefde en eenvoudige non-lineaire/open technieken voorhanden zijn.
Wij weten dat het anders moet. De reacties op het eerste deel van dit artikel waren positief. De tijd lijkt rijp voor een koerswijziging. Kortom, welke ict-organisatie of best practice heeft de vooruitziende blik en de moed de oude vertrouwde (exact/lineaire) denkwijze los te laten en het roer om te gooien, opdat de ict wederom betrouwbaar, betaalbaar en ondersteunend wordt voor de business?
Eugen Oetringer, directeur/oprichter ComDyS
Eugen,
Begrijp ik het goed dat je “tot op zekere hoogte” wil vasthouden aan standaardisatie/procesmatigheid, en dat je “vanaf die hoogte” wil overgaan naar pragmatisme?
En dat je pleit voor zowel een bottom-up als een top-down benadering, en dat – zodra die twee benaderingen elkaar “op zekere hoogte” niet meer aanvullen – de top-down benadering de overhand moet krijgen met “generieke richtlijnen” i.p.v. “specifieke processen en tools”?
Ik krijg het beeld dat de lineaire technieken achterhaald zijn en dat we die fase moeten overslaan: ook onder de critical treshold kunnen de niet-lineaire technieken immers succesvol zijn. Van pragmatisme en (sturen op) zelf-redzaamheid en ownership nemen is een organisatie nog nooit slechter geworden. Bovendien hoef je later de cultuuromslag van lineair naar niet-lineair niet meer te maken (en bespaart daardoor veel kosten in legacy-processen/tools).
Eddy,
Inderdaad. Je hebt het goed gezien. Wij moeten echter opletten dat wij niet van het ene extreme (te veel lineaire/exacte technieken) naar het andere extreme (te weinig lineaire/exacte technieken) gaan. Als bijvoorbeeld precies dezelfde taak steeds maar herhaald wordt en deze hetzelfde blijft, dan is de exacte/lineaire aanpak meestal de efficiëntere oplossing. Uiteindelijk is het mijns inziens een kwestie van evenwicht vinden tussen lineaire/exacte en non-lineaire/open technieken.
Het fundamentele verschil met de huidige standaards/processen is dat alleen dan precies wordt aangeven hoe iets moet worden gedaan als dit ook mogelijk is (zeg maar kan worden getest) en er toegevoegde waarde is. Als dit niet het geval is, dan blijft het wel belangrijk de richting aan te geven. Anders zou iedereen een andere kant opgaan, waardoor nieuwe inefficiënties ontstaan. Uiteindelijk is het een kwestie van voldoende richting geven, zodat de hele organisatie dezelfde richting opgaat en er toch voldoende vrijheden zijn, zodat adequaat en snel op de zich voordoende situaties kan worden ingegaan.
Door iedereen dezelfde KPI’s mee te geven en af te dwingen dat iedereen dezelfde tools gebruikt? Oftewel: iedereen dezelfde gereedschapskist, maar iedereen mag zelf bepalen hoe hij die gebruikt en waarvoor?
Klinkt als Eckart’s Notes: centrale overhead en on-onderhandelbare standaards, gedecentraliseerde (gedelegeerde) inhoud en uitvoering…
Wat afdwingen betreft, de experts van ‘command and control’ (het US militair) en ook Garter hebben er duidelijke uitspraken over gemaakt: het werkt niet in complexe situaties. Aan de andere kant zijn ‘iedereen mag het zelf bepalen’ en ‘eindeloze discussies’ ook geen optie. Wat ik heb zien werken is de gouden middenweg. De truc was de richting (vaak met dieper gaande instructies) zo aan te geven dat de gebruikers compliant wilden zijn. Echter, hier is nog iets van belang.
Er staan momenteel 42 onopgeloste ‘issues’ in de weg (gepubliceerd in het boek ‘The IT Strategy Management Process’). Zolang de medewerkers bijvoorbeeld de instructies in de ‘information overload’ niet kunnen vinden of de instructies zijn achterhaald, hoe kunnen ze compliant zijn? Sterker nog: omdat het beleid over de hele ICT organisatie gaat, is het een extreem complex onderwerp. Ook al worden 35 van deze ‘issues’ opgelost, dan kan het nog zo zijn dat gebruikers wel compliant willen zijn, maar het niet kunnen zijn.
De volgende vraag is uiteraard: hoe kunnen deze 42 issues worden opgelost? Met dit artikel zal duidelijk worden waarom exacte/lineaire technieken deze problematiek niet kunnen oplossen. Met non-lineaire/open technieken (inclusief een pragmatische niet-lineaire/open procesaanpak uit de jaren 90) is het echter een ander verhaal. Sterker nog: omdat het eerder in een complexe ICT-omgeving functioneerde, waag ik te stellen dat de compliance problematiek dan relatief eenvoudig is op te lossen.