Hoe bewaak ik de consistentie tussen uitgevaardigde wet of business rule en de implementatie daarvan in mijn organisatie
Wetswijzigingen , wijzigingen in de dienstverlening of in producten leiden impliciet tot veranderingen in bedrijfsprocessen en hun IT systemen.
Hoe gaan we daar mee om nu de veranderingssnelheid toe blijft nemen ?
Met transparantie bedoelen we hier: inzicht in zowel de besluitvorming als de uitvoerende processen en tussenproducten en de kwaliteit daarvan. Hoe komen bij een project de besluiten tot stand. Welke besluiten zijn waar, door wie en waarom en wanneer genomen en op welke wijze zijn of worden genomen besluiten geïmplementeerd. En hoe is of wordt gecontroleerd of e.e.a. compliant (conform de voorschriften) is en of het doet waar het voor bedoeld is.
Hoe eerder verkeerde besluiten aan de orde komen hoe minder ICT-faalkosten. Hoe minder schade.
Hoe maken we een en ander transparant? Door verslaglegging van bestuursbesluiten, vergadernotulen en besprekingsverslagen op gestructureerde wijze vast te leggen en toegankelijk te maken. Dit geldt ook voor de verslagen van de voortgangsvergaderingen van de operationele bedrijfsprocessen die duidelijk maken waarom bepaalde beslissingen zijn genomen en wat de doelen waren op het moment van besluitvorming.
Dit kan eenvoudig met elk DMS (Document Management System) gerealiseerd worden, als dat al niet het geval is.
Het wordt pas echt transparant als er ook functionaliteit wordt toegevoegd en gebruikt om de relaties te leggen tussen de verschillende documenten, die in de tijd een spoor vormen.
Dit kan op allerlei manieren en is vrij eenvoudig te implementeren. Dan zijn we een stapje verder. Gaan we nog een stapje verder dan leggen we ook de relatie van een aantal kwaliteitsdocumenten vast. De lokaal gehanteerde systeemontwikkelmethode is daarvoor de leidraad. Voorbeelden van kwaliteitsdocumenten zijn bijvoorbeeld: Het Plan van Aanpak, de Business Case, de Functionele Specificatie, een Change Request, een Change, de Testset, het Acceptatietestplan etc. Goed versiebeheer is hierbij een belangrijk issue. Als wijzigingen chronologisch traceerbaar zijn, zijn we al een belangrijk stap verder.
Op deze wijze kun je het proces een stuk transparanter maken. Gaan we nog een stap verder dan koppelen we ook de opgeleverde, gebouwde deelproducten aan elkaar en aan de genoemde kwaliteitsdocumenten. Zodat de relaties tussen alle producten en hun specificaties zichtbaar zijn. Een stapje verder nog en we voegen functionaliteit toe om vanuit elk punt te zien wat de herkomst is en wat de gevolgen zijn geweest. Daarmee wordt dan een betere traceerbaarheid gecreëerd waarmee je ook voor toekomstige wijzigingen impactanalyses kunt uitvoeren. De kosten, benodigde inspanning, doorlooptijd en planning voor elke verandering zijn dan veel nauwkeuriger en veel eenvoudiger van tevoren vast te stellen.
Traceerbaarheid is het enige wapen om in de toekomst sneller en beter en nauwkeuriger aan te geven wat er moet gebeuren en wat het kost en hoeveel tijd het kost om wijzigingen te implementeren.
Als je dit niet implementeert, dan zal je in de toekomst geen enkele verbetering in kwaliteit en betrouwbaarheid en planbaarheid van informatiesystemen gaan zien. Net zoals we dat de afgelopen 20 jaar niet gezien hebben. Een en ander is natuurlijk ook het gevolg van de steeds sneller veranderende digitale wereld. Traceerbaarheid invoeren of verbeteren is een van de sleutels om tot meer kwaliteit en geloofwaardigheid van de ICT te komen. Hier geldt dat stapsgewijze verbetering plaats kan vinden, door te beginnen op de plaatsen waar het gebrek aan traceerbaarheid een belangrijke oorzaak is van knelpunten, vertragingen en kostenverhogingen.
Bij veranderingen aan bestaande applicaties is het bepalen van welke programma’s moeten veranderd worden soms een puzzel. Het is dus essentieel om te weten, welke functionaliteit precies waar in welke programma s zijn geprogrammeerd.
Hier komt het belang van de kwaliteit van de oorspronkelijke specificaties naar voren. Hoe gestructureerder en hoe eenduidiger de oorspronkelijke specificaties, des te eenvoudiger is vast te stellen wat er precies veranderd moet worden. Het helpt aanzienlijk als ook het wijzigingsvoorstel een eenduidige structuur heeft en liefst overal hetzelfde is. Traceerbaarheid aanbrengen begint voor wat het ICT-voor- traject betreft dus met structuur in je specificaties.
We pleiten niet om de boel op de kop te zetten, maar om in elk geval voor nieuwe analyses en ontwerpen gelijke structuren te gebruiken die traceerbaarheid vereenvoudigen.
Voor bestaande applicaties kun je bijvoorbeeld een eenduidige structuur aanbrengen in de oude specificaties en deze koppelen aan de bijbehorende verzameling wijzigingen die in de tijd hebben plaatsgevonden. Het is evident dat dit interessanter is voor applicaties die vanuit hun aard hoogfrequent veranderen, dan voor applicaties die nooit of bijna nooit veranderingen te verwachten hebben vanuit wetgeving of andere externe invloeden. Voor geheel verouderde applicaties die onderhevig zijn aan veel wijzigingen zou je in eerste instantie een vorm van re-engineering van alle specificaties kunnen overwegen… Of als dat niet helpt re-engineering van het geheel.
E.e.a. kan met beperkte aanpassingen van de informatiesysteem-ontwikkelmethode worden geïmplementeerd.
In het ideale plaatje van traceerbaarheid zijn documenten uit de business en business-analyse-fase te koppelen aan functionele specificaties en use-cases. Terwijl vanuit functionele specificaties en use-cases verbanden gelegd zijn met, database items, programmatuur, testsets, bevindingen, change requests en database changes.