Workflow és Petri hálók

Algoritmusok tervezése és elemzése

Workflow és Petri hálók

Molnár András (H9YL5P)

Workflow és Petri hálók Bevezetés A hagyományos információs rendszerekről eddig alkotott kép (személyre szabott, költség-intenzív adatbázis alkalmazások) gyorsan változik köszönhetően a fejlődő szoftver iparnak, mely egyre inkább előnyben részesíti a már elkészült, általános komponenseket és sztenderd szoftver megoldásokat, illetve részben az információs forradalomnak. (Aalst, Hee, 2002) A változások új igényeket támasztottak az információs rendszerek iránt (elsősorban e-commerce és bank, gyártás – beleértve a szoftveripart is, oktatás és képzés területről), melynek hatására új módszereket és általános szoftver csomagokat – úgynevezett Worflow Management Systems (WfMS) – fejlesztettek az üzleti folyamatok kezelésére. Az üzleti folyamatokban szereplő erőforrások (emberek, gépek, anyagok...) és tevékenységek (melynek során szolgáltatások keletkeznek, anyagok alakulnak át, vagy információt dolgoznak fel) összehangolt és megismételhető lépéseinek összességét workflownak nevezzük. A workflow management rendszer olyan szoftver rendszer, mely lehetővé teszi a folyamatok workflowba szervezését, a workflow végrehajtásának felügyeletét, ellenőrzését. Ezen kívül a workflow rendszerek feladata, hogy biztosítsák a megfelelő információ elérhető a megfelelő személy vagy program számára a megfelelő időpontban. Ebből következően a workflow rendszereknek nem feladatuk a folyamatban szereplő feladatok végrehajtása, ami egyrészt előnyös, mert általános szoftver fejleszthető, ami sokféle folyamatot tud kezelni, viszont hátránya, hogy továbbra is szükség van a folyamat-specifikus alkalmazásra.

Workflow modellek A workflow rendszerek célja, hogy leírja az egyedi esetekre alkalmazandó általános üzleti folymatot. Ilyen eset lehet például egy biztosítási igény, egy jelzáloghitel igénylés, adóbevallás, egy rendelés vagy akár egy páciens a kórházban. A hasonló esetekre ugyanaz a workflow alkalmazandó, ugyanakkor minden esetnek van azonosítója (az esetek egymástól való megkülönböztetésére) és állapota, mely három részből épül fel:

1/9




1. attributumok: az esethez tartozó változók 2. feltételek: az eddig teljesült feltételek, leírja, hogy az eset milyen állapotban van (például a kérvényt elutasították, vagy a kérvény elbírálás alatt van) 3. tartalom: a gyakorlatban ez különböző dokumentumokat, fájlokat, képeket jelent, amiket a fájlrendszerben, adatbázisban tárolnak A Workflow-k leírására széles körben használják a Petri-hálókat, melyet 1962-ben Carl Adam Petri javasolt a folyamatok modellezésére és elemzésére. A Petri-háló helyekből (place), átmenetekből (transition), tokenekből (token) és irányított élekből (arc) áll. (Molnár, 2013) Élek csak helyek és átmenetek között szerepelhetnek (hely-hely és átmenet-átmenet él nem megengedett), ebből következik, hogy a Petri-hálók páros gráfok.

