Hogyan (ne) validáljunk? - 1. rész: Ki írja az URS-t?

Beruházói oldalról gyakran felmerül kérdésként, mi is tulajdonképp a validáció, van-e egyáltalán valós haszna, miért és milyen mélységig kell elvégezni. Számos szakkönyv, segédlet és szabvány tárgyalja a validációt, annak módjait és menetét. Mi ehelyett mégis azt szoktuk javasolni a mérnök kollégák számára, hogy egy csésze tea mellett beszélgessünk kicsit arról, ki mit ért egy rendszer fejlesztése, kivitelezése és használata során a mérnöki, beruházói, felhasználói oldalról szükséges tevékenységek alatt.

Emellett áttekintjük azt is, hogy hogyan érdemes meghatározni a feladatokat és a hozzájuk tartozó felelősségeket, valamint, hogy hogyan győződhetünk meg azok megtörténtéről és hogyan rögzíthetjük az eredményeket. A beszélgetés végére az esetek túlnyomó többségében eljutunk arra a pontra, ahol a partner maga jelenti ki, hogy tulajdonképpen ez nem sokban különbözik attól a gondolatmenettől - sőt jó esetben gyakorlattól - amelyet egyébként is alkalmaznak, az eltérés pedig sokkal inkább a terminológiában és a szigorú, precíz dokumentációs fegyelemben semmint a végrehajtott lépésekben keresendő. Ennek az egyszerű ténynek a felismerése kulcsfontosságú a projekt életciklusa szempontjából, hiszen így mindkét oldal látja és elfogadja annak létjogosultságát, sőt igényli a végrehajtását.

A validáció ugyanúgy keretbe foglalja és végigkíséri egy rendszer életciklusát, ahogy jó esetben a hozzá tartozó műszaki vagy épp üzleti dokumentáció, kezdve az igények megfogalmazásától, azok megvalósításának módján keresztül a használatig, majd végül a valamikori leselejtezésig. A validáció - akárcsak azon minőségbiztosítási rendszer, melynek része - egy eszköz, amelynek hatékonysága alapvetően függ az azt használó(k) szaktudásától és elkötelezettségétől. Tévesen, kellő szakismeret hiányában értelmezve és/vagy alkalmazva sokszor nem több, mint aminek sajnos a felhasználói oldalról a legtöbben látják: céltalan bürokratizmus.

Több részesre tervezett cikksorozatunkban az előírások és paragrafusok felsorolása helyett, igyekszünk gyakorlati szempontból, a teljesség igénye nélkül áttekinteni, miként áll és állítható párhuzamba egy élő rendszer tervezése és üzemeltetése során alkalmazott (mérnöki) gyakorlat a helyes minőségbiztosítás elméletével - “science and risk based” megközelítés mellett.

Ki írja az URS-t?

A referencia, amely összegzi a rendszerrel kapcsolatos elvárásokat a Felhasználói Igény Specifikáció, vagy URS (User Requirement Specification), mely a műszaki megvalósítás mellett alapját képezi a rendszerrel kapcsolatos valamennyi tevékenységre vonatkozó elvárás meghatározásának és ilyen módon a validációnak is. Joggal mondhatjuk, hogy az egyik legfontosabb dokumentum, amely a tervezett rendszer életciklusa során készül, mégis ennek jelentőségét szokták a leginkább alábecsülni, melynek eredménye legtöbbször a készítés feladatának ide-oda delegálása, majd ebből következően az általában minden szempontból elégtelen tartalom.

Az igény megszületésével jó esetben egy időben induló változáskövetési eljárás (Change Control) első lépései között szereplő projektindító megbeszélések egyik rettegett kérdése fejezetünk címe, melyre következő jellemző válaszok szoktak születni:

Üzem: “Írja X.Y., a múlt héten lépett be, a géphez még nem ért, a gyártás során nem vesszük hasznát.”

