De kunst van het valideren

Stel dat het bedrijf waarvoor u werkt, tests uitvoert. Het maakt hierbij niet uit of het gaat om geneesmiddelen, kunststoffen of voedingswaren. In alle gevallen is de workflow immers vrijwel identiek: materiaal komt binnen en wordt op basis van de uit te voeren procedures verdeeld in porties. Op deze kleinere porties worden dan verschillende tests uitgevoerd, die kunnen variëren in tijd en complexiteit. Uiteindelijk krijgt u uit deze tests data, die worden verzameld in een – hopelijk – centrale database. Van daaruit kunnen deze dan worden teruggestuurd naar de klant, in verschillende vormen zoals PDF en CSV. Het is aan u als ICT’er om ervoor te zorgen dat u aan de klant kunt aantonen dat de resultaten die u op deze manier produceert, ook zijn terug te vertalen naar de oorspronkelijk ontvangen materialen. Dus moet u zien te bewijzen dat wanneer u receptie hebt gedaan van materiaal, u dit kunt traceren door al uw businessprocessen heen, en dat u ook in staat bent om resultaten die uit verschillende computers komen, naar deze oorspronkelijke oorsprong terug te leiden.   

Testen, debuggen en valideren

U installeert nieuwe software in uw bedrijf of u schrijft een stukje nieuwe functionaliteit voor het intranet. Dan test u die natuurlijk. Bij voorkeur wordt software overigens niet door uzelf getest, want onbewust kunt u wel eens de échte addertjes onder het gras ontwijken. Na het testen volgt het debuggen. Vaak gaat het om randgevallen. Er dient een hoeveelheid te worden ingevoerd en de software loopt vast als er een negatief geval moet worden ingevoerd. Of: invoeren van de gebruikersnaam blijkt hoofdlettergevoelig te zijn, terwijl dit niet de bedoeling was. De code wordt aangepast. De installatie wordt opnieuw uitgevoerd. Dit scenario herhaalt zich een aantal keer totdat de software klaar voor gebruik wordt geacht. Validatie gaat dan nog een stap verder dan testen en debuggen. Het betreft hier het minutieus uitschrijven van een aantal testscenario’s, bij voorkeur gebaseerd op een eerder opgestelde User Requirement Specifications – URS – document. Vervolgens worden deze testscenario’s aan een derde persoon voorgelegd, die ze uitvoert en van elke stap screenshots maakt om formeel vast te leggen dat iets werkt zoals het is bedoeld. Soms wordt nog verder gegaan en worden screenshots afgedrukt, afgetekend en gedateerd, en weer ingescand. Dat dient dan als ‘bewijs’ dat het bedrijf er alles aan heeft gedaan om gevraagde functionaliteit goed op te leveren. De kwaliteit en leesbaarheid van de afgedrukte en opnieuw ingescande screenshots laten we dan even buiten beschouwing. 

Overhead en kosten

Het mag duidelijk zijn dat het systematisch valideren van al uw computersystemen en software op deze manier gigantisch veel tijd en overhead kost. Geschat wordt dat kwaliteitscontrole – QC – momenteel ongeveer twintig procent van alle resources van een bedrijf opslurpt. Dat moet u dan natuurlijk wel kunnen terugverdienen. Het is zeker voor kleinere bedrijven helemaal niet vanzelfsprekend om de steeds nieuwe reguleringen bij te houden. Grote bedrijven beschikken hiervoor over heuse ‘compliance’-afdelingen. Waarom is dat valideren nodig? Omdat de overheid graag regeltjes opstelt. Die zijn ook wel nodig: indien u naar de apotheek gaat voor antibiotica, dan wilt u er natuurlijk zeker van zijn dat er ook daadwerkelijk tetracycline of een andere actieve stof aanwezig is in de tabletjes die u koopt. En voordat een nieuw geneesmiddel of nieuwe voedingsstof op de markt komt, moet deze natuurlijk eerst uitvoerig worden getest en goedgekeurd. Het is ook wel duidelijk dat een klein leger aan consulenten, advocaten, lobbyisten en politici intussen flink verdient aan de kunst van het valideren. De vraag is dan ook of we intussen niet te ver aan het gaan zijn. Op een wetenschappelijk congres in Baltimore vorig jaar gaf een man van de Food & Drug Administration – FDA – een voordracht over digitale microscopie. Een arts verzuchtte vervolgens: “We regulate because we can” (we reguleren zaken nu eenmaal omdat we het kúnnen). Ze kreeg luid bijval van collega’s in de zaal. Recent is het ook een verzuchting van veel ICT’ers dat ze eigenlijk hun werk niet meer naar behoren kunnen doen, omdat er zoveel overhead bij hun dagelijkse taken komt kijken. Een installatie van een nieuwe server loopt maanden vertraging op, omdat deze eerst moet worden ‘gevalideerd’. Noodzakelijke installatie van nieuwe software wordt uitgesteld, omdat de inmiddels gevalideerde server hierdoor opnieuw moet worden gevalideerd. Alles moet tegenwoordig worden gelogd, auditeerbaar zijn en bij voorkeur ook nog eens zijn gedocumenteerd in ellenlange dossiers. Het mag duidelijk zijn dat dit niet bevorderlijk is voor de motivatie en soms zelfs tot een burn-out kan leiden. 

Errare humanum est

Bovendien is al dat validatiewerk maar beperkt nuttig. Het verhoogt om te beginnen de werkdruk, waardoor er minder tijd overblijft om de feitelijke taak uit te voeren. Er dreigen fouten te sluipen in activiteiten die worden gevalideerd, juist doordat deze worden gevalideerd. De zwakste schakel is uiteindelijk de persoon die de taak moet uitvoeren: de werknemer en de mens. De menselijke fout kunt u immers nooit helemaal uitschakelen. Stel dat het personeel in uw bedrijf staalnummers dient in te voeren. Een fout is natuurlijk snel gebeurd, en dus introduceert u barcodescanners. De scanner valideert zo op systematische basis dat een getal correct wordt ingescand. Er treden minder typfouten op, maar stalen kunnen nog steeds worden verwisseld, en in de supermarkt kan het nog altijd gebeuren dat iemand de verkeerde etiketten op een product plakt. Hoe lost u dit op? De IT kan hier maar tot een bepaald niveau meegaan… Er kan in de procedures worden ingebouwd dat er regelmatig dubbele controles worden ingebouwd (zaken opnieuw scannen bijvoorbeeld): indien er te veel fouten blijken op te treden na een bepaalde tijd, dan moet de procedure zelf mogelijk worden aangepast of zelfs helemaal op de schop. Het probleem met automatisering is dat u uiteindelijk ook mensen voor een stuk automatiseert. Een barcode inscannen vereist veel minder moeite dan een product oppakken en daarvan eventueel het identificatienummer moeten opzoeken. Hier is opnieuw een supermarktanalogie relevant: de persoon achter de kassa heeft geen manier – laat staan tijd – om nog te weten of de barcode die hij/zij inscant bij het blik bonen hoort, of bij de afgeprijsde rollen keukenpapier. Tot slot treedt ook apathie op, want de opdracht wordt nu niet langer gezien als het correct registreren van producten, maar wel het correct inscannen van barcodes. 

Loslaten

Een chemische test is relatief makkelijk te valideren. Voer deze twintig of desnoods vijftig keer uit, kijk of hetzelfde resultaat wordt verkregen – binnen een bepaalde foutenmarge -, documenteer en klaar! Met softwareontwikkeling is het anders gesteld: dit is een creatief proces dat we zelden twee keer op dezelfde manier doen. Een server installeren we maar één keer; een besturingssysteem wordt maar één keer ontwikkeld, enzovoort. Net zoals menselijke fouten zullen blijven bestaan, is het evenzeer een noodzaak om er op een bepaald moment vanuit te gaan dat het personeel dat aan een probleem, proces of product werkt, dit ook navenant wil en kan oplossen. Anders had u deze mensen toch niet aangenomen? Validatie is in onze ogen geen wetenschap, maar een kunst. Het is een balancing act. U moet het nodige voorzien om inspecties te doorstaan en geaccrediteerd te blijven voor de activiteiten die u uitoefent, maar tegelijkertijd is het ook van belang uw eigen personeel niet het gevoel te geven dat ze constant worden gewantrouwd. Communicatie is dan cruciaal. Wanneer duidelijk wordt waarom u valideert en waarom er controles zijn, zult u ook op meer begrip en hulp kunnen rekenen. Probeer het maar, uw jaarresultaten zullen u dankbaar zijn.