Acceptatie van een IT-systeem

Acceptatie van een IT-systeem
Het succes van de implementatie van een nieuw informatiesysteem wordt bepaald door de acceptatie van het systeem door de eindgebruikers. Gelukkig is er een acceptatietest die handvatten geeft om de betrokkenheid van eindgebruikers te vergroten en de complexiteit van zowel organisaties als systemen behapbaar te maken.
Twee veel voorkomende opvattingen, die ertoe leiden dat beslissers in de praktijk het nut en de noodzaak van een acceptatietest flink onderschatten, zijn: 'De softwareleverancier test toch?’ en ‘Wij hoeven niet te testen, omdat wij voor een standaard ERP-systeem kiezen.’. Bij veel klantgerichte, middelgrote organisaties (zoals zorgaanbieders en woningcorporaties) vormt ERP-achtige pakketsoftware de kern van de informatievoorziening. In feite is de volledige bedrijfsvoering van de organisatie afhankelijk van het functioneren van dit informatiesysteem. Veel organisaties onderschatten niet alleen de complexiteit van het informatiesysteem (met vaak talrijke integraties) maar ook de complexiteit van hun eigen organisatie die het gevolg is van de vele verschillende rollen en verantwoordelijkheden, de verschillende typen klantcontacten, de door elkaar lopende processen. Onvoldoende realiseren deze bedrijven zich dat zij niet of nauwelijks meer in staat zijn om de kwaliteit van het informatiesysteem te beheersen. Het testen daarvan is domweg een te tijdrovende en te gespecialiseerde klus geworden. Het implementeren van dit type informatiesystemen in organisaties is als het vervangen van een onderdeel in het zenuwcentrum van een menselijk lichaam: het grijpt diep in en fouten zijn meteen voelbaar. Het goed vormgeven van een acceptatietest is derhalve geen sinecure; complexiteit van organisatie en informatiesysteem (en de samenhang daartussen!) vraagt om een aanpak waarvoor de standaard testmethoden vaak geen oplossing bieden.
Wat is dan wel een oplossing? Acceptatietesten ontwerpen met methoden en technieken uit de enterprise engineering kan soelaas bieden. Enterprise engineering geeft meer inzicht in de constructie van de organisatie, onafhankelijk van de implementatie ervan en dus ook los van de gekozen softwareoplossing. In dit artikel presenteren we een acceptatietest die handvatten geeft om de betrokkenheid van eindgebruikers te vergroten en de complexiteit van zowel organisaties als systemen behapbaar te maken. De acceptatietest is niet meer de sluitpost van het implementatieproject van een nieuw informatiesysteem, maar een integraal onderdeel daarvan. Bovendien omvat de test niet alleen de acceptatie van het systeem, maar ook de acceptatie van de ‘nieuwe’ organisatie. De gebruikersacceptatietest krijgt hierdoor een breder perspectief. Uiteraard is voor zo’n test een integrale aanpak noodzakelijk.
Kwaliteit
‘Kwaliteit’ is een containerbegrip. Bovendien zorgt het nogal eens voor controverses. Wat voor de één kwalitatief goed is, kan voor de ander volledig onpraktisch zijn. Over de definitie van ‘kwaliteit’ zijn kasten vol geschreven. Vanuit de systeemontwikkeling maakte Boehm in 1979 al de nodige rekensommen over herstelkosten. Toch kampen we dertig jaar later nog steeds met dezelfde problemen. Indien laat in het traject (acceptatiefase) fouten worden gevonden, leidt dit onherroepelijk tot flinke discussies in de projectteams over de te nemen route. Doorgaans resulteert dat in meer fouten, ‘terug naar de tekentafel’ leidt tot enorme kosten- en tijdsoverschrijding, gefrustreerde eindgebruikers en een wankel informatiesysteem. Kortom, geen gemakkelijke afweging! Binnen het bedrijfsleven is het daarom bijna ‘geaccepteerd’ dat software niet voldoet aan de verwachting, dat eindgebruikers gefrustreerd achter de computer zitten en dat de kosten alsmaar stijgen. De Standish Group doet al jaren onderzoek naar falende, betwiste en succesvolle projecten. Succesvol wordt daarbij gedefinieerd als: binnen tijd, budget en naar verwachting. Falende projecten zijn projecten die nooit zijn opgeleverd of in gebruik zijn genomen. Betwiste projecten zijn opgeleverd, maar boven tijd, budget en/of met minder functionaliteit dan verwacht. Gebaseerd op een analyse van meer dan tachtigduizend projecten wereldwijd, laten zij in hun Chaos Manifest 2011 zien dat 37 procent wordt bestempeld als succesvol, 42 procent als betwist en 21 procent als falend. Uit het onderzoek blijkt bovendien dat betrokkenheid van eindgebruikers op nummer 1 (twintig procent) staat van de lijst met succesbepalende factoren voor ICT-projecten. Een saillant detail is dat 53 procent van de managers/projectleiders het moeilijk vindt deze betrokkenheid te realiseren.
Voor de definitie van ‘kwaliteit’ hanteren we de meest gebruikte en meest eenvoudige definitie, die van Juran: ‘Kwaliteit is geschiktheid voor gebruik’. Het zwaartepunt ligt bij de acceptatiebeleving van de eindgebruikers: ‘geschiktheid voor gebruik’ wordt niet alleen ervaren als het gaat om de functionaliteit van het informatiesysteem, maar ook qua organisatorische impact en verandering.
Integraliteit
Wereldwijd zijn er ongeveer vierhonderd gereedschappen beschikbaar waarmee bedrijfsprocessen volgens een bepaalde methode kunnen worden gemodelleerd. Of het nu gaat om het vastleggen van processen ter verkrijging van het ISO-certificaat, veranderingen in het kader van business process redesign (BPR) of het leggen van de basis voor de bouw en inrichting van softwaresystemen: alle methoden gaan uit van een model dat de bedrijfsprocessen van de huidige of gewenste organisatie volledig beschrijft. In de praktijk komt het vaak voor dat er kasten vol met procesbeschrijvingen worden voorgelegd en dat de organisatie zelf discussieert over de juistheid en eenduidigheid. Hoe kun je dan van de softwareleverancier verwachten dat hij deze processen correct inricht en integreert in het informatiesysteem?
Anderzijds geeft ook de installatie van een standaard ingericht ERP-systeem de nodige frictie aan organisatorische kant: het systeem bepaalt te veel de werkwijze van de organisatie. Iedereen die bij implementaties van informatiesystemen betrokken is kent dit dilemma. Er is daarom grote behoefte de te ondersteunen bedrijfsprocessen ondubbelzinnig en voor alle stakeholders begrijpelijk in kaart te brengen. Deze beschrijving kan dan als kapstok worden gebruikt om de vervolgstappen te bepalen: óf het softwaresysteem inrichten naar de processen óf de organisatie inrichten naar de meegeleverde ‘standaardinrichting’ van het softwaresysteem. Er is geen ‘beste’ methode om bedrijfsprocessen in kaart te brengen, maar door het gebruik van DEMO (Design & Engineering Methodology for Organizations) kunnen de bedrijfsprocessen op een globaal niveau worden opgezet. Dit leidt tot een zuivere afweging over nut en noodzaak waarbij niet alle discussies gaan over details die er nog niet toe doen. Met DEMO beschrijf je de essentie van een organisatie, volledig onafhankelijk van de daadwerkelijke realisatie en implementatie. De essentie is stabiel en altijd up-to-date, omdat het alleen de geleverde producten (of services) laat zien in relatie tot de bijbehorende transacties en actoren.
DEMO bestaat uit drie gelaagde aspectorganisaties, ook wel systemen genoemd: B-systeem (business), I-systeem (informatie) en D-systeem (documentatie). De totale organisatie is samengesteld uit deze drie systemen, waarbij de actoren in het B-systeem originele (nieuwe) feiten creëren door met elkaar afspraken aan te gaan over de levering van producten en diensten. De processoren in het I-systeem bewerken bestaande originele feiten tot informatieproducten, zoals rapportages, jaarrekeningen, overzichten en dergelijke. Het I-systeem is ondersteunend aan het B-systeem, dat wil zeggen actoren in het bedrijfsproces (B-systeem) gebruiken het I-systeem ter ondersteuning van hun onderlinge communicatieve acties (het aangaan en nakomen van afspraken) en van hun besluitvorming. De operatoren in het D-systeem zijn de ondersteuners van het I-systeem door middel van infrastructuur, zoals e-mail en databasemanagementsystemen, maar ook alle elektronische formulieren waar mensen in de organisatie dagelijks mee werken. Bij elke verandering binnen de organisatie (functioneel, maar ook in relatie tot ICT) worden één of meerdere systemen (aspectorganisaties) ‘geraakt’. Het implementeren van een nieuw ERP-systeem heeft met name betrekking op de I-aspectorganisatie en op de D-aspectorganisatie. Indien een nieuw product of service wordt geïntroduceerd heeft dit vooral invloed op de B-aspectorganisatie.
Binnen de drie aspectorganisaties is er sprake van twee (systeem)oriëntaties: functie en constructie. Vanuit de functieoriëntatie wordt gekeken door de bril van de gebruiker van het systeem. Het systeem wordt in beschouwing genomen als black box, alleen vanuit het perspectief ‘gedrag’. Kijkt men vanuit de constructieoriëntatie, dan wordt gekeken door de bril van de bouwer. In dat geval wordt het systeem beschouwd als een white box: hoe het systeem inwendig werkt en is samengesteld. Vanuit de B-aspectorganisatie kent DEMO vier hoofdmodellen: het communicatiemodel (CM), het procesmodel (PM), het actiemodel (AM) en het toestandsmodel (SM). In dit artikel gebruiken we alleen de modellen CM en PM, waarbij binnen het PM ook het transactieprocesmodel (TPM) wordt gehanteerd. Figuur 1 laat zien hoe de samenhang van de systemen (aspectorganisaties) is ingericht in relatie tot de modellen.
Figuur 1. Systemen en modellen
 
In het eerste model, het communicatiemodel, worden de essentiële transacties en hun onderlinge samenhang beschreven in compacte vorm (één A4’tje). Het communicatiemodel geeft de constructie van de organisatie aan. Over deze röntgenfoto moet consensus bestaan, omdat dit model de basis vormt voor de organisatorische inrichting, de vertaling richting ICT en de daadwerkelijke toetsing van de kwaliteit van het informatiesysteem en de (bijbehorende) organisatieverandering. Figuur 2 laat twee transacties uit dit model zien, waarbij de initiërende partij (actor A) een verzoek doet (T01) aan de uitvoerende partij (actor B). De uitvoerende partij krijgt in deze schrijfwijze een zwart vierkantje op de lijn.
 
Figuur 2. Transacties met actoren
 
Binnen een transactie (T01) zit een aaneenschakeling van vijf statussen: (1) A verzoekt aan B; (2) B belooft aan A; (3) B voert uit; (4) B verklaart aan A en (5) A accepteert van B. Elke transactie in het communicatiemodel bevat deze statussen. In het procesmodel wordt vervolgens de volgorde en samenhang van de onderliggende transacties zichtbaar gemaakt. Hiermee wordt bedoeld dat bijvoorbeeld transactie T02 pas kan starten als transactie T01 is afgerond, et cetera. Elke transactie heeft dus eenzelfde patroon van verzoekt-belooft-uitvoering-verklaart-accepteert. Dit patroon wordt het ‘succespad’ van een transactie genoemd, omdat het verzoek altijd wordt afgesloten met een acceptatie. In de praktijk is dat helemaal niet altijd zo, want er kan na een verzoek discussie ontstaan over het verzoek of voor de acceptatie discussie ontstaan over wat is uitgevoerd. Het transactieprocesmodel (TPM) omvat naast het ‘succespad’ ook een universeel ‘niet-succespad’. In dit ‘niet-succespad’ ontstaat discussie over het wel of niet aannemen
van een transactie en in het slechtste geval kan de transactie in zijn geheel worden stopgezet. Samengevat geeft het transactieprocesmodel in één keer zo’n 23 statussen weer. Het transactieprocesmodel reduceert daarmee op eenvoudige wijze de complexiteit van communicatie en de daarbij mogelijke systeemfouten. Figuur 3 laat één transactie zien tussen twee actoren met het ‘succespad (groen)’ en ‘niet-succespad (oranje, rood)’ in hun geheel.
Figuur 3. Transactieprocesmodel met universele statussen

