A folyamatok leírásához, áttekintéséhez az Önök javaslatai és észrevételei alapján véglegesített Excel-táblázat kialakítását követően több teamben is igen rövid idő alatt elkészültek az első folyamatmodellek. Ez alkalommal is köszönjük minden beküldőnek a megbeszélt, szoros ütemezésben elkészített egyes modelleket.
Arra törekszünk, hogy a közös tapasztalatainkat megosztva, az éppen modellező teamek számára elkerülhetővé tegyük a tipikusnak tűnő buktatókat, modellezési csapdákat. Ezért rövid összefoglalót készítettünk, amely az eddig feldolgozott Excel-alapú folyamatleírások tapasztalatait összegzi, és remélhetően segítséget nyújt a felmerülő kérdések tisztázásához, de mindenekelőtt a modellezési idő lerövidítéséhez.
A modellezési sablon használatához fűződő tapasztalatokat a főbb témacsoportok szerint gyűjtöttük össze kérdések formájában.
Mikor kell kapcsolódó folyamatokat használni, hogyan kapcsoljuk őket a tevékenységekhez?
Kapcsolódó folyamat illesztésére akkor van szükség, amikor egy adott folyamat, azon belül is a tevékenységek végrehajtását egy másik folyamat indítja el. A lehetséges kapcsolódási pontok azonosíthatóak (1) a folyamat elején, (2) a folyamat lefutása közben és (3) a folyamat végén. Egy másik terület folyamata tehát kapcsolódó folyamattá válhat, ha az általunk épp modellezni kívánt folyamathoz csatlakozik, de éppígy az általunk modellezett folyamat is elindíthatja egy mások által leírni tervezett folyamat végrehajtását.
Olyan folyamat határozható meg kapcsolódó folyamatként, amelyet a modellezési munkát előkészítő fázisban alfolyamatként / részfolyamatként már azonosítottunk (lásd a folyamatstruktúrát). A kapcsolódó folyamatokat mindig egy eseményen keresztül kapcsoljuk a tevékenységhez. Az esemény megjelölésekor érdemes arra törekedni, hogy meghatározása kellően általános legyen ahhoz, hogy mások is be tudják illeszteni folyamataikba. (Találó esemény meghatározással jelentős időt spórolhatunk meg más teamek számára és majd a folyamatok illesztésének fázisában magunknak is.)
A kapcsolódó folyamat minden esetben valamilyen eseményen keresztül kapcsolódik. A kapcsolódásoknál arra is figyeljünk, hogy a folyamatok nevét és a kapcsolódást jelentő eseményt egységesen ugyanazzal az elnevezéssel tüntessük föl, mint ami a másik, hivatkozott folyamatban szerepel.
Hogyan jelöljük a kapcsolódó folyamat viszonyát a leírt folyamathoz?
A kapcsolódó folyamat lehet az adott folyamatból kifelé mutató, „kikapcsolódó” folyamat, ilyen esetben a „Kapcsolódó folyamat” cellában a kapcsolódó folyamat neve után írjunk (K) jelet. A befelé mutató, „bekapcsolódó” folyamatot jelöljük (B) jellel. Az is elképzelhető, hogy a folyamat két tevékenysége közé ágyazódik be egy kapcsolódó folyamat (amikoris a kapcsolódó folyamat lefutása után a leírt folyamat onnan folytatódik, ahol abbamaradt), ezt jelöljük (Á)-val.
Hogyan jelöljük a kapcsolódásokat folyamaton belül?
A „kapcsolódó folyamat” jelzése az egyes folyamatok (EPC-k) közötti kapcsolatot teremti meg. A folyamaton belüli kapcsolódásokat a tevékenységek sorrendiségével, illetve a folyamaton belüli elágazások (logikai kapcsolók – ÉS / VAGY / KIZÁRÓ VAGY) használatával jelölhetjük.
Miért nem megfelelő a „szerződés megkötése” megjelölés az esemény leírásakor?
Az ARIS eszköz EPC (esemény vezérelt folyamatlánc) modelltípusában az esemény – definíciója szerint – állapotot fejez ki, mégpedig annak a bemutatására, hogy mi indította el, illetve mi zárta le a folyamatot, hol vannak az elágazási, illetve csatlakozási pontok. Ezért az eseménynek nem folyamatban lévő cselekvést, hanem az ahhoz kapcsolódó befejezett állapot jelzését kell szolgálnia. Így az esemény modellkomform megfogalmazásai lehetnek: „A szerződés megkötése megtörtént”, „Szerződés megkötve”, stb.
Amennyiben több esemény meghatározása szükséges a folyamat elindításához, vagy lezárásához, akkor ezeket önálló sorszámú, külön sorokban szükséges a táblázatban szerepeltetni.
Ha a folyamatot több esemény indítja el, akkor használni szükséges a logikai kapcsolókat (ÉS / VAGY / KIZÁRÓ VAGY).
Mikor kell eseményeket használni a folyamatmodell leírásához?
Az eseményeket több esetben kell használni
ˇ Start eseményként
o A folyamat elején, az első tevékenység előzményeként.
ˇ Köztes eseményként
o Logikai kapcsolók után mindig kell használni eseményt, mégpedig annyit, amennyi ága van a folyamati elágazásnak.
o A kapcsolódó folyamat és a kapcsolódó tevékenység között mindig szerepelnie kell eseménynek.
ˇ Vég-eseményként
o A folyamat végén, az utolsó tevékenység lezárásaként.
o A folyamatágak végén, a folyamatágak lezárásaként.
(Ha a folyamat elágazik, akkor minden folyamatágat vég-eseménnyel kell lezárni.)
Kezdőesemények meghatározása
Mindig érdemes végiggondolni, hogy milyen események indíthatják el az adott folyamatot. Nem biztos, hogy csak egy ilyen esemény lehet – ekkor valamennyi lehetséges (vagy szükséges) kezdőeseményt fel kell tüntetni, a megfelelő logikai kapcsoló alkalmazásával.
Kapcsolódhatnak-e szervezeti szereplők, dokumentumok az eseményekhez?
Nem, szervezeti szereplőket, dokumentumokat és informatikai rendszereket csak a tevékenységekhez kapcsolhatunk (az események passzív történések, állapotok).
Mikor és miért fontos kitölteni a tevékenység rövid leírása mezőt?
Azokban az esetekben sikerült kölcsönösen jelentős időt megtakarítani a tevékenység részleteinek leírása révén, amikor a folyamat eredményes adaptálása nem volt valószínű, vagy egyáltalán nem volt lehetséges a szóban forgó tevékenység részletezése, hátterének bemutatása nélkül. Az IFUA a visszacsatolások során igyekszik ezekre a pontokra rámutatni.
A tevékenység rövid leírására tehát akkor van igazán szükség, amikor
ˇ a keletkező információk felhasználása, hasznosulása nem kiolvasható a folyamatból,
ˇ csak részletek jelzésével mutathatóak meg a folyamat hatékony végrehajtásához, működtetéséhez szükséges feltételek,
ˇ a végrehajtás feladataira csak a tevékenység részletezettebb leírása utal egyértelműen,
ˇ fontos a tevékenység végrehajtásban közreműködő vezető és munkatárs feladatainak szétválasztása,
ˇ a folyamat kritikus eleme az információáramlás, -rögzítés formája.
Mikor melyik logikai kapcsolót kell használni?
A tapasztalat azt mutatja, hogy a modellezés során (1) nem mindenhol kerültek beépítésre logikai kapcsolók, ahol alkalmazásukra szükség lett volna, illetve (2) nem mindig a megfelelő logikai kapcsoló alkalmazására került sor. Ezért igen tömören áttekintjük a logikai kapcsolókról a módszertani anyagokban bővebben tárgyaltakat:
ˇ ÉS logikai kapcsoló
o Elméleti példa: ha a folyamat két irányba ágazhat el, akkor mindkét ág párhuzamosan le fog futni.
o Gyakorlati példa: ha az intézmény asztali számítógépeket vásárol, akkor (1) a leszállított számítógépekről szóló számla kifizetése és (2) a számítógépek eszköznyilvántartásba vétele párhuzamosan lezajlik.
ˇ KIZÁRÓ VAGY logikai kapcsoló
o Elméleti példa: ha két irányba ágazhat el a folyamat, akkor vagy csak az egyik, vagy csak a másik ág fog lefutni.
o Gyakorlati példa: az intézményekhez számla érkezik kifizetésre. A gazdasági adminisztráció ellenőrzi, hogy a számla formailag megfelel-e a számviteli törvény előírásainak. (1) Ha igen, akkor folytatja a kifizetési folyamatot, (2) ha nem, akkor visszaküldi a szállítónak a számlát.
Vagy csak az (1), vagy csak a (2) folyamat fut le, hiszen az nem történhet meg, hogy az intézmény a visszaküldött számla ellenére teljesíti a kifizetést.
ˇ VAGY logikai kapcsoló
o Elméleti példa: ha két irányba ágazhat el a folyamat, akkor vagy (1) az egyik ág fut le, vagy (2) a másik ág fut le, vagy (1)+(2) mindkét ág párhuzamosan lefut.
Azaz a folyamatban nem mondható meg biztosan, hogy az ÉS logikai kapcsolat szerint vezérlődik a folyamat vagy a KIZÁRÓ VAGY logikai kapcsolat szerint
o Gyakorlati példa: ha az intézményen belül tanszék(ek) más helységekbe, épületekbe költöznek, akkor ez megvalósulhat (1) csak a belső munkatársak közreműködésével és (2) kizárólag egy külső költöztető cég közreműködése révén. Azonban az is lehetséges megoldás, hogy a belső munkatársak mellett a költöztető cég is részt vesz végrehajtásban, megosztva a feladatokat (1)+(2).
Mindegyik szervezeti elemet kell-e szerepeltetni a táblázatban? (Szervezeti egység, beosztás, szerepkör)
Nem szükséges mindegyik szervezeti elemet szerepeltetni a táblázatban, azonban végrehajtót mindegyik tevékenységhez hozzá kell rendelni. A tapasztalatok szerint az alábbiakra érdemes különösen figyelni a szervezeti elemek használatakor.
ˇ Elsődlegesen a szervezeti egységeket célszerű a szervezeti elemek megjelölésére használni. Akkor használjuk a beosztást, ha az egyértelműen elválik a szervezeti egységtől (például: dékán – dékáni hivatal).
ˇ A szerepkörök használata akkor eredményes, ha a tevékenységhez az értékkészletben szereplő szervezeti egységek közül több is hozzárendelhető.
Jellemző példa a beszerzés folyamata, ahol kötelezettségvállaló, megrendelő szinte bármely szervezeti egység lehet.
(Az értékkészlet bővíthető, megállapodás szerint az erre irányuló igényt a projektvezető jelzi az IFUA felé.)
ˇ Ha az adott tevékenységen belül fontos a végrehajtás és a döntés felelősségét elválasztani, akkor az érintett két szervezeti elem megjelölését követően a kapcsolattípus értékkészletéből a végrehajt és dönt elemek hozzárendelésével ez megvalósítható.
ˇ A később törvényszerűen szükségessé váló módosítások jó részét ki lehet küszöbölni azzal, ha a szervezeti egységeket nem az intézmény jelenlegi szervezeti felépítését leképező módon rendeljük hozzá a folyamatmodellekhez, hanem a normatív modellben megfelelőnek tartott munkamegosztás szerint.
A „dönt” kapcsolódástípus alkalmazásának következménye általában a folyamat elágazása
Ha egy tevékenységhez valamilyen szervezeti szereplőt „dönt” kapcsolattípussal rendelünk, akkor a döntés következményeit a folyamatmodellben is meg kell jeleníteni. Ez pl. jelentheti azt, hogy a javaslatot elfogadják / elutasítják – ennek megfelelően mindkét folyamatágat ki kell fejteni (mi történik akkor, ha a javaslatot elfogadják, és mi akkor, ha elutasítják).
Szerepelhet-e több szervezeti szereplő döntési kompetenciával ugyanazon tevékenységnél?
Általában kerülendő az, hogy két szervezeti egység is „dönt” kapcsolattípust kapjon ugyanazon tevékenység esetében – csak akkor érdemes ezt alkalmazni, ha nyomós oka van (pl. mindkét szereplőnek vétójoga van).
Mi „számít” dokumentumnak, és mi nem?
A dokumentumok körét nehéz előzetesen meghatározni, néhány hüvelykujjszabályt lehet csak mondani. Az adott tevékenység szempontjából túl általános, nehezen meghatározható tartalmú dokumentumokat nem szükséges feltüntetni a modellben (pl. vélemények, jogi háttér). Általában azokat a dokumentumokat érdemes megjeleníteni a modellben, amelyek
ˇ standard információtartalommal rendelkeznek és formalizálhatóak (pl. egy belső megrendelőlap vagy egy egyéni teljesítményértékelő lap);
ˇ egységes dokumentumként döntés tárgyát képezik vagy terjesztésre kerülnek (pl. intézményi stratégia);
ˇ más folyamatok számára is fontos információkat biztosítanak (pl. a nemzetközi kapcsolatok helyzetértékelése) ;
ˇ a tevékenység szempontjából fontos és nevesíthető információforrást jelentenek (pl. Nemzeti Fejlesztési Terv).
Ha egy dokumentum csak arra szolgál, hogy két egymást követő tevékenységet összekössön (és máshol nem is jelenik meg) – például „fejlesztési igények struktúrálatlan halmaza” –, akkor nyugodtan elhagyható a modellből.
Az adott tevékenységhez kapcsolódó dokumentumokat lehetőleg teljeskörűen adjuk meg, ne csak példálózó jelleggel – a modell használhatóságát javítja, ha a "dokumentumnézet" is konzisztens.
Hogyan nevezzük el a dokumentumokat?
A dokumentumok elnevezését minél pontosabban határozzuk meg – pl. az "elemzések" elnevezés nem jelzi kellőképpen a dokumentum tartalmát, nem alkalmas annak azonosítására a folyamaton „kívül”, egy lekért dokumentumlistában. (Az ARIS adatbázisban az „Elemzések” elnevezés ugyanazt az objektumot jelölné minden folyamatban, holott nyilvánvaló, hogy az egyes folyamatokhoz kapcsolódó elemzések tartalma komoly eltérést mutathat.)
Hogyan jelöljük a dokumentumok „státuszait”?
Lehetséges, hogy egy dokumentum változik egy folyamat során (pl. első javaslat, megvitatott javaslat, előterjesztés, módosított előterjesztés, végleges dokumentum). A dokumentumoknak ezeket a „státuszait” nem jelöljük külön a modellben, minden érintett tevékenységhez ugyanazt a dokumentumelnevezést csatoljuk (pl. intézményi stratégia). Ezáltal egyszerűbb és áttekinthetőbb lesz a modell, az egyes státuszokat pedig a tevékenységek elnevezése úgyis jelzi (pl. intézményi stratégia előterjesztése, intézményi stratégia véglegesítése). Az ARIS modellben szaggatott vonallal jelenik meg, ha egy dokumentum tartalma módosul egy adott tevékenység elvégzése során (tehát, ha az adott dokumentum inputja és outputja is az adott tevékenységnek).
|