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
Ik snap niet wat dit hele artikel met ITIL en itSMF, waar naar de kop in verwezen wordt, te maken heeft. Graag uitleg.
Een verwarrend artikel
De redenering van de inleiding is blijkbaar (mijn aanname): ITIL is verleden tijd, dit komt doordat ITSMF geen bestaansrecht meer heeft. Daardoor hebben we de mogelijkheid om de kloof tussen business en ICT te slechten. Daarover (?) zijn adviezen uitgebracht die echter geen verschil maken.
Dit artikel legt (o.a. met bovenstaande) verbanden die ik niet snap, en de hoofdboodschap is mij ondanks de paragraaf “conclusie” niet duidelijk. We moeten de oorzaak van de complexiteit begrijpen, ok. Maar dan, wat doen we daarna? Wat is het alternatief voor de exacte methodieken? Hoe komen we tot die solide oplossingen?
Verder worden er bevindingen gegeven die niet met voorbeelden meetbaar(der) worden gemaakt (bijvoorbeeld de opmerking over capacity management). Vijftig tot honderd methodieken? Dat is ook al niet erg exact. De link tussen ITIL en de recente kritiek op ITSMF ontgaat mij (en als er een “framework” niet exact/lineair is, dan is het wel ITIL). Kortom: een verwarrend artikel.
Ik had een betoog gewaardeerd met als strekking dat methodieken niet alles kunnen oplossen. Dat het uiteindelijk neerkomt op mensenwerk (over methodieken gesproken: ABC of ICT). En dat het uiteindelijk neerkomt op de ultieme best practice: GBV (Gezond Boeren Verstand).
Een prachtig artikel, zeer herkenbaar probleem!
ITIL procesbeschrijvingen werken uitstekend, zolang het gaat om de theorie van één item dat door het proces rolt. Als de druk op de processen toeneemt, wordt het (al snel!) moeilijker.
Ontwerpen en bouwen van een werkende situtatie staat (nog) ver af van beheerprocessen voor onderhoud en wijzigen – de productiestraat, zo je wilt.
Inrichten van beheer (productie) vereist nadrukkelijk andere kennis dan ontwerpen en leveren van een product (of dienst). Andere getallen, andere consequenties en anders denken. Precies zoals Eugen schrijft.
Geachte briefschrijvers,
Helaas zijn bij het invoeren van het artikel op de site de eerste en laatste zin van het artikel weggevallen. Daardoor is onder meer het verhaal over ITIL onduidelijk. Inmiddels is deze fout rechtgetrokken en zijn de ontbrekende zinsneden weer toegevoegd.
ICT moet beter bij de business aansluiten…
Daarin zit m.i. het daadwerkelijke probleem en dan niet zozeer dat het resultaat van een project niet aansluit of dat de staande beheerorganisatie niet aansluit…
Nee, business people en ICT people spreken nu eenmaal een andere taal en modelleren in andere talen met behulp van diverse frameworks. Er bestaat niet één framework voor het beschrijven van de totale architectuur. En zou deze al bestaan dan was er waarschijnlijk niet één persoon die alles kon overzien.
Feitelijk hebben we het over archictuur die moet zorgen voor samenhang tussen en binnen de architectuurlagen. Binnen een laag lukt dat heel aardig maar tussen de lagen gaat dat nogal eens fout door gebruik van verschillende frameworks en, waarschijnlijk nog belangrijker, de mensen die op elkaar moeten aansluiten en *samen* moeten zorgen voor de juiste oplossingen. Allen (2000) noemde dit niet voor niets het abstractiegat tussen business en ICT. Recente ontwikkelingen t.a.v. Business Rule Management laten pogingen zien om juist de business leading te laten zijn in het discreet vastleggen van de regels, iets wat voorheen met name door de ICT werd gedaan. De software code zou bij voorkeur automatisch moeten kunnen worden gegenereerd op basis van deze business rules. Misschien dat we hiermee in de toekomst beter op elkaar kunnen aansluiten… de tijd zal het moeten leren.
Een voorbeeld voor het grote abstractiegat tussen organisatie (gebruikers) en ICT.
Een eindgebruiker belt de helpdesk met de opmerking dat de computer het niet doet. De helpdesk medewerker vraagt om welke computer het gaat. De eindgebruiker antwoordt: “een grijze…”.
Beste Henk,
Dit verklaart zeker een aantal zaken (met name mijn opmerking over “de hoofdboodschap”).
Ik deel overigens de opmerking over ITIL inhoudelijk niet. Waarom zou het goed inrichten van je beheerprocessen (waar ITIL over gaat) geen “must” meer zijn? Dat is ook / juist bij grotere complexiteit van groot belang. Dat je daar andere / meer middelen bij nodig hebt in een complexere omgeving snap ik.
Verder is de link met ITSMF mij nog steeds niet duidelijk. Volgens mij was de strekking van het artikel over ITSMF dat de organisatie die ITSMF is ook haar werkveld naar andere dan ICT-domeinen zou moeten uitstrekken (hetgeen de situatie volgens mij alleen maar complexer maakt).
Interessant betoog om het risico uit te leggen dat (rigide) toepassing van modellen in meer complexe omgevingen niet leiden tot de gewenste efficiency, maar juist tot nog meer complexiteit. Daar schiet (o.a.) ITIL te vaak haar doel voorbij. Mijn ervaring is dat de complexiteit niet zozeer zit in het model maar in de organisatie die haar wil toepassen en de manier waarop zij dat doet. Je vindt dat op meerdere vlakken. Kijk bijvoorbeeld naar de zo vaak mislukte implementaties van standaard oplossingen als SAP. Dat ligt niet aan SAP, dat ligt aan de onwil van de organisatie zich aan te passen aan de gemaakte keuze en daar bovendien flexibel mee om te gaan. Daar ligt het werkelijke probleem. Bij organisaties die niet eerst hun eigen hiërarchie, inrichting en processen onder de loep willen nemen zullen verbetertrajecten mislukken als zij daarvoor “tovermiddelen” in willen zetten. Inzet van modellen, structuren of andere standaardoplossingenwil niets meer zeggen dan dat er een “best practices” toolbox beschikbaar komt waar de organisatie uit kan putten. Als de (proces)inrichting en het (management)model van die organisatie in de hand werken dat in vrijwel alle gevallen teveel tools moeten worden gebruikt, zal er chaos ontstaan in plaats van orde en lopen de uiteindelijke kosten flink uit de hand.
Wat wel interessant is de vraag of de business ook vindt dat zij beter op ICT zou moeten aansluiten. Mijn ervaringen zijn tot nu toe dat ICT blijkbaar vindt dat zij een probleem heeft bij aansluiting op de business en vervolgens een oplossing in het ICT domein zoekt en niet samen met de business probeert te achterhalen of er een probleem is wat dat probleem zou kunnen zijn en wiens verantwoordelijkheid waar ligt binnen dat probleem.
Wat ik dus wil zeggen is dat alle initiatieven om aansluiting te vinden bij de business bij ICT vandaan komen.
Michiel,
Wij zijn het eens. Het inrichten van beheerprocessen blijft een must. Waar het om gaat is vast te stellen wanneer de onderliggende technieken en werkwijzen wél en wanneer ze niet werken. In de huidige complexe omgevingen bestaat een threshold: vóór dat punt zijn ze wel, en voorbij dat punt zijn ze niet meer effectief. Gelukkig kunnen complexe omgevingen op een andere manier effectief beheerd worden, en wel met minder middelen. Zo heb ik tot halverwege de jaren 90 in de rekencentra van mijn vorige werkgever meegemaakt hoe goed ITIL processen functioneerden, zonder dat procesbeschrijvingen of uitgebreide definities bestonden.
Wat itSMF betreft, de losgebarsten kritiek ligt in het verlengde hiervan. Zolang je de echte oorzaak niet te pakken hebt, zal het niet beter worden. En ja, het reikt verder dan Service Management alleen. Het complexe van complexiteit is dat alles met elkaar samen hangt, zodat je je niet kunt beperken tot ITIL of Service Management alleen.
Beste Eugen,
Terechte opmerking m.b.t. het functioneren van (ITIL) processen zonder uitgebreide beschrijvingen. Veel organisaties maken het zichzelf idd te moeilijk door daar in door te slaan (en nee, het is niet ITIL die dat roept, maar de organisatie die dat afdwingt).