Odeslat svou dobrou práci do znalostní báze je jednoduché. Použijte níže uvedený formulář

Studenti, postgraduální studenti, mladí vědci, kteří využívají znalostní základnu ve svém studiu a práci, vám budou velmi vděční.

Vloženo na http://www.allbest.ru

Úvod

Modelování podnikových procesů v kontextu modernizace ekonomiky a managementu je relevantní oblastí, která pomáhá optimalizovat procesy činností organizace a zlepšovat výkonnost podniku. Při modelování podnikových procesů budeme používat terminologii několika oblastí znalostí souvisejících s ekonomikou, informatikou a modelováním složitých systémů. Pojďme si proto definovat základní definice a pojmy.

Podnikový proces je definován jako logicky dokončený řetězec vzájemně souvisejících a opakujících se činností, v jejichž důsledku jsou podnikové zdroje využívány ke zpracování objektu (fyzicky nebo virtuálně) za účelem dosažení určitých měřitelných výsledků nebo vytvoření produktů pro uspokojení interních nebo externích zákazníků. .

Termín „modelování“ má dva hlavní významy. Za prvé, modelování je chápáno jako proces konstrukce modelu jako určité reprezentace (obrazu) originálu, odrážející jeho nejdůležitější rysy a vlastnosti. Pokud je model již vytvořen, pak je modelování procesem výzkumu (analýzy) fungování systému, respektive jeho modelu. Základním účelem modelování podnikových procesů je popsat skutečný průběh podnikových procesů podniku. V tomto případě je nutné určit, co je výsledkem procesu, kdo a jaké úkony provádí, jaké je jejich pořadí, jaký je pohyb dokumentů během procesu a také jaká je spolehlivost procesu (pravděpodobnost neúspěšného provedení) a jak jej lze v budoucnu rozšířit/upravit.

Zajištění transparentnosti průběhu obchodních procesů je důležité, protože pouze v tomto případě vlastník obchodního procesu (zaměstnanec společnosti, který řídí průběh obchodního procesu a je zodpovědný za jeho výsledky a efektivitu), obchodní analytik, management a další zainteresovaní strany budou mít jasnou představu o tom, jak je práce organizována. Pochopení toku stávajících podnikových procesů umožňuje posoudit jejich efektivitu a kvalitu a je nezbytné pro rozvoj podnikové IT infrastruktury. Úspěšný vývoj aplikačních systémů, které podporují provádění obchodních procesů od začátku do konce, je možný pouze tehdy, když jsou procesy samotné jasně do detailu pochopeny.

Model podnikových procesů je jeho formalizovaný (grafický, tabulkový, textový, symbolický) popis, který odráží skutečnou nebo navrhovanou činnost podniku.

Problém této práce v kurzu zní takto: jak praktické jsou diagramy navržené v MS Visio k použití (jednoduchost, vizuální a informativní).

Předmětem je obchodní modelování.

Předmětem bude: modelování podnikových procesů podniku poskytujícího služby silniční dopravy v MS Visio.

Na základě problému definujme cíl: určit, jak praktické je použití diagramů navržených v MS Visio na příkladu dopravní společnosti (TC) EcoTrans LLC.

K dosažení tohoto cíle je nutné vyřešit následující úkoly:

Najít a studovat metodiky modelování obchodních procesů;

Seznamte se s obchodní grafikou v MS Visio;

Analyzujte obchodní procesy společnosti TC LLC "EcoTrans"

Popište obchodní procesy společnosti TC LLC "EcoTrans" pomocí obchodního modelování v aplikaci Microsoft Visio

Pro modelování obchodních procesů lze použít různé metody. Metoda modelování nebo metodologie zahrnuje posloupnost akcí, které je nutné provést pro vytvoření modelu, tj. postup modelování a použitý zápis (jazyk). V této práci budou k modelování obchodních procesů použity metodiky IDEF0, IDEF3.

1. Metodiky pro popis předmětné oblasti

Proces obchodního modelování lze implementovat v rámci různých technik, které se liší především svým přístupem k tomu, co je modelovaná organizace. V souladu s různými představami o organizaci se metody obvykle dělí na objektové a funkční (strukturální).

Objektově založené metody považují modelovanou organizaci za množinu vzájemně se ovlivňujících objektů – produkčních jednotek. Předmět je definován jako hmatatelná realita – předmět nebo jev, který má jasně definované chování. Účelem použití této techniky je identifikovat objekty, které tvoří organizaci, a rozdělit mezi ně odpovědnost za prováděné akce.

Funkční techniky, z nichž nejznámější je technika IDEF0, považují organizaci za soubor funkcí, které transformují příchozí tok informací na výstupní tok. Proces konverze informací spotřebovává určité zdroje. Hlavním rozdílem od objektové metody je jasné oddělení funkcí (metod zpracování dat) od dat samotných.

Z pohledu obchodního modelování má každý z prezentovaných přístupů své výhody. Objektový přístup umožňuje vybudovat systém, který je odolnější vůči změnám a lépe odpovídá stávajícím strukturám organizace. Funkční modelování funguje dobře v případech, kdy je organizační struktura v procesu změny nebo je obecně špatně formována. Přístup z vykonávaných funkcí interpreti intuitivně lépe pochopí, když od nich obdrží informace o své aktuální práci.

1.1 Pochopení rodiny standardů IDEF

Jedním z nejdůležitějších cílů při přípravě projektu výstavby informačního systému je jasné a správně pochopené vyjádření problému. K dosažení tohoto cíle je nutné prozkoumat všechny probíhající finanční a ekonomické procesy a jim odpovídající toky informací v podniku, identifikovat ty, které by měly být nejdříve reorganizovány, tzn. vybudovat tzv. business model. Takové komplexní průzkumy podniků jsou vždy složité a případ od případu se výrazně liší. K řešení takových problémů modelování složitých systémů existují osvědčené metodiky a standardy. Tyto standardy zahrnují rodinu metodologií IDEF. S jejich pomocí můžete efektivně zobrazovat a analyzovat vzorce aktivit široké škály složitých systémů v různých kontextech. Šíři a hloubku zkoumání procesů v systému si přitom určuje sám vývojář, což umožňuje nepřetěžovat vytvořený model zbytečnými daty.

Metodika IDEF byla vytvořena v rámci programu průmyslové elektronizace ICAM (Integrated Computer Aided Manufacturing) realizovaného ve Spojených státech amerických, při jehož realizaci byla identifikována potřeba vývoje metod pro analýzu interakčních procesů ve výrobních systémech. Odtud pochází název této rodiny standardů – Icam DEFINition – IDEF.

V současné době rodina IDEF zahrnuje následující standardy:

IDEF0 - metodologie funkčního modelování. Pomocí vizuálního grafického jazyka IDEF0 se zkoumaný systém jeví vývojářům a analytikům ve formě sady vzájemně provázaných funkcí (funkčních bloků – řečeno IDEF0). Modelování IDEF0 je zpravidla prvním krokem při studiu jakéhokoli systému;

IDEF1 je metodika pro modelování informačních toků v rámci systému, která umožňuje zobrazit a analyzovat jejich strukturu a vztahy;

IDEF1X (IDEF1 Extended) - metodika pro budování relačních struktur. IDEF1X patří k typu metodologií „entity-relationship“ (ER - Entity-Relationship) a zpravidla se používá k modelování relačních databází relevantních pro daný systém;

IDEF2 je metodika pro dynamické modelování vývoje systémů. Vzhledem k velmi vážným potížím analýzy dynamických systémů byla tato norma prakticky opuštěna a její vývoj se zastavil v úplné počáteční fázi.

IDEF3 je metodika pro dokumentaci procesů probíhajících v systému, která se využívá např. při studiu technologických procesů v podnicích. IDEF3 popisuje scénář a sekvenci operací pro každý proces. IDEF3 má přímou souvislost s metodikou IDEF0 - každá funkce (funkční blok) může být reprezentována jako samostatný proces pomocí IDEF3;

IDEF4 je metodika pro budování objektově orientovaných systémů. Nástroje IDEF4 vám umožňují vizuálně zobrazit strukturu objektů a základní principy jejich interakce, čímž vám umožní analyzovat a optimalizovat složité objektově orientované systémy;

IDEF5 je metodologie pro ontologický výzkum komplexních systémů. Pomocí metodiky IDEF5 lze ontologii systému popsat pomocí specifického slovníku pojmů a pravidel, na jehož základě lze vytvořit spolehlivá prohlášení o stavu uvažovaného systému v určitém okamžiku. Na základě těchto tvrzení se vyvozují závěry o dalším vývoji systému a provádí se jeho optimalizace.

V této práci se budeme podrobněji zabývat standardy, které budou vyžadovány při popisu obchodních procesů: IDEF0, IDEF3.

Funkční metoda IDEF0.

Účelem techniky je sestrojit funkční schéma studovaného systému, popisující všechny potřebné procesy s přesností dostatečnou pro jednoznačné modelování činnosti systému.

Metodika je založena na čtyřech hlavních pojmech: funkční blok, oblouk rozhraní, dekompozice, glosář.

a) Activity Box představuje určitou specifickou funkci v rámci uvažovaného systému. Podle požadavků normy musí být název každého funkčního bloku formulován ve verbálním duchu (například „produkovat služby“). V diagramu je funkční blok znázorněn jako obdélník (obrázek 1.1). Každá ze čtyř stran funkčního bloku má svůj specifický význam (role) a:

Horní strana je nastavena na "Control";

Levá strana je nastavena na "Input";

Pravá strana je nastavena na Výstup;

Spodní strana má význam "Mechanismus".

Toto označení odráží určité systémové principy: vstupy se převádějí na výstupy, řídí limity nebo předepisují podmínky pro provádění transformací, mechanismy ukazují, co a jak funkce vykonává.

Každý funkční blok v rámci jednoho uvažovaného systému musí mít své vlastní jedinečné identifikační číslo.

Obrázek 1.1 - Funkční blok

b) Šipka rozhraní představuje prvek systému, který je zpracován funkčním blokem nebo jinak ovlivňuje funkci reprezentovanou tímto funkčním blokem. Oblouky rozhraní se často nazývají toky nebo šipky.

Pomocí oblouků rozhraní se zobrazují různé objekty, které do té či oné míry určují procesy probíhající v systému. Takovými objekty mohou být prvky reálného světa (díly, auta, zaměstnanci atd.) nebo toky dat a informací (dokumenty, data, instrukce atd.).

Podle toho, na kterou stranu funkčního bloku tento oblouk rozhraní pasuje, se nazývá „příchozí“, „odchozí“ nebo „ovládací“.

Je třeba poznamenat, že každý funkční blok musí mít podle požadavků normy alespoň jeden oblouk ovládacího rozhraní a jeden výstupní. To je pochopitelné - každý proces musí probíhat podle nějakých pravidel (zobrazených řídicím obloukem) a musí přinést nějaký výsledek (odchozí oblouk), jinak jeho uvažování nedává smysl.

Povinná přítomnost oblouků řídicího rozhraní je jedním z hlavních rozdílů mezi standardem IDEF0 a ostatními metodikami tříd DFD (Data Flow Diagram) a WFD (Work Flow Diagram).

c) Rozklad je základním konceptem standardu IDEF0. Principu rozkladu se využívá při rozdělení komplexního procesu na jeho dílčí funkce. V tomto případě úroveň detailu procesu určuje přímo vývojář modelu.

Dekompozice umožňuje postupně a strukturovaně prezentovat model systému ve formě hierarchické struktury jednotlivých diagramů, díky čemuž je méně přetížený a snáze stravitelný.

Model IDEF0 vždy začíná pohledem na systém jako na jeden celek – jeden funkční blok s oblouky rozhraní přesahujícími uvažovanou doménu. Takový diagram s jedním funkčním blokem se nazývá kontextový diagram a je označen identifikátorem „A-0“ (obrázek 1.2).

Obrázek 1.2 - Příklad kontextového diagramu

Vysvětlující text ke kontextovému diagramu by měl ve formě stručného popisu uvádět Účel sestavení diagramu a zaznamenávat úhel pohledu.

Definování a formalizace cíle vývoje modelu IDEF0 je nesmírně důležitý bod. Cíl ve skutečnosti definuje relevantní oblasti ve zkoumaném systému, na které je třeba se zaměřit jako první. Pokud například modelujeme činnost podniku s cílem vybudovat na tomto modelu v budoucnu informační systém, pak se tento model bude výrazně lišit od toho, který bychom vyvinuli pro stejný podnik, ale s cílem optimalizace dodavatelských řetězců.

Hledisko určuje hlavní směr vývoje modelu a požadovanou úroveň detailů. Jasná fixace pohledu umožňuje vyložit model tím, že odmítnete detaily a studujete jednotlivé prvky, které nejsou nutné, na základě zvoleného pohledu na systém. Například funkční modely stejného podniku z pohledu hlavního technologa a finančního ředitele se budou výrazně lišit ve směru jejich detailování. Je to dáno tím, že finančního ředitele nakonec nezajímají aspekty zpracování surovin na výrobních strojích a hlavní technolog nepotřebuje kreslená schémata finančních toků. Správná volba úhlu pohledu výrazně zkracuje čas strávený stavbou finálního modelu.

Během procesu dekompozice je funkční blok, který představuje systém jako celek v kontextovém diagramu, podrobně popsán v jiném diagramu. Výsledný diagram druhé úrovně obsahuje funkční bloky, které zobrazují hlavní podfunkce funkčního bloku kontextového diagramu a ve vztahu k němu se nazývá Child diagram (každý z funkčních bloků patřících do child diagramu se odpovídajícím způsobem nazývá Child Box) . Funkční blok předka se nazývá rodičovský blok ve vztahu k podřízenému diagramu (Parent Box) a diagram, ke kterému patří, se nazývá rodičovský diagram (Parent Diagram). Každá z dílčích funkcí podřízeného diagramu může být dále podrobně popsána podobným rozkladem jejího odpovídajícího funkčního bloku. Je důležité poznamenat, že v každém případě dekompozice funkčního bloku jsou všechny oblouky rozhraní vstupující nebo vycházející z tohoto bloku fixovány v podřízeném diagramu. Tím je dosaženo strukturální integrity modelu IDEF0. Princip rozkladu je názorně znázorněn na obrázku 1.3. Měli byste věnovat pozornost vztahu mezi číslováním funkčních bloků a diagramů - každý blok má na diagramu své jedinečné sériové číslo (číslo v pravém dolním rohu obdélníku) a označení v pravém rohu označuje číslo podřízeného diagramu pro tento blok. Absence tohoto označení naznačuje, že pro tento blok neexistuje žádný rozklad.

Často se vyskytují případy, kdy jednotlivé oblouky rozhraní nemá smysl nadále uvažovat v podřízených diagramech pod určitou úrovní v hierarchii nebo naopak - jednotlivé oblouky nedávají od určité úrovně praktický smysl. Například nemá smysl zobrazovat oblouk rozhraní znázorňující „díl“ na vstupu do funkčního bloku „Proces na soustruhu“ na diagramech vyšších úrovní - diagramy by to jen přetížilo a bylo by obtížné je pochopit. Na druhou stranu může vzniknout potřeba zbavit se jednotlivých „koncepčních“ oblouků rozhraní a nedetailovat je nad určitou úroveň. Pro řešení těchto problémů poskytuje standard IDEF0 koncept tunelování. Označení Arrow Tunnel se dvěma závorkami kolem začátku oblouku rozhraní označuje, že oblouk nebyl zděděn z funkčního nadřazeného bloku a objevuje se (z „tunelu“) pouze v tomto diagramu. Na druhé straně, stejné označení kolem konce (šipky) oblouku rozhraní v bezprostřední blízkosti bloku přijímače znamená skutečnost, že tento oblouk nebude zobrazen a uvažován v podřízeném diagramu tohoto bloku. Nejčastěji se stává, že jednotlivé objekty a jim odpovídající styčné oblouky nejsou uvažovány na některých mezilehlých úrovních hierarchie - v tomto případě jsou nejprve „ponořeny do tunelu“ a poté, pokud je to nutné, „vráceny z tunelu“ .

d) Glosář. Pro každý z prvků IDEF0 – diagramy, funkční bloky, oblouky rozhraní – stávající standard vyžaduje vytvoření a údržbu sady vhodných definic, klíčových slov, narativních prohlášení atd., které charakterizují objekt zobrazený prvkem. Tato sada se nazývá glosář a je popisem podstaty daného prvku. Glosář harmonicky doplňuje vizuální grafický jazyk a poskytuje diagramům potřebné doplňující informace.

Standard procesní dokumentace IDEF3.

IDEF3 je standard pro dokumentaci technologických procesů probíhajících v podniku a poskytuje nástroje pro vizuální studium a modelování jejich scénářů. Scénář (Scenario) je v tomto případě popis sledu změn vlastností předmětu v rámci uvažovaného procesu (například popis sledu fází zpracování dílu v dílně a změna jeho vlastností po průchodu každým stupněm).

Dokumentační a modelovací nástroje IDEF3 vám umožňují provádět následující úkoly:

Zdokumentujte dostupné údaje o technologii procesu, identifikované řekněme v procesu dotazování kompetentních zaměstnanců odpovědných za organizaci daného procesu;

Identifikovat a analyzovat body vlivu souvisejících toků dokumentů na scénář technologického procesu;

Identifikovat situace, ve kterých je vyžadováno rozhodnutí, které má vliv na životní cyklus procesu, například změna konstrukčních, technologických nebo provozních vlastností konečného produktu;

Podporovat přijímání optimálních rozhodnutí při reorganizaci technologických procesů.

Ve standardu IDEF3 existují dva typy diagramů, které představují popis stejného procesního scénáře z různých perspektiv. Diagramy patřící do prvního typu se nazývají diagramy popisu toku procesů (PFDD) a druhý typ se nazývají diagramy objektové stavové sítě (OSTN).

Předpokládejme, že potřebujete popsat proces lakování součásti ve výrobní dílně v podniku. PFDD diagramy dokumentují sled a popis fází zpracování dílce v rámci studovaného technologického procesu. OSTN diagramy se používají k ilustraci transformací součástí, ke kterým dochází v každé fázi zpracování.

Na následujícím příkladu popíšeme, jak grafické nástroje IDEF3 umožňují dokumentovat výše uvedený výrobní proces lakování součásti. Obecně se tento proces skládá přímo ze samotného lakování, prováděného na speciálním zařízení, a z fáze kontroly kvality, která určuje, zda je potřeba díl přelakovat (v případě neshody s normami a zjištěny závady) nebo poslat k dalšímu zpracovává se.

Obrázek 1.4 ukazuje diagram PFDD, což je grafické znázornění scénáře zpracování součásti. Obdélníky v diagramu PFDD se nazývají jednotky chování (UOB) a představují událost, fázi procesu nebo rozhodnutí. Každý UOB má svůj vlastní název, zobrazený ve slovesné náladě, a jedinečné číslo. Šipky nebo čáry představují, jak se součást během procesu pohybuje mezi bloky UOB.

Obrázek 1.4 - PFDD diagram scénáře zpracování dílu

Objekt označený J1 se nazývá Junction. Křižovatky se používají k zobrazení logiky toho, jak šipky (vlákna) interagují při slučování a větvení, nebo k zobrazení více událostí, které mohou nebo musí být dokončeny, než může začít další práce. Jsou zde průsečíky pro slučování (Fan-in Junction) a větvení (Fan-out Junction) šipky. Průsečík nelze použít pro sloučení i rozvětvení. Při přidávání průsečíku do diagramu musíte určit typ průniku. Klasifikace možných typů křižovatek je uvedena v tabulce 1.

Tabulka 1 - Klasifikace typů křižovatek

název	Význam v případě sloučení šipek (Fan-in Junction)	Význam v případě rozvětvených šipek (Fan-out Junction)
Asynchronní AND	Všechny předchozí procesy musí být dokončeny	Všechny následující procesy musí být spuštěny
	Všechny předchozí procesy jsou dokončeny současně	Všechny následující procesy běží současně
	Jeden nebo více předchozích procesů musí být ukončeno	Musí být spuštěn jeden nebo více z následujících procesů
	Jeden nebo více předcházejících procesů skončí současně	Jeden nebo více následujících procesů běží současně
XOR (exkluzivní OR)	Byl dokončen pouze jeden předchozí proces	Pouze jeden další proces začíná

Scénář zobrazený na diagramu lze popsat následovně:

Díl dorazí do lakovny připravený k lakování. Během procesu lakování se nanáší jedna vrstva emailu při vysoké teplotě. Poté se díl vysuší, poté začíná fáze kontroly kvality nanesené vrstvy. Pokud zkouška potvrdí nedostatečnou kvalitu nanesené vrstvy (nedostatečná tloušťka, heterogenita atd.), pak díl prochází lakovnou znovu. Pokud díl úspěšně projde kontrolou kvality, je odeslán do další dílny k dalšímu zpracování.

Každý funkční blok UOB může mít sekvenci rozkladů, a proto může být podrobný s libovolnou požadovanou přesností. Dekompozicí rozumíme reprezentaci každého UOB pomocí samostatného diagramu IDEF3. Můžeme například rozložit Paint Part UOB tak, že jej představíme jako samostatný proces a vytvoříme pro něj vlastní PFDD diagram. V tomto případě se tento diagram bude nazývat podřízeným diagramem ve vztahu k diagramu znázorněnému na obrázku 1.4 a tomuto diagramu, respektive nadřazenému diagramu. Čísla UOB podřízených diagramů mají průběžné číslování, tj. pokud má nadřazený UOB číslo „1“, pak bloky UOB při jeho rozkladu budou mít čísla „1.1“, „1.2“ atd. Aplikace principu dekompozice v IDEF3 umožňuje popsat procesy strukturovaným způsobem s libovolnou požadovanou úrovní detailů.

Pokud jsou PFDD diagramy technologickým procesem „z pohledu pozorovatele“, pak další třída diagramů IDEF3 - OSTN nám umožňuje uvažovat o stejném procesu „z pohledu objektu“. Obrázek 1.5 ukazuje proces lakování z hlediska OSTN diagramu. Klíčovými pojmy OSTN diagramu jsou „stavy objektů“ (v našem případě části) a „změna stavu“. Stavy objektů jsou zobrazeny jako kruhy a jejich změny jako směrované čáry. Každý řádek má odkaz na odpovídající funkční blok UOB, který vedl ke změně stavu objektu, který zobrazuje.

Obrázek 1.5 - Proces lakování z pohledu OSTN diagramu

2. Nástroje pro modelování podnikových procesů

Existuje mnoho nástrojů pro popis obchodních procesů: BPWin, ERWin, PowerDesigner, Business Studio, ELMA BPM, Visual Paradigm a další.

Do výše uvedeného seznamu můžete přidat jeden, který patří do přední rodiny kancelářských produktů vyráběných lídrem softwarového průmyslu - Microsoft Visio. Samozřejmě není tak funkční z pohledu modelování podnikových procesů, ale je velmi oblíbený a rozšířený díky relativně nízké ceně.

2.1 Technické vlastnosti. Datové úložiště

Technicky je Visio desktopová aplikace, která manipuluje s jednotlivými soubory (dokumenty). Dokument Visio obsahuje jeden nebo více diagramů uspořádaných na jedné nebo několika stránkách. Každý dokument obsahuje sadu symbolů (odpovídajících objektům modelu) a konektorů (odpovídajících spojením), přičemž symboly mohou mít kromě názvů další atributy, které definuje uživatel během procesu modelování.

V případě potřeby lze sadu symbolů dodávaných s produktem rozšířit o symboly vytvořené uživateli. Neexistují žádná globální omezení pravidel a možnosti vytvářet spojení mezi určitými typy symbolů v produktu, má však mechanismus pro tzv. šablony diagramů, jejichž použití umožňuje omezit množinu přímo dostupných symbolů. na odpovídajícím panelu nástrojů během procesu modelování. Šablony mohou vytvářet uživatelé a produkt je dodáván se sadou hotových šablon (obrázek 2.1).

Soubor modelů popisujících činnost podniku je zpravidla souborem jednotlivých souborů, přičemž v případě poměrně velkých podniků a komplexního popisu činností může být počet takových souborů i několik tisíc. Technické prostředky pro zajištění vztahů mezi modely uloženými v různých souborech nejsou implementovány na úrovni produktu, i když produkt poskytuje nástroje pro nezávislou implementaci takových vztahů (o nich bude řeč později). Proto použití Visio v takových případech, zejména v podmínkách neustále se měnících procesů, vyžaduje značné náklady na údržbu tak působivé sady modelů.

Obrázek 2.1 - Sada hotových šablon MS Visio

2.2 Podporované metodiky a notace

Vzhledem k tomu, že sadu symbolů a šablon Visio lze libovolně rozšiřovat a samotný produkt neznamená globální omezení možností použití symbolů a propojení mezi nimi, lze popis obchodních procesů pomocí Visio formálně provádět v rámci téměř jakéhokoli metodologie. Zároveň produktový balíček v libovolné edici (Standard, Professional) obsahuje sadu šablon modelů pro nejběžnější zápisy, jako jsou diagramy datových toků, přidané diagramy řetězců kvality, Event-driven Process Chain, IDEF0, diagramy typu SwimLane , a také šablony pro modelování organizačních struktur firem.

3. Analýza předmětné oblasti EcoTrans LLC

Dopravní společnost EcoTrans LLC byla založena v roce 2008. První přepravní služby byly poskytovány spotřebitelům podnikajícím v regionu Oryol. Řada největších podniků v regionu uzavřela s firmou dlouhodobé smlouvy na nákladní a osobní přepravu. Pro společnost EcoTrans LLC se služby nákladní dopravy (region Oryol) v regionu staly úspěšným začátkem dalšího rozvoje. Dnes se geografie dopravní obslužnosti posunula daleko za hranice našeho rodného kraje. Rozšíření geografie jejích aktivit si vyžádalo nárůst počtu moderních nákladních vozů, takže pro rozvoz zboží dnes využívá nejen vlastní rozsáhlý vozový park, ale i vozy partnerů.

EcoTrans LLC zajišťuje nejen nákladní přepravu po celém Rusku, ale poskytuje klientům i související služby, jako je spedice a pojištění nákladu.

a) Přepravní spedice. Tato služba umožňuje klientovi nejen usnadnit proces přepravy nákladu, ale také snížit její náklady. Spedice se skládá z několika typů služeb:

Příprava potřebných dokumentů. Nákladní listy, celní prohlášení, doklady pojišťovny atd. dokumenty, stejně jako jejich podepisování, se již klienta netýkají;

Výběr vozidla. Zohledňuje se hmotnost nákladu, jeho rozměry a trasa;

Plánování trasy. Je vybrán nejrychlejší a nejbezpečnější způsob provozu;

Řešení dalších problémů, které na trase nastanou.

b) Pojištění nákladu. Nákladu se po cestě může stát cokoli. Může být poškozen, zničen, odcizen atd. K eliminaci těchto rizik pojišťovny pojišťují náklad, přepravní náklady na jeho doručení a dokonce i nějakou část očekávaného zisku.

Posláním společnosti EcoTrans LLC je poskytovat klientům vysoce kvalitní, vysoce profesionální dopravní služby s cílem navázat dlouhodobá partnerství se stávajícími spotřebiteli a přilákat nové.

3.1 Organizační struktura společnosti EcoTrans LLC

Ve společnosti EcoTrans LLC jsou generálnímu řediteli podřízeni: hlavní účetní, hlavní inženýr, elektrotechnik, správce systému. Účetní podává zprávy hlavnímu účetnímu. Skladník se hlásí účetní. Hlavnímu inženýrovi jsou podřízeni: skladník, mechanik, zdravotník, dispečer. Dispečerovi jsou podřízeni: mechanici, řidiči automobilů, řidiči autobusů, řidiči vysokozdvižných vozíků. Mechanikovi jsou podřízeni: řidiči automobilů, řidiči autobusů a řidiči vysokozdvižných vozíků.

3.2 Obchodní proces „Přeprava nákladu“

Obchodní proces „Nákladní přeprava“ zahrnuje:

1 Příjem žádosti. Zákazník odešle požadavek dispečerovi a ten jej akceptuje.

2 Uzavření smlouvy. Mezi zákazníkem a ředitelem je uzavřena smlouva, na základě které je přeprava realizována.

3 Kontrola existence smlouvy. Dispečer zkontroluje existenci smlouvy.

4 Zpracování žádosti. V souladu s technickými vlastnostmi vozidla dispečer na základě aplikace s přihlédnutím k rozměrům, hmotnosti nákladu a přepravním podmínkám přiděluje vozidla.

5 Vystavení nákladního listu. Dispečer zavolá řidiči, informuje ho o nadcházejícím letu a trase a vystaví nákladní list.

6 Absolvování lékařské prohlídky. Řidič se podrobí lékařské prohlídce.

7 Známka při absolvování lékařské prohlídky. Zdravotnický pracovník zjišťuje obsah alkoholu a psychotropních látek v těle, zdravotní stav: měří puls, krevní tlak, teplotu, zjišťuje míru únavy a kvalitu spánku. Pokud je lékařská prohlídka úspěšná, zdravotnický pracovník vyznačí na nákladním listu.

8 Denní údržba vozidla. Řidič provádí každodenní údržbu vozidla. Kontroly: kompletnost vozu, hladina chladicí kapaliny a mazacích kapalin, těsnost systémů vozu, stav a upevnění kol, činnost brzdových systémů, světelná a zvuková signalizace.

9 Vyznačte provozuschopnost vozidla na nákladním listu. Řidič vyznačí na nákladním listu poznámku o kontrole vozidla.

10 Kontrola vozidla. Řidič předá vozidlo ke kontrole mechanikovi. Mechanik kontroluje vozidlo. Kontroly: těsnosti a funkce brzdových systémů, systémů napájení, chladicích systémů, výfukových systémů; provozuschopnost řízení, vnějšího osvětlení, stěračů čelního skla; upevnění kola; dostupnost lékárničky, hasicího přístroje a výstražného trojúhelníku.

11 Vyznačte provozuschopnost vozidla na nákladním listu. Mechanik učiní poznámku o provozuschopnosti vozidla na nákladním listu.

12 Nákladní doprava. Řidič odjede na linku, vyzvedne náklad na určeném místě a doručí jej příjemci.

13 Příjem dokumentů . Řidič si vyzvedne dodací listy od zákazníka.

14 Vraťte se z řady. Řidič z linky se vrací do garáže.

15 Kontrola vozidla. Při návratu z linky poskytne řidič vozidlo ke kontrole mechanikovi.

16 Poznámka o stavu vozidla na nákladním listu. Mechanik zaznamená stav vozidla do nákladního listu.

17 Předání dokladů do účtárny. Řidič předkládá faktury účetnímu oddělení.

18 Vystavování dokladů účetním oddělením. Účetní oddělení vystavuje doklady: potvrzení o provedení práce, fakturu, fakturu k zaplacení.

19 Platba za služby zákazníkem. Účetní oddělení předá vystavené doklady k platbě zákazníkovi. Zákazník platí za poskytnutou službu.

3.3 IT infrastruktura

modelování informační sítě

Síťová architektura je kombinací topologií, metod přístupu k médiím a protokolů nezbytných k vytvoření funkční sítě.

LAN - místní síť (LAN, local area network).

V organizaci EcoTrans LLC je LAN vytvořena podle „hvězdové“ topologie.

IS objektu průzkumu využívá adresářovou službu Microsoft Corporation - Active Directory. Tato služba se používá k regulaci zásad skupiny domén. Domény mají hierarchickou strukturu.

V hardwarové části IS objektu: 2 servery; 16 pracovních stanic.

Software EcoTrans LLC: operační systém Windows XP Service Pack 2/3, MS Office 2007, antivirový software - Panda Antivirus Platinum, daňový poplatník, právnická osoba, 1C: Účetnictví, 1C: Platy a personál, PP "Adresář certifikátů", CIPF Crypto About CSP, PP "STEC-Trust". AWS "TRUST-Client", Systém "STEC-Trust". Pracovní stanice pojistníka, Nástroj pro Fond sociálního pojištění, Dokumenty PU 5, CheckXML, Canon Solution Menu, ABBYY FineReader Professional Edition, Total Commander, WinDjView, Adobe Acrobat Professional, WinRAR a další.

4. Popis obchodních procesů TC LLC "EcoTrans" s využitím obchodního modelování v Microsoft Visio

4.1 Sestavení modelu v notaci IDEF0 a jeho rozklad

Vytvořme model TC LLC "EcoTrans" pomocí metodiky IDEF0. Nejprve sestavíme kontextový diagram obchodního procesu „Nákladní přeprava“ (obrázek 4.1). Podle notace IDEF0 nazvěme tento funkční blok „Transport cargo“.

Obrázek 4.1 - Kontextový diagram procesu „Přeprava nákladu“.

Poté rozdělíme obchodní proces „Přeprava nákladu“ na komponenty: „Zpracování žádosti“, „Uzavření smlouvy“, „Příprava na přepravu nákladu“, „Příprava dokumentů potřebných pro přepravu nákladu“, „Provedení přeprava nákladu“. A podle toho rozložíme funkční blok „Transport cargo“ (obrázek 4.2).

Obrázek 4.2 - Schéma rozkladu procesu „Přeprava nákladu“.

Podívejme se blíže na obchodní procesy: „Zpracování aplikací“ (obrázek 4.3); „Příprava na přepravu nákladu“ (obrázek 4.4); „Evidence dokumentů nezbytných pro přepravu zboží“ (obrázek 4.5); „Přeprava nákladu“ (obrázek 4.6).

Obrázek 4.3 - Schéma rozkladu procesu „Zpracování aplikace“.

Obrázek 4.4 - Schéma rozkladu procesu „Příprava na přepravu nákladu“.

Obrázek 4.5 - Schéma rozkladu procesu „Evidence dokladů nezbytných pro přepravu zboží“

Obrázek 4.6 - Schéma rozkladu procesu „Přeprava nákladu“

4.2 tSestavení modelu v notaci IDEF3

Nyní sestavíme model TC LLC "EcoTrans" pomocí metodiky IDEF3. Rozklad procesu „Přeprava nákladu“ je znázorněn na obrázku 4.7

Obrázek 4.7 - PFDD diagram rozkladu procesu „Cargo Transportation“.

Symbol „“ znamená „Exkluzivní OR“, také známý jako „XOR“ (Exkluzivní OR).

Závěr

Při studiu tématu „Popis podnikových procesů podniku poskytujícího služby silniční dopravy v MS Visio“ byl zjištěn význam popisu podnikových procesů pro optimalizaci procesů podniku.

Popis obchodních procesů je možný různými způsoby: textovým, tabulkovým, grafickým. K jejich popisu existuje mnoho metodik (IDEF0, IDEF3, DFD, WORKFLOW, UML, ARIS a další) a nástrojů (BPWin, ERWin, PowerDesigner a další).

Pro popis obchodních procesů společnosti TC LLC "EcoTrans" v grafické podobě byly zvoleny metodiky modelování obchodních procesů IDEF0, IDEF3. Modelování bylo provedeno pomocí produktu společnosti Microsoft – Visio. Tento program má připravenou šablonu pro modelování v notaci IDEF0, ale pro IDEF3 jsme si museli vytvořit vlastní sadu prvků. To potvrzuje nízkou funkčnost, ale zároveň absenci globálních omezení v procesu návrhu.

Přidání grafického popisu k jednoduchému textovému popisu obchodních procesů společnosti EcoTrans LLC jim poskytlo přehlednost. A ve výsledku poskytl více příležitostí pro systémovou analýzu a optimalizaci činností společnosti.

Pokud vezmeme v úvahu dostupnost programu Microsoft Visio pro ruského uživatele, jeho snadnost použití a vezmeme v úvahu nově vznikající výhody grafického modelování obchodních procesů, lze tvrdit, že diagramy navržené v MS Visio jsou dostatečně praktické. pro velký počet uživatelů.

Literatura

1 Golichev V.D., Golicheva N.D., Gusarova O.M. a další Aktuální otázky ekonomiky a managementu v kontextu modernizace. Kolektivní monografie. - Smolensk: Smolgortypografie, 2014. - 212 s.

2 Gusarová O.M. Modelování obchodních výsledků v organizačním řízení // Perspektivy rozvoje vědy a vzdělávání. - Tambov: Business-Science-Society, 2014. - str. 42-43.

Publikováno na Allbest.ru

...

Podobné dokumenty

Provedení předprojektového průzkumu podniku. Budování modelu organizační a funkční struktury společnosti. Vytvoření organizačního schématu v MS Visio. Seznam a struktura dokumentů, které by měl informační systém generovat.

praktické práce, přidáno 14.02.2012

Modelování podnikových procesů jako prostředek hledání cest k optimalizaci činnosti firmy. Metodologie SADT (Structural Analysis and Design), rodina standardů IDEF a algoritmické jazyky jsou základem metodologií modelování obchodních procesů.

abstrakt, přidáno 14.12.2011

Architektura integrovaných informačních systémů ARIS jako metodika pro modelování podnikových procesů, výhody a nevýhody použití. Výběr podnikového procesu pro modelování a jeho smysluplný popis, tabulkový formát pro jeho popis.

práce v kurzu, přidáno 19.06.2015

Účel aplikace Microsoft Visio. Soubory obrázků objektů určitých typů. Požadavky na software. Vlastnosti uživatelského rozhraní. Funkce, operace a techniky Microsoft Visio. Interakce designéra s aplikacemi.

test, přidáno 19.12.2010

Podstata, význam a metodika modelování podnikových procesů. Historie vývoje metodik modelování. Systematizace znalostí o firmě a jejích obchodních procesech ve vizuální grafické podobě pro analytické zpracování obdržených informací.

abstrakt, přidáno 29.04.2009

Hlavní význam UML popisu. Popis hlavních součástí používaných v aplikaci Microsoft Visio. Tvorba diagramů tříd v Microsoft Visio 2010. Revize vygenerovaného modelu při úpravách systému. Struktura systému, jeho třídy, atributy a operátory.

praktické práce, přidáno 05.07.2014

Návrh lokální počítačové sítě. Výběr topologie sítě, architektury a struktury systému. Analýza informačních toků v distribuovaném systému, výběr simulačního systému. Stanovení nákladů na vytvoření a vývoj systému.

práce, přidáno 21.05.2015

Správa vzdálené konfigurace a instalace softwaru. Historie vývoje VMware ThinApp. Vytvoření automatického instalačního balíčku pro Microsoft Office Visio Professional 2007. Analýza softwaru pro něj. Testování výsledného balíčku msi.

práce v kurzu, přidáno 14.03.2013

Srovnávací analýza hotelových informačních systémů. Analýza a výběr CASE nástrojů pro modelování podnikových procesů. Vizuální a matematické modely oboru, volba architektury a platformy informačního systému, konstrukce databáze.

práce, přidáno 20.07.2014

Prostředí Microsoft Visio: koncepce, hlavní funkce. Funkce automatického připojení v aplikaci Office Visio 2007. Funkce pravděpodobnosti protokolování. Graf pravděpodobnosti selhání verze softwaru. Vizuální modelování v UML. Celkový pohled na diagram tříd.

Pracovní postupy jsou důležitou a téměř povinnou součástí portálu SharePoint, jsou základem toku dokumentů a mnoha dalších obchodních procesů. Není divu, že existují systémy jako Nintex, které se snaží rozšířit a doplnit možnosti standardních pracovních postupů.

Z mé zkušenosti s prací s Nintexem mohu říci, že tento systém není bez nevýhod: vysoká cena, periodické chyby, obecná pomalost systému (ačkoli to je typické pro všechny SharePointy) - to vše mě nutí používat standardní mechanismus workflow . Nintex má však důležitou výhodu – vizualizaci diagramu a aktuálního stavu procesu. Díky tomu je tvorba workflow zjednodušena a mohou je vytvářet i lidé, kteří mají do programování poměrně daleko (správci obsahu, business analytici atd.). SharePoint 2010 má podobnou schopnost vytvořit pracovní postup založený na vizuálním diagramu pomocí Visio 2010 a SharePoint Designer 2010.

Vytvořte diagram v aplikaci Visio

Visio 2010 má novou šablonu – Microsoft SharePoint Workflow (k dispozici pouze v Premium edici Visio). Diagram získaný z této šablony lze exportovat do Designeru pro další práci.
Otevřete tedy Visio a vyhledejte šablonu v kategorii Vývojový diagram.

Po otevření šablony budou prvky diagramu umístěny vlevo - podmínky, akce, začátek a konec (snímek obrazovky zobrazuje pouze „rychlé“ akce, obecně jich je mnohem více):

Nyní se zamyslíme nad logikou obchodního procesu a vytvoříme diagram pomocí nezbytných prvků. Jako příklad jsem vytvořil jednoduchý proces schvalování firmy:

existují 2 seznamy – „Doručená pošta“ a „Odpovědnost“
v seznamu „Odpovědní“ jsou kategorie požadavků (návrh/dotaz/stížnost atd.) a odpovídající odpovědné osoby
uživatel vytvoří položku ve složce Doručená pošta a určí kategorii
workflow najde osobu odpovědnou za tuto kategorii a vytvoří pro ni úkol
odpovědná osoba na úkol zareaguje a stav požadavku v seznamu doručené pošty se změní

Samozřejmě je těžké to pojmout slovy, takže vám okamžitě dám hotový diagram pracovního postupu:

Při vytváření diagramu není nic složitého, stačí si představit logiku obchodního procesu. Popisky u prvků jsou celkem přehledné, ikony zabraňují záměně. Po vytvoření exportujte proces do souboru pro SharePoint Designer:

Navázání procesu na data v SharePoint Designeru

Otevřete Designer, připojte se k požadovanému webu a přejděte do složky Workflows. Na pásu karet klikněte na tlačítko „Importovat z aplikace Visio“ a zadejte soubor s uloženým diagramem. Napíšeme název pracovního postupu a seznam, ke kterému ho vážeme (v tomto případě „Doručená pošta“). Designer sám vygeneruje kód a komentáře k němu, vše, co musíme udělat, je označit pole, ze kterých získáme data (konkrétně v tomto případě jsem měl drobné problémy kvůli použití pole typu Lookup, ale obvykle; vše je jednoduché):

Po dokončení pracovního postupu přejděte do nastavení. Zde označíme nezbytnou podmínku spuštění (spustí se automaticky při vytvoření prvku) a také zaškrtneme možnost „Zobrazit vizualizaci pracovního postupu na stavové stránce“ (je třeba aktivovat funkce SharePoint Server Enterprise na kolekci webů). To je přesně to, proč stojí za to vytvářet pracovní postupy ve Visiu. Nyní přejděte na web, vytvořte libovolnou položku v seznamu Doručená pošta, přejděte na seznam úkolů a dokončete úkol a poté otevřete okno stavu pracovního postupu:

Vidíme tedy docela pěkný workflow diagram, který označuje všechny dokončené fáze. Pokud by se proces v jakékoli fázi zastavil (například čekal na schválení od nás), bylo by to také zaznamenáno na diagramu. Díky tomu bude každý uživatel vidět, v jaké fázi schvalování se jeho požadavek nachází.

Závěr

Jako shrnutí uvedu pozitivní a negativní aspekty používání Visia k vytváření pracovních postupů (podle mého subjektivního názoru).
Klady:

Snadné vytvoření, nemusíte být programátor
Uživatel může snadno zobrazit a pochopit stav požadavku

mínusy:

Vyžaduje SharePoint Enterprise Server a Visio Premium

Často dostávám otázku – co číst o obchodních procesech?
Jedna z nejlepších stránek na ruském internetu je www.klubok.net. Sám jsem na fóru a článcích na tomto webu „vyrostl“. Mnoho článků neztratilo na aktuálnosti ani nyní. Doporučuji začít s ním studovat.

Ale pokud mluvíme o knihách, mohu s jistotou říci, že nejlepší knihou o obchodních procesech je kniha napsaná Repinem a Eliferovem: „Podnikové procesy, analýza, regulace“.

Popis obchodních procesů: snaha o jednoduchost.

Článek pojednává o problematice výběru notace pro popis procesů za účelem následné regulace. Porovnávají se často používané zápisy Work Flow, jako například: „Simple Flow Diagram“ v MS Visio, „Procedure“ v Business Studiu, zápis ARIS eEPC a další.

Při porovnávání zápisů je hlavní důraz kladen na vytváření procesních diagramů, které jsou jednoduché a srozumitelné pro zaměstnance organizace.

Pro obchodní analytiky společností jsou teze diskutované v článku vážným důvodem k zamyšlení nad tím, jak efektivní jsou přístupy, které používají k vytváření grafických diagramů organizačních procesů.

Úvod

Jedním z nejdůležitějších cílů vytváření grafických procesních diagramů je jejich následné použití v regulačních dokumentech organizace. Tato schémata zpravidla používají zaměstnanci, kteří nejsou vyškoleni ve složitých notacích, nemají dovednosti systémové analýzy atd. Jednoduchost a přehlednost schémat je pro ně velmi důležitá. Složitým, matoucím diagramům obsahujícím mnoho různých symbolů lidé špatně rozumějí, což ztěžuje jejich použití v praxi. Proto je pro praktické účely důležité správně vybrat a používat notaci (metodiku) pro popis procesů. Jaká kritéria by měla být použita pro výběr takového zápisu? Jak porovnat různé zápisy mezi sebou? Podívejme se na několik populárních notací a pokusme se na tyto otázky odpovědět.

Porovnání notací

Pro srovnání byly zvoleny následující zápisy popisu procesu:

„Jednoduchý vývojový diagram“ (zobrazení pohybu dokumentů pomocí bloku „Řešení“);
„Jednoduché blokové schéma“ (bez zobrazení pohybu dokumentů, bez použití bloků „Řešení“);
„Postup“ systému Business Studio (jedna z možných variant prezentace);
ARIS eEPC.

Jako testovací případ byl zvolen jednoduchý a intuitivní proces. Výsledky popisu tohoto procesu jsou uvedeny na Obr. 1-4.

Rýže. 1. Diagram procesu v zápisu „Simple Flowchart“ v MS Visio (s pohybem dokumentů pomocí bloku „Rozhodnutí“).

Ve schématu Obr. 1. Posloupnost operací procesu v průběhu času je znázorněna pomocí silných šipek a pohyb dokumentů je znázorněn pomocí tenkých tečkovaných šipek. Bloky řešení se používají klasickým způsobem. Zobrazují informace (otázky), na kterých „závisí“ další průběh procesu. Tento přístup k používání „diamantů“ je velmi běžný. Ve skutečnosti by však celá logika rozhodování a vytváření určitých výstupů (dokumentů) měla být obsažena v operacích procesu. Pokud se nad tím zamyslíte, hodnota (význam) kreslení těchto „diamantů“ není zřejmá. Jaké jsou tyto objekty: operace procesů, události? Zdá se, že není ani jedno, ani druhé. Jedná se spíše o operátory pro rozhodování na základě nějaké podmínky. Ale vyvíjíme procesní diagram pro lidi, a ne píšeme počítačový program ve speciálním jazyce. V počítačovém programu by byl „diamant“ plnohodnotnou operací pro porovnávání podmínek atd. Procesní diagram však musí zobrazovat skutečné objekty - procesy prováděné lidmi, dokumenty, informační systémy atd. Přemýšlejte o tom: je správné zobrazovat „diamanty“ odděleně od operace procesu na diagramu? Místo toho můžete:

a) popsat logiku rozhodování ve formě sledu operací na schématu uvažovaného procesu;
b) popsat logiku ve formě diagramu kroků odpovídajícího podprocesu s přechodem na nižší úroveň;
c) popsat logiku textem (v textových atributech operace) a následně ji zobrazit v předpisech pro provádění procesu.

Zformulujme „pro“ a „proti“ výše popsané metody použití „diamantů“ (obr. 1).

"Jednoduchý vývojový diagram" v MS Visio (s pohybem dokumentu, pomocí bloku "Řešení")
"Klady"	"mínusy"
Vizuální zobrazení „logiky“ výběru určitých procesních výstupů. Zaměření pozornosti interpreta na rozhodovací bod/rozvětvení procesu v závislosti na podmínkách.	Přesunutí rozhodovací logiky „mimo“ procesní provoz (nesprávné z hlediska formální dekompozice procesu). Dokumentovat proces je nepohodlné (při vytváření textového popisu operace musíte „kosočtverce“ duplikovat textem). Procesní diagram se stává informačním přetížením. „Diamanty“ se často používají příliš formálně, bez skutečné potřeby.

Na Obr. 2. ukazuje příklad stejného procesu, pouze popsaného bez použití bloků a dokumentů „Solution“. Je snadné zkontrolovat, že tento diagram má o 24 méně grafických prvků než diagram na Obr. 1. Schéma Obr. 2. vypadá mnohem jednodušeji. Grafické prvky neoslňují oči a z hlediska informačního obsahu je toto schéma celkem srozumitelné a dostupné koncovému uživateli. Pokud u každé procesní operace popíšete textově požadavky na její implementaci, pak kombinací tabulkové a grafické prezentační formy můžete zcela adekvátně popsat postup provedení procesu pro zaměstnance firmy.

Rýže. 2. Diagram procesu v zápisu „Jednoduchý vývojový diagram“ v MS Visio (bez pohybu dokumentu, bez použití bloku „Rozhodnutí“).

„Pro“ a „proti“ grafického znázornění procesu ve formě uvedené na Obr. 2. jsou uvedeny níže.

Obecně platí, že použití diagramů ve formátu podobném těm na Obr. 2 je vhodný jak pro vývojáře, tak pro zaměstnance pracující na těchto schématech.

Na Obr. 3. Zobrazí se procesní diagram vytvořený v zápisu „Procedura“ v modelovacím prostředí Business Studio. Schéma má několik funkcí. Za prvé, bloky „Rozhodnutí“ se nepoužívají standardním způsobem – nikoli jako grafický prvek pro zobrazení otázky a větvení, ale jako plnohodnotná procesní operace spojená s rozhodováním. V Business Studiu má „diamant“ téměř všechny atributy plnohodnotného procesu, ale nelze jej rozložit (snad to vývojáři systému časem umožní). Použití „diamantu“ (místo čtyřúhelníku) činí diagram vizuálnějším. Zároveň můžete do atributů „diamantu“ zadat libovolné textové informace: popis, začátek, dokončení, požadavky na termín atd.

Druhý rys procesního diagramu na Obr. 3., je použití šipek. Chcete-li zobrazit posloupnost operací, můžete použít šipku s jedním hrotem - šipku „precedence“. K zobrazení pohybu dokumentu můžete použít dvouhlavou šipku. Ale právě v Business Studiu můžete použít pouze jeden typ šipek - šipky „precedence“. Zároveň lze na pojmenované šipky propojit požadovaný počet dokumentů, které jsou definovány v adresáři objektů aktivit. Tento přístup umožňuje:

výrazně snížit počet grafických prvků v procesním diagramu a zároveň:
zobrazit potřebné informace o příchozích a odchozích dokumentech v procesních předpisech.

Bez zahlcení diagramu zbytečnými prvky můžeme přesto celý proces popsat a všechny potřebné informace nahrát do předpisů.

„Pro“ a „proti“ grafického znázornění procesu ve formě uvedené na Obr. 3. jsou uvedeny níže.

Rýže. 3. „Procedura“ systému Business Studio (možnost s netradičním využitím bloků „Solution“).

Při použití Business Studia lze zápis procedury používat mírně odlišnými způsoby. Autor článku se přiklání k přístupu uvedenému na Obr. 3.

Na Obr. Obrázek 4 ukazuje schéma uvažovaného procesu vyvinutého v notaci ARIS eEPC. Všimněte si, že některé procesní operace se do diagramu nevešly. Tento dílčí diagram jednoduchého procesu, napsaný v notaci ARIS eEPC, obsahuje čtyři logické příkazy a osm událostí! Osoba, která čte diagram, musí být schopna správně interpretovat všechny tyto logické operátory. Bez speciálního školení a určitých dovedností ve čtení takových diagramů je nepravděpodobné, že by běžný zaměstnanec byl schopen porozumět logice daného procesu bez podrobného textového popisu nebo pomoci kvalifikovaného obchodního analytika.

Všimněte si, že procesní diagram v notaci ARIS eEPC zabírá podstatně více místa než diagramy uvedené na Obr. 1-3. Složitost vytvoření takového schématu je také výrazně vyšší.

Procesní diagram v notaci ARIS eEPC (vestavěný v Business Studiu)
"Klady"	"mínusy"
Při vytváření diagramu je zachována přísná formální logika procesu. Všechny události, ke kterým během procesu dojde, jsou jasně definovány.	Obtížnost vnímání. Značná složitost tvorby schématu. Personál musí mít specializované dovednosti a zkušenosti s interpretací takových diagramů. Informační redundance. Zabírá příliš mnoho místa, což je pro dokumentaci nepohodlné.

Obecně platí, že pokud se nechystáte kupovat SAP R/3, pak výběr a používání notace ARIS eEPC není z pohledu autora článku optimálním řešením. Stojí za to věnovat pozornost zápisům pro popis procesů, které jsou pro účinkující vizuálnější a intuitivnější. Někomu se však může zdát zápis ARIS eEPC vizuálnější a srozumitelnější. Do jisté míry je to věc vkusu.

Rýže. 4. Diagram procesu v notaci ARIS eEPC (vestavěný v Business Studiu).

Popis procesu pro účely následné automatizace

Je zajímavé podívat se na dotyčný procesní diagram, pokud je popsán v notaci BPMN 2.0. Tento zápis je určen k popisu „provádění“ procesů, tzn. procesy podporované systémem BPM.

Váš názor na používání BPMN 2.0. akcie A.A. Belaichuk - generální ředitel společnosti "Business Console":

Na Obr. Obrázek 5 znázorňuje stejný proces v notaci BPMN. Jak vidíme, tento obrázek je podobný obrázku 1: v zápisu BPMN jsou úkoly zobrazeny jako obdélníky, vidlice jako kosočtverce a data jako ikona podobná dokumentu. Řídicí toky jsou plné čáry, datové toky jsou tečkované.

Je třeba vzít v úvahu, že tento diagram používá pouze malou část zápisu BPMN: pouze jeden typ vidlice z 5 dostupných v paletě, jeden typ úlohy z 8. Kromě širší palety je tato notace vyznačuje se schopností modelovat nejen izolovaný pracovní tok, ale také několik procesů, které na sebe vzájemně reagují prostřednictvím zpráv nebo dat. Tento zápis je navíc přísnější: definuje nejen ikony, ale také pravidla, podle kterých je lze vzájemně kombinovat. Potřeba takových pravidel je dána skutečností, že notace BPMN je zaměřena nejen na skutečnost, že bude čtena lidmi, ale také na přímé provádění speciálním softwarem - „motorem“ systému BPM.

Zároveň, jak ukazuje tento příklad, při použití omezené podmnožiny palety se ukázalo, že BPMN není o nic složitější než konvenční vývojový diagram. Pro ty, kteří chtějí BPMN ovládnout profesionálně, doporučujeme specializované školení www.bpmntraining.ru.

Rýže. 5. Diagram procesu v notaci BPMN 2.0.

Životní praxe

Na Obr. Obrázek 6 ukazuje fragment procesního diagramu vyvinutého obchodními analytiky velmi specifické společnosti v notaci, kterou vynalezli. Diagram je postaven na principech „Simple Block Diagram“ - blok „Solution“ je použit v klasické verzi. Kromě toho schéma ukazuje mnoho dalších symbolů používaných nestandardním způsobem.

Při vytváření diagramu na Obr. 6, obchodní analytici evidentně „bojovali“ o srozumitelnost a maximální srozumitelnost pro běžného uživatele. Snažili se minimalizovat, nebo dokonce eliminovat textové komentáře k procesním diagramům. Účinkující byli jednoduše vytištěni schématem formátu A3, po přečtení bylo vše okamžitě jasné: co dělat, jak, jaké dokumenty použít atd.

Zvažované schéma samozřejmě není příkladem jednoduchosti a jasnosti. Byl však vytvořen tak, aby zprostředkovával maximum užitečných informací těm, kteří jsou zapojeni do procesu.

závěry

Je tedy zřejmé, že při popisu procesů je třeba usilovat o jednoduchost a přehlednost pro zaměstnance.
Použití složitých, formalizovaných zápisů při popisu procesů vede k:

potíže při používání (interpretaci) diagramů běžnými zaměstnanci;
nemožnost (obtížnost) organizace práce na popisu procesů zaměstnanci oddělení, kteří neprošli speciálním školením;
výrazné zvýšení mzdových nákladů obchodních analytiků při vytváření schémat;
další potíže při dokumentaci obvodů (velký objem atd.);

Proto byste neměli zahlcovat procesní diagram různými grafickými prvky. Ale i když je používáte, je lepší, aby přinášely užitečné informace pro zaměstnance a nebyly pouze důsledkem formálního použití modelovacích notací.

V.V. Repin, Ph.D., docent, výkonný ředitel BPM Consulting Group LLC, vedoucí. Katedra řízení podnikových procesů Národní vzdělávací instituce vyššího odborného vzdělávání „IEF „Synergy“, zakladatel portálu www.FineXpert.ru

Právě tyto jednoduché principy se snažím zprostředkovat obchodním lídrům, kteří okouzleni krásnými prezentacemi softwarových produktů často zapomínají, že jednoduchý kontrolní seznam je často lepší než 10 stránek předpisů.

Tato lekce pojednává o vytváření jednoduchých (shora dolů, sledování dat, plánování procesů atd.) a funkčních vývojových diagramů (zobrazujících vztahy mezi obchodním procesem a odděleními).

Jednoduché blokové schéma

Šablona Simple Flowchart je navržena pro navrhování vývojových diagramů, diagramů shora dolů, diagramů sledování dat, diagramů plánování procesů a diagramů strukturální prognózy. Šablona obsahuje potřebné tvary, spojovací čáry a vazby.

Cvičení 1

Rýže. 3.3.Jednoduchý vývojový diagram (3. fáze)

8. Zadejte text do tvarů vývojového diagramu (viz obrázek 3.4). Chcete-li zadat text do tvaru, postupujte takto:

9. Na kartě Domov ve skupině Servis vyberte nástroj Ukazatel.

Klepněte na tvar, kam chcete zadat text.
Zadejte požadovaný text.

Poznámka:

Chcete-li obrázek přiblížit, stiskněte klávesovou zkratku + a klikněte levým tlačítkem na tvar, dokud nedosáhnete požadovaného měřítka.
Chcete-li zmenšit měřítko obrázku, stiskněte klávesovou zkratku + a klikněte pravým tlačítkem na tvar, dokud nedosáhnete požadovaného měřítka.

Rýže. 3.4. Jednoduchý vývojový diagram (fáze 4)

Číslování obrázků v blokovém schématu

Visio umí číslovat obrazce ve vývojovém diagramu. Chcete-li zadat možnosti číslování, na záložce Pohled ve skupině Makra klikněte na tlačítko Doplňky a vyberte ve skupině Další řešení Visio tým Číslování figurek. V okně, které se otevře Číslování figurek zadejte požadované parametry číslování a klikněte na tlačítko OK.

Úkol 2

Do blokového diagramu připraveného během úlohy 1 doplňte automatické číslování všech obrázků (viz obr. 3.6).
Pro tohle:
- Na kartě Pohled ve skupině Makra klepněte na tlačítko seznamu Doplňky, vyberte skupinu Další řešení Visio a v něm příkaz Číslování figurek.
- V okně, které se otevře Číslování figurek specifikovat parametry
  - na kartě Jsou běžné:
    - Provoz - Automatické číslování;
    - Použít na - Všechny tvary;
    - Začít od - 1;
    - Interval - 1;
    - Zaškrtněte políčko Pokračovat v číslování obrazců při jejich přetahování na stránku.
  - Na kartě dodatečně:
    - Číslo místa - Před text tvaru;
    - Pořadí číslování: Zleva doprava, shora dolů;
    - Zaškrtněte políčko Vyloučit spojovací vedení.
  - Klepněte na tlačítko OK.
Uložte vývojový diagram.

Rýže. 3.6. Jednoduchý vývojový diagram (krok 6)

Změna vývojového diagramu

Přidání tvaru mezi dva další tvary

Chcete-li přidat nový tvar mezi dva další tvary vývojového diagramu, přetáhněte nový tvar na spojnici, která spojuje tvary, mezi které vkládáte. Visio vloží nový tvar mezi stávající a automaticky rozšíří vývojový diagram.

Smazání tvaru

Chcete-li odebrat tvar z vývojového diagramu, vyberte tvar a klikněte na klávesnici.

Přečíslování čísel

Chcete-li přečíslovat obrázky vývojového diagramu, postupujte takto:

Na kartě Pohled ve skupině Makra klikněte na tlačítko Doplňky a vyberte ve skupině Další řešení Visio tým Číslování figurek.
V okně, které se otevře Číslování figurek na kartě Jsou běžné vyberte přepínač Přečíslujte ve stejném pořadí, prosím Ukaž startovní číslo pro číslování a klikněte OK.

Úkol 3

Upravte vývojový diagram připravený v úloze 2:
- Smazat tvar Dokument(Odeslat přihlášku).
- Mezi figurkami Řešení(Přihláška je vyplněna správně) a Dokument(Odeslat odmítnutí) umístěte figurku Proces(Přeposlat asistentovi veletrhu).
- Přidejte tvar Proces(Zavolejte vystavovateli ohledně platby) níže na obrázku Dokument(zaslat fakturu).
- Přečíslujte obrázky blokového diagramu ve stejném pořadí, počínaje počátečním číslem - 1.
Uložte vývojový diagram.

Rýže. 3.7. Jednoduchý blokový diagram (krok 7)

Přeuspořádání spojených tvarů

Jakmile jsou tvary vývojového diagramu připojeny, můžete je zcela přeuspořádat a přeuspořádat připojení. Chcete-li to provést, na kartě Konstruktér ve skupině Rozložení klepněte na tlačítko seznamu Změnit rozvržení stránky a vyberte požadované rozvržení.

Pokud změníte rozložení vývojového diagramu, nemusí se vejít na stránku dokumentu. V takovém případě změňte velikost stránky (tab Konstruktér, skupina Nastavení stránky, tlačítko Seznam velikostí) nebo jeho orientaci (tab Konstruktér, skupina Nastavení stránky, tlačítko seznamu Orientace).

Úkol 4

Funkční blokové schéma

Účel uspořádání Funkční blokové schéma

Rozložení Funkční blokové schéma je určen k zobrazení vztahu mezi obchodním procesem a organizačními nebo funkčními jednotkami, jako jsou oddělení odpovědná za provádění kroků v tomto procesu.

Pruhy ve vývojovém diagramu představují funkční jednotky, jako jsou oddělení, pozice nebo jiné funkce. Každý tvar představující krok procesu je umístěn ve stopě funkční jednotky odpovědné za tento krok.

Úkol 5

Přidávání, přesouvání, mazání stopy

Pro dodatky stopy do funkčního blokového diagramu, proveďte jednu z následujících akcí:

Klikněte pravým tlačítkem na stopu na diagramu a vyberte Předtím vložte "Track". nebo Vložte "Track" za.
Najeďte myší na roh jedné ze stop. Klikněte na modrou šipku, která se zobrazí Vložte tvar cesty.
Na kartě Funkční blokové schéma ve skupině Vložit klikněte na tlačítko Dráha. Stopa bude přidána za vybranou stopu nebo na konec proužku, pokud stopa není vybrána.
Ze sady prvků Funkční blokové diagramy přetáhněte stopu na požadované místo na okraji pruhu.

Pro hnutí stopy:

Klepnutím na název stopy, kterou chcete přesunout, ji zvýrazníte. Ukazatel myši se změní na ikonu přesunutí.
Přetáhněte stopu na požadované místo.

Figurky umístěné na dráze se budou pohybovat spolu s ní. Chcete-li zkontrolovat, zda je obrazec na stopě nebo pouze nad ní, vyberte tvar. Pokud je figurka na dráze, barva stopy se změní na žlutooranžovou. Pokud figurka není na dráze, ale je třeba ji tam umístit, trochu s ní pohněte a stopa ji identifikuje.

Pro odstranění stopy:

Klikněte na štítek stopy, který chcete odstranit.
Stiskněte klávesu na klávesnici.

Poznámka. Odstraněním stopy se také odstraní všechny tvary, které obsahuje.

Tento článek navazuje na sérii publikací věnovaných nástrojům, které mohou ruské společnosti použít k řešení problémů modelování a zlepšování podnikových procesů bez významných rizik. Připomeňme, že předchozí článek této série hovořil o produktech společnosti IDS Scheer, která zaujímá nejvyšší příčky v hodnocení analytických společností. Dnes bude řeč o produktu jiné cenové relace, ne tak funkčním z pohledu modelování podnikových procesů, ale velmi oblíbeném a rozšířeném - Microsoft Visio.

A opět názor analytiků...

Nízké náklady společnosti Visio spolu s faktory, jako je například zařazení do přední rodiny kancelářských produktů od lídra v softwarovém průmyslu, vedly k velmi významnému tržnímu podílu nástrojů pro modelování obchodních procesů (34 % podle Gartner) a vysokému umístění ve zprávách analytiků. . Analytická společnost Gartner tak řadí tento produkt mezi lídry trhu (obr. 1).

Rýže. 1. Přední výrobci nástrojů pro analýzu podnikových procesů
(zdroj: Blechar M. Magic Quadrant for Business Process Analysis Tools,
2H07-1H08 – Výzkumná zpráva Gartner G00161090, 23. září 2008)

Podle Gartneru je Visio jedním z nejlepších nástrojů pro ty společnosti, které teprve začínají modelovat a analyzovat své obchodní procesy a zaměřují se především na jejich vizualizaci. V procesu rozvoje této oblasti ve firmě je však tento produkt obvykle nahrazen funkčnějším nástrojem.

Visio na ruském trhu

Na ruském trhu je Visio prezentováno stejným způsobem jako ostatní kancelářské produkty Microsoftu, to znamená, že je dostupné ve všech regionech prostřednictvím velmi rozvinuté partnerské sítě. Jeho prostřednictvím jsou poskytovány podpůrné služby, technická podpora a školení v ruštině. Ruská verze tohoto nástroje existuje již poměrně dlouho. O produktu a řešeních na něm založených existují knihy (včetně nástrojů pro modelování obchodních procesů; tyto nástroje jsou však předmětem samostatné diskuse, protože jejich dostupnost, možnosti a ceny se výrazně liší od dostupnosti, možností a cen původního produktu). ).

Vlastnosti produktu

Technické vlastnosti. Datové úložiště

Rýže. 2. Šablony diagramů, které jsou součástí aplikace Visio

Podporované metodiky a zápisy

Pokud lze sadu symbolů a šablon Visio libovolně rozšiřovat a produkt sám o sobě neznamená globální omezení možností použití symbolů a propojení mezi nimi, lze popis obchodních procesů pomocí Visio formálně provádět v rámci téměř jakoukoli metodiku. Zároveň produktový balíček v libovolné edici (Standard, Professional) obsahuje sadu šablon modelů pro nejběžnější zápisy, jako jsou diagramy datových toků, přidané diagramy řetězců kvality, Event-driven Process Chain, IDEF0, diagramy typu SwimLane , dále šablony pro modelování organizačních struktur firem (obr. 3 a 4).

Rýže. 3. Procesní model Swim Lane

Rýže. 4. Model typu EPC (Event-driven Process Chain).

Dokumentování procesů a vytváření řešení na bázi Visio

Microsoft Visio obsahuje prostředí pro provádění kódu Visual Basic for Applications, které umožňuje jak psát kód, zatímco uživatel pracuje, tak jej vytvářet pomocí vývojového prostředí (obrázek 5).

Rýže. 5. Vývojové prostředí VBA v aplikaci Microsoft Visio

Pro přístup k datům modelu poskytuje Visio odpovídající objektový model, který je přístupný prostřednictvím rozhraní COM jak z runtime kódu VBA v rámci samotné aplikace, tak z externích aplikací. Všimněte si, že programovací jazyk i objektové modely všech aplikací Microsoft Office, včetně aplikace Visio, jsou dobře zdokumentovány. To znamená, že s určitou znalostí programování VBA může uživatel generovat sestavy jakékoli složitosti, vytvářet nástroje pro přenos dat mezi Visio a dalšími modelovacími nástroji, generovat modely vytvářením řešení založených na aplikacích této rodiny a rozšiřovat funkčnost modelování. samotný nástroj a vytváření různých řešení (například pro simulační modelování, automatizované publikování modelů na internetu a další úkoly).

Kromě VBA můžete použít nástroje pro integraci Visia s aplikacemi Microsoft Office k dokumentaci procesů, jako je vkládání diagramů Office Visio 2007 do dokumentů Microsoft Office jako ilustrace a vytváření diagramů Visio 2007 přímo v těchto aplikacích, nástroje pro vytváření kalendářů ve Visiu 2007 pomocí Data aplikace Office Outlook 2007, nástroje pro připojení grafů aplikace Visio 2007 k tabulkám aplikace Excel 2007 nebo databázím aplikace Access 2007 za účelem integrace zdrojů dat a komponent grafů, nástroje pro generování grafů a Ganttových diagramů ve Visiu 2007 importem relevantních dat z aplikace Project 2007, nástroje pro export informací obsah Ganttových diagramů a grafů Visio 2007 v Office Project 2007, nástroj pro vytváření organizačních diagramů založený na globálním adresáři Exchange.

Dalšími zajímavými funkcemi pro dokumentování procesů jsou možnost uložit práci jako webové stránky, kterou poskytuje nejnovější verze Visio, a také možnost dynamicky vyměňovat procesní data s jinými aplikacemi pomocí standardizovaných výměnných formátů založených na XML, jako jsou ODX a BPEL.

Omezení a možné problémy

Fráze „v rámci téměř jakékoli metodiky“ použitá v jedné z předchozích částí článku neznamená, že Visio je nejlepším nástrojem pro modelování a analýzu obchodních procesů. Na rozdíl od rodiny produktů ARIS tedy Visio explicitně neřeší problém „co je stejný objekt“ – pravidla, podle kterých se rozhoduje, zda dva symboly na stejném modelu představují stejný objekt, musí uživatelé vyvíjet nezávisle a nezávisle jej dodržovat, přičemž produkt neposkytuje technické prostředky, které vyvinuté pravidlo podporují – budou muset být vytvořeny nezávisle pomocí stávajících softwarových rozhraní.

Kromě toho, jakmile počet modelů podnikových procesů potřebných k řešení podnikových problémů přesáhne tucet a existuje několik autorů modelů, otázka omezení přístupu autorů modelů k datům se stává velmi aktuální. Toto rozlišení můžete implementovat při používání Visio pomocí nástrojů pro řízení přístupu k souborům poskytovaných operačním systémem odpovídajícího souborového serveru nebo pomocí systému správy dokumentů, jako je EMC Documentum. Prostředky pro řízení přístupu k modelům jsou v tomto případě prostředky správy operačního systému nebo systému správy dokumentů, což znamená, že úkoly omezení přístupu k modelům jsou ve skutečnosti svěřeny správci systému.

Visio také neposkytuje mechanismus pro metodologické filtry (nástroje pro omezení typů modelů, objektů, vztahů dostupných konkrétnímu uživateli nebo skupině uživatelů pro konkrétní projekt), podobně jako jsou dostupné v řadě dalších nástrojů (např. , v produktech rodiny ARIS).

Co se týče prostředků pro zachování integrity a konzistence dat, ani zde nejsou součástí produktu žádné hotové mechanismy, ale můžete si je vytvořit sami pomocí výše uvedených softwarových rozhraní. Vývoj funkčnosti, která v produktu chybí, je však nákladem navíc a není pravda, že použití Visia v takových podmínkách bude ekonomicky opodstatněné.

Srovnání s jinými produkty

Zkusme porovnat Visio s jinými modelovacími nástroji.

Hlavní výhodou Visia oproti produktům zmíněných rodin je nízká cena a snadné použití, což z něj dělá dobrý startovací nástroj pro společnosti, které teprve začaly popisovat své obchodní procesy a stále se zajímají především o jejich vizuální znázornění. Další výhodou tohoto produktu je jeho dokonalá integrace s dalšími aplikacemi Microsoft Office – kancelářským balíkem, který je bezesporu lídrem na trhu. Důležitou výhodou tohoto produktu jsou dobře zdokumentovaná softwarová rozhraní – díky nim bylo vytvořeno mnoho řešení založených na Visiu, včetně dražších nástrojů pro modelování a analýzu obchodních procesů vyvinutých partnerskými společnostmi Microsoftu.

Nevýhody Visia jako nástroje pro modelování obchodních procesů jsou ve skutečnosti pokračováním jeho výhod. Snadné použití má za následek nedostatek funkčnosti, která se od takových nástrojů obvykle očekává, například nedostatek nástrojů pro omezení přístupu k datům, analýzu a kontrolu správnosti modelů, zachování integrity a konzistence dat. To znamená, že poté, co se rozhodnete používat Visio ve fázi formování procesního řízení a analýzy obchodních procesů, v budoucnu budete pravděpodobně muset věnovat pozornost jiným, funkčnějším modelovacím nástrojům, například produktům od IDS Scheer.

V diskuzi o nástrojích pro modelování obchodních procesů budeme pokračovat v dalších článcích této série.