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 mégis azt szoktuk javasolni a mérnök kollégáknak, 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.

Ilyenkor á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 legtöbb beszélgetés végén úgy állunk fel, hogy a partner maga jelenti ki: 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 az a 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.

Az előírások és paragrafusok felsorolása helyett, igyekszem 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ó (angol terminológiával URS – User Requirement Specification), amely 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, és még nem ért a géphez, ezért a gyártás során nem vesszük hasznát."

Az a lehető legrosszabb megoldás, sok esetben már az is jobb, ha nem születik USR. Egy gyógyszergyárban, azon belül egy termelőegységben történő munkavégzés számos olyan ismeretet kíván, amit pusztán elméleti úton nem lehet elsajátítani. 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 (Key Performance Indicator) 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: a végfelhasználónak tekintett fél használattal kapcsolatos igényeit. 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 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 kudarcot hoz, ám megléte önmagában még nem garantálja a megfelelő eredményt.

Egy rendszer megfelelő, gyors, hatékony, az elvárt paraméterek szerinti, ugyanakkor 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ő. Ezenfelül a felhasználót egyetlen dolog érdekli, amely 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 folyamatról, amely 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ér-információkkal, melyek egy új gép meglévő, üzemelő (műszaki) infrastruktúrába történő sikeres integrálásához kellenek. (Most nem térünk ki  többek között 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ére, melyek szintén kizárják, 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 ami szomszéd gyártóegységben 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 USR egy nagy közös buli

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 olyan anyagi és humán-erőforrás ráfordítást követel meg, valamint olyan kompromisszumok meghozatalát igényli, 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 (Good Manufacturing Practice) á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: A cikkben nem tértem ki az URS kötelező és opcionális formai, tartalmi elemeire. A helyes dokumentációs gyakorlat szerinti felépítésről számos, a cégünk által is alkalmazott segédlet, előírás található akár a világhálón is.

A szerző informatikus mérnök, több éve dolgozik nagy projekteken a Com-Forth Kft.-nél architektként.