A lehető legrosszabb megoldás, sok esetben ennél már az is jobb, ha nem születik ilyen dokumentum. Egy gyógyszergyárban, azon belül egy termelőegységben történő munkavégzés számos olyan ismeretet kíván, amelynek pusztán elméleti úton történő elsajátítására nincs mód. A helyi sajátosságok, a gyártástechnológiához tartozó tipikus problémák, a rendszer adott környezetbe illesztése, a munkamódszerek ismerete - és a felsorolás hosszasan folytatható - mind olyan tényezők, melyek elsősorban a gyakorlat során ismerhetőek meg. A helyzetet tovább bonyolítja, hogy a minőségbiztosítási rendszer korábban már említett helytelen alkalmazása miatt - melynek sok esetben szintén a humán erőforrás hiányából adódó feladatdelegálás az oka - ezen dokumentumok teljes megírását a termelőegység dolgozóira, mint egyedüli felhasználónak kikiáltott szereplőre bízzák. Ennek eredménye aztán az, hogy a KPI mutatókat tartani igyekvő, munkaerőhiánnyal küzdő műszakvezető, a gyártósor mellé frissen felvett, betanulási időszakát töltő pályakezdő részére adja ki azt a feladatot, amelyet ideális esetben a helyes gyártási gyakorlat írott és íratlan szabályait, fogásait a leginkább ismerő, harminc éve a gyárban dolgozó operátor tudása alapján kellene összeállítani, vagy összeállíttatni.

Beszerzés: “Majd megírja, aki megnyerte a projektet.”

Az URS dokumentumot sokan - tévesen - kizárólag a gyógyszeripari minőségbiztosítás specifikumának tekintik, holott ez maximum az elnevezésre igaz. Bármely más iparág esetén általános, hogy egy új rendszer beszerzésének pályáztatásához szükséges megadni azon paramétereket, elvárásokat amelyek alapján a kivitelezők ajánlatot tudnak tenni a projektre. Az egy mondatos, “Kell egy autokláv.” típusú igények alapján születnek azok a műszaki szempontból össze nem hasonlítható, konkrét elvárások hiányában beruházói oldalról kiértékelhetetlen ajánlatok, melyek eredményeképpen kizárólag pénzügyi szempontok alapján hozott döntéseket követően, egy, a felhasználói igényeket jó esetben is csak részben teljesítő, deviációk és CAPA (Corrective Action / Preventive Action) intézkedések egész sorát maga után vonó rendszerek kerülnek megvalósításra.

Üzem, technológusok: “Mi nem villamosmérnökök vagyunk, írja meg a mérnökség, milyen gépet akar.”

Egy dolog van, amit egy jó URS-nek mindenképpen tartalmaznia kell: az pedig a végfelhasználónak tekintett fél igényei a használattal kapcsolatosan. Számos esetben találkozunk olyan megoldásokkal, amelyekben egy általános dokumentumsablon első pár oldala tömve van az ilyen-olyan, törvényeknek, szabványoknak és ajánlásoknak való megfelelőségre vonatkozó előírások felsorolásával, sokszor ez anélkül, hogy az adott elvárás vagy előírás a megvalósítani kívánt rendszerre egyáltalán értelmezhető lenne, ugyanakkor arról, hogy miként is kívánja az azt üzemeltető fél használni, egy sor sem kerül bele.

A mérnök elsődleges és legfontosabb feladata, hogy a műszaki megoldások formájában válaszokat, megoldásokat adjon a felhasználó által megfogalmazott kérdésekre, igényekre. Az üzemi mérnökségen dolgozó mérnökök - értelemszerűen az iparági sajátosságokra való rálátás mellett - ugyanúgy mérnöki szemléletmódot alkalmazva állítják össze azt, mintha külsős mérnökök számára szerveznék ki. Az ő dolguk, hogy megértsék a végfelhasználók által támasztott követelményeket, szükség esetén megfogalmazzák vagy kiegészítsék ezek műszaki aspektusait, közvetítsenek a technológiát ismerő üzemi szakértő és a rendszert műszaki szempontból definiáló mérnök között, hogy a kérdésekre, igényekre adott válaszok valóban megfelelőek legyenek. A mérnöki szaktudás és tapasztalat hiánya egy projekt során biztos kudarc, megléte önmagában viszont még nem garantálja a megfelelő eredményt.

Egy rendszer megfelelő, gyors, hatékony, az elvárt paraméterek szerinti, ezzel egy időben megbízható és robusztus működésének megvalósítása számos kihívás elé állítja a mérnököt, mégis ezen kritériumoknak való megfelelés evidensnek tekinthető. Ezen felül a felhasználót egyetlen dolog érdekli, mely amellett, hogy visszavezet ezekre a tulajdonságokra, ki is egészíti azokat: milyen könnyen és hatékonyan lehet az adott berendezéssel dolgozni, milyen a felhasználói élmény, melyek együttesen alapvetően befolyásolják a termelékenységet. Ennek optimalizálása egyrészről a mérnök feladata, másrészről megköveteli a felhasználótól, hogy a projekt keretein belül átadja a mérnöknek a folyamat felhasználói szempontból alkotott mentális modelljét, melyet az aztán reprodukál az implementáció során és - ami legalább ilyen fontos - vizualizál a kezelő- és megjelenítő felületek kialakításakor. Ebben a folyamatban az üzemi mérnök legfeljebb közvetítő szerepet tölthet be.