Illustration 1: Klasszikus Petri-háló Formálisan a Petri-háló egy N=(P, T, F) hármas, ahol P a helyek (places) és T az átmenetek (transitions) diszjunkt véges halmazai, F pedig (P x T) U (T x P) egy részhalmaza. Az egyes helyeken tetszőleges számú token fordulhat elő, a tokenek akkor kerülhetnek át a következő helyre, ha az átmenethez vezető élek mindegyikén az átmenet feltétele teljesül. (Molnár, 2013) Magasabb szintű Petri-hálóknak a Petri-hálók kiterjesztéseit nevezzük, melyek közül a három legfontosabb a szín-, az idő- és a hierarchia kiterjesztés. A klasszikus Petri-hálóban definíció szerint a tokenek homogének, egymástól nem megkülönböztethetőek, viszont általában ez nem praktikus. Gyakran az esetek tulajdonságai alapján szeretnénk megkülönböztetni a tokeneket, például hiteligényléseknél a hitel célja (általános, lakáscélú) vagy a fedezet típusa (fedezetlen, jelzálog, gépjármű) alapján. Szín kiterjesztés esetén minden token kap egy értéket vagy színt, ezzel – hasonlóan a színezett/súlyozott gráfokhoz – megkülönböztethetővé válnak a tokenek, az átmeneteken ennek megfelelően lehet definiálni (például csak bizonyos típusú tokeneket fogad el inputnak, vagy a token 2/9




típusa alapján más outputot ad). Az idő kiterjesztés segítségével a Petri-háló teljesítményével kapcsolatos feltételeket fogalmazhatunk meg. Ilyen lehet például, amikor a közlekedési jelzőlámpák folyamatait szeretnénk leírni (mennyi idő múlva váltson a jelzőlámpa). Ekkor a tokenek egy időbélyeget kapnak, melyek azt mutatják, mikor lesz legközelebb elérhető az adott token (engedélyezési idő). Az időbélyegek a különböző átmenetek során változhatnak. A háló ütemezése a FIFO (first-in, first-out) elvet követi, több egyforma időbélyeg esetén nem-determinisztikus döntést hoz. Az előző két kiterjesztéssel bár elég bonyolult hálók hozhatók létre, végül csak egy hálózatot kapunk, amiben a strukturáltság elvész. Ezzel szemben a hierarchikus kiterjesztés segítségével al-folyamatok is definiálhatók, melyek az üzleti folyamatok modellezésénél különösen hasznosak lehetnek. Fontos még kiemelni a routing (útvonalválasztás) szerepét, mivel a folyamatokban megengedhetünk opcionális feladatokat is. A routing használatával a következő konstrukciók írhatók le (Aalst, Hee, 2002): 1. sequential routing: Sequential routing esetén a feladatok közvetlenül egymás után következnek.

Illustration 2: Sequential routing A Petri-hálóban akkor érdemes használni, ha a folyamatban a következő lépésnek szüksége van az előző lépés eredményére. 2. parallel routing: Ha több feladatot egymással egy időben is végre lehet hajtani, akkor érdemes őket párhuzamosítani.

Illustration 3: Parallel routing

3/9




Fontos, hogy a folyamat csak akkor haladhat tovább, ha minden párhuzamosított feladat befejeződik (AND-join), így eleget téve a t2 feltételnek. 3. selective routing: Előfordulhat, hogy bizonyos feladatokat nem minden esetben kell végrehajtani, vagy csak bizonyos típusú eseteknél fontosak, ilyenkor alkalmazható a selective routing, ami az elágazáshoz hasonló. Az átmenteket lehet úgy is definiálni, hogy előfeltételekként funkcionáljanak.

Illustration 4: Selective routing Ebben az esetben t1-ben döntés születik, hogy az adott token c2-ben vagy c3-ban folytatja útját, így csak task1 vagy csak task2 hajtódik végre. 4. iterative routing: Iterative routing esetén adott feladatot többször hajthatunk végre. Erre lehet példa egy javító műhelyben a javítás elvégzése utáni teszt. Ameddig nem sikerül kijavítani az alkatrészt, addig minden javítás után a tesztet újra el kell végezni.

Illustration 5: Iterative routing

4/9




Workflow elemzés Üzleti folyamat létrehozásának vagy módosításának számottevő hatásai lehetnek, így célszerű a bevezetés vagy módosítás előtt mindenre kiterjedően elemezni a folyamatot. Kétféle elemzése különböztethetünk meg: kvalitatív (minőségi) és kvantitatív (mennyiségi) elemzések. A kvalitatív elemzés üzleti folyamatok esetén elsősorban a logikai helyesség ellenőrzését jelenti, például a holtpontok (deadlock, livelock) kizárása. A kvantitatív elemzés során a folyamat teljesítményét vizsgálják a meglévő/új teljesítmény indikátorok segítségével. Ilyen indikátor lehet a kapacitás kihasználtság, a szolgáltatás minősége, vagy az átlagos végrehajtási idő. A Petri-háló segítségével elkészíthetjük a folyamat elérhetőségi gráfját, amelyben leírjuk, hogy a különböző állapotok hogyan, illetve milyen sorrendben érhetők el.

Illustration 6: Elérhetőségi gráf az 1. képen lévő klasszikus Petri-hálóhoz

Workflow fejlesztés Az egyik előnye a workflow-k használatának, hogy segítségükkel könnyebben lehet az üzleti folyamatokat megváltoztatni. Erre elsősorban akkor lehet szükség, ha túl sok eset van folyamatban, teljes elkészülési idő túl hosszú, vagy a szolgáltatás minősége túl alacsony. A problémák azonosításához benchmarkok, az okainak feltárására teljesítmény indikátorok bevezetését javasolja (Aalst, Hee, 2002). Használatukkal a workflow teljesítménye mérhetővé válik a vizsgált változó

5/9




alapján. Megkülönböztetünk külső (az esethez kapcsolódó) és belső (erőforráshoz kapcsolódó) teljesítmény indikátorokat. Míg az előbbi a workflow környezetére vonatkozó tulajdonságokat (pl. átlagos elkészülési idő), addig utóbbi az ehhez igénybe vett erőforrásokat (pl. adott erőforrást mennyi eset használja egy időben) méri. A workflow fejlesztésre ezen kívül számos elméletet és módszertant dolgoztak ki, a leggyakoribbak: 1. Six Sigma Célja a folyamat eredményének minőségének növelése a hibák okainak megkeresésével és megszüntetésével. Ehhez empirikus, statisztikai módszereket használ. 2. TQM (Total Quality Management) Olyan vállalati szintű vezetési módszer, melynek célja az erőforrások hatékony felhasználása. A hangsúlyt a vevői elégedettségre és a szervezeti működés folyamatos fejlesztésére helyezi. 3. BPR (Business Process Re-engineering) Olyan servezési/vezetési stratégia, ami a workflow-k és üzleti folyamatok elemzésére, illetve azok hatékony újratervezésére fókuszál. Segítségével a szervezetek alapvetően és radikálisan újratervezhetik üzleti folyamataikat. 4. Lean systems Olyan vállalatirányítási rendszer, melynek célja, hogy a vállalat minél gazdaságosabban állítsa elő a termékeit, szolgáltatásait. Ezt úgy éri el, hogy mindent, ami a vevő számára nem teremt értéket, pazarlásnak tekint, és megszünteti. 5. Theory of constraints Olyan vezetési módszer, ami a hatékonyság növelését a szervezetben lévő korlátok, megszorítások feltárásával, illetve megszüntetésével éri el.

Szoftveres támogatás Több szoftver is készült a workflow-k és az üzleti folyamatok támogatására. Az SAP Business Workflow mellett szól, hogy képes a többi SAP szoftverrel együttműködni. A szoftverrel lehetőség nyílik a különböző jóváhagyási folyamatok, például beszerzési igény, számla jóváhagyás automatizálására. Ezen kívül definiálhatóak azok a folyamatok, amik gyakran ismétlődnek és adott szabályok szerint kell végrehajtani őket. Jellegzetes példa egy üzleti partner nyilvántartásba vétele. Miután felvesszük a partnert a nyilvántartásunkba, további információkat kell beállítani, mint például a 6/9




hitelkeretet, vagy az elérhetőségeket. Egy másik példa egy vállalatnál az új munkatárs felvételének folyamata. A szoftverrel továbbá egyszerűbbé válik a folyamatok ellenőrzése, felülvizsgálata. Ez a funkció a különböző (belső/külső) auditokon való megfelelés mellett a különböző szabályzatoknak (pl. Sarbanes Oxley, törvényi előírások, vállalati complience) betartását is segíti. Az SAP szoftver használatával előre elkészített workflow-t is lehet használni a különböző modulokban/folyamatokhoz. Ilyen például a vállalatirányítás (ERP) vagy a kapcsolat menedzsment (CRM, SRM).

Kimondottan

BPM

és

workflow

feladatokra

készült

a

Bonita

szoftvercsomag

(http://www.bonitasoft.com/ ), ami egy nyílt forrású szoftver, melyet sikeresen alkalmaznak olyan komplex projektekben, mint az ellátási-lánc menedzsment (SCM), e-Kormányzat, HR illetve szerződések kezelése.

7/9




Meg kell említeni még Microsoft Windows Workflow Foundation-t, ami a .Net keretrendszeren belül nyújt támogatást a workflow-k kezelésére. A keretrendszert több alkalmazás, így például a SharePoint is használja, segítségével olyan folyamatok automatizálhatók, mint például a dokumentum jóváhagyás, vagy vélemények gyűjtése.

8/9




Felhasznált irodalom Aalst, W. M. P. van der, and Hee, K. van, 2002. Workflow Management, Models, Methods, and Systems. Cambridge, Massachusetts London, England, The MIT Press. Molnár, B., 2013. Szolgáltatás orientált architektúrák információs rendszerekben - A szervezeti architektúra nézetei, nézőpontjai és tervezési módszerei. Molnár, B., Tarcsi, Á. -. Design and architectural issues of contemporary web-based information systems, Budapest, Hungary.

9/9

Workflow és Petri hálók

Recommend Documents