Skip to content

Lean validatie – Stap 5: Gebruik wetenschappelijke testmethodes

10 september 2014

validatie
Validatie wordt gezien als een tijdrovende activiteit en dat is het ook. Maar vaak wordt de validatie niet zorgvuldig uitgevoerd en levert de validatie niet de informatie die later van groot nut kan zijn. Daarmee wordt validatie een tijdrovende verspilling. Het belangrijkste voordeel van een transparant Lean Validatie proces is dat verspilling tot een minimum wordt beperkt. Lean Validatie bevordert een wetenschappelijk en data-gedreven proces met een preventieve aanpak van kwaliteitsproblemen en een proactieve beheersing van alle risico’s en onzekerheden.
In deze blogserie ga ik in op het efficiënt en effectief plannen, uitvoeren en rapporteren van validatie. Het maakt daarbij niet uit of het om validatie van productiesystemen, voorzieningen (utilities) of geautomatiseerde systemen gaat. Om tot een transparante organisatie van de validatie te komen moeten de volgende stappen worden gemaakt:

Ken het systeem
Ken de risico’s
Gebruik het ontwikkelproces
Gebruik de leverancier
Gebruik wetenschappelijke testmethodes
Gebruik de overdracht
Gebruik wijzigingsbeheer

Stap 5 Gebruik wetenschappelijke testmethodes
Alle eisen en specificaties die na het volgen van stap 1 en 2 als relevant zijn geïdentificeerd, moeten tijdens de validatie worden getoetst. Hiervoor moeten testmethodes worden gedefinieerd. Het valideren van de hypothese dat een productiesysteem geschikt is voor het beoogde gebruik vereist een door wetenschappelijke methode verkregen bewijs. Goede analytische vaardigheden van vakexperts zijn vereist om ervoor te zorgen dat de systeemeisen en -specificaties volledig en juist worden getoetst. Zorg voor de inbreng van individuen met kennis van het specifieke product, het proces, de technologie, statistiek, kwaliteitsmanagement en regelgeving.

Pas wetenschappelijk denken toe bij het nemen van logische en verantwoorde besluiten tijdens het opstellen van de testprotocollen. Validatie vraagt om een koppeling van wetenschap en techniek. Een aantal fundamentele definities kunnen je helpen bij deze koppeling:

  • Hypothese is een veronderstelling op basis van ervaring of eerdere waarneming waarvan nog bewezen moet worden dat het juist is.
  • Bewijs is het beschikbare geheel aan feiten of informatie die aantoont of een hypothese waar of geldig is.
  • Testen is een procedure voor het verzamelen van bewijs.
  • Validatie is het geldig verklaren van de hypothese.
  • Wetenschap is een intellectuele en praktische activiteit die de systematische studie van hypothesen door middel van observatie en experiment omvat.
  • Engineering is de tak van wetenschap die zich bezighoudt met het ontwerp, de bouw en het gebruik van apparatuur, machines en constructies.

De definities geven aan dat het verzamelen van (gedocumenteerd) bewijs een essentiële activiteit is voor valideren. Vaak wordt gesteld dat we met valideren voor veel geld vaststellen wat we al wisten. De feiten leren ons echter dat wat we voor waar hielden slechts onterechte aanames waren. In de praktijk is de informatie te omvangrijk en te complex om nog volledig te overzien. Vanwege eigenbelang kijken we ook selectief en zien we alleen wat we hopen te zien. Vandaar wordt het verzamelen van de feiten vooraf geprotocolleerd, om zo op systematische wijze alle en voldoende gegevens te verzamelen om gedegen besluiten te nemen ten aanzien van de geschiktheid van het systeem.

Het is essentieel voor het succes van de validatie-inspanning dat het testproces goed wordt begrepen. Zorg ervoor dat de testscripts in het protocol zijn geschreven in een beknopte, correcte en ondubbelzinnige taal. Bespreek de testen met degenen die ze moeten uitvoeren, zodat zij de essentie van de test begrijpen. Zeker als de testen worden uitgevoerd op systemen die nieuw zijn voor de eindgebruiker, zullen zich onherroepelijk onverwachte situaties voordoen. Als de uitvoerders niet worden begeleid of onvoldoende op de hoogte zijn gebracht van de noodzaak van elke test, kun jij niet verwachten dat zij gepast zullen reageren op die bijzondere situaties.

De elementen van een testscript omvatten het volgende:

  • Inleiding: context en doelstelling van de test(en);
  • Randvoorwaarden voor het uitvoeren van de test(en) of veronderstellingen;
  • Koppeling naar de gebruikerseisen of functionele en technische specificaties;
  • Een korte beschrijving van de testmethode: een testscript met specifieke stappen die de uit te voeren handelingen beschrijven;
  • Voorzieningen voor het vastleggen van de resultaten;
  • Verwachte resultaten van het script en acceptatiecriteria voor de test;
  • Voorzieningen voor het per stap of test vastleggen van het oordeel: systeem voldoet wel of niet aan gestelde eis.

Daarnaast moet het protocol een verantwoording geven van de gekozen aanpak; zowel van de testmethode als de gekozen steekproef. Welke testmaterialen (monsters) worden gebruikt in het protocol en voor welke producten zijn zij representatief. Vormen zij een worst case scenario, of is er sprake van gelijkwaardigheid van testmaterialen om de functionaliteit aan te tonen. Is voldoende onderbouwd dat de grootte van de steekproef voldoende is om een wetenschappelijke, statistische uitspraak te doen over de geschikheid van het systeem?

Voor het opstellen van protocollen hebben de meeste bedrijven een sjabloon of template, of meerdere voor verschillende protocoltypen, beschikbaar. Deze sjablonen hebben als doel het opstellen van protocollen te ondersteunen, maar in veel gevallen doen zij slechts afbreuk aan de oorspronkelijke bedoeling van Lean Validatie: de energie gaat naar het correct invullen van het sjabloon in plaats van naar het aantonen of het systeem geschikt is voor het beoogde gebruik. De sjablonen lijken maar steeds om meer informatie te vragen in een schijnbare poging om alle bijzondere situaties te kunnen ondervangen. Sommige templates vereisen welhaast een handleiding om het goed te kunnen invullen! Dergelijke sjablonen schakelen het wetenschappelijk denken volledig uit en behandelen de validatie als operationele activiteit. Omdat elk systeem en zijn toepassing uniek is, is het aantal mogelijke bijzondere situaties eindeloos. Er is dus helemaal geen hoop op een perfecte template.

“Perfectie is niet bereikt als er niets meer is toe te voegen, maar is bereikt als er niets meer is weg te laten”. Dit citaat van de Franse schrijver Antoine de Saint-Exupery is het fundament van de lean aanpak van validatie.

Ook lijkt de review van de protocollen en rapporten zich te richten op de consistentie met de template: zijn alle paragrafen aanwezig. De wetenschappelijke inhoud wordt minder beschouwd. Vaak is uit een validatierapport niet eens te halen welk systeem voor welk gebruik en met welke instellingen is beoordeeld. Zelfs een simpele verwijzing naar een systeem asset ID en het werkvoorschrift ID (inclusief revisie) ontbreekt. Dergelijke rapporten zijn bij latere raadpleging volledig onbruikbaar als bewijs voor geschiktheid en dus een volledige verspilling van tijd, geld en energie.

Advertenties

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s

%d bloggers liken dit: