‘Er wacht een braakliggend gebied op de testdeskundige’, stellen Henk van Merode en Marc Hesse. In hun ogen moet hij voor de beheerorganisatie de schakel naar de ict-projecten worden.
De ict-gemeenschap, de beheerorganisaties en de eindgebruikers spreken een andere taal. Dit kan heel vervelend zijn, maar is een vaststaand feit. Extra aandacht moet gericht worden op die vlakken waarbij samenwerking tussen it en klant voorwaardelijk is. In plaats van de eeuwige strijd tussen de it en beheer moet de vraag gesteld worden: ‘waartoe dient het ict-product waar we mee bezig zijn’. Het antwoord is simpel: ‘om te ondersteunen bij het bereiken van de primaire doelstellingen waaraan het bedrijf of de instelling zijn bestaansrecht ontleent’. Belangrijke factoren hierbij zijn continuïteit en maatschappelijke relevantie.
Ons model (zie figuur) gaat uit van de verbondenheid tussen functioneel-, technisch- en applicatiebeheer, die alle in dienst staan van de continuïteit en verbetering van het bedrijfsproces. Om dit te kunnen realiseren hebben alle beheercomponenten een organisatie ingericht: model (0).
Aangezien stilstand achteruitgang betekent zal het bedrijfsproces continu in beweging zijn, hiertoe gedwongen door ‘business drivers’, zoals veranderende wetgeving, De beheercomponenten zullen dus ook in beweging moeten blijven. Dit kan onder regie van een project of door initiatieven van de afzonderlijke beheerorganisaties. Dit model geeft dat weer als evolutie van de organisatie van model (0) naar model (+1).
Scheefgroei
Een groot risico hierbij is dat wijzigingen niet doorgevoerd worden in alle componenten, waardoor scheefgroei gaat plaatsvinden. Hierdoor raakt de verbondenheid uit balans, met als zichtbaar gevolg dat de processen niet meer op elkaar afgestemd zijn en verouderen. Onbegrip over elkaars functioneren, te lange communicatielijnen, misverstanden en problemen zullen een logisch gevolg zijn. Samengevat: de kosten van beheer stijgen de pan uit. Het terug in evenwicht brengen van de organisatie zal alleen kunnen als er flinke investeringen tegenover gezet worden. Helaas kan hier niet altijd budget voor vrijgemaakt worden.
Wie kent niet het probleem van projecten die onder de druk van tijdige oplevering besluiten minder aandacht te besteden aan documentatie ten behoeve van applicatiebeheer. Het resultaat is een relatief kleine besparing voor het project, maar een Pyrrusoverwinning als je kijkt naar de consequenties op langere termijn.
De meeste testmethoden en testtechnieken zijn ontstaan vanuit de it-projecten. Hierdoor zijn ze niet toegespitst op de problematiek van de beheerorganisatie. Er zit een duidelijk verschil in het projectmatig testen en het bedrijfsproces testen (ofwel acceptatietesten).
Het fenomeen acceptatietesten vindt plaats in de ontwikkeling van model (0) tot model (+1) bij de afdelingen functioneel-, technisch- en applicatiebeheer. Tijdens deze ontwikkeling zijn de diverse beheerorganisaties bezig met het klaarmaken van hun organisatie om het projectresultaat te ontvangen en vlekkeloos te implementeren in het bedrijfsproces. Dit geeft aan dat de belangen van de beheerorganisatie anders zijn dan de projectbelangen: daar waar beheer zich richt op de lange termijn (continuïteit), is het project vernieuwend en wordt het vaak afgerekend op de aloude tgkio-principes. Binnen deze principes zijn ’tijd’ en ‘geld’ de sterkst bepalende factoren, en zijn ‘kwaliteit’, ‘informatie’ en ‘organisatie’ van ondergeschikt belang. Onbegrip en wrevel is het logische gevolg.
Schakel
Gevoelsmatig kunnen de testtrajecten van beheer en project los van elkaar opgezet worden. Ervaring leert echter dat gedurende de projectlevenscyclus eisen en wensen van de klant veranderen en dat dit grote impact kan hebben op het uiteindelijk op te leveren product. Er moet dus altijd een bepaalde betrokkenheid zijn van de beheerorganisaties bij de projecten. Ongeacht de verantwoordelijkheid van de beheerorganisatie voor haar eigen (beheer)proces zal zij ook een duidelijke rol in het project moeten spelen.
Hierbij moet vooral de nadruk liggen op de afstemming van de diverse beheeraspecten (functioneel, applicatie en technisch). Het verband tussen deze aspecten is belangrijker dan het incidentele project dat voorbijkomt. Het bedrijf is namelijk gebaat bij een goede beheerorganisatie, enerzijds voor de continuïteit en anderzijds om aan toekomstige ‘business drivers’ het hoofd te kunnen bieden.
De beheerorganisatie wordt vaak verweten dat zij passief is en te laat de consequenties van het project overziet. Dit wordt voornamelijk veroorzaakt door de wetenschap dat een beheerorganisatie verantwoordelijk is voor beheren en het liefst niet ziet dat haar (broze) proces verstoord wordt door nieuwigheden. Daarnaast zit zij ook niet te wachten op een uitbreiding van haar rol met het, inmiddels onderkende, specialisme testen.
Ziehier een rol die een testafdeling kan spelen. Van oudsher kijkt de tester naar relaties vanuit een integrerende rol en is hij de verbindingsolie tussen de diverse partijen binnen een project. Daarnaast bezit de tester de kennis en kunde van te gebruiken methoden en technieken. Hij is dus een volwaardige partner voor de beheerorganisatie om de schakel te zijn naar het project.
De essentie
Deze rol van de tester binnen de beheerorganisatie start bij het bepalen van de impactanalyse. Uit deze analyse volgt een opsomming van aspecten die de huidige beheerorganisaties raken. Met andere woorden: welke veranderingen moet de beheerorganisatie doorvoeren om het resultaat van het project te kunnen beheren (gewenste groei van model (0) naar model (+1)). Deze analyse is dus de initiator van het veranderingsproces bij de beheerorganisatie, waarbij de tester een grote rol kan spelen. Vervolgens moeten project- en beheerorganisaties regelmatig met elkaar contact hebben om wijzigingen van vereisten en consequenties daarvan door te spreken.
De vooronderstelling is dat de beheerorganisatie het model (0) goed beschreven heeft. Dit blijkt in de praktijk niet altijd het geval, waardoor men dus ook niet weet wat er moet veranderen en wanneer een project acceptabel is. Ook hier ligt een mooie taak voor de testdeskundige: bepaal op basis van een gedegen testrisicoanalyse de kern van de (beheer)organisatie in testware. Deze manier voorkomt ook te grote investeringen om de beheerprocessen opnieuw op elkaar af te stemmen.
Concluderend stellen we dat er een groot braakliggend gebied op de testdeskundige wacht om ontwikkeld te worden. Hierbij moet alles in het teken staan van de essentie van het ict-product: ‘het bijdragen aan het bestaansrecht van het bedrijf of de instelling waarvoor we werken’.
Henk van Merode, team manager test management KLM Information Services, en Marc Hesse, testconsultant en testmanager Atos Origin
