ICT moet beter bij de business aansluiten

Eerst hoorde je het op de werkvloer. Vanaf 2008 hoorde je het van gerenommeerde experts. Symptomatisch is het verhaal van ITIL. Tot voor kort was ITIL, zwaargewicht bij de gebruikersgroep itSMF, een must voor ict-organisaties. Oktober vorig jaar verscheen hier het artikel 'itSMF is gedoemd te verdwijnen'. De tijd lijkt rijp voor fundamentele veranderingen die de kosten drastisch omlaag brengen en ict beter bij de business laten aansluiten. Er zijn dan ook veel adviezen verschenen. Maar er is niets dat maakt dat we zeggen: 'nu begrijp ik het! Dit gaat het verschil maken!”

Als wij de vijftig tot honderd methodieken, frameworks, best practices of modellen bekijken, die vandaag in de ict worden ingezet, dan valt er iets op: exacte/lineaire technieken zijn dominant aanwezig. Dat wil zeggen, er wordt veel nadruk gelegd op het gebruik van getallen, procesbeschrijvingen, verantwoordelijkheden, instructies, oorzaak en gevolg relaties, in kaart brengen van afhankelijkheden en het gebruik van computer programma's. Als het te ingewikkeld is, dan wordt er opgedeeld in werkbare stukken, waar vervolgens dezelfde technieken worden toegepast. Deze technieken hebben zich keer op keer bewezen. Toch zijn er duidelijke vraagtekens gerezen.

Bij mij zijn deze vraagtekens twintig jaar geleden opgekomen. Na mijn wiskundestudie kwam ik bij een groot computer service bedrijf bij rekencentra terecht. Snel werd duidelijk dat het lastig was ingewikkelde uitdagingen in exacte data te vertalen. Sterker nog, de wiskundige aanpak bleek regelmatig slechte resultaten te leveren of te falen.

Eenvoudig versus ingewikkeld

Een van mijn eerste taken was de belangrijke apparatuur van een rekencentrum in kaart te brengen. Wij hadden de keuze tussen een bestaande software en één – met een tekstverwerker bij te houden – tekening. De tekening was eenvoudig en operators konden er ook problemen mee oplossen. Daar tegenover stond de uitdraai van de software, die zelfs voor de experts moeilijk te begrijpen was. De totale kosten van de tekeningaanpak waren minder dan 5 procent van de softwareoplossing. Het werd dus de tekening. Later kwamen wij de functionaliteit van de software weer tegen. Het was inmiddels een standaard: de configuration management database (CMDB).

Toegegeven, de apparatuur van vandaag kan niet meer in één tekening worden weergegeven. Anderzijds, bij configuration management projecten viel iets op. Op kleine schaal (onder meer ‘proof of concept') werkte het. Maar zodra het in een grotere omgeving in productie ging, ging het mis. Met veel aandacht op hoog management niveau was het soms nog mogelijk de CMDB op werkbaar niveau te krijgen. Dat bleek echter de kleinere uitdaging. De gegevens met hun afhankelijkheden bijhouden was veel lastiger. Er was behoorlijk wat werk mee gemoeid. Met reorganisaties of grotere technologiewijzigingen namen deze werkzaamheden exponentieel toe.

Het patroon

In de loop der tijd begon een patroon op te vallen: configuration management had met een omslagpunt of Critical Threshold te maken. Vóór dit omslagpunt waren de gebruikte technieken effectief. Voorbij dat punt werden ze contraproductief. Sterker nog, ze maakten het complexer, waardoor de kans op falen ook snel toenam. Eén niveau aan extra data kon de nodige werkzaamheden al exponentieel doen toenemen. Hoewel wij het toen niet door hadden, bleek dit patroon zich ook in andere gebieden voor te doen.

Voorbeelden

Capacity management: het zeer uitgebreide en met veel data werkende capacity management voor computers leverde tegenvallende resultaten (ook daar dus een threshold).

Project management: halverwege de jaren negentig was het nog mogelijk onvoorziene ontwikkelingen en problemen, die op het project afkwamen, te beheren. Vandaag zijn het er zo veel en zijn ze zo ingewikkeld, dat de lineaire technieken van toen het niet meer aankunnen (voorbij een threshold).

Definiëren als techniek: uitgangspunt is dat het zo exact mogelijk beschrijven van processen, verantwoordelijkheden, beleid en standaarden deze optimaal doet functioneren. Dit werkt bij producten, dus het zou ook bij services zo moeten zijn. Waaruit blijkt dat dit zo is? In de praktijk blijkt dat er te veel veranderingen, interpretatieverschillen, afhankelijkheden en dergelijke zijn, die niet kunnen worden voorzien, laat staan getest (voorbij een threshold). Hierdoor komen gebruikers veel te vaak in processen of tussen verantwoordelijkheden vast te zitten.

Een pijnlijk voorbeeld is ten slotte de banksector: ook daar werden de exacte/lineaire technieken de afgelopen jaren intensief ingezet om de efficiëntie te verhogen en risico's te beperken. Het heeft niet geholpen. Tevens is duidelijk dat ontwikkelingen heel snel kunnen gaan, met verstrekkende gevolgen (zie collaps in de grafiek).

Het moet anders

Veel collega's weten bij nieuwe projecten intuïtief: 'er ontbreekt iets maar ik weet niet wat'. Op het congres 'Complexiteit in de greep' formuleerde Sven Withofs van NPI de huidige situatie als volgt: 'Wij weten dat het anders moet maar doen het niet'. Daarbij past de toevoeging: wij doen het niet omdat wij niet weten hoe het anders moet.

Behalve met de tekeningaanpak is het vaak gelukt eenvoudige oplossingen te vinden. Bijvoorbeeld voor capacity management. Diep technologisch en commercieel inzicht, alsmede begrip van grotere afwijkingen in het verbruik van klanten, maakte het mogelijk met veel minder data en kosten een veel beter resultaat te bereiken. Ook was er een procesaanpak in productie, die bijna zonder procesbeschrijving werkte en zeer effectief was. Mensen werden "automatisch" door het proces geleid (terwijl vandaag de dag gebruikers geacht worden hun weg door het proces te vinden).

Conclusie

Voor solide oplossingen is het essentieel dat wij de fundamentele oorzaak van de complexiteitsproblematiek begrijpen. Voor de threshold leveren de lineaire/exacte technieken goede resultaten. Voorbij die threshold zijn deze technieken ineffectief. Veelvuldige toepassing van exacte/lineaire technieken voorbij de threshold verhoogt bovendien de complexiteit: dat gebeurt doordat er meer en meer nieuwe objecten, met hun directe en indirecte afhankelijkheden, worden gecreëerd, die gemanaged moeten worden en ook nog eens 'tussendoor' veranderen. Niet alleen kom je dan in de gevarenzone met falen als gevolg, ook de kosten lopen exponentieel op. Omdat budgetten beperkt zijn betekenen meerdere van dit soort situaties dat budgetten en mensen van productieve activiteiten worden weggehaald, wat weer nieuwe problemen veroorzaakt.

Dit biedt uitzicht op buitengewone mogelijkheden voor solide oplossingen met veel lagere kosten, productiviteitsverbeteringen en betere aansluiting bij business. Deel II gaat over een ‘pathway' naar die oplossingen.

Eugen Oetringer, directeur/oprichter ComDyS