Complexiteit is aan te pakken

Waardoor wordt automatisering steeds complexer? In tijden waarin alles wordt geautomatiseerd ligt dit niet aan de bedrijfsfuncties, maar primair aan de relaties en connecties tussen systemen. Complexiteit wordt niet zozeer bepaald door individuele informatiesystemen, maar door het aantal interfaces tussen systemen, medewerkers en de buitenwereld. Een voorbeeld. De eerste keer dat een softwareontwikkelafdeling requirementsmanagement op CMMI level II uitvoert, is zij geneigd eenvoudige hulpmiddelen te gebruiken. Wat blijkt: een simpel project heeft al snel zo’n honderd eisen. Tot nu toe niets aan de hand, echter deze eisen hebben relaties en afhankelijkheden, zowel onderling als met de omgeving. Alles wordt netjes in kaart gebracht en men begint met een detailontwerp of direct met de realisatie. En dan komt het: eisen veranderen, worden toegevoegd of vallen af, zelfs eerder veranderde eisen veranderen. Relaties en afhankelijkheden verschuiven, en alles begint een beetje ondoorzichtig te worden, wat uiteraard het ‘professionele’ proces niet helpt. Kortom, complexiteit wordt verhoogd door het aantal connecties, onzekerheden en veranderingen tussen systemen, en laat zich moeilijk sturen of vormen. Fragiliteit is een interessant kenmerk. Gevoelsmatig betekent het kunstzinnig en elegant, maar ook broos, kwetsbaar, breekbaar, een kleine fout kan grote gevolgen hebben. Het eerste willen we eigenlijk wel, het tweede is de grote angst van opdrachtgevers, de business. Deze spagaat veroorzaakt dat fragiliteit geen kwaliteitskenmerk is, het heeft immers zowel positieve als negatieve aspecten in zich. Het aanverwante kwaliteitskenmerk is robuust, gevoelsmatig de tegenhanger van fragiel. Om te bepalen wat de mate van robuustheid van een informatiesysteem is, zijn testen ontwikkeld met betrekking tot hackersbestendigheid, inbreuk, kwetsbaarheid enzovoorts. Als de informatievoorziening deze testen doorstaat is sprake van een hoge mate van robuustheid ofwel het systeem heeft geen probleem met fragiliteit. Naar onze mening speelt hier nog iets anders. Neem bijvoorbeeld een Windows-versie of een internettoepassing. Deze zijn met de beste wil van de wereld niet robuust te noemen, maar de klant/gebruiker lijkt dit weinig tot niet te deren. Andere aspecten en kenmerken zijn kennelijk zo belangrijk dat de kwetsbaarheid van dit soort toepassingen voor lief wordt genomen. Kortom: fragiliteit is een keuze die bewust wordt genomen. Dit geldt ook voor de softwareontwikkeling. Indien doel, functie en uitdaging interessant genoeg zijn accepteren we veel op het gebied van fragiliteit. Mogelijke gevolgen ondervangen we met directe ondersteuning en beheer, en als dit niet helpt is er altijd nog de software-ANWB in de vorm van de tweede- en derdelijnsondersteuning. Keuze Kiezen we zelf voor fragiliteit of wordt ons die keuze opgedrongen? De mate waarin een organisatie zelf die keuze maakt is groter dan we denken. Mensen stappen zonder probleem in een vliegtuig, in het volste vertrouwen tijdig en gezond op de plaats van bestemming aan te komen. Toch zit dat vliegtuig vol softwaresystemen die met elkaar en met de bemanning communiceren en interfereren. En honderd eisen? Ja, wellicht voor ieder klein onderdeel van een component van het systeem. En toch is hier nauwelijks sprake van fragiliteit of kwetsbaarheid. Andere voorbeelden zijn er genoeg, denk aan een regelkamer van een (nucleaire) energiecentrale, een supertanker of een verkeerscentrale. De complexiteit van de hierin samengebalde softwaresystemen is honderden malen groter dan in de administratieve wereld terwijl van fragiliteit nauwelijks sprake is. Waarom? Omdat de aard en functie van het product direct invloed hebben op het menselijk bestaan. Kortstondig of deels falen van software kan gigantische consequenties hebben: de invloed op de directe leefomgeving van betrokkenen en hun omgeving is enorm. Ondanks alle complexiteit mogen deze softwareomgevingen absoluut niet fragiel zijn. Er wordt voor kwaliteit gekozen door niets aan het toeval over te laten en door kosten noch moeite te sparen om de softwareomgeving volledig stabiel, robuust en veilig te maken. Processen zijn geborgd, transparant en worden bewaakt. Producten en halffabrikaten worden getest totdat de laatst mogelijke en zelfs onwaarschijnlijke fouten zijn getraceerd en verholpen. Gevonden fouten worden geanalyseerd en leiden tot verbeteringsacties in het ontwikkelingsproces. En vervolgens wordt gedurende de totale levenscyclus een zeer frequente en allesomvattende kwaliteitsborging uitgevoerd om te blijven zorgen voor een robuust en veilig product. Hoe anders ligt dit voor administratieve systemen. Hier wordt vrijwel uitsluitend gestuurd op tijd en kosten. De teneur is bliksemsnel en goedkoop. Kwaliteitsborging in de vorm van testen wordt met de mond beleden maar het verbaast niemand als op de testtijd en -inspanning drastisch wordt besnoeid vanwege de oplevering. Het zal en moet in productie gaan, de problemen worden later tijdens het beheer wel opgelost. Voor kwaliteitsborging gedurende de gehele levenscyclus bestaan bewezen modellen en processen die maar deels worden uitgevoerd. Natuurlijk worden tussentijdse wijzigingen getest, maar of en in hoeverre het onderhavige product stabiel en robuust blijft, is geen onderwerp van controle. Het resultaat is voorspelbaar. En niet de complexiteit maar de keuze van de organisatie of onderneming is bepalend. Hierbij ligt de nadruk op ‘een organisatie’; het is niet het individu maar de samenwerkende organisatie en haar cultuur die deze keuze maakt. Maatregelen Wat is hieraan te doen? Het is onwaarschijnlijk dat in tijden van moordende concurrentie en korte marktcycli meer geld en tijd voor kwaliteit beschikbaar komt. Echter, kwaliteitszorg levert geld op, een goed werkend robuust product heeft minder beheer nodig en levert tevreden klanten op. De volgende kwaliteitsmaatregelen vragen weinig investering: • Kennis: binnen IT is het noodzakelijk voldoende kennis en inzicht te hebben in het functioneren van de organisatie. Het begrijpen van de klantbehoefte is de eerste en belangrijkste stap om vele systeemveranderingen te voorkomen. Kennis van de ‘core business’ moet een deel van de cultuur zijn. • Ontwikkelproces: middelen en methoden zoals CMMI en TMap zijn van wezenlijk belang om het ontwikkelproces professioneel uit te voeren, vooral wat betreft de performance en kenniskant van CMMI. Inzicht in de performance is de eerste stap op weg naar verbetering hiervan. • Leren van fouten: IT ontwikkelafdelingen kunnen goed ‘plannen’, voeren dit ook redelijk uit (‘do’) en willen zelfs een evaluatie (‘check’) uitvoeren. Reactie op de evaluatie (‘act’) blijft vervolgens achterwege, daar is geen tijd voor. Let wel: een individu kan leren van zijn fouten, waar de organisatie deze cultuur niet heeft. Als dit leerproces niet verankerd wordt in de bestaande cultuur, zichtbaar en duidelijk voor alle medewerkers, is het bedrijf niet in staat te leren. Het zal immers altijd kiezen voor de bestaande en bekende weg als niet een sterke impuls tot verandering aanwezig is. Met andere woorden: fragiliteit is niet nodig, betere tot excellente kwaliteit kan dit in grote mate voorkomen. AUTEUR: Marcel Claessens Marcel Claessens is senior-kwaliteitsmanager bij KZA Improvement in ICT (mclaessens@kza.nl). Met dank aan Henry Dijkstra.