Hoewel door de meeste mensen ict als ondersteunend wordt gezien ten aanzien van bedrijfsprocessen, is ict de laatste jaren doorgedrongen tot de haarvaten van menig proces en is het vaak zelfs een bedrijfskritisch component geworden. Niet alleen voor de ondersteuning van het eigen proces, maar ook in de communicatie met partners waarmee samen een proces wordt uitgevoerd, een zogenaamd ketenproces. Hierdoor komen de afhankelijkheden tussen deze ketenpartners in het betreffende ketenproces steeds nadrukkelijker naar voren. De invloed van andere partijen op het proces van de eigen organisatie wordt steeds groter.
Door de steeds verder gaande toepassing van ict in ketenprocessen, worden ook steeds specifiekere en complexere eisen gesteld aan het testen van de ict-ondersteuning van deze ketenprocessen. Dit ketentesten begint idealiter al tijdens het (keten)procesontwerp en loopt door tijdens de ontwikkeling en oplevering van de ict-oplossing(en). Een belangrijke basis voor de uiteindelijke werking van het ketenproces is de tussen betrokken ketenpartners gemaakte set van afspraken ten aanzien van de te gebruiken communicatie-infrastructuurvoorzieningen, de te hanteren standaarden (zowel technisch als inhoudelijk) en de specificaties van de uitwisselingsprocessen alsmede de uit te wisselen berichten.
De problematiek rond ketentesten
Door een goede afsprakenset tussen ketenpartners wordt de onafhankelijkheid van de eigen processen zoveel mogelijk gewaarborgd. De invloed van andere ketenpartners op de eigen organisatie wordt hiermee sterk beperkt.
Door de in de inleiding geschetste ontwikkeling van de toepassing van ict in ketenprocessen, zijn de (ict-)projecten, die voor de ondersteuning van de bedrijfsprocessen van ketenpartners moeten zorgen, ook steeds meer afhankelijk van elkaar geworden. Dit beperkt zich uiteraard niet tot het ontwerp en bouwtraject, maar doet zich extra gelden in het testtraject. Om op dit moment de gegevensuitwisseling te testen tussen twee of meer partijen, dienen al deze partijen zowel de infrastructuur die nodig is om uit te wisselen als de uit te wisselen berichten gerealiseerd te hebben conform de gemaakte ketenafspraken. In de praktijk blijkt dat, met name in ketenprojecten waarbij een aantal organisaties betrokken zijn, de ene organisatie veel eerder ‘klaar' is dan de ander. Dit heeft veelal te maken met verschillend gebruikte ontwikkelmethoden van ketenpartners, verschillende projectgroottes en/of verschillende infrastructuren.
Gegevensuitwisseling op basis van communicatiestandaarden en gebruik makend van ketenvoorzieningen, belooft in principe een reductie van de onderlinge afhankelijkheid tussen ketenpartners. Maar voordat deze belofte kan worden ingelost zien we dat in ketentesten de afhankelijkheid juist enorm toeneemt, met alle kosten en fricties die daarmee gepaard gaan.
Tevens kan gesteld worden dat, bij doorontwikkelen zonder inachtneming van de afhankelijkheden tussen ketenpartners onderling, zich een exponentiële groeicurve van risico's manifesteert. Tevens geldt dat naarmate er meer ketenpartners deelnemen, de kans van daadwerkelijk optreden van die risico's groter wordt met een eveneens groter wordende impact op de uiteindelijke doorlooptijd van het ontwikkelproces. De kern zit daarbij in afhankelijkheden tussen ketenpartners in het ketentesttraject.
Het is dus waardevol om in ketentesttrajecten gebruik te maken van een voorziening waarmee ketenpartners, onafhankelijk van elkaar, kunnen bepalen of aan gemaakte afspraken is voldaan en de gegevensuitwisseling naar behoren gaat werken.
Terugbrengen afhankelijkheden
Om deze problematiek het hoofd te bieden, moet gezocht worden in de richting van het terugbrengen van de afhankelijkheden. Dit is mogelijk door in de ontwikkelingsfase en de testfase van de projecten gebruik te maken van een simulator voor berichtenuitwisseling waarmee de verschillende systeemontwikkelingtrajecten zoveel mogelijk ontkoppeld worden. De afhankelijkheid van de ketenpartners onderling wordt door de inzet van een dergelijke testsimulator sterk verkleind, waardoor alle aandacht gericht kan worden op de ontwikkeling en het testen van de eigen organisatie en bijbehorende ict-ondersteuning.
Conclusie
Testsimulatoren kunnen een belangrijke rol vervullen in het reduceren van afhankelijkheden bij het organiseren en uitvoeren van ketentesten. Dit wordt met name bereikt door het ontkoppelen van de verschillende systeemontwikkelingtrajecten en het bieden van eenzelfde ontwikkel- en testbasis met deze testsimulator. Gebruik van een dergelijke simulator voor het ontwikkel- en testproces neemt niet weg dat er uiteindelijk toch een ‘echte' ketentest met de betrokken ketenpartners moet worden uitgevoerd. Echter, naast de voordelen in het voortraject, eerder ontdekken van fouten, afstemmingsproblemen en het oplossen daarvan, zal de echte ketentest een substantieel kortere doorlooptijd kennen en minder fouten bevatten. Dit resulteert in substantieel lagere kosten voor betrokken ketenpartners. Niet alleen zullen de betrokken professionals minder hoeven te wachten op andere ketenpartners, ook de projectrisico's kunnen beter worden beheerst.
Ik vrees dat het probleem toch nog wel een dimensie groter is dan Derksen schetst. In hedendaagse informatiemaatschappij spelen partners niet zozeer een rol in een stabiele k?ten; ze spelen tegelijkertijd rollen in meerdere onderling afhankelijke en ook veranderlijke (!) ketens. En dat noemen we een… netwerk!
De keten is inmiddels achterhaald. En een veranderlijk netwerk is kwalitatief anders dan stabiele keten. Om die reden moeten er dan ook heel andere potjes op het vuur komen. En die zullen het testen grondig beinvloeden. En niet alleen het testen – vrees ik. Het wordt tijd voor informatie-infrastructuur als enkelvoudige informatievoorziening voor een veelheid aan wisselende keten – ooops – netwerkpartners.