Mérnökség: “Az URS-t a felhasználó írja, semmi közünk hozzá.”

A felhasználó a saját területének szakértője és ideális esetben átfogó elméleti és gyakorlati tapasztalattal rendelkezik az általa végzett/felügyelt termelési folyamatra vonatkozóan, mely egy gyógyszergyár esetében legtöbbször vegyipari műveletek sokaságát foglalja magában, ennek okán pedig ezen személyek az esetek túlnyomó többségében vegyészmérnökök, biomérnökök, gyógyszerészek, akiktől a gépészet, a villamosság, az automatika és az informatika világa pont ugyanolyan messze áll, mint ezen szakágak képviselőitől az általa ismert terület. A felhasználó tudja mit akar elérni, de azt csak részben, vagy egyáltalán nem, hogy műszaki szempontból hogyan akarja, vagy hogyan akarhatja elérni. Melyek azok az elméleti és gyakorlati határok, melyek mentén az igényeket megfogalmazhatja? Mit várhat el és mit nem a tervezett berendezéstől, annak egyes elemeitől? Nincs tisztában azokkal a háttérinformációkkal, melyek egy új gép meglévő, üzemelő (műszaki) infrastruktúrába történő sikeres integrálásához kellenek. Nem beszéltünk a teljesség igénye nélkül a gazdasági / pénzügyi szempontok, a magasabb minőségbiztosítási irányelvek és egyéb, termelési szempontból csak nehézkesen, vagy egyáltalán nem belátható, ám arra közvetlen hatással bíró szempontok jelentőségéről, mely szintén kizárja, hogy az URS megírásának terhét egyedül a felhasználóra róják.

Üzem: “Nem írunk URS-t, nincs szükség rá. Ugyanolyan kell, mint a szomszéd gyártóegységben is van.”

Bár kisebb gépek esetén előfordul, mégis viszonylag ritka azon esetek száma, ahol valóban beszélhetünk két teljesen egyforma rendeltetésű, felépítésű és használat szempontjából is egyforma működésűnek tekinthető rendszerről. Az esetek túlnyomó többségében vannak eltérések, a megközelítésből adódóan pedig sajnos ezek lesznek azok a pontok, amelyeknek vagy azért nem tulajdonítottak jelentőséget, mert ezzel időt kívántak spórolni, vagy azért, mert eleve nem is vették azokat számba, mégis amelyek az első deviációkat eredményezik majd. Még egyenértékűnek tekintett rendszereknél is szükség van önálló URS kiadására, hogy a dokumentációs struktúra intakt, a rendszer, a projekt és a validáció pedig áttekinthető, követhető és számonkérhető maradjon.

Az URS összeállítása több terület aktív közreműködésével zajló folyamat, melynek nem kellő gondossággal történő végrehajtása a rendszer teljes életciklusára kihat, és olyan kihívások, megoldásra váró problémák elé állítja a projekt valamennyi résztvevőjét, melyek az igények helyes megfogalmazása mellett fel sem merülnének. Ezek megoldása egyaránt követel majd meg olyan anyagi és humán-erőforrás ráfordítást valamint igényli olyan kompromisszumok meghozatalát, melyek a gyártási folyamat körülményesebbé tétele mellett egy későbbi esetleges hatósági inspekció alkalmával igen nehéz perceket szerezhetnek az üzem, a management és a minőségbiztosítás számára is.

A gyógyszeripartól független mérnöki gyakorlatban a tervezést megelőző egyeztetések, bejárások, interjúk lefolytatása és dokumentálása éppúgy szerves részét képezik egy rendszer életciklusának, mint a GMP által meghatározott szigorú minőségbiztosítási követelmények mellett folyó fejlesztés esetén. Az egyedüli különbség ebben az esetben az ezeket strukturált és egységes formában összefoglaló dokumentum, az URS nevesítésében és megkövetelésében van.

Megjegyzés #1:

Cikkünk nem tér ki az URS kötelező és opcionális formai, tartalmi elemeire. A helyes dokumentációs gyakorlat szerinti felépítésre vonatkozóan számos, akár a világhálón is fellelhető cégünk által is alkalmazott segédlet illetve előírás áll az olvasó rendelkezésére.

Megjegyzés #2: 

A cikk eredetileg 2018. március  7-én jelent meg, melyet azóta frissítettünk, hogy aktuális legyen.