Skip to content

Lean Validatie – Stap 7: Gebruik wijzigingsbeheer

15 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 7: Gebruik wijzigingsbeheer
Een efficiënt change managementproces dat naadloos integreert met het configuratie managementproces is onontbeerlijk om een systeem in een gevalideerde staat te houden. Onbeheerste wijzigingen aan het systeem vormen de grootste bedreiging voor een gevalideerd systeem. Validatieresultaten hebben namelijk betrekking op een bepaalde systeemconfiguratie, inclusief de instellingen en de beschreven toepassing. Verandert er iets aan de configuratie of aan de wijze waarop het systeem wordt gebruikt, dan kan niet zonder meer worden aangenomen dat het systeem nog geschikt is voor de toepassing. Configuratiebeheer zorgt voor het handhaven van de consistentie van de systeemsamenstelling en de systeemprestaties (de functionele en technische kenmerken) met het operationele doel. Ook als een systeem voor een ander doel wordt toegepast is de geschiktheid niet impliciet. Op zijn minst moet aan de hand van een risico-analyse de noodzaak voor een validatie van de wijziging worden verantwoord.

GAMP5 beveelt de volgende volgorde aan:

  • Beschrijf de voorgestelde wijziging, inclusief het beoogde doel van de wijziging
  • Beschrijf de gevaren met betrekking tot de geschiktheid van het systeem en evalueer bijbehorende risico’s
  • Stel vast welke testen moeten worden uitgevoerd om vast te stellen dat het doel van de wijziging wordt bereikt en dat de risico’s verwaarloosbaar zijn
  • Sluit het wijzigingstraject af wanneer de validatietesten de effectiviteit van de verandering hebben aangetoond, dat wil zeggen, het beoogde doel van de wijziging is bereikt met blijvende geschiktheid van het systeem.

Validatie van een systeem is dus geen eenmalige gebeurtenis. Validatie strekt zich vanaf de commissioning tijdens ontwerpfase uit tot de decommissioning aan het einde van de levensduur van het systeem. Gedurende de levensduur moet met enige regelmaat worden vastgesteld of het systeem hervalidatie of een aanvullende validatie behoeft. De volgende vragen moeten worden gesteld om de validatiebehoefte te bepalen:

  • Is sinds de voorgaande validatie het systeem of de toepassing gewijzigd?
  • Zijn er veel minimale wijzigingen geweest, die afzonderlijk geen reden voor hervalidatie zijn, maar in hun gezamenlijkheid wel een validatiebehoefte creëren?
  • Zijn perifere (indirect impact) systemen die invloed hebben op het functioneren van het systeem gewijzigd?
  • Is nieuwe informatie over het functioneren of de risico’s van het systeem beschikbaar die niet is meegenomen in de opzet van de oorspronkelijke validatie?
  • Zijn er de laatste tijd veel of meer productafwijkingen die kunnen worden toegeschreven aan het systeem?

Het is belangrijk om de eindgebruiker te informeren over het hoe en waarom van wijzigingsbeheer. Ik heb niet zelden meegemaakt dat nog voordat een systeem formeel werd vrijgegeven voor gebruik, de PLC software alweer was gewijzigd, beveiligingen werden verbroken of mechanische regelingen werden aangepast. Het betrekken van de eindgebruiker bij het uitvoeren van de PQ helpt om dit bewustzijn te creëren. Daarnaast wordt tijdens de PQ de werkelijke situatie getoetst. Die is vaak minder ideaal dan verondersteld door het validatieteam.

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: