Bij grote organisaties is de samenwerking tussen technologie, mensen en processen een complex systeem geworden met een teveel aan onderdelen en afhankelijkheden. Veranderingen zorgen voor onvoorziene sneeuwbaleffecten. Standaardmethodieken, zoals Cobit of ITIL, projectmanagement of Six Sigma, functioneren maar ten dele. Volgens Eugen Oetringer van ComDys bestaat er een uitweg voor het terugdringen van de complexiteit en het vinden van effectieve oplossingen.
Het hoge percentage projectfalen is in de ict-sector een standaardnorm geworden, constateert Eugen Oetringer spijtig. De oprichter van ComDys uit Rotterdam kan zich nog de tijd herinneren dat de sector succesvolle projecten en diensten afleverden die niet gehinderd werden door een verstikkende bureaucratie en complexiteit. Het mislukken van veel projecten vormde voor hem aanleiding op zoek te gaan naar de fundamentele patronen hiervan.
In dienst van EDS publiceerde hij het boek 'The IT Strategy Management Process', waarin Oetringer een aanpak uitlegt om om te gaan met die talloze beheermethodieken die er inmiddels bestaan. 'Er circuleren wel zo'n vijftig methodieken, modellen en 'best practices' op de markt. ITIL, IT Governance/Cobit, projectmanagement, qualitymanagement, CMMI, Basel II, enterprise architecture, Six Sigma, knowledge management, noem maar op. Het aantal alleen al roept al vragen op. Duidelijk is in ieder geval ze niet afdoende zijn om complexe systemen aan te kunnen. De verwachtingen ervan zijn te veel ingekaderd. Iets als 'best practices' is een standaard geworden, maar onduidelijk is wie de waarde ervan bepaalt. Als de oplossing voor een probleem buiten zo'n kader ligt, wordt die niet meer gevonden.'
Domino-effect
Het ontstaan van bureaucratie en complexiteit is geen typisch ict-probleem, maar komt binnen organisaties op een breed front voor. Toch springt ict er boven uit als het gaat om het mislukken van projecten en het vastlopen van systemen. 'Zo'n ict-systeem wordt dan uit den treure getest, maar houdt dan te weinig rekening met de situatie en het gedrag van gebruikers. Ik heb meegemaakt dat door de starre structuur een nieuw inkoopsysteem het onmogelijk maakte om nog een pc of bloknote te bestellen. Of denk aan het doorvoeren van wijzigingen in complexe systemen. Omdat er zoveel mensen bij betrokken zijn, zijn de gevolgen eigenlijk niet goed te overzien. Dan blijkt ineens functionaliteit voor bepaalde medewerkers te zijn weggevallen en moet er weer een wijziging komen, etc. Dat ontstaat er een sneeuwbaleffect.'
Lineair versus non-lineair
Ingewikkelde oplossingen zijn een verwachtingspatroon geworden, stelt Oetringer vast. Maar zodra het bij een systeem ingewikkeld wordt, ontstaan falende projecten. Zijn voorstel is om op zo'n punt te stoppen en te zoeken naar eenvoudiger oplossingen. Hij is een groot voorstander van het non-lineaire denken: breng zaken terug tot de essentie, denk buiten de kaders, gebruik intuïtie en ondernemerszin en zet via 'trial en error' een zelflerende organisatie op. Het lineaire denken, volgens strakke, mathematische uitgangspunten, leent zich goed voor het opzetten van simpeler computerprogramma's, maar is niet geschikt om een complexe it-omgeving te overzien, aldus Oetringer. Hij merkt dat er langzamerhand vanuit verschillende hoeken belangstelling ontstaat voor het onderwerp. 'Ik was recent op het congres van Impa, een internationale vereniging van projectmanagers, met als thema Complexiteit in de greep. Ook daar was de roep om een andere, effectievere aanpak hoorbaar.'
Workshop
Op dinsdag 8 december organiseert Comdys de workshop 'Complex systems made simple.' Facilitator is organisatie-adviseur Hugo Roele. Naast Eugen Oetringer spreekt professor Michael Fitzgerald, die ingaat op de relatie tussen het Asperger-syndroom (autisme) en geniale denkers, zoals Einstein, en eigenschappen die hen waarschijnlijk in staat hebben gesteld oplossingen te vinden. Speciale aandacht is er voor capaciteitsknelpunten in systemen en de rol die hersenonderzoek hierbij zou kunnen spelen. Meer informatie: www.comdys.com.
@Eugen, als er veelvuldig interrupties en wijzigingen op een project afkomen die een projectbrede impact hebben, dan is het project verkeerd ingericht. Dan zijn er verkeerde afspraken gemaakt, is er een verkeerde architectuur gekozen of worden bijvoorbeeld afspraken niet nagekomen.
Voor de zaken die echt niet te voorzien waren (en die zijn er altijd), kan er samen met specialisten op centraal niveau een oplossing gezocht worden.
Soms komt het voor dat een project vervangen wordt door een ander wegens nieuwe omstandigheden. Dan moet het oude project gewoon stopgezet worden en er opnieuw begonnen worden. (Uit politieke motieven) doen alsof het oude project enkel wat bijgesteld wordt, kost alleen extra tijd en geld. En de kans op mislukking is erg groot.
Het veronderstellen van Asperger (vorm binnen het autisme spectrum) bij Einstein op basis van getuigenissen uit tweede hand is van het niveau “your guess is as good as mines”. Er zijn vast ook andere redenen te bedenken waarom hij pas op latere leeftijd zo geniaal bleek te zijn.
Daarbij weet men niet wat autisme is. Men kent alleen verschillende verschijningsvormen en mogelijke manieren hoe daarmee om te gaan. Het wetenschappelijk inzicht in autisme is zo gering dat men het niet kan verhelpen middels medische ingrepen of medicijnen (net als bij de meeste afwijkingen en ziektes in de hersenen).
Dus deze discussie is wel interessant, maar nog niet relevant voor de ICT. Outside the box-denken is goed, maar realisme ook.
Nu deze workshop heeft plaatsgevonden: de lezing van prof. Fitzgerald over Einstein, Newton, etc. werd dusdanig interessant dat spontaan werd besloten meer tijd aan te besteden dan de bedoeling was. De uitkomst: Deze heren vertonen een aantal meer of minder gezamenlijke karakteristieken, ondermeer: ignoreren van bestaande zienswijzen, “start from scratch”, “break the rules” en “don’t fear the consequences”. Deze lijken hard nodig om baanbrekende oplossingen te vinden.
Vandaag zijn wij hard op zoek naar baanbrekende oplossingen. Maar wie staat nog een project toe als het niet in bestaande zienswijzen past? Wat als er al is geïnvesteerd en de eenvoudige oplossing niet in het geïnvesteerde past? Wat als de “scope” van een opdracht ons niet toestaat de eigenlijke root cause van een probleem aan te gaan?
Samenvattend: huidige denk en werkwijzen belemmeren ons erin karakteristieken toe te passen die Einstein, Newton, etc. in staat hebben gesteld dat te bereiken wat ze hebben bereikt. Een reeks van deze karakteristieken zouden vandaag breed kunnen worden toegepast. Wij zouden ze alleen weer moeten toestaan.
“als er veelvuldig interrupties en wijzigingen op een project afkomen die een projectbrede impact hebben, dan is het project verkeerd ingericht. Dan zijn er verkeerde afspraken gemaakt, is er een verkeerde architectuur gekozen of worden bijvoorbeeld afspraken niet nagekomen.”
Ik respecteer deze zienswijze. Een andere zienswijze is deze: Doordat architecturen in grotere organisaties zeer complex en dynamisch zijn, kan er bijna altijd worden aangeven dat de architectuur verkeerd is. Omdat wij vaak met verschillende culturen en talen te maken hebben, is het normaal dat dingen anders worden geïnterpreteerd en opgepakt als men verwacht. Zo kunnen er nog vele voorbeelden worden gegeven. Uiteindelijk betekent deze zienswijze: Net als bij sommige andere methodieken is er een verwachtingshouding dat mensen, culturen, andere methodieken, politiek, software, etc. zich aan de eisen van de methodiek aanpassen. Echter, de afgelopen jaren laten zien, dat er te veel in de weg staat om dit te laten gebeuren.
Een voorbeeld waar deze verwachtingshouding bestond is ITIL. Een paar jaar geleden was gebruik van ITIL een vereiste. Met de nieuwe versie 3 werd geprobeerd van te veel theorie over te stappen naar een praktische aanpak. Nu ITIL een stap in de goede richting had gezet, verscheen in deze krant op 28 oktober het artikel “itSMF is gedoemd te verdwijnen”(itSMF: ITIL gebruikersvereniging) en op 03-12-2009 “itSMF stelt commissie in na kritiek leden”. Waar ik mij trouwens zorgen over maak is een mogelijke ontwikkeling van te veel ITIL naar te weinig ITIL. Vaak is de optimale oplossing ergens in het midden te vinden.
Eugen, ben het nu een keer met je eens. ITIL kwam uit de praktijk, maar versie 3 wordt weer minder praktisch. Natuurlijk zijn er ook positieve kanten aan ITIL v.3 te ontdekken, de dienstverlening staat er meer centraal. OGC heeft ITIL über konstruiert onder de invloed van het boeken- en cursussencircuit rond ITIL (itSMF en conculega’s).
Hoop van harte dat de oude versie voorlopig massaal in gebruik blijft en dat er een volgende versie komt die beter integreert met ASL en BiSL. Daarbij moeten de overlappingen en de verschillen in definities verdwijnen. Dat communiceert beter en is dus ook beter voor de klant.