Írta: Hóringer Tamás
2018. december 10. 17:22:38 CET
A témában szolgáltatást nyújtó piaci szereplőként, számos megkeresést, felkérést kapunk olyan partnerektől, akik számára ugyan nem idegen a minőségirányítási rendszer, ezen belül a validáció fogalma, de ennek IT aspektusaival eddig nem, vagy csak érintőlegesen foglalkoztak. Az ok egyszerű: korábban ez a terület, főleg a konkrét elvárások, illetve az azokat ténylegesen ellenőrizni képes felügyeleti szervek hiányában, kívül esett az inspekciókon jellemzően felmerülő témák körén. Ezen felül, az infrastruktúra jellege, az IT/automatizált elemek aránya, a funkcionalitások összetettsége vagy az ebben tárolt/kezelt adatok hiánya - különösen a szektorban kis-, vagy közepes méretű szereplőként jelen lévő cégeknél - az esetek többségében minimálisra csökkentette ennek jelentőségét.
Ez azonban mára megváltozott. A digitalizáció hétköznapivá válásával, az ipar 4.0 vagy az IoT mind nagyobb térnyerésével, jelentősége egyre kevésbé marad el a bármely más, gyógyszergyártásban használt technológia esetén elvárt helyes gyakorlatnak való megfelelőség megkövetelésétől.
Az új helyzet új elvárásokat, újfajta igényeket szül. A tapasztalat az, hogy bár az érintettek egyre nagyobb többsége ismeri ezt fel, tényleges intézkedésre mégis leginkább csak akkor kerül sor, amikor egy lezajlott vagy közelgő hatósági vagy vevői audit okán ezt már elkerülhetetlenné válik. Általában ezen a ponton kapcsolódunk be az események folyamatába...
A vezetőség elkötelezettségének hiánya
Az erőforrás és az idő hiánya
Az átláthatóság hiánya
A szaktudás és/vagy a gyakorlat hiánya
A szabályzatok hiánya
Minden munkánk megkezdése előtt fel szoktuk tenni ügyfeleinknek a kérdést, hogy mi az a cél, amit el szeretnének érni. Sajnos, mivel a motiváló tényező az esetek szinte kizárólagos többségében valamely felügyeleti szerv korábbi észrevétele, vagy egy jövőbeli ellenőrzésen ennek elkerülése, ezért a megközelítés is általában az, hogy “írjunk pár oldalt, amivel a következő ellenőrzésen átmegyünk”. Ezzel az a baj, hogy a minőségbiztosításnak, a validációnak elsősorban következménye, nem pedig célja a - pejoratív felhanggal - egyszerűen papírgyártásnak aposztrofált dokumentáció. Tehát önmagában nem is lehet annak elsődleges mérőszáma még akkor sem, ha természetesen mind a túl-, mind az aluldokumentáltság állapota kerülendő. Lényegében a minőségbiztosítási szabványok mindegyike egy keretrendszer, ami azt határozza meg, hogy a folyamat milyen kontrollált lépések mentén halad, nem pedig azt, hogy ezt hányszáz oldalon kell dokumentálni. Egy szervezeten belül a megfelelően felépített minőségbiztosítási rendszer egyik alapköve, hogy a tulajdonostól kezdődően, az ügyvezetésen és a menedzsmenten át a gyártósor mellett dolgozó operátorokig mindenki tisztában van a (minőségi) célkitűzésekkel és elkötelezett azok teljesítésére vonatkozóan a saját területén.
Mit jelent ez a gyakorlatban? A minőségbiztosítás, természetéből adódóan sajnos idő és munkaigényes, ennélfogva mind bevezetés mind pedig fenntartás szempontjából jelentős, széles spektrumú erőforrásigénnyel bír, aminek biztosítása elsődlegesen a vezetés felelőssége. Ha ezen a szinten nem megfelelő a megközelítés, alsóbb szinteken ezt korrigálni, elvárni majdhogynem lehetetlen és nem is életszerű.
A vezetés részéről a legfontosabb, hogy felismerje és megértse a validáció jelentőségét, ezt tudatosítsa a szervezet valamennyi érintett tagjával és lehetővé tegye, hogy az egyes szinteken az ehhez szükséges tevékenységeket hatékonyan el tudják végezni. Mindennapos, hogy tanácsadóként egy olyan szervezeti egység (pl.: IT/OT üzemeltetés, mérnökség, stb.) munkáját kell(ene) támogatnunk, amelynek feladata és szinte kizárólagos prioritása az üzemvitel fenntartása. Olyanokra, akik munkájuk jellegénél fogva eleve feszített tempóban, állandó, dedikált rendelkezésre állással, végrehajtóként azon kell dolgozzanak, hogy a termelés zavartalan, annak feltételei műszaki szempontból adottak legyenek. Mindezt úgy, hogy erre további erőforrás nem biztosított. Ez a felállás nemcsak eleve magában hordozza, de tulajdonképp evidenssé teszi, hogy a tényleges munkát végzők tehertételként és nem lehetőségként kezelik a projektet, amelynek egyetlen célja, a lehető legkevesebb - erőforrásként nem létező, hiszen eleve máshová allokált - idő és energiaráfordítással “legyártani néhány papírt”.
Nem meglepő ezek után, ha az említett kollégák - különösen a kezdeti időkben - nem igazán partnert, sokkal inkább olyan kibicet látnak bennünk, akikkel felsővezetői döntés értelmében kénytelenek együtt dolgozni, akik kívülállók és akiknek a tevékenysége kizárólag plusz feladatokat ró rájuk. Mivel egy külsős partner nyilvánvalóan csekély rálátással rendelkezik a helyi sajátosságokra és az érintett rendszerekre vonatkozóan, a “No data, no headache!” elv alapján igyekeznek az információ-megosztást a minimálisan szükségesre korlátozni. Ezzel egyrészt drasztikus mértékben rontják a projekt sikeres kimenetelének esélyét, hiszen induláskor mi csak azokkal a tényekkel tudunk számolni, azok figyelembe vételével tudunk javaslatokat tenni amelyről tudunk. Másrészt adott esetben megsokszorozzák a saját munkájukat, mert a tapasztalat az, hogy a munka előrehaladtával előbb-utóbb fény derül a korábban elhallgatott részletekre és ez sokszor olyan stratégiai kérdéseket is érint, amelyek a projekt egyes szakaszainak megismétlését vonják maguk után. Akár az egyik, akár a másik tényezőt tekintjük, könnyen belátható, hogy a magán a végeredményen felül végső soron mindkét esetben a hatékonyság látja ennek leginkább kárát.
Nem egyszer rendkívüli technikai tudású mérnökökkel van módunk együtt dolgozni és a projekt során mi is minden esetben folyamatosan tanuljuk az adott cégre és gyártási technológiára, valamint az alkalamzott műszaki megoldásokra vonatkozó sajátosságokat. Az ügyfél oldaláról a nehézséget általában az okozza, hogy azon szakértők, akik az informatika és automatizálás tekintetében kellő műszaki szak- és helyismerettel rendelkeznek, az esetek többségében a validációval előzőleg nem, vagy csak egészen minimális mértékben kerültek kapcsolatba. Így a helyes validációs/dokumentációs gyakorlat sokszor ismeretlen terep, amelynek írott és íratlan szabályait a projekt során el kell sajátítaniuk. A projekt előrehaladtával egyre nagyobb rutinra tesz szert ennek alkalmazásában az ügyfél, ezzel párhuzamosan, ha az előző pontban említett bizalmatlanságból adódó nehézségeket sikerül leküzdeni, mindinkább belelátunk mi is partnerünk rendszereibe, értjük és látjuk annak összefüggéseit, így kialakul egy egymás preferenciáit ismerő és elfogadó, a másik fél erősségeit hatékonyan felhasználó kooperatív munkakapcsolat.
A multinacionális világcégek túlnyomó többsége saját, a regionális és nemzetközi előírásokkal konform, az IT / Automatizált rendszerek életciklusát és validációját teljes egészében lefedő belső politikával és komplett szabályzattal rendelkezik. Ez általában nemcsak az elvárt tevékenységekre, hanem azok végrehajtásának módjára is konkrét direktívákat tartalmaz. Az ezek felett végzett munka során szinte minden, a validációs stratégia szempontjából lényeges szempont illetve maga a tervezés folyamata is leegyszerűsödik. Legtöbbször elégséges ezek hivatkozása mellett konkrétan a megközelítést és az elvégzendő/elvégzett tevékenységeket dokumentálni, nincs szükség egyenként azok céljának és a validációs stratégiában elfoglat szerepének ismertetésére. Ezzel szemben azoknál a cégeknél, akik korábban ezzel a területtel nem foglalkoztak, ezek, kevés kivételtől eltekintve mindig hiányoznak és az erőforrások, főként az idő hiánya miatt előzetes (vagy akár projekt közben történő) létrehozására nincs reális esély. A legsúlyosabb probléma, hogy a bejáratott eljárásrendek mellett számos olyan feladat-, szerep- és felelősségi kör, melyet egyébként általában a QMS vonatkozó területei definiálnak, hiányzik. A tapasztalat az, hogy ezek egy része “papíron” a projekt keretén belül is létrehozható, ugyanakkor ezek későbbi fenntartása, felügyelete, vagy más, hasonló belső projektekkel történő összehangolása szinte lehetetlen.
Ha csak egy tanácsot adhatnánk valamennyi leendő ügyfelünknek, az valahogy így hangzana: “Kezdjük az alapoktól! Inkább apróbb de megfontolt, tudatos, tervezett lépésekkel!” Az utolsó pillanatban, az alapok és egységes koncepció nélkül összeollózott validációs csomag jó eséllyel csak kérdéseket és kételyeket fog ébreszteni egy ellenőrzés során, amelyekre, pont az előzőekben felsorolt okokból kifolyólag senki nem tud majd hihető, konzekvens, racionális válaszokat adni. Egy átgondolt, következetesen összeállított, az egységes szerkezetre törekvő rendszerben a hibák a legtöbbször korrigálhatóak, a hiányosságok pótolhatóak, a szabályzottság, a kontroll foka pedig skálázható.
