{"id":59,"date":"2026-05-01T20:38:32","date_gmt":"2026-05-01T20:38:32","guid":{"rendered":"https:\/\/qualityengineering.dk\/?p=59"},"modified":"2026-05-01T20:42:25","modified_gmt":"2026-05-01T20:42:25","slug":"skalerbarhed-stop-med-at-validere-alt-paa-samme-maade","status":"publish","type":"post","link":"https:\/\/qualityengineering.dk\/?p=59","title":{"rendered":"Skalerbarhed: Stop med at validere alt p\u00e5 samme m\u00e5de\u200b"},"content":{"rendered":"\n

\u200bVi har alle pr\u00f8vet det. Et projekt, hvor en mindre \u00e6ndring p\u00e5 et eksisterende anl\u00e6g udl\u00f8ser den samme store forkromede dokumentpakke, som hvis vi byggede en hel fabrik fra bunden.<\/p>\n\n\n\n

Vi k\u00f8rer slavisk igennem URS, DQ, IQ, OQ og PQ, selvom sund fornuft fort\u00e6ller os, at halvdelen af arbejdet ikke skaber nogen reel v\u00e6rdi for produktkvaliteten.\u200bDet er her, skalerbarhed kommer ind i billedet.\u200b<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Skalerbarhed er ikke bare et corporate buzzword til bullshit bingo. Det er evnen til at tilpasse valideringsindsatsen efter risiko, kompleksitet og sund fornuft.\u200b<\/p>\n\n\n\n

\n

Hvad er skalerbar validering egentlig?<\/p>\n<\/blockquote>\n\n\n\n

\u200bI sin kerne handler skalerbarhed om at turde differentiere. Vi skal holde op med at behandle en standardpumpe og en steril fyldelinje ens. For at skalere rigtigt, kigger jeg typisk p\u00e5 tre parametre:\u200b<\/p>\n\n\n\n

    \n
  1. Risiko<\/strong>: Hvor kritisk er systemet for patienten og produktet?<\/li>\n\n\n\n
  2. Kompleksitet<\/strong>: Er det en gennemtestet hyldevare (COTS) eller en specialbygget l\u00f8sning?\u200b<\/li>\n\n\n\n
  3. Modenhed<\/strong>: Er teknologien velafpr\u00f8vet og kendt i vores setup, eller er det en ny og umoden proces for organisationen?\u200b<\/li>\n<\/ol>\n\n\n\n

    Det giver en god id\u00e9 om, hvor grundigt og gennemtestet vores system skal v\u00e6re inden vi tager det i brug.<\/p>\n\n\n\n

    Den direkte vej: Fra design til performance<\/strong><\/h3>\n\n\n\n

    \u200bEn af de st\u00f8rste misforst\u00e5elser i den traditionelle valideringsverden er, at man skal igennem alle faser hver gang. I s\u00e6r IQ og OQ er favoritter. Men i en moderne, risikobaseret tilgang handler det om at v\u00e6lge den mest logiske vej for verifikation.\u200b<\/p>\n\n\n\n

    Og nogle gange er den mest effektive vej at g\u00e5 direkte fra design (DQ) til performance test (PQ).\u200b<\/p>\n\n\n\n

    Tag for eksempel en \u00e6ndring i et produktdesign. Hvis selve installationen og de basale funktioner p\u00e5 maskinen ikke er \u00e6ndret, hvad f\u00e5r vi s\u00e5 ud af en IQ og en OQ?<\/p>\n\n\n\n

    Ingenting<\/em><\/strong>. <\/p>\n\n\n\n

    Den reelle risiko ligger i, om det nye design performer som \u00f8nsket under faktiske driftsforhold. Her er PQ den eneste test, der reelt giver v\u00e6rdi og beviser, at vi er i kontrol. <\/p>\n\n\n\n

    Tilgangen er is\u00e6r egnet til medico virksomheder, der fremstiller medicinsk udstyr og for meget modne procesteknologier. Den duer ogs\u00e5 til GAMP kategori 1 og 3 software, som er standardvare. <\/p>\n\n\n\n

    \u200bPV er ikke standard: Det er en strategisk beslutning<\/strong><\/h3>\n\n\n\n

    \u200bDet samme g\u00e6lder for Process Validation (PV). Mange organisationer lider under den opfattelse, at enhver \u00e6ndring kr\u00e6ver en fuld PV. Men PV er en tung disciplin, der b\u00f8r reserveres til de tunge l\u00f8ft:<\/p>\n\n\n\n

      \n
    • \u200bEtablering af en ny fabrik eller produktionslinje.\u200b<\/li>\n\n\n\n
    • Indk\u00f8ring af nye produkter p\u00e5 eksisterende linjer.\u200b<\/li>\n\n\n\n
    • \u00c6ndringer, der direkte p\u00e5virker markedsf\u00f8ringstilladelsen.\u200b<\/li>\n<\/ul>\n\n\n\n

      Hvis vi “bare” opgraderer en komponent i en stabil proces med h\u00f8j modenhed, giver det sj\u00e6ldent mening at rulle det helt store PV-apparat ud. Her skal vi turde stole p\u00e5 vores tekniske verifikation og den l\u00f8bende overv\u00e5gning.\u200b<\/p>\n\n\n\n

      Kombinerede test: Mindre bureaukrati, mere verifikation\u200b<\/strong><\/h3>\n\n\n\n

      Skalerbarhed handler ogs\u00e5 om at fjerne de kunstige barrierer. For mindre komplekst udstyr giver det ingen mening at lukke \u00e9n protokol, vente p\u00e5 en godkendelsessignatur og derefter \u00e5bne den n\u00e6ste.\u200b Vi kan med fordel kombinere faserne (f.eks. en IQ\/PQ). Det handler om at dokumentere det som giver mening: “Vi har modtaget udstyret, tjekket installationen og verificeret, at det leverer varen under belastning.”<\/p>\n\n\n\n

      \u00c9n arbejdsgang, \u00e9n dokumentpakke, men samme (eller h\u00f8jere) sikkerhedsniveau.\u200b<\/mark><\/em><\/strong><\/p>\n\n\n\n

      Hvorfor kr\u00e6ver det autoritet at skalere?\u200b<\/strong><\/h3>\n\n\n\n

      Det er nemt at f\u00f8lge en fast skabelon. Det kr\u00e6ver ingen sv\u00e6re beslutninger at sige “vi g\u00f8r, som vi plejer”. Det er ogs\u00e5 nemmere i teorien, at tr\u00e6ne og uddanne, for alle skal kunne det samme.<\/p>\n\n\n\n

      Men i praksis bliver det tungt. Det har jeg selv pr\u00f8vet og resultatet bliver langsomme valideringsforl\u00f8b, hvor man fors\u00f8ger at passe den store pakke ned I en \u00e6ske, fordi den er for omfattende, eller uegnet til eksempelvis et ventilskifte. <\/p>\n\n\n\n

      Det kr\u00e6ver derimod faglig ballast og mod at sige: “Vi springer OQ over her” eller “Vi n\u00f8jes med PQ og laver ikke en ny PV”. Men det er netop her, vi flytter validering fra at v\u00e6re en administrativ stopklods til at v\u00e6re et v\u00e6rkt\u00f8j, der sikrer fremdrift og reel kvalitet.\u200b<\/p>\n\n\n\n

      N\u00e5r vi skalerer rigtigt, fjerner vi st\u00f8jen og fokuserer vores energi der, hvor risikoen rent faktisk er.<\/p>\n\n\n\n

      <\/p>\n","protected":false},"excerpt":{"rendered":"

      \u200bVi har alle pr\u00f8vet det. Et projekt, hvor en mindre \u00e6ndring p\u00e5 et eksisterende anl\u00e6g udl\u00f8ser den samme store forkromede dokumentpakke, som hvis vi byggede en hel fabrik fra bunden. Vi k\u00f8rer slavisk igennem URS, DQ, IQ, OQ og PQ, selvom sund fornuft fort\u00e6ller os, at halvdelen af arbejdet ikke skaber nogen reel v\u00e6rdi for […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,7],"tags":[],"class_list":["post-59","post","type-post","status-publish","format-standard","hentry","category-quality-risk-management","category-validering-og-kvalificering"],"_links":{"self":[{"href":"https:\/\/qualityengineering.dk\/index.php?rest_route=\/wp\/v2\/posts\/59","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/qualityengineering.dk\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/qualityengineering.dk\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/qualityengineering.dk\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/qualityengineering.dk\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=59"}],"version-history":[{"count":2,"href":"https:\/\/qualityengineering.dk\/index.php?rest_route=\/wp\/v2\/posts\/59\/revisions"}],"predecessor-version":[{"id":64,"href":"https:\/\/qualityengineering.dk\/index.php?rest_route=\/wp\/v2\/posts\/59\/revisions\/64"}],"wp:attachment":[{"href":"https:\/\/qualityengineering.dk\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=59"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/qualityengineering.dk\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=59"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/qualityengineering.dk\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=59"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}