De complexiteit van de organisatie wordt door deze manier van modelleren enorm vereenvoudigd. Er is immers een essentieel model ontstaan, in de ‘taal’ die iedereen in de organisatie kan praten en verstaan. Op basis van dit transactieprocesmodel kan op essentieel niveau een uitgebreide set van gedetailleerdere testscenario’s worden beschreven, omdat alle ‘niet-succespad’-statussen vooraf gedefinieerd zijn.
Bovendien zijn de scenario’s opgesteld vanuit een gemeenschappelijk begrip van de organisatie en niet vanuit het informatiesysteem. Uit onderzoek is bovendien gebleken dat het organiseren en inrichten van de gebruikersacceptatietest met deze gestructureerde werkwijze qua resultaten een beter resultaat geeft dan de huidige praktijkmethoden. Figuur 4 laat zien dat er twee verschillende acceptatietesten zijn uitgevoerd: één op basis van de DEMO-denkwijze (EO) en één op basis van ‘best practice’ (T) op hetzelfde onderdeel van het ERP-systeem. De testresultaten zijn gecategoriseerd op basis van vooraf opgestelde kwaliteitscriteria, die zwaarder wegen naarmate het belang van het toepassingsgebied toeneemt.


Figuur 4. Resultatenvergelijking van de twee acceptatietestmethoden

De vergelijking van de beide testmethoden laat zowel overeenkomsten als (verrassende) verschillen zien. Op basis van beide testmethoden kan de conclusie worden getrokken dat het ERP-systeem de nodige risico’s met zich mee zou brengen op het gebied van de financiële functionaliteit. Bij gebruik van de EO-methode is het resultaat van het criterium ‘herleidbaarheid’ veel gedetailleerder (en slechter) doordat het transactieprocesmodel standaard de universele ‘niet-succespad’-statussen beschrijft. Het verschil bij het acceptatiecriterium ‘stabiliteit’ heeft te maken met de gedetailleerdere acceptatietestscripts die ontstaan op basis van de DEMO-werkwijze. Naast de ‘harde’ resultaten merkten we tijdens het proces dat door het gebruik van het communicatiemodel een zuiverder discussie plaatsvond over wat nu wel en niet essentieel was.

Niet te beheersen
We concluderen dat het nut en de noodzaak van een gedegen acceptatietest belangrijk zijn. De samenhang van de complexiteit van zowel organisaties als informatiesystemen is zonder methodische aanpak niet meer te beheersen. De acceptatietest is daarom geen sluitpost meer van een project, maar een integraal onderdeel van het gehele project. Door het ontwerpen van de acceptatietest al eerder in het project een prominente rol te geven en gebruik te maken van methoden en technieken uit de enterprise engineering ontstaan zuiverder discussies over hoofd- en bijzaken voor alle betrokken. Daarnaast groeien eindgebruikers mee in het project door de gestructureerde manier van modelleren en de afgeleide werkwijze om testscenario’s en -scripts te maken. Naast de betere testresultaten hebben de eindgebruikers een grotere acceptatie van zowel het ERP-systeem als de ‘nieuwe’ organisatie, wat uiteindelijk leidt tot lagere kosten.
 
Drs. René Ceelen is directeur van CEPO en doet promotieonderzoek bij het Institute for Computing and Information Sciences (ICIS) aan de Radboud Universiteit Nijmegen. E-mail: rceelen@cepo.nl
Literatuur
Boehm B. / Englewood C., Software Engineering Economics. NJ : Prentice-Hall, 1981
Ceelen R. / Metz L., Procesgestuurd testen met een hogere dekkingsgraad, Informatie 6 2009, p 22–27
Dietz J., Enterprise Ontology - Theory and Methodology. Springer, 2006
Dipten E. Van/ Mulder H., Basic Enterprise Engineering Map, Informatie 10 2011, p. 54-61
Juran J.M., Quality Control Handbook, Third Edition (New York McGraw-Hill, 1979), p. 5-11
Metz L., A testing framework based on DEMO. Master’s the-sis, Delft University, 2008
Standish Group. Chaos, tech. report. Technical report, Standish Group Int’l, 2011
www.demo.nl
 

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag