1. Az EPC funkciódiagramnak legalább egy kezdő eseménnyel kell kezdődnie (a start esemény követheti a folyamat interfészt), és legalább egy befejező eseménnyel kell végződnie (a befejező esemény megelőzheti a folyamat interfészt).

2. A folyamat végrehajtása során az eseményeknek és funkcióknak váltakozniuk kell. A folyamat további menetéről a funkciók döntenek.

3. Az ajánlott függvényszám a diagramon nem több, mint 20. Ha a diagramfüggvények száma jelentősen meghaladja a 20-at, akkor fennáll annak a lehetősége, hogy a legfelső szintű folyamatok hibásan vannak kiemelve, és szükséges a modell javítása.

4. Az eseményeknek és funkcióknak szigorúan egy bejövő és egy kimenő kommunikációt kell tartalmazniuk, tükrözve a folyamat előrehaladását.

5. A fenti diagramban szereplő függvényt körülvevő események és operátorok ( 16. ábra) legyen a start/eredmény események és operátorok a függvénybontási diagramban ( 17. ábra).

16. ábra Folyamatdiagram, ahol az 1. funkció előfordul	17. ábra Dekompozíciós diagram 1. funkció

6. A diagram nem tartalmazhat egyetlen kapcsolat nélküli objektumot.

7. Minden egyesítő operátornak legalább két bejövő és csak egy kimenő kapcsolattal kell rendelkeznie, az elágazó operátornak csak egy bejövő és legalább két kimenő kapcsolata lehet. Az üzemeltetőknek nem lehet egyszerre több bejövő és kimenő kapcsolata.

8. Ha az operátornak bejövő hivatkozása van az "event" elemről, akkor rendelkeznie kell egy kimenő hivatkozással a "function" elemhez és fordítva.

9. Egyetlen eseményt nem követhet "OR" vagy "XOR" operátor.

10. Az operátorok csak a funkciókat vagy csak az eseményeket egyesíthetik vagy eloszthatják. A funkció és az esemény egyidejű összevonása/elágazása nem lehetséges.

11. Az elágazó ágak kezelőjének és ezen ágak összevonásának kezelőjének azonosnak kell lennie. Az a helyzet is megengedett, ha az elágazás operátora "AND", az unió operátora "OR".

Példák elfogadható helyzetekre ( 18. ábra, 19. ábra, 20. ábra, 21. ábra):

18. ábra	19. ábra	20. ábra	21. ábra

Példa egy illegális helyzetre ( 22. ábra).

Minden dolog a határtalan sokféleség megnyilvánulási formája.

Kozma Prutkov

Bevezetés az eEPC-jelölésbe

Jelenleg az üzleti folyamatok grafikus ábrázolásának számos különböző elve létezik, amelyeket jelöléseknek neveznek. Miért van belőlük sok? Évtizedek óta mindenki felteszi ezt a kérdést, aki szembesül az üzleti folyamatok leírásának szükségességével. Nézzük az okokat. Három van belőlük (szerintem):

• - Különféle feladatok. Nem minden jelölés egyformán kényelmes a különböző problémák megoldására. Például a jelölés kényelmes lehet egy legfelső szintű üzleti folyamathoz, és egyáltalán nem alkalmas egy munkafolyamat leírására.

Az ilyen jelölések különböző fejlesztői. Különböző időkben a különböző fejlesztők megpróbáltak új elveket kidolgozni az áramkörök leírására. Jó szándékból tették, amikor a gyakorlatban olyan helyzetbe kerültek, amikor az általuk használt jelölések nem (vagy nem egyértelműen) tükrözték a szükséges finomságokat. Néha az evolúció során az ilyen jelölések mintegy párhuzamosakká váltak, pl. másképp néz ki, de ugyanazokat a problémákat oldja meg.

A kitűnésre való törekvés. Ilyenkor ismeretlen okból hirtelen felbukkan egy új jelölés, amiben nincs semmi kiemelkedő, de valamiért tökéletes know-how-ként népszerűsíti alkotója. Ez még mindig előfordul.

Ennek a cikknek nem az a célja, hogy mindenféle jelölést figyelembe vegyek (szándékosan nem nevezem meg), hanem az, hogy részletesen leírjam a jelöléseket, amelyeket a projektjeimhez választottam a legoptimálisabb hosszú keresés során. választási lehetőség.

Ha valakit érdekel, hogy mik azok a jelölések és mire használják őket, azt egy másik cikkben tervezem megtenni, aminek a címe "Beszéljünk a jelölésekről", de ez még tervben van.

Itt az ideje elkezdeni történetünket egy nagyon érdekes, egyszerű és praktikus eEPC jelölésről (lefordítva: a folyamatok eseményláncának kiterjesztett leírása). Szó szerinti fordításából is kiderül fő célja: az üzleti folyamatok láncolatának leírása. A jelölés fő "trükkje" az "eseményesség" elve, amelyet részletesen megvizsgálunk.

Melyek az eEPC jelölés előnyei:

1. Először is, ez nem igazán tiszta jelölés. Azok. ha egyes jelölésekben merev elemek és használatukra vonatkozó szabályok vannak (különben minden összezavarodik), akkor az eEPC-elv lehetővé teszi saját elemek hozzáadását. Hogyan biztosított ez? Persze van egy bizonyos „mag”, ami köré minden épül, pl. világos szabályok készlete, amelyek alapján a sémát felépítik, és amelyek szerint olvassák. Ezenkívül hozzáadhat saját elemet, beépítheti a használatának szabályait a saját vállalati szabványába (hogy kizárja azokat az amatőr akciókat, amelyek megzavarhatják a diagramot és megnehezíthetik az olvashatóságot), és kész! Ez egy nagyon fontos szempont. Ezen túlmenően, bármilyen egyéb korlátozás és szabály beállítható a vállalati szabványban.
2. Az eEPC logikai elemeket tartalmaz. Ez lehetővé teszi sémák felépítését olyan feltételekkel, amelyek szükségesek a tevékenység leírásához ("ha a szerződés megegyezik, akkor ...., Ellenkező esetben ...")
3. Az elemek egyszerűsége lehetővé teszi a diagramok rajzolását mind szoftvertermékekben, mind bármilyen más módon, akár papíron is, nem fog összezavarodni.
4. Az eEPC olyan könnyen megtanulható és megérthető, hogy a való életben is használható, nem csak a szekrényben gyűjti a port. A szabályok elsajátítása körülbelül 2 órát vesz igénybe (ha a tanuló úgy kívánja).

Természetesen, mint mindennek ezen a világon, ennek is vannak hátrányai. De az ésszerű használat minimálisra csökkenti őket. A fő hátrány szerintem az, hogy ha egyszerű eszközöket használunk (pl. diagramok rajzolására és nem üzleti folyamatok modellezésére szolgáló programokat), akkor nincs egyetlen objektumadatbázisunk sem. Ráadásul a be- és kimenetek vezérlése is nehézkes (szabályozni kell, vagyis szükség esetén ki kell találni a vezérlés módját). Másrészt viszont az összetett üzleti folyamatok modellezésére szolgáló eszközök használata igen lenyűgöző összegbe kerül, az ezeket használó projekt pedig milliókban mérhető. Így van egy nagyon gazdaságos és érthető eszközünk. Pontosabban, ez a hiányosság kifejezetten az általam vizsgált leírási módra vonatkozik, pl. MS Visio vagy hasonló szoftver használatával. Ha speciális rendszereket használ az üzleti folyamatok leírására, amelyek támogatják az objektumok adatbázisait, akkor ez a hátrány elkerülhető. Nos, ideje elkezdeni...

Az eEPC-jelölés fő tengelye

Mint már említettem, az eEPC rövidítés szó szerinti fordítása magában rejti az eseményszerűség fogalmát. Ez egy nagyon fontos pont, amelyre az áramkör építésének teljes elve épül. Tehát két kulcsfogalom létezik: „Esemény” és „Funkció”. Amikor valaki először próbálja megrajzolni a folyamatát eEPC diagram formájában, gyakran felmerül a kérdés, hogy miben különbözik egy esemény a függvénytől? Ennek világosnak kell lennie önmaga számára, különben kiszámíthatatlan eredményt kap. Tehát: az esemény valaminek a megvalósulásának ténye, és nincs időbeli időtartama, vagy ez az idő nullára hajlik (vagy nem számít). Sőt, egy esemény mindig egy függvény végrehajtásának szükségességét idézi elő, és egy függvény végrehajtása mindig eseménnyel végződik Hadd magyarázzam el egy példával. A telefon csörög. A menedzser felvette a telefont telefonbeszélgetés céljából. Ebben az esetben a „Cseng a telefon” egy esemény. A telefonbeszélgetés egy funkció. A beszélgetés véget ért (letette) - ismét esemény. Így megfigyelhető az események láncolata: Hívás - beszélgetés - hívás vége. A hívás befejezéséhez pedig valószínűleg új funkcióra lesz szükség: a hívás eredményének rögzítésére stb.

Próbáljuk meg lerajzolni. Először is ki kell találnia, hogyan jelennek meg az „Esemény” és „Funkció” elemek.

Ez a két egyszerű elem képezi az alapját az üzleti folyamatok leírásának szabályainak az eEPC-jelölésben. Azt hiszem, néhány szót kell ejtenem a használt színekről. Ha találkozott a folyamatok leírásával más jelölésekkel, az általában fekete-fehér volt. És ez így van, nem szabad, hogy a tartalom kifejezetten függjön a színtől, mert az ábra ceruzával papírra rajzolható, fekete-fehér nyomtatóra nyomtatható, stb. Ebben az esetben (eEPC jelölésben) történelmileg előfordult, hogy az elemek bizonyos színűek. Nem azt mondom, hogy szükség volt rá, de kialakul a megszokás, és az elektronikus formában való érzékelés is jobb - azonnal látszik, hogy melyik melyik. Ezek a színek iránymutatónak tekinthetők. Miért ilyenek? Nem tudom pontosan, de nekem úgy tűnik, hogy az ARIS cég, amikor támogatta az eEPC jelölést a termékében, ilyen színeket adott nekik, ezek "leragadtak". Egyébként ezt a jelölést néha "ARIS"-nak, "ARIS EPC-nek" is hívják, ami nem teljesen helyes, mivel Az ARIS nem találta ki ezt a jelölést, hanem támogatta az üzleti folyamatmodellező szoftverében. Általában a színek használatát javaslom. A lényeg az, hogy az elemek formája nem azonos (azaz csak színben különbözik), hiszen fekete-fehérben ez zavaró lehet. Vannak más szabályok, amelyek lehetővé teszik, hogy "harmóniát" adjon az eEPC diagramnak, ezekről beszélünk.

Tehát van esemény, van funkció. hogyan kapcsolódnak egymáshoz?

Látjuk, hogy az esemény1 egy bizonyos funkció végrehajtásának szükségességéhez vezetett, ami az esemény2-vel végződött. Ha telefonhívással alkalmazzuk a példára, akkor a következő lesz:

Egy eseményt - függvényt - szokás fentről lefelé egy sorban, illetve balról jobbra megjeleníteni. A lánc irányát összekötő vonalak nyilakkal jelzik. Annak érdekében, hogy a diagram leíróbb legyen, a jelölés még néhány szabványos elemet tartalmaz:

• Pozíció (előadó). Aki ezt a funkciót ellátja
• Információ. Bármilyen információ, amelyet valamely funkció végrehajtására használnak, kivéve a dokumentumfilmet. Például egy telefonhívás, egy művelet végrehajtására vonatkozó utasítások stb.
• Dokumentum. A „Dokumentum” elem információhordozók (papír vagy elektronikus) megjelenítésére szolgál. Azok. információ megjelenítése meghatározott struktúrában.
• Program (jelentkezés). A funkció végrehajtásához használt szoftver.

Az összes többi elem kiegészítő jellegű, és gyakorlatilag nem szabályozzák maga az eEPC követelményei. Azonban nincs akadálya saját elemek hozzáadásának. A lényeg az, hogy ezt rögzítsék a belső szabványban, hogy egységes legyen, hogyan néznek ki és miért használják őket. Egy ilyen kiterjesztés nem sérti a követelményeket, ha az esemény-funkció-esemény kapcsolat nem sérül, és csak az információ észlelésének javítására vagy a leírási szabályok adaptálására szolgál bármely iparági specifikusan. Hozzáadtam a saját elemkészletemet, amelyet az alábbiakban tárgyalok.

Azt is meg kell találni, hogy a figyelembe vett elemek hogyan helyezkedjenek el. Mindezeket az elemeket valamilyen módon társítani kell egy függvényhez. Ez egy általános ökölszabály: egyetlen elem sem társítható más eseményhez, csak egy függvényhez. Azok. mindezeket az elemeket nyilakkal kell összekötni a funkcióval. Ami a nyilakat és azok irányát illeti: általánosan elfogadott, hogy ha nincs információátviteli irány, akkor nyíl helyett vonal jelenik meg. Ha információ lép be (bemenet), akkor a nyíl iránya az objektumtól a függvény felé, ha kilép, akkor fordítva.

Még néhány szó ezeknek az elemeknek a diagramon való elhelyezkedéséről, és a híváskezelési funkció végrehajtásának megadásával átrajzolhatja diagramunkat. Az elemek elrendezésére nincsenek szigorú követelmények, de ezeket minden diagramon egyformán szokás megjeleníteni (az ábra egységessége, harmóniája érdekében). Az üzleti folyamatok grafikus diagramjainak megjelenésének egységesítéséhez az ilyen szabályokat a belső szabványban kell rögzíteni és be kell tartani. Kicsit később adok néhány ajánlást ezzel kapcsolatban. Most rajzoljuk újra a sémánkat:

Azt látjuk, hogy az operátor a bejövő hívások feldolgozására vonatkozó szabályok szerint dolgoz fel egy bejövő hívást, és ehhez a „CRM” programot használja. Ebben az esetben sem a bejövő, sem a kimenő dokumentumok nem kerülnek felhasználásra.

Mint korábban említettem, a jelölés egyik erőssége a logika elemeiben rejlik. Ugyanakkor ez az egyik legnehezebben megérthető pillanat. Ezért először mondok egy példát, majd külön foglalkozunk a logika elemeivel.

Legyen ez a mi példánkban: ha az ügyfél érdeklődik, az értékesítési vezető folytat vele a további munkát, és tesz egy kereskedelmi ajánlatot, amelyet postai úton küld el az „MS Outlook” levelezőkliens segítségével. Ha nincs érdeklődés, akkor a hívás feldolgozásra kerül. A való életben jó lenne a hívás befejezésének szabályait alkalmazni, de mellesleg ez én vagyok, egyelőre leegyszerűsítjük. Íme, amit kapsz:

Logikai elemek az eEPC jelölési sémákban

A logika elemei egyszerűek, de vannak sajátosságok és szabályok, hogy a séma logikus és egyértelműen értelmezhető legyen. A 100%-os betartás legfontosabb szabálya az, hogy logikai döntéseket csak akkor lehet meghozni, ha egy függvényt végrehajtanak. Azok. nem lehet elágazás valamilyen esemény után. Miért? Mert ebben az esetben ez ellentmond az esemény fogalmának – egyszerű és azonnali, végrehajtási idő nélkül. Például, ha csörgött a telefon, és az ember ülve gondolkodik azon, hogy felvegye vagy ne vegye fel a telefont, akkor elméletileg ez már egy olyan funkció lesz, ahol ő dönt. De gyakorlatilag, józan észből is, sérti a híváskezelési szabályokat, tk. fizetést kap azért, hogy kezelje ezeket a hívásokat, és nincs miről vitatkozni (általában, ahogy a diagramon látható).

Összességében a logikának 3 eleme van:

• I. Ha két vagy több esemény történik egyszerre;
• VAGY. Amikor egy vagy több esemény bekövetkezhet, de legalább egynek meg kell történnie;
• KIZÁRÓLAGOS VAGY. Vagy az egyik, vagy a másik. Azok. két lehetőség egyszerre lehetetlen.

Mint látható, a logikai elemek grafikus megjelenítésére két lehetőség van. Nem különböznek egymástól, teljesen alternatívak. Mindkettőt elhoztam, mert a gyakorlatban mindkét lehetőséget láthatja különböző forrásokban. Ön dönti el, hogy melyiket használja. Nekem az első jobban tetszik.

Most ki kell találnia, hogyan használja a logika elemeit. Először megvizsgáljuk a felmerülő lehetőségeket, majd továbblépünk egy példára. Nézzük meg az egyes elemeket külön-külön.

Logikai elem "AND". Ha egy függvénynek több esemény egyidejű futtatásához szükséges:

Példa: Ha a beszámolási időszak lezárult (1. esemény), és eljött a vezetőnek történő bejelentés határideje (2. esemény), a munkavállaló havi jelentést készít.

Elemek összekapcsolása, ha egy függvény végrehajtása során több esemény történik:

Példa: Elvégzett néhány munkát egy ügyféllel. Egyszerre két esemény került rögzítésre: a kölcsönös elszámolások egyeztetése (1. esemény), az okirat aláírása (2. esemény). A gyakorlatban ez az alkalmazás nem általános. Általános szabály, hogy ha sok műveletet egyesítenek egy funkcióban

Elemek összekapcsolása, ha több funkció végrehajtása során egy esemény történik:

Példa: A raktáros felvette a rendelést (1. funkció), az üzemeltető kiírta a dokumentumokat (2. funkció), az áru készen áll a szállításra (esemény).

Elemek összekapcsolása, ha egy esemény bekövetkezése több funkció végrehajtásához vezet:

Példa: Egy köteg áru (esemény) érkezett. Ezzel egyidejűleg megkezdődik a vevők által korábban megrendelt áruk kiszállítása és megkezdődik a megmaradt áruk raktárban történő elhelyezése.

Logikai elem "OR".

Elemek összekapcsolása, ha valamelyik esemény a függvény végrehajtását okozhatja:

Példa: A telefonon érkezett kérelem (1. esemény) vagy e-mailben (2. esemény) érkezett kérelem feldolgozása szükségessé válik.

Csatlakozó elemek, ha egy függvény képes legalább egy eseményt kiváltani:

Példa: Elkészítette és elküldte az áruszámlát az ügyfélnek történő elküldésre. A számlát postai úton (1. esemény), faxon (2. esemény) lehetett elküldeni.

Logikai elem "EXCLUSIVE OR".

Összekötő elemek, amikor egy funkció végrehajtásához csak egy esemény szükséges:

Példa: Egy vásárló személyesen érkezett az üzletbe (1. esemény), vagy megrendelést adott le az interneten keresztül (2. esemény). Az árut el kell küldenie (1. funkció).

Elemek összekapcsolása, ha a függvény végrehajtása következtében legfeljebb egy esemény következik be:

Példa: A döntés vagy megszületik, vagy nem.

Elemek összekapcsolása, ha az esemény csak egy függvény végrehajtása után következik be.

Példa: Az áruk kiszállítását (1. esemény) vagy saját szállítmányozással (1. funkció), vagy egy szállító céggel (2. funkció) végeztük.

A logikai elemek helyes alkalmazása gyakorlást igényel. De nem nehéz. Megjegyzendő, hogy nem minden figyelembe vett kombinációt alkalmaznak széles körben a gyakorlatban (és általában az elemző gondolkodásmódja határozza meg). Próbálja meg a logika elemeit a gyakorlatban átültetni. Ha bármilyen nehézséged van, írj, megpróbálok segíteni.

A jelölések kiterjesztése saját elemekkel

Mint mondtam, az eEPC valójában nem jelölés, hanem inkább leírási szabályok. És ezek a szabályok nem tiltják saját elemek hozzáadását a diagramhoz. A lényeg az, hogy ezek az elemek érthetőek legyenek, és van egy dokumentum, ahol rögzítik az ilyen elemkiterjesztéseket. Például a következő kiegészítő elemeket használom, amelyek fokozatosan jelentek meg a különböző feladatok valós folyamatainak leírása során, az egyszerű leírásoktól az automatizálási feladatok beállításáig.

Adatfájl. Akkor használatos, ha egy művelet eredményeként adatfájl jön létre, vagy a fájlt művelet végrehajtására használják.

Adatbázis. Az automatizált rendszerek közötti információáramlás leírására szolgál.

Kártyafájl. Papírfájl vagy archívum megjelenítésére szolgál.

Anyagáramlás. A bejövő és kimenő anyagáramlások, valamint a folyamat végrehajtása során felhasznált erőforrások jelzésére szolgál. Az anyagáramlás a kísérő dokumentumoktól balra látható.

Információk klasztere. Strukturált információ (entitás reprezentáció) jelzésére szolgál. A diagram használható egyedi alkalmazások segítségével programozottan előállított dokumentumokra. Ebben az esetben a „Cluster” elem a megfelelő dokumentumtól balra található. Azok. azt jelzi, hogy a felhasználó nemcsak papíralapú dokumentumot hozott létre, hanem másolatot is készített róla a programban.

Konvenciók az alakzatok diagramban való elhelyezésére vonatkozóan

Önmagában az eEPC jelölés nem támaszt szigorú követelményeket az elemek egymáshoz viszonyított elrendezésében, bár a diagramot fentről lefelé vagy balról jobbra szokás rajzolni. Ha ez több szakember munkája esetén nem egységes, akkor egyfajta „vinaigrette” alakulhat ki. Ennek elkerülése érdekében javasolt az elemek elrendezésére vonatkozó saját szabályok kidolgozása és jóváhagyása. Az alábbi irányelveket követem (és javaslom):

• Az események és funkciók sorrendje fentről lefelé (jobb) vagy balról jobbra (ha nincs elég hely) van elrendezve;
• Az előadókat jelölő elemek a funkcióktól jobbra helyezkednek el;
• Bejövő dokumentumok a funkciók bal felső sarkában; nyíl iránya a dokumentumoktól a funkcióig;
• Kimenő dokumentumok a funkciók bal alsó sarkában; nyíl iránya a funkciótól a dokumentumok felé;
• Az "Információ" elem a funkció jobb alsó sarkában található. Ha nincs elég hely, tetszőleges elrendezés megengedett, a funkcióhoz a lehető legközelebb;
• Az Alkalmazás elem a függvények jobb felső sarkában található. (ha nem jelentésnek minősülő fájltárolókat használunk erre, akkor azok ugyanúgy megjelennek). Kommunikáció nyíl nélkül.
• Az „Adatbázis” és a „kártyaindex” elemek véletlenszerűen helyezkednek el;
• Az „Anyagáramlás” elem a kísérő dokumentumoktól balra található, a dokumentumra egy nyíl nélküli vonallal hivatkozva;
• A „Cluster” elem a „Dokumentum” alakzattal együtt használva egy elektronikus formátumú dokumentum jelzésére a megfelelő dokumentumtól balra található.

Például: A bérkalkulátor a rendelkezésére bocsátott "Dandár felszerelés" dokumentumok alapján számolja ki a béreket. Ugyanakkor a „Bérekre vonatkozó szabályok” dokumentum vezérli, a számítást az „1C: ZiK” programban végzik. A számítás eredménye a „Kivonat” dokumentum.

Elemek azonosítása diagramon

Mint ismeretes, az üzleti folyamatok leírásának kompetens megközelítése magában foglalja azok azonosítását, pl. amikor minden folyamatnak saját kódneve van. Ennek megfelelően a folyamaton belüli egyes funkcióknak is megvan a saját neve és azonosítója.

A "Dokumentum" és a "Funkció" ábrákat kötelezően azonosítani kell a diagramon.

A bizonylat azonosítása a jelentés vagy bizonylat bal felső sarkában található iktatókönyv szerinti kód feltüntetésével történik. Az áruk és szolgáltatások szállítóitól kapott (bejövő) dokumentumok csak név szerint azonosíthatók.

Egy függvény azonosítása a folyamatcsoporthoz tartozó függvény sorszámának megadásával történik. Azok. a függvényszám mindig a folyamatcsoport kódjával kezdődik. A folyamatcsoportok azonosításának kérdései túlmutatnak jelen cikk keretein, ezeket külön tárgyaljuk. Ezenkívül meg kell tanulnia azonosítani a folyamatokat, mielőtt elkezdi leírni őket, különben felmerülhet a vágy, hogy a vállalat összes tevékenységét egy diagramon írja le, ahogyan néha megpróbálják.

Ezért most csak egy példával mutatom meg, hogyan ábrázolható ez a diagramon. Térjünk vissza a híváskezelési példához. Tegyük fel, hogy a „04” kódot az értékesítési osztályhoz rendeltük, a „VK” kódot pedig a bejövő kapcsolat feldolgozási folyamatához. Ezután a diagram a következő formában jelenik meg (az azonosítás az egyértelműség kedvéért pirossal van kiemelve). A bizonylatkód egyúttal az irat általános okmánynyilvántartásban szereplő sorszámát is jelzi (erről külön is szót ejtünk, amikor az iratkezelő rendszer vizsgálatához érünk).

Visszajelzés kijelző

A modellek felépítésénél gyakran szükséges valamilyen feltételnek megfelelő ciklikus folyamat végrehajtása vagy a döntéshozók tevékenységének tükrözése. Ebben az esetben visszajelzésről beszélünk. A vezérlési visszacsatolás megjelenítéséhez a "közvetlen beillesztés" elvét alkalmazzák egy további vezérlőfunkció folyamatába, majd ezt követően elágazzák (az "Exkluzív VAGY" logikai elemet használják). Például:

A folyamatok szöveges leírása

Bármennyire is próbálunk egy üzleti folyamatot diagramon megjeleníteni, nem sikerül teljes részletességgel elérni, különben elakadhat az elemek és feltételek végtelen láncolata. Ennek elkerülésére, valamint a folyamat leírásához grafikusan nem megjeleníthető információkkal egészítjük ki a leírást szöveges kísérettel. Ehhez különféle szövegsablonokat dolgoznak ki, amelyeket a leírás során töltenek ki. Az ilyen sablonok formái különbözőek lehetnek, külön szakaszokat tartalmazhatnak a bemenetek és kimenetek leírásával, az elhasznált erőforrásokkal, a használt szoftverekkel stb.

A legegyszerűbb esetben egy üzleti folyamatleíró sablon így nézhet ki:

Üzleti folyamat:	Bejövő kapcsolat feldolgozása	04.VK
A folyamat funkciói:
Név	Leírás	Szám a diagramon
Bejövő hívások feldolgozása	Ha bejövő hívás érkezik, az operátor a hívást a bejövő hívások feldolgozására vonatkozó szabályok szerint dolgozza fel. Azonosítja az ügyfél érdeklődését, tájékoztatást ad a szolgáltatásokról	04. ВК.01
Kereskedelmi ajánlat megalkotása	Ügyfél érdeklődése esetén az üzemeltető a kapcsolatot átadja az értékesítési vezetőnek. Az értékesítési vezető elkészíti a kereskedelmi ajánlatot és e-mailben elküldi az ügyfélnek	04.VK.02
Folyamatjelzők:
Név	Értékelés / mérési módszer
Az elutasítások száma	Adatbázis statisztika

E cikk hatókörén kívül olyan fontos témák is szerepelnek, mint az információgyűjtés, az üzleti folyamatok elkülönítése, a dekompozíció és a mutatók azonosítása. Ezeket a kérdéseket mindenképpen tanulmányozni fogjuk a következő számokban.

EPC szabvány

Az EPC (Event-Driven Process Chain) egy folyamat előrehaladásának megjelenítésére szolgáló jelölés, amelynek kulcselemei az események és a funkciók. Az EPC jelölést a XX. század 90-es éveiben fejlesztették ki. Az EPC-t Wilhelm-August Scheer német professzor találta ki az ARIS módszertan keretein belül.

Az EPC-ben az üzleti folyamat diagramjának eseménnyel kell kezdődnie és végződnie. A függvényt mindig eseménynek kell követnie, vagyis a függvény végrehajtása valamilyen eseményt (állapotot) hoz létre. A dokumentumok, szervezeti kapcsolatok, információ- és anyagáramlások, az információs rendszer elemei (szoftverek, adatbázisok) saját grafikai jelöléssel rendelkeznek. Egy folyamat elágazásához az ÉS, VAGY, kizárólagos VAGY operátorokat használjuk.

Az EPC az üzleti modell leírásának alsó szintjein használatos, amikor a feladat egy üzleti folyamat részletes folyamatának leírása. Az EPC függvények felbonthatók (részletes üzleti folyamatokra bontva csak EPC jelöléssel).

Az EPC hátrányai közé tartozik, hogy ez a jelölés nagyon sokféle grafikus elemet tartalmaz, ami más jelölésekhez képest nehezen érthető lehet. A folyamatok fejlesztése ebben a jelölésben és azok olvasata megköveteli a dolgozók előzetes képzését.

Az EPC előnyei közé tartozik, hogy nagyon részletesen és pontosan leírható egy üzleti folyamat végrehajtása, grafikus formában ábrázolható diagramon minden előadó, minden felhasznált objektum. Az EPC diagramok másik előnye, hogy az IDEF0 diagramokhoz hasonlóan itt is megadhatjuk az egyes funkciók bemeneti és kimeneti adatait, nyomon követhetjük a bemeneti és kimeneti adatok mozgásának logikáját blokkról blokkra. Ezenkívül, az azonos IDEF0-tól eltérően, lehetővé vált a folyamat párhuzamosítása, csak az egyik alternatív ág mentén irányítva (IDEF0-ban, ha párhuzamosságot adunk a végrehajtáshoz, akkor az összes párhuzamos függvény egyszerre fog végrehajtani). Az is előnynek tűnt számomra, hogy minden szakaszhoz (értsd: függvényekhez) meg lehetett adni a végrehajtót. De az IDEF0-ban a végrehajtó minden dekompozíciós szinten egyszer meg van adva, és az ő nevében a nyilak az általa végrehajtott összes blokkra nyúlnak. Az EPC-ben annak kiszámításához, hogy hány műveletet hajt végre az előadó, végig kell menni az összes műveleti blokkon, és ellenőrizni kell, hogy a számunkra szükséges előadót jelzi-e.

Ez a jelölés nagyon vonzónak bizonyult a folyamat végrehajtásának nyomon követése szempontjából - minden függvény változatlanul átviszi a rendszert egy új állapotba, amiből az következik, hogy az egyes funkciók végrehajtása után a rendszer ellenőrizhető, hogy az átmenet a kívánt állapotba ténylegesen végrehajtották.

Általánosságban elmondható, hogy az EPC-jelölést világszerte elismerik, mint az egyik legjobb jelölést az üzleti folyamatok felépítésére és a vállalati működés modellezésére.

Modellezési módszer kiválasztása

A szükséges üzleti folyamat modellezéséhez a BPMN módszertant választottuk. Ez a választás annak a ténynek köszönhető, hogy a BPMN jelölés lehetővé teszi a logikai folyamatok legpontosabb megjelenítését olyan feladatok végrehajtása során, amelyek a műveletek sorrendjének nagy pontosságú leírását igénylik, bemutatják az alkalmazottak és az ügyfél interakcióját, és lehetővé teszik hogy megmutassa az egyes feladatok végrehajtása közötti időbeli eltérést.

2010. szeptember 22. 20:30

"Sárkányok, vak ember buff és cédula
Bújócska, labdák, ugróbéka és ugrókötelek,
És egyszerű, egyszerű, és csak ugrókötelek,
Hát egyszerű, egyszerű, csak ugrókötelek!!!"

A.Vratarev

A cikk elkészítése során felfedeztem egy hihetetlen tényt: az EPC jelölésről, amely olyan egyszerű és annyira népszerű (vannak olyan vélemények, hogy még a BPMN-nél is népszerűbb), mindössze 4 nyelven vannak cikkek a Wikipédián: angol, német, cseh és üzbég. Ráadásul ezek a cikkek meglehetősen rövidek. Talán a cikk végére te és én, kedves olvasó, megértjük, miért.

Először is, az EPC jelölést az 1990-es évek elején fejlesztették ki. az ARIS módszertan fejlesztése során, mint mondjuk annak folyamateleme. Az EPC alapító atyja Wilhelm-August Scheer professzor, akinek a neve már csak hangzásánál fogva félelmet kelt a laikusban (kimondja hangosan és érezze). Mit is mondhatnánk annak a karnak a nevéről, ahol ez a tekintélyes bácsi dolgozott: Institut für Wirtschaftsinformatik of the University of Universität des Saarlandes.

Az EPC jelölés létrehozásának célja az volt, hogy a folyamatokat le lehessen írni úgy, hogy a bennük végrehajtott funkciók a diagram keretein belül globális szemantikával rendelkezzenek, ami azt jelenti, hogy egy függvény végrehajtása az EPC diagramokon nem feltétlenül pontosan meghatározott, hanem függhet a diagram többi csomópontjának állapotától, amelyek néha nagyon távol vannak egymástól.

A jelölés neve az Event-driven Process Chain rövidítése, ami egyértelműen jelzi, hogy az események az EPC jelölési diagramok központi eleme. Az események bizonyos résztvevők által bizonyos műveletek végrehajtását váltják ki. A műveletek végrehajtásának befejezése pedig újabb eseményt generál, és így tovább, amíg a rendszer olyan állapotba nem kerül, amelynek megjelenése a folyamaton belüli végső eseménynek minősül.

A jelölés lehetőségeinek egyértelmű bemutatására egy hétköznapi példát használok, amelyet a közelmúltban befejeződött meleg vidéki nyaralás ihletett. Egy elismert szálloda recepciósa, Ivo Petkov az egyik vendégtől kérést kap a szobában lévő mosóeszközök sürgős cseréjére. Teljesen érthető, hogy feladata az ügyfél kérésének teljesítése, illetve EPC szempontjából a rendszer „Megérkezett mosótartozékok cseréjére vonatkozó kérés” állapotból a „Ügyfél kérése kielégítve” állapotba hozni a rendszert.

A vázlatrajzon feltesszük a két jelzett állapotot, és azonnal észrevesszük, milyen könnyen olvasható lesz a diagramunk, mert minden elemének nemcsak formája, hanem színe is van. Tehát az események piros hatszögek, a funkciók zöld téglalapok lekerekített élekkel, az előadók pedig sárga oválisok.

Szóval, vissza a példához. Az ügyfél kérésének kézhezvétele után az Ivo-nak azonnal kérést kell küldenie a szobalánynak az ügyfél kérésének teljesítésére, ezzel a rendszert "Teljesítési kérelem elküldve" állapotba hozza. A szobalány a raktárban lévő készletet felhasználva teljesíti Ivo kérését. És itt jelenik meg először folyamatunk párhuzamosítása: ha a szobalány rájön, hogy a szükséges mosási kellékek (mondjuk tusfürdő) nincsenek most a raktárban, akkor ő maga, talán nem is akarja, állapotba hozza a rendszert. „A kérést nem lehet teljesíteni”, amiből természetesen az következik, hogy Ivonak nem a legkellemesebb beszélgetést kell folytatnia az ügyféllel, és az, hogy a rendszer milyen állapotba kerül, csak az ügyfél indulataitól és harci hajlamától függ. Ha a raktárban minden szükséges kellék megvan a vendég számára, akkor a szobalány sikeresen teljesíti a neki küldött kérést, a teljesítésről jelentést tesz Ivónak, aki viszont erről tájékoztatja az ügyfelet. És mindenki boldogan él, míg meg nem hal, és ugyanazon a napon hal meg.

Ezt az egyszerű folyamatot tükrözi az 1. ábrán látható, örömmel kacsintó piros, zöld és sárga diagram.

Rizs. 1. EPC diagram a vevői kérelem feldolgozásának folyamatáról egy szállodában

És most, a hagyomány szerint, a jelölés előnyei és hátrányai.

Amikor először találkoztam az EPC diagramokkal, mint korábban említettem, nagyon megörültem, hogy milyen könnyen olvashatóak: minden blokk kiemelve van alakban és színben, nagyon jól látható az előadók, a szükséges anyagok, kiemelik a listát. a lehetséges rendszerállapotokról, a folyamatfüggvények menetének listája. Ez kétségtelenül óriási plusz: az ügyfélnek nem okoz nehézséget az EDMS implementációja során az üzleti folyamat diagram olvasása, ha az pontosan az EPC jelölésben szerepel. Elképzelhető azonban, hogy a megrendelőt összezavarja az állam ilyen gigantikus száma, mert valójában ezek miatt nagyon nő a rendszer. Még a mi példánkban is: néhány 4 függvény akár 5 állapotot is generált (a kezdeti állapotot nem számítva). Néha elgondolkozol azon, hogy miért kell mindet mutogatnod. Például miért szükséges a megállapodás vezérigazgató általi jóváhagyása után egy külön blokkban feltüntetni „A megállapodás megtörtént”, aláírás után pedig „A megállapodás aláírása megtörtént”, ha a folyamat még hátra van lineáris. Őszintén szólva, semmi szükség, hacsak nem Ön nyilvánvaló Kapitány.

És néha nem világos, hogyan kell kiválasztani azt az állapotot, amelybe a funkció átviszi a rendszert. Még ennek az egyszerű példának az elkészítése közben is tapasztaltam bizonyos nehézségeket, amelyek éppen ezzel a pillanattal kapcsolatosak.

Az EPC diagramok előnye, hogy az IDEF0 diagramokhoz hasonlóan itt is megadhatjuk az egyes funkciók bemeneti és kimeneti adatait, nyomon követhetjük a bemeneti és kimeneti adatok mozgásának logikáját blokkról blokkra. Ezenkívül, az azonos IDEF0-tól eltérően, lehetővé vált a folyamat párhuzamosítása, csak az egyik alternatív ág mentén irányítva (IDEF0-ban, ha párhuzamosságot adunk a végrehajtáshoz, akkor az összes párhuzamos függvény egyszerre fog végrehajtani). Az is előnynek tűnt számomra, hogy minden szakaszhoz (értsd: függvényekhez) meg lehetett adni a végrehajtót.

De! Az IDEF0-ban minden dekompozíciós szinten egyszer meg van adva a végrehajtó, és az általa végrehajtott összes blokkra nyilakat húznak a nevében. Az EPC-ben annak kiszámításához, hogy hány műveletet hajt végre az előadó, végig kell menni az összes műveleti blokkon, és ellenőrizni kell, hogy a számunkra szükséges előadót jelzi-e.

Ez a jelölés nagyon kényelmesnek tűnt számomra a folyamat végrehajtásának nyomon követése szempontjából: minden funkció minden bizonnyal új állapotba helyezi a rendszert, amiből az következik, hogy az egyes funkciók végrehajtása után ellenőrizhető a rendszer, hogy az a kívánt állapot valóban megvalósult. De rögtön felmerült a kérdés: valóban szükséges? Például ritkán van ilyen vágyam =)

Tehát általánosságban az EPC jelölés számomra kényelmetlennek tűnik az üzleti folyamatok leírására: túl sok figyelem az eseményekre, túl kevés figyelem a cselekvésekre, és különösen azok művész vagy a felhasznált anyagok szerinti csoportosítása. Igen, egyszerű, igen, gyönyörű, és igen, sajnos csak ennyit tudok róla elmondani, mint valószínűleg sok más emberről. =)

Az UML és BPMN jelölésekről szóló cikkek pedig egyre közelebb kerülnek.

(4,14 - 21 ember értékelte)

A folyamatmodell funkcionális, viselkedési, információs és szervezeti szempontok egymással összefüggő, integrált halmaza, de a ma újratervezési gyakorlatban használt modellek közül sok nem elégíti ki ezt.

2011.10.12. Igor Fedorov

A folyamatmodell funkcionális, viselkedési, információs és szervezeti nézőpontok egymással összefüggő, integrált halmaza, azonban számos ma az újratervezés gyakorlatában használt modell nem felel meg a folyamatmodellek követelményeinek, és nem nevezhető folyamatmodellnek, mivel hiányos képet ad. a modellezés tárgyát, és nem tartalmazzák a végrehajtható modell létrehozásához szükséges összes információt.

Az üzleti folyamatok modellezésére szolgáló jelölések megválasztásával kapcsolatos vita továbbra is folytatódik. Az elemzés megvizsgálja az EPC (Event-driven Process Chains) és a BPMN (Business Process Modeling Notation) képességeit, a szintaxist, a leírási nyelvi primitívek halmazát stb. Nem helyes azonban a jelöléseket és a nyelveket összehasonlítani egy vállalkozás leírásához. folyamat funkcionalitásuk elemzésével - a modell funkcionális vagy folyamatalapú-e, nemcsak a jelölést, hanem a módszertant is meghatározza. A modellezési módszert gyakran felváltja a jelölés, ami súlyos hibákhoz vezet az üzleti folyamatok tervezésében és rossz minőségű modellek megjelenéséhez.

Modellek és perspektívák

Modell- Ez egy tárgy vagy jelenség anyagi vagy mentális reprezentációja, amely megismétel néhány olyan tulajdonságot, amelyek egy adott modellezés céljaihoz elengedhetetlenek, és mellőznek más, jelentéktelen tulajdonságokat, amelyekben a modell eltérhet a prototípustól. Egy összetett objektumot, például egy üzleti folyamatot, egy sor modell ír le, amelyek mindegyike egy korlátozott tulajdonságkészletet jelenít meg, és együtt leírják a teljes modellezési objektumot. Mindegyik modellhez egy fő kérdés tartozik, amelyre a megfelelő modellnek válaszolnia kell. Az üzleti folyamatmodellnek négy perspektívája van (lásd az ábrát).

Funkcionális:– Mit csinálnak a résztvevők? Leírja az elvégzett munka körét.

Viselkedési:– Hogyan dolgoznak a résztvevők? Leírja a sorrendet, a végrehajtás ütemezését, az üzleti szabályokat.

Tájékoztató:– Mit dolgoznak fel a résztvevők? Leírja a folyamattartomány üzleti entitásait.

Szervezeti:– Ki végzi a munkát? Leírja az előadók összetételét és felépítését.

Egy-egy perspektívát leíró modell több kérdésre is választ ad, de ezek között mindig ott van a fő, amelyre a modellnek kimerítő választ kell adnia, és előfordulhat, hogy a továbbiak nem adnak teljes választ. Ez utóbbi esetben különösen óvatosnak kell lenni, a modell perspektíváját pontosan a fő kérdés határozza meg, nem pedig a segédkérdés.

Funkcionális perspektíva

A funkcionális modell statikus állapotban írja le a rendszert, és segít megválaszolni a "mit kell tenni a kitűzött cél elérése érdekében?" A válasz a tervezett eredmény eléréséhez szükséges összes művelet listája. A projektmenedzsmentben széles körben használják munkalebontás(Work Breakdown Structure) - a benne felsorolt ​​műveletek nem kapcsolódnak egymáshoz időben. Hasonlóképpen, a folyamatok modellezésekor nagyon hasznos olyan szerkezeti felbontást létrehozni, amely segít megérteni a folyamat logikáját, és ne felejtse el végrehajtani a fontos funkciókat. Ha két különböző szervezet hajtja végre ugyanazt a folyamatot, akkor a munka funkcionális felosztása azonos lesz számukra, bár a munkavégzés sorrendje eltérő lehet, figyelembe véve a szervezeti felépítésük eltéréseit. Így a funkcionális modell gyengén függ a szervezeti struktúrától és referenciaként tekinthető.

A funkcionális modellt gyakran tévesen folyamattérképnek nevezik; például a SCOR (The Supply-Chain Operations Reference-model) és az ETOM (Enhanced Telecom Operations Map) modellek funkcióhierarchiákat és értékláncokat tartalmaznak, folyamatokat azonban nem. Még a TeleManagement Forum útmutató dokumentumai is megkövetelik a folyamat, mint tevékenységsorozat és a folyamat, mint a vállalat iránya közötti különbségtételt.

A viselkedési perspektíva szempontjai

Egy viselkedési perspektíva, amely egy rendszer dinamikáját írja le, választ ad a „hogyan működnek a résztvevők?” kérdésre. A modellezéshez egy szabályozási folyamatábra szolgál. A fő kérdés a "hogyan?" három részre osztható: „Milyen sorrendben hajtják végre a folyamatot alkotó műveleteket? Mikor történik a műtét? Miért a megadott sorrendben hajtják végre a műveleteket?"

Az első kérdésre az üzleti logika adja meg a választ, amely a munkavégzés sorrendjének eljárási leírását adja, ennek grafikus megjelenítésére munkafolyamat-diagram szolgál. A másodikra ​​a folyamat-végrehajtási ütemterv ad választ, amely meghatározza, hogy ez vagy az a munka mikor valósul meg, mennyi időt nem végeztek el, milyen intézkedéseket kell tenni a végrehajtási ütemterv megsértése esetén. A harmadik kérdésre az üzletszabályzat ad választ, amely deklaratív módon írja le a folyamatra rótt korlátozásokat.

A folyamat üzleti logikája

A folyamatot alkotó műveletsort üzleti logikának nevezzük, leírására munkafolyamat-diagramok (UML, EPC, ABC Flowchart - folyamatábrákon alapuló leírások) szolgálnak. Az üzleti logika kifejezett, előíró jellegű információkat tartalmaz a folyamat végrehajtási útvonaláról, de csak közvetetten veszi figyelembe a megfelelő döntések meghozatalának kritériumait.

A folyamatábra tartalmaz egy „elágazó” elemet, amely lehetővé teszi, hogy a folyamat végrehajtását az előre meghatározott útvonalak egyikén irányítsa az előre meghatározott feltételeknek megfelelően. Az elágazás az üzleti logika eleme, az elágazás feltétele pedig üzleti szabály. Az üzleti elemzők gyakran nem választják el a logikát a szabályoktól, és elágazó elemet helyeznek el a diagramban, hanem kihagyják a kapcsolódó elágazási szabályt.

Az üzleti logikát leíró diagramok vizuálisan egyszerűek és egyértelműek, mivel nem tartalmaznak üzleti szabályokat, végrehajtási ütemtervet, korrekciós intézkedéseket, amelyeket akkor kell megtenni, ha a folyamatmutatók az elfogadható tartományon kívül esnek, ezért sok elemző ezeket használja az üzleti képviselőkkel való megegyezéshez. Az egyszerűség azonban csal - az informatikai fejlesztőknek újra össze kell gyűjteniük a hiányzó információkat, és a folyamat megértése nagyon eltérhet az elemzőétől. Ennek eredményeként a modell nem írja le teljesen a folyamatot, a részletek nincsenek egyértelműen rögzítve, hanem csak a programozók fejében léteznek. Ennek eredményeként a papíron lévő folyamatmodell nem felel meg az informatikai rendszer logikájának - az üzleti folyamat kezdeti leírásának pontatlanságai azok, amelyek számos fejlesztést eredményeznek, amelyek az információs rendszerek megvalósításának szakaszában merülnek fel.

Üzleti szabályok

Az üzleti szabály általában olyan kijelentésként értendő, amely meghatározza vagy korlátozza az üzlet bizonyos vonatkozásait. Az eljárási leírással ellentétben a szabályok korlátozásokat írnak elő egy folyamat végrehajtására vonatkozóan, de nem határozzák meg, hogy az eredményt pontosan hogyan kell elérni. Ronald Ross üzleti szabályok szakértője az üzleti szabályok következő osztályozását adja:

• magatartási szabályok határozzák meg a megfelelő intézkedés végrehajtásának és az ellenőrzés gyakorlásának szükségességét;
• definíciós szabályok határozzák meg a ténynek nevezett üzleti koncepció alkalmazhatóságának kritériumát;
• a számítási szabályok segítenek megtudni a szükséges mennyiségek értékét, amelyeket tényeknek nevezünk; például a kereskedelmi engedmény meghatározható egy bizonyos időszakra vonatkozó teljes vásárlási mennyiség alapján stb.;
• az osztályozási szabályok segítik a tények igazságtartalmának ellenőrzését; Például egy ügyfél akkor minősül VIP-nek, ha van egy bizonyos összeg a számláján, és nem volt még kintlévősége.

Az elágazási folyamat egy viselkedési szabály alapján történik, amely az argumentum értékének megfelelően váltja az útvonalat, amely az "igaz" vagy a "hamis" értéket veszi fel, de mi az "igaz" és mi a " false" értékét az osztályozási szabály határozza meg, amelynek viszont bemenetként kell kapnia a számítási szabály segítségével kapott értéket. Képzeljük el például a következő műveletsort: számítsuk ki a diszkont értékét az aktuális rendelés nagyságának függvényében (számítási szabály); osztályozza a kedvezmény mértékét: nagy, közepes, alacsony (besorolási szabály); küldje el az ügyletet jóváhagyásra egy megfelelő szintű jogosultsággal (magatartási szabály) rendelkező vezetőnek. Elterjedt azonban az a gonosz gyakorlat, hogy egy "elágazó" elemet helyeznek el egy diagramon, amely magában foglalja mind a viselkedési, mind a definíciós szabályokat, ami a diagramot rugalmatlanná, a leírást pedig hiányossá teszi. Tehát egyértelműen szét kell választani az összes szabályt különálló konstrukciókba a munkafolyamat-diagramon, ami segít az elemzőnek a megfelelő logika egyértelmű lokalizálásában.

Végrehajtási ütemterv

Az anyaggyártás területén széles körben elterjedt a munkarend, amivel egy-egy cikk előállítására fordított időt számolják ki. Az üzleti folyamatok esetében a munkaütemezés bonyolultabb, mivel minden művelet időben végrehajtható, és a teljes folyamat az újrafeldolgozásra való visszaküldés miatti késéssel fejezhető be.

Az üzleti folyamatok leírására használt időontológia két alapvető fogalmat tartalmaz: eseményeket és intervallumokat. Az esemény alatt az időskála egy olyan pontját értjük, amelynek nincs időtartama. Az események különböző folyamatok vagy ugyanazon folyamat ágai végrehajtásának koordinálására szolgálnak. Intervallum alatt az idővonalon a kezdeti és a végső események közötti intervallumot értjük. Az intervallumok lehetővé teszik egy adott művelet vagy műveletcsoport végrehajtásához rendelkezésre álló időkorlát meghatározását.

Az üzleti folyamatok modellezésére szolgáló jelölések összehasonlításakor elemezni kell, hogy működnek-e az „esemény” és az „időintervallum” alapfogalmakkal. Ez segít megérteni, hogy a jelölés lehetővé teszi-e egy folyamat időbeli jellemzőinek modellezését, a folyamatok és ágaik végrehajtásának koordinálását. Megfigyeléseink azt mutatják, hogy sok üzleti folyamatmodellezési jelölés nem használja ezeket az alapfogalmakat.

Az üzleti logika részletessége

A „hogyan?” kérdés megválaszolásához egy kontroll diagramnak tartalmaznia kell a folyamatot alkotó tevékenységek lehető legrészletesebb leírását. Sok elemző a funkciók felsorolására szorítkozik anélkül, hogy megadná a megvalósítás részleteit, feltételezve, hogy az előadó tudja, hogyan kell elvégezni a munkát. A gyakorlatban azonban az alkalmazottak inkább egyéni tapasztalataik alapján végzik el a munkát, ami a folyamat végrehajtásának nagy változatosságához vezet. A modellezési jelölések nem határozzák meg a leírás részletességét, így ezt a kérdést az elemző kegyére bízzák. Határozzuk meg a részletezés kritériumait.

Az oroszországi Gosstandart útmutató dokumentuma, „A funkcionális modellezés módszertana IDEF0” bevezeti a „cselekvés” és „művelet” fogalmát. A műveletet úgy definiáljuk, mint „egy anyag vagy információ objektum egy tulajdonságának más tulajdonsággá alakítását”, a műveletet pedig „szekvenciálisan vagy/vagy párhuzamosan végrehajtott műveletek halmazaként”.

Tisztázzuk ezeket a definíciókat a folyamatmodellezés esetére. Akció meghívjuk a résztvevő által egy folyamatobjektumon végzett munkát, amely megváltoztatja ezt az objektumot, de nem vezet állapotváltozáshoz; például a résztvevő új adatokat adott meg, de ez nem jelenti a jelentkezés feldolgozásának végét. Művelet egy objektum állapotának megváltozásához vezető cselekvések halmazát fogjuk nevezni; például az összes ellenőrzés elvégzése után a kérelmet jóváhagyhatják.

A munkafolyamat-diagram általában a tevékenységi szintre korlátozódik. Úgy gondolják, hogy a túlzott részletesség megnehezíti a folyamat logikájának megértését. Az irányítási diagramnak kimerítő választ kell adnia a folyamat végrehajtásának kérdésére, részletes intézkedési szinttel kell rendelkeznie. Ennek eredményeként az ilyen diagramok túlságosan részletesnek bizonyulnak, és fennáll annak a veszélye, hogy túlterhelődnek a részletekkel. Ez azonban inkább modellezési stílus kérdése - a többszintű strukturált modellek kombinálhatják az üzleti logika egyszerűségét a diagram felső szintjén, és az egyes műveletek részletes leírását az alján.

A folyamat üzleti logikájának teljességi foka

A legtöbb munkafolyamat-diagram a végrehajtási forgatókönyvek korlátozott készletét írja le, és csak a legnyilvánvalóbb útvonalakat határozza meg. Nem tartalmaznak ritkán végrehajtott szkripteket, a különleges és kivételes helyzeteket figyelmen kívül hagyják. A végrehajtás ilyen hiányos leírásának joga van létezni, amikor olyan funkcionális információs rendszer kifejlesztését tervezik, ahol egy személy határozza meg a műveletek végrehajtásának sorrendjét. A folyamatorientált rendszer felépítésénél azonban a műveletek sorrendjét maga a rendszer határozza meg, ezért a modellnek minden lehetséges végrehajtási forgatókönyvet le kell fednie, beleértve a vezérlés visszatérését az előző lépéshez, vagy az egyes feldolgozási lépéseket megkerülő átmenetek előzését. figyelembe veszi a probléma eszkalációjának lehetőségét, a kivételek kezelését, különben a rendszer nem fog működni.

EPC és BPMN jelölések összehasonlító elemzése

Megmutattuk, hogy különbséget kell tenni a munkafolyamat diagramok, a szabályozási folyamatábrák és a folyamatmodell között. A munkafolyamat-diagram meghatározza az üzleti logikát, a műveletek végrehajtásának sorrendjét, a műveletek szintjének részletessége van, nem tartalmazza a folyamat végrehajtásának ütemezését, és nem feltétlenül határozza meg teljes mértékben egy folyamat üzleti szabályait. A vezérlési folyamatábra finomítja a munkafolyamat-diagramot a végrehajtási ütemterv és az üzleti szabályok szempontjából, rendelkezik a cselekvési szint granularitásával, le kell írnia az összes végrehajtási lehetőséget, vagyis leírja azt a technológiát, amely garantálja a tervezett eredmény elérését. előre meghatározott műveletsor pontos végrehajtásának esete. Legalább egy komponens hiányában a leírás hiányos lesz, a technológia nem követhető. A folyamatmodell egymással összefüggő nézőpontok összessége, amelyek mindegyike leírja a folyamat viselkedésének egyes aspektusait, és együttesen integrált, összetett és teljes képet alkotnak a folyamatról és annak végrehajtásáról. A vezérlési folyamatábra alkalmazása leírja az üzleti folyamatmodell viselkedési perspektíváját.

Az EPC-jelölés egy folyamat üzleti logikájának leírására szolgáló eszköz. Ahogy az összehasonlítás is mutatja, a jelölés lehetővé teszi az üzleti logika alapvető mintáinak megvalósítását, nem rosszabb, mint a folyamatok leírására szolgáló többi jelölés. Az EPC diagramok gyakran nem tartalmaznak üzleti szabályokat, de ezt a hiányosságot nem a jelölésnek, mint olyannak, hanem az alkalmazási módszertannak kell betudni. Ami a végrehajtási ütemtervet illeti, meg kell jegyezni, hogy nincsenek eszközök a végrehajtás időbeli jellemzőinek modellezésére. Az EPC jelölés egy "esemény" konstrukciót tartalmaz, de egy vezérlőobjektum állapotának leírására szolgál, nem pedig a végrehajtás szinkronizálására. Az EPC módszertana nem a kapott diagramok részletezettségére és teljességére összpontosít, ezt a kérdést az elemző kegyére bízza. Szigorú szabályozás hiányában az elemzők törekednek a diagramok egyszerűségére és olvashatóságára, ezért a műveletek szintjének leírására szorítkoznak, és nem törekednek minden végrehajtási útvonal azonosítására. Az EPC-jelölést gyakran használják funkcióorientált rendszerek automatizálására, ahol egy személy vezető, irányító szerepet tölt be, így a végrehajtási parancsfájl hiánya nem veszélyes. Mindez lehetővé teszi az EPC-modellek munkafolyamat-diagramként történő osztályozását.

Az ARIS-ben található jelölések rendkívül hatékonyak a modellezési folyamatokban, de nem támogatják őket a nyílt és felhasználó által elérhető módszerek. Az "ARIS Methodology" dokumentum nem a módszertant írja le, hanem a jelölés alkalmazásának szabályait, amely a modellezési módszerek széles körű "értelmezési" lehetőségét teszi lehetővé.

Az EPC-probléma azzal a kísérlettel függ össze, hogy ezt az eszközt túl sokféle feladat megoldására adaptálják anélkül, hogy az adott esetre vonatkozó alkalmazási szabályokat elmagyaráznák. Ennek eredményeként az elemzők számos konstrukciót és mechanizmust használnak intuitívan és öntudatlanul. Néha a szándékuk megérthető a feladat kontextusából, de nem valószínű, hogy egy modern számítógép képes lesz magát a kontextust elemezni, amikor egy diagramot futtatható formátumba konvertál.

A BPMN jelölés egy folyamat logikáját írja le. Az üzleti logikai minták valamivel jobb támogatása az EPC-hez képest nem döntő előny. A jelölés az "esemény" és az "időintervallum" fogalmával operál, tartalmaz eszközöket a folyamatágak és a folyamatok egymással való szinkronizálására. Maga a jelölés nem javasolja a logika és a szabályok szétválasztását, de a helyes modellezési stílus irányelvei tartalmaznak ilyen ajánlást. A BPMN jelöléssel folyamatorientált rendszereket hoznak létre, ahol egy személy beosztottat játszik, és a rendszer vezető szerepet tölt be, ezért egy, még a legritkább forgatókönyv kihagyása sem teszi lehetővé a munka elvégzését, és ezért elfogadhatatlan. , illetve a BPMN modellek lefedik az összes végrehajtási forgatókönyvet. A BPMN modellek végrehajtható modellek, ezért minden részletet leírnak, egészen az elemi műveletekig. A fentiek mindegyike lehetővé teszi egy BPMN diagram besorolását vezérlési folyamatmodellként.

A BPMN-jelöléssel kapcsolatos problémák azzal a ténnyel kapcsolatosak, hogy a diagramok általában túlterheltek részletekkel, és ezért nehezen olvashatók. A kiutat a hierarchikus többszintű modellek felépítésének módszertanának fejlesztésében látjuk, ahol a felső szint a teljes folyamat végrehajtási kontextusát írja le, a középső szint a végrehajtási logikát, az alsó szint pedig a megvalósítás részleteit írja le. az egyes műveletek.

A BPM és a BPMS (Business Process Management Suite) iránti érdeklődés elérte az érettségi fokot, amikor már nem kell divatról beszélni. Ezen túlmenően a szabványok háborúja véget ért, és a BPMN-jelölést minden jelentős szereplő elismerte, de facto szabvány lett. Ez az esemény fontosságát tekintve összevethető az SQL megjelenésével, amely a modern információs rendszerek alapjává vált.

A BPMS végül az üzleti folyamatok grafikus modellezését, az üzleti folyamatmodell végrehajtását, a monitorozást és elemzést (Business Activity Monitoring, BAM) támogató szoftverosztályként jelent meg. A különböző termékek azonban eltérő módon valósítják meg ezt a funkciót, és egy adott BPMS kiválasztásakor először a következőket kell figyelembe venni.

• BPMN támogatás. A BPMN melyik verziója támogatott (1.x vagy 2.0)? Mennyire teljes a megvalósítás: üzenetek, jelzések, tranzakciós részfolyamatok támogatottak?

• A BPMN folyamatmotor egy típusa. A közvetlen végrehajtás előnyösebb, mint a más reprezentációba fordítás – csak ebben az esetben lehetséges az üzleti folyamatok folyamatos fejlesztése a gyakorlatban.
• Kommunikáció a folyamatok és az adatok között. Célszerű a pro attribútumokat tárolni
Folyamat a legnyitottabb formában - egy relációs DBMS táblázataiban és oszlopaiban, amely hivatkozási integritást, magas működési jellemzőket és a kívülről származó adatokhoz való hozzáférés szabadságát biztosítja, szemben például az attribútumok XML karakterláncként való tárolásával.
• Felhasználói felület. A felületnek funkcionálisnak, ergonomikusnak kell lennie
és gyorsan fejleszthető, kódolás nélkül. A rendszernek lehetővé kell tennie egy üzleti elemző számára, hogy működő felhasználói felületet hozzon létre, amely igény szerint programozó bevonásával módosítható.
• Rendszer platform. A cég műszaki politikájától függően a választás
korlátozható a Java platformra ill. Net – A mindkét platformot támogató BPMS ritka.
• Engedélyezési rendszer. A Shareware rendszerek lehetővé teszik, hogy spóroljon azon
cenzúra, de nagy erőforrásokat igényel a fejlesztés; egyes kereskedelmi rendszerek minimális konfiguráció mellett is drágák.
• Képviselet vagy partner jelenléte Oroszországban.

Nem szabad megfeledkezni arról, hogy a BPMS csak egy összetevője a BPM-nek, és egy üzleti folyamatirányítási rendszert létrehozó projekt sikeréhez módszertani és agilis projektmenedzsment-kompetenciák is szükségesek.

Anatolij Belaychuk ([e-mail védett]) - a "Business-Consol" cég elnöke (Moszkva).

Az EPC diagramok végrehajtható formátumra fordítási problémái

Az EPC jelöléssel végzett modellezés eredményei nem mindig vezetnek olyan modell létrehozásához, amely jelentős változtatások nélkül konvertálható végrehajtható BPM formátumba.

Soroljuk fel a tipikus modellezési hibákat!

A kezdő elemzők számára az EPC-modell a legvalószínűbb végrehajtási lehetőséget írja le, mellőzve a ritkán használt alternatív útvonalakat: diagramjaikon ritkán találhat leírást a nem szabványos és kivételes helyzetekben végrehajtott műveletekről.

A modellek nagyon gyakran nem fedik le teljes mértékben az összes döntési kritériumot. Ennek következtében a modellt át kell dolgozni az üzleti szabályok finomítása érdekében.

Az elemzők nem figyelnek a folyamatvezérlő objektum változásaira. Képzeljen el egy technológiai folyamat leírását, amely magában foglalja az alkatrészek gyártását. Ha a komponensek megrendelésre készülnek, akkor a gyártás leírását is bele lehet foglalni a fő folyamatba, de ha a komponensek a főalkatrészhez aszinkron módon készülnek, akkor a gyártásuk külön folyamat legyen, saját vezérlőobjektummal. Az elemzőnek gondosan figyelemmel kell kísérnie a folyamatvezérlő objektumot, mivel annak változása a végpontok közötti folyamat lehetséges felosztásának jele, kölcsönhatásban lévő folyamatok láncolatára.

A folyamat elégtelen részletezettsége a hiányzó részletek pontosításának és leírásának szükségességét vonja maga után a kidolgozott informatikai rendszer követelményeinek előkészítésének szakaszában.

Az EPC diagramok nem írnak le végrehajtási ütemterveket, figyelmen kívül hagyják az egyik folyamat ágainak egymással és más, külső folyamatokkal való szinkronizálásának kérdéseit.

Tehát elmondhatjuk, hogy az EPC problémái az alkalmazási módszertan területén vannak, és ha lenne olyan modellezési megállapodás, amely meghatározná a kidolgozott modell minden részletét, a legtöbb probléma, kivéve a végrehajtás időzítési paraméterei elkerülhetők.

Nem a jelölés, hanem a módszertan határozza meg, hogy a modell funkcionális vagy folyamatalapú-e. A folyamatmodell egy többrétegű leírás, amely funkcionális, viselkedési, információs és szervezeti szempontok egymással összefüggő leírásait tartalmazza. A viselkedési perspektíva leírásához olyan szabályozási folyamatábrát kell használni, amely átfogó választ ad a „hogyan zajlik a folyamat?” kérdésre. A munkafolyamat-diagram, amelyet indokolatlanul folyamatmodellnek neveznek, nem írja le a folyamat viselkedésének minden részletét, és nem is folyamatdiagram.

Sok, az újratervezés gyakorlatában használt modell nem felel meg az összes felsorolt ​​követelménynek, ezért nem nevezhető folyamatmodellnek. Felmerül a kérdés: lehet, hogy ebben rejlik ezeknek az üzleti folyamatokat áttervező projekteknek a kudarca?

Irodalom

1. B. Curtis, M. Kellner, J. Over. Folyamatmodellezés, 1992.
2. eTOM, Reprezentatív folyamatok. ITU. s.l .: Az ITU távközlési szabványosítási ágazata, 2004.
3. R. Ross. Az üzletszabályzati megközelítés alapelvei. Addison-Wesley Professional (2003).
4. C. Pedrinaci, Domingue, A. Alves de Medeiros. A Core Ontology for Business Process Analysis, Proceedings of the 5th European Semantic Web Conference on The semantic web: research and applications, Springer-Verlag Berlin, Heidelberg, 2008.
5. Funkcionális modellezési módszertan IDEF0. Moszkva: Oroszország Gosstandartja, 2000.
6. N. Russell, A. ter Hofstede, W. M. P. van der Aalst, N. Mulyar, Workflow control-flow patterns.
7. Módszerek ARIS 7.0. Saarbrucken: IDS Scheer AG, 2005.
8. B. Ezüst, BPMN módszer és stílus. Cody-Cassidy Press, 2009.

Igor Fedorov ([e-mail védett]) - a MESI Folyamatirányítási Kompetencia Központ igazgatója (Moszkva).

Üzleti folyamatok modellezése, modellezési perspektíva, funkcionális és folyamatmodellezés