Folyamatbányászat Starkné dr. Werner Ágnes
Adatok felhasználása A folyamatbányászat az adatbányászat egy speciális területének is tekinthető
Folyamat Olyan cselekvések vagy lépések egymás utáni sorozata, melyek eredményeképpen eljutunk egy bizonyos végpontra. Három különböző nap tevékenységei
Sematikus folyamatmodell a példánkra
Petri-hálók A Petri-háló struktúra definíciója a következőképpen hangzik: Egy (P, T, Pre, Post) négyest Petri-háló struktúrának nevezzük, ha P és T nemüres véges halmazok, Pre, P T-ből {0,1}-be képező függvény, Post, T P-ből {0,1}-be képező függvény. P = {p 1, p 2,, p n } és T = {t 1, t 2,, t m } halmazokat rendre a helyek és átmenetek halmazának nevezzük. A Pre függvény a bemeneti, a Post függvény pedig a kimeneti függvény. A Petri-hálók állapotukat tokenek segítségével fejezik ki. Egy hely tokenszámát úgy tudjuk jelölni, hogy a helynek megfelelő körbe bizonyos darab pöttyöt rajzolunk.
Folyamatkezelő információs rendszerek folyamatirányító rendszerek, pl.: WebSphere software, Staffware, Flower, Eastman software, People Soft, Adept web szerverek, pl.: Apache SCM rendszerek (Szoftver Konfiguráció Menedzsment rendszerek), pl.: Subversion, CVS napló fájlok
A folyamatbányászat perspektívái Minden folyamatot megvizsgálhatunk más-más szempont szerint is, ezeket perspektíváknak nevezzük.
Mi is a folyamatbányászat? A folyamatbányászat a célja: a folyamati adatokból valódi hasznosítható tudásanyag kinyerése. Felderíthetők és megjeleníthetők azok az összefüggések (pl. az ügyfélcsoportok, régiók, a termékek stb. között), amelyek a hosszú átfutási időért, a magas költségekért, a rossz minőségért felelősek. Különösen az igen sok folyamattal rendelkező vállalatok számára hatékony a módszer használata, hogy a problémákat mielőbb azonosítani lehessen.
A folyamatbányászat célja másképpen megfogalmazva: a bányászat során a folyamatkezelő információs rendszerek által létrehozott eseménynaplókból információkat nyerjünk ki. Az elmentett naplók általában különböző végrehajtott eseteket, időbélyegeket, a folyamatot végrehajtó személyeket, rendszereket stb. A folyamatbányászat lehetővé teszi a folyamatok különböző szempontok szerinti vizsgálatát.
A folyamatbányászat magas szintű modell diagramja
Egy lehetséges implementáció
A folyamatbányászat segítségével választ kaphatunk a tipikus menedzseri kérdésekre: Melyik a leggyakrabban használt útvonal a folyamatban? Milyen bejárható útvonal lehetőségek léteznek a folyamatban? Mennyi az átfutási ideje az egyes eseményeknek? Mennyi a feladatok kiszolgálási ideje? Mikor zárul le egy eset? Mennyi idő telik el két feladat között a folyamatban? Tipikusan hány embert érint egy bizonyos feladat? Mely emberek jelentenek központi szerepet a szervezetben? stb.
Hol alkalmazhatjuk a folyamatbányászatot? Önkormányzatoknál (pl.: Alkmaar, Heusden, Harderwijk) Kormányzati ügynökségeknél (pl.: Rijkswaterstaat, Centraal Justitieel Incasso Bureau, Justice department) Biztosításokhoz kapcsolódó társaságoknál (pl.: UWV) Bankoknál (pl.: ING Bank) Kórházakban (pl.: AMC kórház, Catharina kórház) Multi cégeknél (pl.: DSM, Deloitte) Média vállalatoknál (pl.: Winkwaves) High-tech rendszerek gyártóinál és fogyasztóiknál (pl.: Philips Healthcare, ASML, Thales) stb.
Egy folyamatbányászati probléma: Philips Egészségügyi Rendszerének problémája Pl. a röntgen gépek naplózzák a különféle eseményeket; az Allura Xper termékcsalád a szív- vagy májbetegségek területén segédkezik. A részletes események elemzése nagy segítséget nyújt a későbbi gépek továbbfejlesztésében. A folyamatbányászat segítségével a olyan kérdésekre kaphatnak választ, mint: Hogyan lehetne tesztelni a röntgen rendszert valóságos körülmények között? Milyen gyorsan lehetne beépíteni és használni az új fejlesztéseket? Hogyan lehetne növelni a megbízhatóságot és diagnosztizálni a visszatérő problémákat? Hogyan lehetne megjósolni a meghibásodásokat és megelőző lépéseket tenni ezek ellen? Eredmények: A folyamatbányászat felhasználásával a felépítettek egy olyan teszt profilt, amely rávilágított az Allura Xper termékcsalád tényleges használatára a világ különböző pontjain. Ezzel a módszerrel sikerült lecsökkenteni a rendszer tesztelésére fordított időt és megnövelni a tesztelés hatékonyságát. A jövőben a folyamatbányászat segítségével feltárhatók a megbízhatósági problémák és támogatást nyújthatnak a megelőző kezelésekben.
Folyamatbányászati segédprogramok A folyamatbányászat fő lépései
Az eseménynapló A folyamatkezelő információs rendszerek széles köre használatos a gyakorlatban az információs rendszerek mindegyike másképpen naplózza az eseményeket a folyamatkezelő információs rendszerek és a folyamatbányászati alkalmazások között meg kell találni a megfelelő kapcsolatot létezik egy meta modell a naplófájlok számára: ebben megadják az alapvető követelményeket, hogy milyen adatoknak kell feltétlenül rögzítve lenniük. A meta modellhez egy, az XML nyelv speciális változatát használják, az úgynevezett Mining XML, MXML formátumot.
A naplófájlok felépítésének követelményei Minden tárolt adatnak valójában egy eseménynek kell lennie, amit egy meghatározott időpontban végrehajtottak. Nem vonatkozhat azonban időtartamra. Például egy munkafolyamat megkezdése, valamint befejezése megfelelő eseménynek számít, azonban az a folyamat, ami alatt a munkát végezték már nem az. Valamennyi tárolt adat csak egy bizonyos eseményre utalhat, mely események egyedileg meghatározottak. Mindegyik adatnak tartalmaznia kell egy eseményleírást, hogy pontosan mire utal. Például egy tevékenység befejeződött (complete). Minden tárolt adat bejegyzésnek hivatkoznia kell egy specifikus folyamati esetre. Például tudnunk kell azt, hogy egy számlához milyen fajta fizetési mód párosult. Minden folyamati eset egy specifikus folyamathoz kell, hogy tartozzon.
Az információk meta modelljének létrehozása Eseménynapló meta modellje, UML diagram
Mining XML struktúra
A Staffware rendszer saját formátumú naplózásának MXML formátumra való fordításából kapott eseménynapló egy részlete: <Source program="staffware"> <Data> <Attribute name="version">7.0</attribute> </Data> </Source> <Process id="main_process"> <Data> <Attribute name="description">complaints handling</attribute> </Data> <ProcessInstance id="case 1"> <AuditTrailEntry> <WorkflowModelElement>Case start</workflowmodelelement> <EventType unkowntype="case_event">unkown</eventtype> <Timestamp>2002-04-16T11:06:00:000+001:00</Timestamp> </AuditTrailEntry> <AuditTrailEntry> <WorkflowModelElement>Register complaint</workflowmodelelement> <EventType>schedule</EventType> <Timestamp>2002-04-16T11:16:00:000+001:00</Timestamp> <Originator>jvluin@staffw</Originator> </AuditTrailEntry>
Folyamatbányászati eszközök Futura Reflect A Futura Reflect egy intelligens folyamatkezelői és folyamatbányászati alkalmazás, amit a Futura Process Intelligence cég fejlesztett ki. https://www.futura-reflect.nl fő jellemzői: folyamatok feltárása; képes automatikusan létrehozni a folyamatmodellt a naplózási adatok alapján (ki, mikor, mit csinált, melyik esettel kapcsolatban); társadalmi hálózatok automatikus feltárása; tevékenységek animációs illusztrálása; teljesítményelemzés.
MiMo (Mining Module) Az ExSpect (Executable Specification Tool) nevezetű programra épül http://www.exspect.com Jellemzői: használja a folyamatbányászati α-algoritmust; két részből áll: (1) egy munkafolyamat-irányító napló generátorból és (2) egy munkafolyamat-irányító naplóelemzőből
Egy pillanatkép a MiMo eszközről, melyen láthatjuk az architektúrát (bal felső ablak), a munkafolyamat-irányító napló generátort (jobb felső ablak), valamint a naplóelemzőt (alsó ablak)
EMiT (Enhanced Mining Tool) Ha rendelkezésünkre áll egy folyamatkezelő információs rendszer log fájlja, legyen az akár kevés esetből álló, kisebb log is, meglehetősen nehéz feladat feltárni a munkafolyamat struktúráját, azzal, ha csak vizsgálgatjuk a logot. Ekkor lehet a segítségünkre az EMiT. Használatának szakaszai: 1. előfeldolgozás: beolvassuk a log fájlt, majd a program felépíti a különböző kapcsolatokat a naplózás alapján; számos beállítás áll rendelkezésünkre, például megadhatjuk, milyen eseményekkel dolgozzon a program; 2. feldolgozás: megadhatjuk, hogy milyen bányászati plugin-t használjunk, majd létrehozza a program a Petri-hálót; 3. utófeldolgozás: betöltjük az eredeti logot, majd a már kész Petri-hálóval egyszerre lehetőségünk van utólagos információkat is kinyerni. http://prom.win.tue.nl/research/wiki/discontinued/emit
ProM nyílt forráskódú folyamatbányászati eszköz; jelenleg több mint 280 plugin érhető el az alkalmazáshoz jellemzői: az eseménynaplót MXML formátumban várja; naplózás szűrése; támogatja a legfontosabb folyamatmodelleket is inputként (Petri-háló, EPCs/EPKs (Aris gráf formátum), YAWL stb.; konvertálási lehetőségek; analízis; megfelelőség vizsgálat; verifikáció; stb.
A ProM keretrendszer architektúrája
Bányászati plugin-ek Más perspektívához más-más plugin tartozik. A folyamat perspektívához négy fontos plugin tartozik: α-algoritmus: tartalmazza az α-algoritmust és kiterjesztéseit. Feladata, hogy felépítsen egy olyan Petri-hálót, amely modellezi azon folyamatokat, amelyeket a log tartalmaz. Tshingua-α algoritmus: időbélyegeket használva építi fel a Petrihálót, működése hasonló az α-algoritmushoz, de más megközelítést használ. (Érdekessége, hogy ez a plugin az első, amelyet független kutatók fejlesztettek ki, Kínában, a Tshinghua Egyetemen és minden gond nélkül be lehetett integrálni a keretrendszerbe.) Genetikai algoritmus: ez a plugin genetikai algoritmust használ, amellyel a log fájlban esetlegesen előforduló zavaró hatásokat szűrik ki. Kimeneti formátuma egy heurisztikus háló, amely természetesen átalakítható EPC, vagy Petri-hálóvá. Többfokozatú bányászat: ez a plugin egy sor folyamatbányászati algoritmust használ, amelyek különböző diagramokat, gráfokat, sematikus ábrákat tudnak megjeleníteni.
Bányászati plugin-ek A szervezet perspektívához egyetlen fontos plugin tartozik: Társadalmi hálózat bányászat: a naplózást felhasználva felderíti az emberek társadalmi hálózatát. Az eset perspektívához is egy fontos plugin tartozik: Eseti adat kinyerés: amelyet egyfajta illesztőegységként használnak más, tudásfeltárás alapú programok során(pl.: Viscovery és SPSS AnswerTree)
Példa az α-algoritmus-ra: Példánk egy cég telefonjavítási folyamatát mutatja be. 1. Három féle telefontípust képesek helyrehozni (T1, T2, T3). 2. A folyamat azzal indul, hogy regisztrálják a telefonkészüléket, amelyet a megbízó küldött. 3. Miután ez végbement, a telefon a Probléma Detektálási (PD) részlegre kerül. Itt elemzik a hiba okát és az általuk 10 féle javítási kategóriába sorolják. 4. Ha ez megtörtént a készülék a hiba adataival együtt a Javítási (R) részlegre kerül. 5. A Javítási részlegnek két csoportja van. Az egyik, amely az egyszerűbb hibákat javítja, a másik a bonyolultabb meghibásodások javításaiért felelős. Léteznek olyan hibák is, amelyeket mindegyik csapat meg tudja javítani. 6. Miután helyrehozták a készüléket a Minőség Ellenőrzés veszi át az irányítást, ahol megbizonyosodnak a hiba tényleges kijavításáról. 7. Ha a telefon újabb javításokra szorul, visszakerül a Javítási részlegre. 8. Ha a készülék immár hibátlan, az ügyet archiválják, és a telefont visszaküldik a megbízónak. 9. Ha bizonyos javítás után sem lehet helyrehozni a telefont, az ügyet akkor is lezárják, és az ügyfél kap egy teljesen új készüléket.
A folyamat eseménynaplójának egy részlete: <?xml version="1.0" encoding="utf-8"?> <!-- MXML version 1.0 --> <WorkflowLog xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:nonamespaceschemalocation="http://is.tm.tue.nl/research/processmining/workflowlog.xsd" description="cpn Tools simulation log"> <Source program="cpn Tools simulation"/> <Process id="default" description="simulated process"> <ProcessInstance id="1" description="simulated process instance"> <AuditTrailEntry> <WorkflowModelElement>Register</WorkflowModelElement> <EventType >complete</eventtype> <Timestamp>1970-01-02T12:23:00.000+01:00</Timestamp> <Originator>System</Originator> </AuditTrailEntry> <AuditTrailEntry> <WorkflowModelElement>Analyze Defect</WorkflowModelElement> <EventType >start</eventtype> <Timestamp>1970-01-02T12:23:00.000+01:00</Timestamp> <Originator>Tester3</Originator> </AuditTrailEntry> <AuditTrailEntry> <Data> <Attribute name = "phonetype">t2 </Attribute> <Attribute name = "defecttype">6 </Attribute> </Data> <WorkflowModelElement>Analyze Defect</WorkflowModelElement> <EventType >complete</eventtype> <Timestamp>1970-01-02T12:30:00.000+01:00</Timestamp> <Originator>Tester3</Originator> </AuditTrailEntry>
A ProM által generált Petri-háló
A ProM által generált EPC folyamatmodell