VEZETÉS- ÉS SZERVEZÉSTUDOMÁNY
Dr. Mezey Gyula
AZ ADATMINŐSÉG IRÁNYÍTÁSA A HADKÖTELES NYILVÁNTARTÁS TERÜLETÉN II.
AZ ELŐÍRT MINŐSÉG Nem feltétlenül szükséges kizárólag mutatószámokkal előírni a minőséget. Célszerű a számszerű minőségmérések összesítő eredményeinek és a nem-számszerű megállapítások szöveges értékelésének együttes alkalmazása. Ezenkívül el kell kerülni a szemellenzős, csak költségorientált könyvelői szemléletet. A minőségirányítás éppen arra jó, hogy a munkavégzés folyamatait értékelve, elemezve a vezetők felismerjék a problémákat, és képesek legyenek azokat ki is javítani. Kíséreljük meg elemezni a nyilvántartás ügyviteli munkafolyamatait. A munkafolyam a hadköteles-nyilvántartás esetén a „sorozatgyártás” jellegzetességeit mutatja, de ezt ugyanakkor az egyedi adattermékek fogadásának és kibocsátásának jellegzetességeivel ötvözi. Csaknem minden egyes adattermék egyedi: egyforma kérdések és egyforma válaszelemek vannak, de két teljesen egyforma összetett választ (mint adatterméket) csak ritkán lehet adni. Pl. a népességnyilvántartás egyes szolgáltatásait folytonos üzemben nyújtja, az ingatlannyilvántartás is tömegtermelő „iratgyár”, mégis minden ügy egyedi. Kisebb ügyiratforgalmú irodáknál a munkafolyam általában kevésbé strukturált, mint egy nagy „iratgyárban”. Az információs rendszer felfogható úgy, mint egy csatorna, amelyben iratok, mint elintézendő „munkadarabok” folyama áramlik. Ez a (lényegében ügyviteli) munkafolyam, amely a különböző adathordozókon levő munkadarabok szállítására alkalmas alcsatornákra bomlik. Egyazon „munkadarab” (pl. mint elektronikus adattermék) megjelenhet egyidőben akár mint pontos képi hasonmás, akár csak mint afféle „vetülete”, rövidített vagy kódolt karakteres kivonata egyszerre szinte valamennyi alcsatornában. A „munkadarab-vetületek” darabszám szerinti teljesség ellenőrzését egyazon „munkadarabra” vonatkozóan így az alcsatornák összetalálkozásánál lehet elvégezni, ezek fontos ellenőrzőpontok. Egy
ellenőrzőponton emellett még másféle ismérvek ellenőrzését is végezhetjük. Az alcsatornák elnevezése: papírfolyam, adatfolyam, képfolyam (de lehetne még jobban tagolni: pl. mikrofilmfolyam, kártyafolyam). ¨ A papíriratokról való képfelvételek áramlása alkotja a képfolyamot. Kiindulópontja a speciális célberendezéssel felvett képmás (image), végpontja a (központi) képi adatbázis (AB). ¨ A legalapvetőbb a papíriratok áramlása, ez alkotja a papírfolyamot. Kiindulópontja pl. a decentrumban kitöltött nyomtatvány, végpontja az archívum. ¨ A papíriratokról rögzített vagy géppel leolvasott adatok áramlása az adatfolyam. Kiindulópontja a decentrumban rögzített adatrekord, végpontja a (központi) strukturált AB.
A papírfolyamban áramló objektumok A papírfolyamban küldemények áramlanak. Egy küldemény több eltérő tárgyú iratot is magába foglalhat. Tipikus, hogy egyazon típusú iratokat küldenek egyszerre (pl. kitöltött nyomtatványköteg), és a papírfolyam zavartalan működésének vezérlését megkönnyítő kísérőirat (vagy lista) is része a küldeménynek. Tartalmilag számos esetben egy papír bizonylat egy ún. kapcsolat-előfordulásnak felel meg, viszont ugyanakkor egy n-ed rendű relációt hordozó fizikai objektum is. Azonban egy papírbizonylaton esetleg több, ún. logikai rekord is elhelyezkedhet (pl. javítólista, javítóbizonylat). Ritkán előfordulhat, hogy egy logikai rekordot több (pl. két) papírbizonylat hordoz (szegmentálás). Az alapnyilvántartásba jutó papírbizonylatok áramlása nem szinkronizált, azonban az áramlásban késleltetések és holtidős szakaszok is megjelennek. A papírfolyam áramlása nem gyorsabb, mint az adatfolyamé. A nagyvolumenű feldolgozások forrásbizonylatai leggyakrabban űrlapok, amelyek lehetnek: ¨ papíriratok, nyomtatványok (papírfolyam); vagy ¨ képernyő űrlapok, E-mailek (az adatfolyamban).
Az érdemi ügyintézés számára szükséges adatok áramoltatása mellett a forrásbizonylat még más funkciókat is betölthet, így pl. űrlap esetén: ¨ esemény előfordulásakor a rögzítendő adatok struktúráját megadja, így befolyásolható: — a kódolandó vagy rögzítendő adatoknak az iratra való felviteli sebessége és hibaaránya; — az iratra rögzített adatoknak a géppel való leolvasási sebessége és hibaaránya. ¨ vezérli a munkafolyamot, amennyiben adatai: — befolyásolják az ellenőrzést (pl. kötegteljesség ellenőrzését); — tájékoztatnak egy ügy állásáról, nyomon követhetővé teszik az ügyirat áramlását a folyamatban. Az űrlapokhoz kitöltési utasítás, valamint a kódolási hibaarány csökkentése érdekében gyakran egyes adatmezőkhöz input kódértékek tartoznak. A könnyebb nyomon követhetőség céljából az űrlapot egyedi bizonylat-azonosítóval látják el. Ha a forrásbizonylatokat — még pl. a nyomdában, de mindenesetre — kitöltésük előtt egyedi azonosítóval el nem látták, akkor külön eljárások szervezésére van szükség, hogy biztosíthassuk minden egyes kitöltött űrlap nyomon követését. Nyomon követhetőség nélkül viszont az adatgyűjtő-rendszer nem is lehet megfelelően ellenőrzött, hiszen e nélkül nem állapítható meg sem az, hogy valamennyi tranzakció[1] bejött-e, sem az, hogy esetleg ismételten is elküldték és újra beérkezett-e egy tranzakció. Az irathelyességet első közelítésben az irathitelesség ellenőrzésével állapíthatjuk meg. Papíriraton ezt a forrásbizonylaton, illetve a kötegelt forrásbizonylatok kísérőiratain szereplő aláírás(ok) és pecsét(ek) (esetleg illetékbélyeg stb.) vizsgálata jelenti.
Az adatfolyamban áramló objektumok Lehetséges, hogy a bizonylatról lerögzített adatrekordból több tranzakció (tranzakciócsoport) származik és áramlik tovább. A csoporton belül több egyazon típusú ilyen tranzakció is előállhat, de a tranzakciók típusa eltérő is lehet.
Előfordulhat olyan bizonylatfajta, amelynél sem azt nem lehet előre tudni, hogy egy lerögzített bizonylat adattartalmából hány input tétel (tranzakció) képződik, sem azt, hogy ezek mely tranzakciótípusba tartoznak majd. Akkor ezt a bizonylatfajtát célszerű átalakítani úgy, hogy közvetlenül rögzíthető legyen mindkét információ. A tranzakció-előfordulásokat típusuk szerint osztályozva, majd munkaadatállományokba (köteg) csoportosítva juttatják tovább az egyik ellenőrző ponttól (feldolgozástól) a másikhoz. A központi adatbázis egy karbantartási ciklusa alatt az újabb karbantartásra összegyűlt hibátlan input tételek alkotta adatállományt és a kísérő működésvezérlő információt dolgozzák fel. Az input tételeket ellenőrző eljárások célja, hogy biztosítsák: ¨ valamennyi releváns külső eseményről keletkezzen tranzakció; ¨ valamennyi tranzakció érkezzen be az adatgyűjtő rendszeren át; ¨ egy tranzakciót csak egyszer dolgozzanak fel, ismételt feldolgozásra ne kerüljön sor; ¨ a tranzakció adatai feleljenek meg a valóságnak (ami első közelítésben azt jelenti, hogy csakis hitelesített adattermékek kerüljenek feldolgozásra és tárolásra). Az adatfolyamot alkotó újabb és újabb input-tételek több ellenőrző-programon áthaladva, formailag és tartalmilag kifogástalannak bizonyulván a központi nyilvántartás (több különböző) adatbázisát frissítik. A bármely ellenőrző pontnál fennakadt input-tételeket azonban a bizonylatot elindító igazgatási szervnek (a bizonylatazonosítóra hivatkozva) hibalistán visszaküldik javítás és újra történő feladás céljából (javítóbizonylatok). Javítás csak javítóbizonylaton fogadható el.
A képfolyamban áramló objektumok A képfolyamban áramló objektumok egyrészt azokról az iratfajtákról készült felvételek, amelyek az alapnyilvántartás jelenlegi alapiratai, másrészt az alapnyilvántartásba addig beérkezett iratfajták képmásai. A képmás vagy közvetlenül a valóság egy objektumáról (pl. egy bizonylatról), vagy (áttételesen) a papírfolyam egy objektumáról bináris nagy adatobjektummá[2] átalakított kép. Már a felvételtől kezdve el kell kerülni a terjedelmes adatobjektumok kezelését. Ha a papírűrlap
keretvonalait ún. vakszínnel nyomtatjuk, és a képfelvevő eszköz azt nem is érzékeli, akkor eleve kevesebb adatot kell ezután eltárolni és kezelni. Az adatobjektumokat ezután még tömörítjük, így lényegesen kevesebb adatot kell ezután átvinni, tárolni. Véleményünk szerint a munkafolyam ellenőrzésének megtervezésén belül technikailag először a legnagyobb követelményeket állító képfolyam igényeire kell tekintettel lenni, ennek alárendelten kell kialakítani az adatfolyamot, mindkettő követelményeire tekintettel pedig a papírfolyamot. Azonban papírfolyamnak és a képfolyamnak van egy közös követelménye: ne vesszen el irat. Ez az (darabszám szerinti) iratteljesség követelménye és a jelenlegi hazai perrendtartás miatt döntően fontos. Hiába van ugyanis meg egy, az iratról rögzített adatrekord, ha nincsen meg az aláírt, lepecsételt eredeti papírirat, vagy legalább arról készült hiteles felvétel (képmás), mert ekkor az adatrekord jogvita esetén egymagában semmit sem bizonyít a bíróság előtt (nem okirat, nem hiteles). Az igazságszolgáltatási gyakorlat egyes országokban más, ott a hatóság által digitális pecséttel ellátott, a strukturált adatbázisban tárolt, majd kinyomtatott adatrekord is elegendő a lehet a bíróság számára, éppen ezért nincsen szükség pl. központi okmánytárak működtetésére, elegendőek a levéltárak, ami jelentősen leegyszerűsíti az országos alapnyilvántartások működését, részben megtakarítja költségeiket. Az ISO[3] 9001 előírja, hogy az egyedi termékeknek vagy tételeknek (szállítmányoknak) legyen egyedi azonosítója, ha a nyomon követhetőség előírt követelmény. Tekintetbe véve, hogy az irodai nyilvántartások vagy az okmánytárak tételei általában egyedi adattermékek, a megbízható működéshez elengedhetetlen, hogy a bevitt adattermékek (de az odaszállított bizonylatkötegek is) egyedileg visszakereshetők, így nyomon követhetők legyenek. Erre különös figyelmet kell fordítani és az ISO 9004 termékbiztonságra és felelősségre vonatkozó ajánlása (19.d.) alapján nyomon követési rendszert kell létrehozni. T. C. Redman [1] nyomon követési eljárása (data tracking) — az SPC[4] és a manuális hibaforrás-behatárolás kombinációja — jelenlegi formájában egy-egy attributumra tud koncentrálni és az egyed életciklusán keresztül a felvett értékei konzisztenciáját ellenőrzi, de ehhez elég sok ember-gép dialógusra is szükség van. A célja az, hogy behatárolja az(oka)t a tevékenység(ek)et, amely(ek) a folyamaton belül inkonzisztens adatokat produkál(nak). Javasoltak azonban más nyomon követési eljárásokat is. [2] A biztonsági okmányt lehetőleg teljes életciklusán át nyomon kell követni. Az adattermék teljes életciklusán keresztüli nyomon követés hatékony megvalósításának része az áramló, mozgó objektum ún. automatikus azonosítása (vonalkód, OCR[5] stb.). A hatékony nyomon követés a munkafolyamban áramló munkadarabokat (termékeket) automatikusan követő munkafolyam-vezérlő rendszer alkalmazását is feltételezi.
MUNKAFOLYAM-VEZÉRLÉS (WFLM - WORKFLOW MANAGEMENT)
Munkafolyam-vezérlő rendszer A WFLM-rendszerek célja, hogy hatékonyabbá tegyék az ügyintézési és az ügyviteli folyamatokat. Az ügymenetmodell az ügymenet érdemi ügyintézésének és ügyviteli tevékenységének (feladatainak) ún. részben rendezett sorozatát jelenti, és meghatározza azt, hogy: ¨ milyen feladatokat kell végrehajtani; ¨ milyen sorrendben; ¨ mely munkakörök által; ¨ mely korlátozó feltételek (pl. időkorlát) mellett. A feladatok egy részét automatikusan lehet végrehajtani; más részét kizárólag emberi közreműködéssel; végül vannak részben emberi közreműködéssel, részben géppel végrehajtható feladatok is. A hagyományos adatfeldolgozási számítógépes megoldások azonban hoszszabb holtidőkkel nehezen voltak beilleszthetők a gyorsabb válaszokat igénylő ügymenetekbe. Többek között ezért is kellett speciális, a hagyományos adatfeldolgozási technikától elütő, irodai munkafolyam-vezérlést végző programcsomagokat kialakítani. A WFLM-rendszer elősegítheti a meglévő régi információrendszerbe egy új (grafikus) alrendszer könnyebb bekapcsolását. Igen gyakori megoldás, amikor az ügyiratok áramlását egy új iratfeldolgozó[6] (vagy más néven képfeldolgozó) alrendszer bevezetésével, az ügymenet-modell követését pedig egy ezzel párhuzamosan üzembe állított WFLM-rendszerrel oldják meg. Mindkettő kapcsolódik a már régebben meglévő adatgyűjtő és adatfeldolgozó rendszerhez. Természetesen lehet olyan eset is, amikor nincsen ilyen kapcsolat, autonóm módon csupán a DIP és a WFLM dolgoznak együtt. Számos WFLM-rendszerre az jellemző, hogy az ügyiratot egy képi AB-ba szkennelik, majd E-mail segítségével a munkahely egyik képernyőjéről a másikhoz
átvivő processzek, ún. „ügynökök” továbbítják. A rendszer felhasználói (a dolgozók és az alkalmazói programok) olyan eszközöket használnak, mint pl. szövegszerkesztők, AB-ok, E-mail, Internet. Ha csak a fenti eszközöket kell alkalmazni, akkor mindaz az ismeret és felelősség, ami a folyamattal kapcsolatos, az „ügynökök” birtokában van, akik ennek megfelelően dolgoznak az ügyirat intézéséhez szükséges elemi gépi döntések előkészítésén, illetve döntenek arról, hogy menet közben merre menjen tovább az ügyirat. [3] A termelő vállalatok ún. reálfolyamatai és az igazgatás folyamatai közötti lényeges különbség, hogy a reálfolyamatokban nem csupán egyedi, hanem a sorozat- és tömegtermelés igényeinek megfelelően egymással teljesen csereszabatos munkadarabok áramlanak, amelyek egyedi azonosítására nincs is szükség, elegendő csak az áramlás darabszám, sorozatnagyság, sarzsméret stb. szerinti figyelése. Az igazgatási folyamatokban azonban általában tartalmukban legalább részben eltérő iratok áramlanak, amelyek egyedi azonosítására feltétlenül szükség van, és az áramlás mennyiségi jellemzőinek megfigyelése mellett az iratok tartalom szerinti összefüggéseinek figyelésére van elsősorban szükség. Nem egyszerűen csak a nyomon követhetőség miatti egyedi azonosításról van szó, hanem arról, hogy ha például a termelésben egy alkatrész hibás, akkor azt félretehetik, és a gyártásközi készletből a sorozatot kiegészíthetik egy új, hibátlan alkatrésszel, így az haladhat tovább. Viszont ha egy okirat tartalma hibás, akkor azt a helyes tartalommal újra elő kell állíttatni az eredeti aláírókkal stb., és amíg a javított példány elő nem áll, addig esetleg egy egész küldemény vagy egy iratköteg egésze áll és várakozik. Helyes adatérték híján az adathibát nem lehet kijavítani. Következménye ennek a viszonylag sokkal több ráfordítást igénylő, és sokszor csak áttételesen, másokkal (a helyes adatot „beszállítókkal”) elvégeztethető hosszú javítási ciklus. Amíg egy termék előállításához a reálfolyamatok szervezésekor szükség van pl. a munkadarab, a technológia és a homogén gépcsoportok adataira, addig egy igazgatási ügy elintézésének megszervezéséhez szükség van legalább az ügyirat, az ügymenet és annak információ-igényére, valamint az érintett munkakörök adataira. Az utóbbi ahhoz is kell, hogy akár a reálfolyamatban, akár az igazgatási folyamatban áramló munkatárgy esetén meghatározható legyen, hogy a folyamatbeli áramlás közben az éppen hol tart, melyik gépcsoportnál, munkahelynél, munkakörnél található. Ha ilyen részletes, munkahelyre, munkakörre vonatkozó információ nem lenne, akkor legalább szervezeti egység szintjén kell ismerni a vezetőnek azt, hogy egy ügy hozzávetőleg hol tart (pl. a 4721. számú ügy a számlázási csoportnál van). Az áramló adattermék (pl. ügyirat, költségvetési terv) feladatspecifikációt is közvetít, nem csak passzív munkadarab. A feladat lehet a szerv szintjén érkező utasítás, megrendelés, amely egy folyamat elindítását (ügyirat áramlását) váltja ki. Ugyanez a feladat azonban egy dolgozó szintjén már csak egy konkrét
munkahelyre beérkezett ügyirat, amelynek valamely részletére vonatkozóan munkatevékenységet kell elvégeznie. A feladat fogalom (a termelő szférában ismert „belső megrendelés” elnevezés helyett) alkalmazása mellett a WFLM-rendszerek alapfogalma még az ún. kivétel. Tapasztalhatjuk azt, hogy konkrétan milyen tevékenységet és hogyan kell elvégezni egy ügyiraton, nehéz minden egyes esetre általános érvénnyel részletesen előírni. [4] Amíg a termelő reálfolyamatokban mereven elő lehet írni, hogy pl. előírt jellemző értékeket minden egyes munkadarabnak ki kell elégíteni, s amelyik ettől eltér, az selejt, az igazgatási ügyek intézésénél rugalmasabbnak kell lenni, és el kell intézni a néha igen ritkán előforduló kivételes ügyeket is. Ez azt jelenti, hogy a tipikus ügyekre felépített ügymenetet szükség esetén gyorsan és rugalmasan meg kell változtatni ahhoz, hogy az ilyen kivételes ügyeket is kezelni lehessen. Ez jelenthet pl. kiegészítő adatfelvételt, újabb telefonokat, előre nem látott tevékenységként egy számítás elvégzését, egy további tanú meghallgatását stb. Bár az igazgatásban vannak ügytípusok, de minden szempontból tipikus ügy alig, szinte minden ügy egyedi. A többlettevékenységek egy részét az ügy indításakor még nem is lehet előre felmérni, azok menet közben bukkannak fel. Ez azt jelenti, hogy a rendelkezésre álló kapacitások egyenletes leterhelése érdekében a szokásosnál gyakrabban újra kellene tervezni egy-egy iroda kapacitásleterhelését, „műhelyszinten” kell átdiszponálni, részletekbe menően irányítani, terhelés szempontjából optimalizálni a munkafolyamot. Mindennek az okát úgy is megfogalmazhatjuk, hogy az ügy konkrét lefutása nem előre rögzített, hanem feltételes. Természetesen az ügymenetnek van egy tipikus, várható menete, de az egy statikus modell. Az ún. várósor-kezelés az iratok áramoltatásának eszköze. Minden ügyintézőhöz, illetve tevékenységhez rendelhető várósor, amelybe a szükséges ügyirat az esetleges kapcsolódó iratokkal együtt bekerül. Az ügyintéző — ha a prioritás módosításával nem bíráltuk felül — a bevitel sorrendjében kapja meg az iratokat, a feldolgozásukhoz szükséges eszközökkel együtt. Ezt követően, az ügymenettől függően, az irat átkerülhet más ügyintéző(k) várósorába vagy az archívumba. Ha egy munkaszakasz elvégzéséhez több kapcsolódó iratra van egyidejűleg szükség, az iratok bevárják egymást anélkül, hogy ehhez beavatkozásra lenne szükség. A feladat ilyen magasfokú automatizálásához szükség van [5]: ¨ a folyamat modelljére (sémájára), ez az ügymenet-modell. Azonban jelenleg ahány WFLM, annyi modell-leíró módszer van, nincs sem szabvány, sem ajánlás rá. Viszont általában van a WFLM-nek saját, géppel támogatott „folyamatmodellezője”;
¨ egy automatikus ügyirat kézbesítő mechanizmusra, amelyet az ügymenet modell és az éppen zajló folyamat információi vezérelnek; ¨ egy olyan mechanizmusra, amely automatikusan fog behívni programokat. A két utóbbi elemet együtt hívják munkafolyam-gépnek. Ezt a munkafolyam-gépet adatok és események hajtják meg és felhasználja az ügymenet modelljéből származó ismeretet ahhoz, hogy amikor egy „ügynök” már végzett egy ügyiraton a feladatával, akkor el tudja azt dönteni, hogy hová kell az ügyiratot továbbítani.
Aktiv AB rendszerek (aABR) Azonban más megoldás is megvalósítható az ún. aktív AB-rendszerek (aABR) segítségével. Itt a munkafolyam-gép magvalósítására aktív AB-t használnak fel. Az aktív AB lényegében egy közönséges (passzív) AB kibővítése egy ún. szabálybázissal. [6] A szabályok tevékenységeket specifikálnak, amelyeket automatikusan végre kell hajtani, valahányszor bizonyos események be fognak következni, és az előre megfogalmazott feltételek is fennállnak. Az aABR jellemzője, hogy képes felismerni adott helyzeteket (az adatbázisban, az adatbázis-kezelő rendszerekben [ABKR], a környezetben), és anélkül képes azokra reagálni, hogy ehhez szükség lenne akár a felhasználó, akár egy alkalmazás azonnali bevonására. Az eddig kifejlesztett (hagyományos) ABKR-ek a való világ szemantikai összefüggéseiből „épített” ún. sémára (adatmodellre) alapoztak. A tényadatok logikai struktúráit szabványos műveletekkel operáló, az AB konzisztenciáját fenntartó ABKR-nek azonban szüksége volt még egy tranzakció-modellre (hozzáférési modellre) is, amellyel működése hatékonyabbá vált. Azonban az AB az ügyviteli és munkafolyamatokat csak úgy segítette, hogyha egy tranzakció az AB-t egy új állapotba vitte, ezt az új állapotot egy ember észlelte, a tennivalókat mérlegelte, döntött és megtette a szükséges intézkedéseket, a munkafolyamatokba célszerűen beavatkozott, azokat szabályozva. Az aABR képes arra, hogy az ügyviteli vagy a munkafolyamatot teljesebben segítse azzal, hogy a munkafolyamatokba való beavatkozást elvégezze. Ehhez azonban arra is szükség van, hogy az AB egy új állapotának beállását maga az
aABR észlelje, tehát az előállható események típusai rendelkezésre álljanak a hozzájuk előírt feltételrendszerrel és a szükséges intézkedésekkel, teendőkkel egyetemben rendszerezve és tárolva. [7] Az aABR egy új funkciója tehát az, hogy ismerjen fel előre megadott szituációkat, amelyek részben az AB-ban, részben az alkalmazásokban, részben a környezetben fognak előállni. Új funkció az is, hogy indítson el (trigger) a fenti szituációk előfordulásakor megfelelő reakciót, választevékenységet (AB-műveletet, bármely programot). Az aABR új problémák sorát veti fel. Pl. mi az a „szituáció”, hogyan lehet leírni. Erre pl. lehet az a válasz, hogy: ¨ AB egy adott állapota; ¨ AB egy adott állapotának megváltozása; ¨ adott AB-művelet bekövetkezése; ¨ adott időpont; ¨ felhasználó által rögzített előfordulás; ¨ alkalmazás által rögzített előfordulás; és ¨ a fentiek kombinációja egyaránt lehet szituáció. A szituáció (helyzet, együttállás) leírására pedig alkalmasak az esemény és a feltétel fogalmak együttesen. Az eseményrész arra ad választ, hogy mi és mikor történt, a feltétel rész pedig arra, hogy mely AB-állapot(ok)kal egyidőben kell ennek tényleges választevékenységet kiváltania. Szituáció = esemény(előfordul) + feltétel (fennáll). A fenti felfogás esetleg vitatható, mégis széles körben elfogadott. Az esemény (Event), feltétel (Condition), tevékenység (Action) összefüggéseket, szabályokat tárgyaló szakirodalom ECA-szabályok szóhasználattal él. Ha E előfordul, ellenőrizd C-t, és ha fennáll, akkor hajtsd végre A-t. Jelölése: (E,C) — A, de programban a szituáció az alábbi módon fejezhető ki: ¨ ON: az előírt esemény előfordulásakor;
¨ IF: ha az előírt feltétel is fennáll, a szituáció; ¨ DO: hajtsd végre az előírt választevékenységet, reakció. Az előírt esemény definíciójában mindig meg van adva az az időpont, amikor majd az előírt választevékenységet el kell kezdeni. A feltétel mindig egy AB- állapothoz van kötve. Meg kell valamilyen mechanizmussal állapítani (érzékelni), hogy mikor jelez be a megfelelő eseményfajta egy előfordulása. Ha ekkor az előírt feltétel éppen fennáll, akkor az előírt választevékenységet kell kezdeni. A választevékenység bármely futtatható állapotban levő program (ideértve az ABműveleteket is) elindítása lehet, így pl.: ¨ adatkarbantartó műveletek; ¨ adatvisszakereső műveletek; ¨ objektumorientált módszerek; ¨ más AB-parancsok (pl. Commit TA, Abort TA); ¨ bármely alkalmazási procedúra; ¨ esetleg további események bejelzése (impliciten vagy expliciten). Az aABR-ek alapgondolatai már régebben is felmerültek, így pl.: ¨ AB procedúrák (Codasyl hálós modellben definiálhatók a séma egyedtípusaihoz): ON STORE CALL <procedure> ON ERROR DURING MODIFY CALL <procedure> ¨ Triggerek (System R és SQL 2/3); ¨ Sybase SQL server (Transact-SQL Enhancements); ¨ INGRES Knowledge Management; ¨ programnyelvekben (exceptions); ¨ mesterséges intelligencia-rendszerek (deamons).
Az aABR legfontosabb fogalma az esemény és az eseménykezelés, ehhez képest azonban ezeknek definíciója, érzékelése és belső gépi reprezentációja még mindig részben kutatás alatt levő problémák. Számos még le nem zárt kérdés létezik, pl.: ¨ Mely eseményt, feltételfajtákat, választevékenység-fajtákat kellene specifikálni? ¨ Egy esemény előfordulás egészen pontosan mit is jelent? ¨ Hogyan, mikor kellene érzékelni egy ABKR-nek, hogy esemény bekövetkezett? ¨ Pontosan mikor kellene ellenőrizni egy feltételt? ¨ Hogyan kellene kezelni a szabályokat mint az AB elemeit? ¨ Hogyan kellene a tipikus ABKR-mechanizmusokat a szabályokhoz és azok végrehajtásához alkalmazni (pl. szinkronizáció, jogosultság)?
A MINŐSÉGMUTATÓ-RENDSZER ALAPJAI A munkafolyam végén megjelenő előirt minőségű szolgáltatás feltételezi a folyamat egyes tevékenységeiről, hogy azok szintén előírt minőség-követelményeket kielégítve valósultak meg. A folyamat minden eleme minősítésére szolgálnak a minőségmutatók, amelyek célszerűen egységes rendszert képeznek. A mutatórendszer rendeltetése az, hogy a szervezet vezetőinek rámutasson a megoldandó problémákra, illetve az ügyfeleket tájékoztassa a szolgáltatás színvonaláról. Ez azért is indokolt, mert az ügyfelek egy része adatterméket beszállító is. Ennek megfelelően legalább háromszintű mutatórendszert javasolunk: ¨ szolgáltatási minőség-mutatók; ¨ igazgatási esemény-minőség mutatók; ¨ üzemi minőség-mutatók. Kezdetben csak néhány olyan egyszerű, üzemi szinten egyértelmű, az ISO 9000el összhangban álló és magától értetődő mutatók képzése látszik célszerűnek, mint a következőkben bemutatandók.
Javaslat üzemi szintű adatminőség-mutatókra Feltesszük, hogy az adatminőséget az alábbi dimenziókban biztosan mérni kell: ¨ teljességi vetület (szállítás, tárolás, működés); ¨ helyességi vetület (megbízhatóság és pontosság); ¨ időszerűségi vetület (átlagos átfutási idő, késések). A teljességi és a helyességi vetületet hibaaránnyal mérjük.
A darabszám szerinti teljességi vetület tényezői ¨ iratteljesség: követelmény az, hogy irat el ne vesszen a papírfolyamban; ¨ adatteljesség: követelmény az, hogy az iratról rögzített adatrekord el ne vesszen az adatfolyamban; ¨ képteljesség: követelmény az, hogy az iratról felvételezett kép (image) el ne vesszen a képfolyamban. Azt, hogy miért éppen ezt a 3 tényezőt választottuk, az adat- és iratgyűjtési alrendszer (ezt tekintjük az információrendszer adatminősége szempontjából főfolyamatnak) 3 jelentősebb alcsatornára szétbontása indokolja. Ha több alcsatornát (pl. hang, mikrofilm, kártya) definiálhatunk egy konkrét helyzetben, akkor értelemszerűen ugyanannyi újabb mutatót is számításba vehetnénk: ¨ iratteljességi arányt: It = elveszett iratok/összes iratok száma; ¨ adatteljességi arányt: At = elveszett adatrekordok/összes adatrekord száma; ¨ képteljességi arányt: Kt = elveszett képrekordok/összes képrekordok száma.
Mindhárom fenti mértéket azonos időszakaszra vonatkoztatva, az abban az időszakban érvényes teljességi arányszámok eredője adja az adatminőség teljességi összetevőjét. Amennyiben a multimédia iratok gyűjtése kapcsán más (pl. audio, mozgókép, mikrofilm) állományokat is tartalmazna az adattár, akkor a fenti hibaarányokhoz hasonló mutatók rájuk vonatkoztatva is képezhetőek lennének.
Az információtartalom-helyességi vetület tényezői ¨ Irathelyesség: követelmény az, hogy az irat ne hamisítvány vagy utánzat legyen. ¨ Adathelyesség: követelmény az, hogy a papíriratról mágneses adathordozóra rögzített rekord adatmezőinek tartalma feleljen meg a papírirat megfelelő rovatai tartalmának, valamint az alapnyilvántartásnál működő input-ellenőrzés által képviselt feltételeknek (amelyek a változás-jelentésnek a valóságtól, pontosabban az előzőleg több oldalról is megfigyelt eseményektől való eltérései kimutatását célozzák). ¨ Képhelyesség: követelmény az, hogy a papíriratról való képfelvételezéstől (vagy képlemezre történő átmásolástól) kezdve az iratkép (fénykép, rajz, térkép stb.) információtartalmából ne veszítsen, így minősége ne romoljon. ¨ Irathelyességi arány: Ih = ellenőrzésen fennakadt hamis/összes kibocsátott irat. ¨ Adathelyességi arány: A h = ellenőrzésen fennakadt rögzített/összes rögzített rekord. ¨ Képhelyességi arány: Kh = lecsökkent minőségű/összes felvételezett képek.
Az időszerűségi vetület tényezői ¨ Iratátfutási idő: a papírfolyam egy iratának átlagos átfutási ideje. ¨ Adatátfutási idő: az adatfolyam egy input tételének átlagos átfutási ideje. ¨ Képátfutási idő: a képfolyam egy image-ének átlagos átfutási ideje. Az átfutási idő értelmezhető a munkafolyam vagy valamely részfolyam (papír, kép, adat) teljes hosszára, vagy annak csupán egy szakaszára is. A hibaarányokat periodikusan (pl. karbantartási ciklusonként) decentrumonként, azon belül minden egyes beszállítóra, minden alapbizonylat-típusra (illetve eseménytípusra), azon
belül minőségmutatónként külön-külön összesítjük, és a vezetői értékeléshez szükséges összetett mutatók képzéséhez felhasználjuk. Természetesen valamennyi mutató-átlagérték mellett statisztikai jellemzőket (pl. szórás) is képezni és elemezni szükséges.
FELHASZNÁLT IRODALOM [1] REDMAN, T. C.: Data quality — management and technology. BantamBooks, New York, 1992. [2] WANG, Y. R.—MADNICK, S. E.: A source tagging theory for heterogenous DB systems. Proc. Int. Conf. on Inf. Sys., Coebenhavn, 1990. [3] HAMMAINEN, H.—SULONEN, R.—BERARD, C.: Pages — intelligent forms, intelligent mail and distribution. Proc. IFIP WG 8.4 Working Conference, 1986. [4] SHU, N. C.—LUM, V. Y. ET AL.: Specification of forms processing and business procedures for offices automation. IEEE Trans. on Software Eng. Vol. 8. No. 5., 1983. [5] PRINZ, W.—SPETH, R.: Group communication and related aspects in office automation. Message Handling System Proc. IFIP, 1988. [6] STONEBRAKER, M.: The integration of rule systems and DB systems. IEEE Trans. on Knowl. and Data Eng. Vol. 4. No. 4., October, 1992. [7] GATZIU, S.—DITTRICH, K. R.: Events in an active object-oriented DB system. Proc 1st Intl. Workshop on Rules in DB Systems. Edinborough, August, 1993. [8] MEZEY GY.: Biztonságos információrendszerről vezetőknek. OMIKK, Budapest, 1997.
[1] Eltérően a köznapi, illetve a kereskedelemben használt értelmezéstől, itt a tranzakció alatt a következőket értjük: igazgatási eseményeket egyedileg azonosító, illetve leíró adatok forrásbizonylatról lerögzített rekordjai, illetve ezekből programmal képzett input (bevitt) tételek (tranzakciók).
[2] Bináris nagy adatobjektum — Binary Large Object Block — BLOB. [3] ISO — International Standard Organization — Nemzetközi Szabványügyi Hivatal. [4] SPC — Statistics Process Control — Statisztikai folyamatszabályozás. [5] OPC — Optical Character Reader — Optikai jelolvasás. [6] Document Image Processing — DIP.
