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

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

Úvod

Modelování podnikových procesů v kontextu modernizace ekonomiky a managementu je důležitou oblastí, která pomáhá optimalizovat procesy organizace a zlepšovat výkonnost podniku. Když už mluvíme o modelování podnikových procesů, budeme používat terminologii několika oblastí znalostí souvisejících s ekonomikou, informatikou, modelováním komplexní systémy. Proto si vymezíme základní definice a pojmy.

Podnikatelský 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 zdroje podniku 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í vnitřních nebo externí spotřebitelé.

Termín „modelování“ má dva hlavní významy. Za prvé, modelování je chápáno jako proces budování modelu jako jakési reprezentace (obrazu) originálu, odrážející jeho nejdůležitější rysy a vlastnosti. Pokud byl model již vytvořen, pak je modelování procesem studia (analýzy) fungování systému, nebo spíše jeho modelu. Základním účelem modelování podnikových procesů je popsat skutečný průběh podnikových procesů podniku. Zároveň 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 jaká je spolehlivost procesu ( pravděpodobnost neúspěšného provedení) a jak jej lze v budoucnu rozšířit / upravit.

Je důležité zajistit transparentnost průběhu obchodních procesů, 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 odpovědný pro její 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 IT infrastruktury, která podporuje podnikání. Ú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čné nebo zamýšlené aktivity podniku.

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

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

Za předmět si označme: modelování podnikových procesů podniku, který se zabývá poskytováním služeb v autodopravách, v MS Visio.

Na základě problému určíme cíl: pomocí příkladu určit, jak praktické jsou diagramy navržené v MS Visio dopravní společnost(TK) 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 "EcoTrans" LLC

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

Chcete-li modelovat obchodní procesy, můžete použít různé metody. Metoda nebo metodologie modelování zahrnuje posloupnost akcí, které je třeba provést k sestavení modelu, tj. postup modelování a aplikovanou notaci (jazyk). V tomhle seminární práce, IDEF0, IDEF3 metodiky budou použity pro modelování obchodních procesů.

1. Metodika popisu předmětné oblasti

Proces obchodního modelování lze realizovat v rámci různých metod, které se liší především svým přístupem k tomu, co tvoří modelovanou organizaci. V souladu s různými představami o organizaci metod je zvykem je dělit na objektové a funkční (strukturální).

Objektové metody považují modelovanou organizaci za množinu vzájemně se ovlivňujících objektů – výrobní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ělení odpovědností mezi nimi za prováděné akce.

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

Z hlediska 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, lépe odpovídá stávajícím strukturám organizace. Funkční modelování se dobře projevuje v případech, kdy je organizační struktura v procesu změny nebo je obecně špatně navržena. Interpreti intuitivně lépe porozumí přístupu prováděných funkcí, 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 budování informačního systému je jasné a správně pochopené zadání problému. K dosažení tohoto cíle je nutné prostudovat všechny probíhající finanční a ekonomické procesy a odpovídající informační toky v podniku, identifikovat ty, které by měly být v první řadě reorganizovány, tzn. vybudovat tzv. business model. Takovéto komplexní průzkumy podniků jsou vždy složité a případ od případu se výrazně liší. Pro řešení takových problémů modelování složitých systémů existují dobře zavedené metodiky a standardy. Tyto standardy zahrnují rodinu metodologií IDEF. S jejich pomocí můžete efektivně zobrazovat a analyzovat modely aktivit široké škály komplexních systémů v různých sekcích. Šířku 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 jako součást programu průmyslové elektronizace ICAM (Integrated Computer Aided Manufacturing) ve Spojených státech amerických, během něhož byla odhalena potřeba vyvinout metody pro analýzu interakčních procesů v USA. výrobních systémů. Odtud název této rodiny standardů - Icam DEFINition - IDEF.

V současné době lze do rodiny IDEF přiřadit následující standardy:

IDEF0 je metodologie funkčního modelování. S pomocí vizuálního grafického jazyka IDEF0 se zkoumaný systém vývojářům a analytikům jeví jako soubor vzájemně provázaných funkcí (funkčních bloků – ve smyslu IDEF0). Typicky je modelování IDEF0 prvním krokem při učení jakéhokoli systému;

IDEF1 - 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) a obvykle se používá k modelování relačních databází relevantních pro uvažovaný systém;

IDEF2 je metodika pro dynamické modelování vývoje systémů. V souvislosti s velmi vážnými obtížemi při analýze dynamických systémů byl tento standard prakticky opuštěn a jeho vývoj byl pozastaven již v 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římý vztah k metodologii IDEF0 - každou funkci (funkční blok) lze pomocí nástrojů IDEF3 reprezentovat jako samostatný proces;

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é studium komplexních systémů. Pomocí metodiky IDEF5 lze ontologii systému popsat pomocí určitého slovníku pojmů a pravidel, na jejichž 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.

Podívejme se blíže na standardy, které budou vyžadovány při popisu obchodních procesů v této práci, jsou to: IDEF0, IDEF3.

Funkční metodika IDEF0.

Účelem metodiky je sestavení funkčního diagramu zkoumaného systému, který popisuje 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 je nějaký druh specifická funkce 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“). Ve schématu je funkční blok znázorněn obdélníkem (obrázek 1.1). Každá ze čtyř stran funkčního bloku má svůj specifický význam (role), přičemž:

Horní strana je "Ovládání";

Levá strana je "Vstup";

Pravá strana je nastavena na "Výstup";

Spodní strana má hodnotu "Mechanism" (Mechanismus).

Takové 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í jednotka v rámci jednoho uvažovaného systému musí mít své jedinečné identifikační číslo.

Obrázek 1.1 - Funkční blok

b) Oblouk rozhraní (šipka) 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 označují jako 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, vagony, zaměstnanci atd.) nebo datové a informační toky (dokumenty, data, instrukce atd.).

Podle toho, na kterou stranu funkčního bloku daný oblouk rozhraní zapadá, se nazývá „příchozí“, „odchozí“ nebo „řídící“.

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í oblouk. 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. Princip dekompozice se uplatňuje, když je složitý proces rozčleněn na jednotlivé funkce. V tomto případě úroveň detailu procesu určuje přímo vývojář modelu.

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

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

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

Ve vysvětlujícím textu pro kontextový diagram účel (Účel) sestavení diagramu ve formuláři Stručný popis a úhel pohledu je pevný.

Definice a formalizace účelu vývoje modelu IDEF0 je extrémně důležitým bodem. Cíl ve skutečnosti určuje relevantní oblasti ve zkoumaném systému, na které je třeba se zaměřit jako první. Pokud například modelujeme činnost podniku, abychom na tomto modelu v budoucnu vybudovali 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 řetězec dodavatelů.

Hledisko určuje hlavní směr vývoje modelu a míru potřebného detailu. Jasná fixace pohledu umožňuje vyložit model, odmítnout detaily a studovat 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ího technologa nezajímají dohledávaná schémata. finanční toky. Správná volba úhlu pohledu výrazně zkracuje čas strávený stavbou finálního modelu.

V procesu dekompozice je funkční blok, který v kontextovém diagramu zobrazuje systém jako celek, 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á podřízený diagram (Child diagram) (každý z funkčních bloků patřících do podřízeného diagramu je resp. nazývaný dětský blok - Child Box). Funkční blok - předchůdce se zase nazývá rodičovský blok ve vztahu k podřízenému diagramu (Parent Box) a diagram, ke kterému patří - rodičovský diagram (Parent Diagram). Každá z podfunkcí 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ě rozkladu funkčního bloku jsou všechny oblouky rozhraní obsažené v tomto bloku nebo z něj vycházející pevně 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 nemá smysl nadále uvažovat jednotlivé oblouky rozhraní v podřízených diagramech pod určitou úrovní v hierarchii nebo naopak - jednotlivé oblouky od určité úrovně nedávají praktický smysl. Například oblouk rozhraní znázorňující „detail“ na vstupu do „Zpracování zapnuto soustruh” nemá smysl reflektovat diagramy vyšších úrovní – tím se diagramy pouze přetíží a znesnadní jejich čtení. Na druhou stranu je potřeba zbavit se samostatných „koncepčních“ oblouků rozhraní a nedetailovat je hlouběji než na určitou úroveň. Pro řešení těchto problémů poskytuje standard IDEF0 koncept tunelování. Označení „tunelu“ (Arrow Tunnel) ve formě dvou závorek kolem začátku oblouku rozhraní znamená, že tento oblouk nebyl zděděn z funkčního nadřazeného bloku a objevil se (z „tunelu“) pouze na tomto diagramu. Na druhé straně, stejné označení kolem konce (šipky) oblouku rozhraní v bezprostřední blízkosti bloku přijímače znamená, že tento oblouk nebude zobrazen a nebude 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ě se nejprve „ponoří do tunelu“ a pak se v případě potřeby „vrátí z tunelu“.

d) Glosář. Pro každý z prvků IDEF0 – diagramy, funkční bloky, oblouky rozhraní – stávající standard předpokládá vytvoření a údržbu sady vhodných definic, klíčová slova, narativní výpovědi atd., které charakterizují objekt zobrazený tímto prvkem. Tato sada se nazývá glosář a je popisem podstaty tohoto 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í výzkum a modelování jejich scénářů. Scénář (Scenario) je v tomto případě popis sledu změn vlastností objektu 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;

Určit a analyzovat body vlivu toků doprovodného workflow na scénář technologických procesů;

Identifikujte situace, ve kterých je vyžadováno rozhodnutí, které má vliv životní cyklus zpracovat např. změnu konstrukčních, technologických nebo provozních vlastností konečného výrobku;

Přispívat k 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 úhlů pohledu. Diagramy související s prvním typem se nazývají diagramy popisu toku procesů (PFDD) a druhý typ se nazývá diagramy objektového stavu přechodové sítě (OSTN).

Předpokládejme, že chcete popsat proces lakování součásti ve výrobní dílně v podniku. Pomocí PFDD diagramů je dokumentován sled a popis fází zpracování dílce v rámci zkoumané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í příklad, popíšeme, jak nám grafické nástroje IDEF3 umožňují výše uvedené dokumentovat výrobní proces detailní zbarvení. Obecně se tento proces skládá přímo ze samotného lakování, které se provádí na speciálním zařízení, a z fáze jeho kontroly kvality, která určuje, zda je třeba díl přelakovat (v případě zjištění nesouladu s normami a manželství ) nebo odeslány k dalšímu zpracování.

Obrázek 1.4 ukazuje diagram PFDD, který je grafickým znázorněním scénáře zpracování součásti. Obdélníky v diagramu PFDD se nazývají funkční prvky nebo prvky chování (Unit of Behavior, UOB) a představují událost, procesní krok nebo rozhodnutí. Každá UOB má své jméno zobrazené ve verbální náladě a jedinečné číslo. Šipky nebo čáry představují pohyb součásti mezi bloky UOB během procesu.

Obrázek 1.4 - Diagram PFDD scénáře zpracování součásti

Objekt označený J1 se nazývá Junction. Křižovatky se používají k zobrazení logiky vzájemného působení šipek (toků) při slučování a větvení nebo k zobrazení sady událostí, které mohou nebo musí být dokončeny před zahájením další práce. Jsou zde křižovatky pro slučování (Fan-in Junction) a rozvětvení (Fan-out Junction) šipky. Křižovatku nelze použít pro sloučení a rozvětvení současně. 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ě odbočení vějíře
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 byly dokončeny ve stejnou dobu	Všechny následující procesy běží současně
	Jeden nebo více předcházejících procesů musí být ukončeno	Musí být spuštěn jeden nebo více 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ý v diagramu lze popsat následovně:

Díl vstupuje 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 je díl znovu pasován lakovnou. 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 samostatným diagramem 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ě bude tento diagram nazýván podřízeným diagramem ve vztahu k diagramu zobrazenému na obrázku 1.4, respektive rodičovským diagramem. Čísla UOB podřízených diagramů jsou číslována postupně, 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ě s libovolnou požadovanou úrovní detailů.

Pokud PFDD grafy technologický postup"Z pohledu pozorovatele", pak další třída diagramu IDEF3 - OSTN umožňuje uvažovat o stejném procesu "Z pohledu objektu". Obrázek 1.5 ukazuje zobrazení procesu barvení z pohledu OSTN diagramu. Klíčovými pojmy OSTN diagramu jsou „stavy objektů“ (v našem případě detaily) a „změna stavu“. Stavy objektu jsou zobrazeny jako kruhy a jejich změny jako směrované čáry. Každý řádek má vazbu na odpovídající funkční blok UOB, což vedlo ke změně stavu objektu, který představuje.

Obrázek 1.5 - Proces barvení z hlediska OSTN diagramu

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

Pro popis obchodních procesů je jich mnoho nástroje BPWin, ERWin, PowerDesigner, Business Studio, ELMA BPM, Visual Paradigm a další.

Do výše uvedeného seznamu můžete přidat Microsoft Visio, který patří do přední rodiny kancelářských produktů vyráběných lídrem softwarového průmyslu. Samozřejmě není tak funkční z hlediska modelování obchodních procesů, ale je velmi oblíbený a masivní 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). Výkres Visio obsahuje jeden nebo více diagramů uspořádaných na jedné nebo více stránkách. Každý dokument obsahuje sadu symbolů (odpovídajících objektům modelu) a spojnic (odpovídajících vztahům), přičemž symboly mohou mít kromě názvů další atributy definované uživatelem během modelování.

V případě potřeby lze znakovou sadu dodávanou s produktem rozšířit o znaky vytvořené uživatelem. Neexistují žádná globální omezení pravidel a možnosti vytvářet vazby mezi určitými typy symbolů v produktu, nicméně je v něm dostupný mechanismus tzv. šablon diagramů, jejichž použití umožňuje omezit množinu symboly dostupné přímo na příslušném panelu nástrojů během procesu modelování. Šablony mohou vytvářet uživatelé a produktový balíček obsahuje sadu hotových šablon (obrázek 2.1).

Soubor modelů popisujících činnost společnosti je zpravidla souborem samostatných souborů a v případě dostatečného velké společnosti a komplexní popis činnosti, počet takových souborů může být několik tisíc. Technické prostředky poskytovat vztahy mezi modely uloženými v různých souborech, není implementováno na úrovni produktu, ačkoli produkt poskytuje prostředky pro nezávislou implementaci takových vztahů (o nich si povíme trochu 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é množství údržby pro tak působivou sadu 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 Visia lze libovolně rozšiřovat a produkt sám o sobě neznamená globální omezení možností použití symbolů a vztahů mezi nimi, lze popis obchodních procesů pomocí Visia formálně provádět v rámci téměř jakoukoliv 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ů, řetězové diagramy s přidanou kvalitou, Event-driven Process Chain, IDEF0, diagramy SwimLane , dále šablony pro modelování organizačních struktur firem.

3. Analýza předmětu LLC "EcoTrans"

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. Mnoho největší podniky kraje podepsaly se společností 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 geografie dopravní obslužnosti pokročila daleko za hranice rodného regionu. Rozšíření geografie jejích aktivit si vyžádalo nárůst počtu moderních nákladních vozidel, proto k rozvozu zboží nyní využívá nejen vlastní rozsáhlý vozový park, ale i vozy partnerů.

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

A) Doprava 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:

Výzdoba požadované dokumenty. Přepravní 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é se na cestě objeví.

b) Pojištění nákladu. Nákladu se na cestě může stát cokoli. Může být poškozen, znehodnocen, odcizen atd. Aby tato rizika eliminovala Pojišťovny pojistit 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 zákazníků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 EcoTrans LLC

Ve společnosti EcoTrans LLC generální ředitel odpovídá: Hlavní účetní, Hlavní inženýr, Elektroinženýr, Správce systému. Účetní podává zprávy hlavnímu účetnímu. Skladník se hlásí účetní. Hlavnímu inženýrovi podřízeni: skladník, mechanik, zdravotnický pracovník, dispečer. Dispečerovi jsou podřízeni: mechanik, řidiči automobilů, řidiči autobusů, řidiči nakladačů. Na mechaniky se vztahují: řidiči aut, řidiči autobusů, řidiči vysokozdvižných vozíků.

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

Obchodní proces "Nákladní doprava" 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 Zkontrolujte existenci smlouvy. Dispečer zkontroluje existenci smlouvy.

4 Zpracování žádosti. V souladu s Technické specifikace dispečer vozidel na základě žádosti s přihlédnutím k rozměrům, hmotnosti nákladu a podmínkám přepravy 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č prochází lékařskou prohlídkou.

7 Označte o absolvování lékařské prohlídky. Zdravotník zjišťuje obsah alkoholu a psychotropní látky 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ích a mazacích kapalin, těsnost systémů vozu, stav a upevnění kol, činnost brzdových systémů světelných a zvukových alarmů.

9 Poznámka k provozuschopnosti vozidla v nákladním listu. Řidič vyznačí kontrolu vozidla v nákladním listu.

10 Kontrola vozidla. Řidič předá vozidlo ke kontrole mechanikovi. Mechanik kontroluje vozidlo. Kontroly: těsnost a funkce brzdových systémů, systémů napájení, chladicích systémů, výfukových systémů; provozuschopnost řízení, externích světelných zařízení, stěračů čelního skla; upevnění kola; dostupnost lékárničky, hasicího přístroje, značky nouzového zastavení.

11 Značka o provozuschopnosti vozidla v nákladním listu. Mechanik označí provozuschopnost vozidla v nákladním listu.

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

13 Příjem dokumentů. Řidič si od zákazníka převezme nákladní list.

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 Označte stav vozidla v nákladním listu. Mechanik označí stav vozidla v nákladním listu.

17 Předání dokladů do účtárny. Řidič odešle nákladní list do účetního oddělení.

18 Vystavování dokladů účetním oddělením. Účetní oddělení vypisuje doklady: provedené dílo, faktura, faktura k úhradě.

19 Platba za službu zákazníkem. Účtárna zasílá 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ů potřebných k vytvoření fungující sítě.

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

V organizaci EcoTrans LLC je LAN vytvořena podle hvězdicové 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 objektu IS: 2 servery; 16 pracovních stanic.

Software EcoTrans LLC: operační systém Windows XP Servise Pack 2/3, MS Office 2007, antivirový software - Panda Antivirus Platinum, daňový poplatník, 1C: Účetnictví, 1C: Mzdy a lidské zdroje, PP "Adresář certifikátů", CIPF Crypto Pro CSP, PP " STEK-Trust"". Pracovní stanice "TRUST-Client", Systém "STEK-Trust". Pojištěná pracovní stanice, FSS Utility, Documents 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 obchodního centra LLC "EcoTrans" podle metodiky IDEF0. Nejprve sestavíme kontextový diagram obchodního procesu „Přeprava nákladu“ (obrázek 4.1). Podle notace IDEF0 říkejme tomuto funkčnímu bloku „Transport cargo“.

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

Poté rozdělíme obchodní proces „Nákladní přeprava“ na komponenty: „Zpracování žádosti“, „Uzavření smlouvy“, „Příprava na přepravu nákladu“, „Platba dokladů nezbytných pro přepravu nákladu“, „Přeprava nákladu“. A podle toho rozložíme funkční blok „Přeprava nákladu“ (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 zboží" (obrázek 4.4); „Vyřizování dokumentů požadovaných pro přepravu zboží“ (obrázek 4.5); "Realizace nákladní dopravy" (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 zboží"

Obrázek 4.5 - Dekompoziční schéma procesu "Vyřizování dokumentů potřebných pro přepravu zboží"

Obrázek 4.6 - Schéma rozkladu procesu "Realizace nákladní dopravy"

4.2 Sestavení modelu v notaci IDEF3

Nyní sestavme model společnosti 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 "Přeprava nákladu".

Symbol "", znamená "Exkluzivní OR", je to také "XOR" (Exkluzivní OR).

Závěr

V rámci studia 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é způsoby: textové, tabulkové, grafické. 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 pro 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 a pro IDEF3 jsem si musel 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 je učinilo přehlednějšími. A ve výsledku poskytl více příležitostí pro systémovou analýzu a optimalizaci činností společnosti.

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

Literatura

1 Golichev V.D., Golicheva N.D., Gusarova O.M. Aktuální otázky ekonomiky a managementu v podmínkách modernizace. Kolektivní monografie. - Smolensk: Smolgortipografiya, 2014. - 212s.

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

Hostováno na Allbest.ru

...

Podobné dokumenty

Podíl předprojektový průzkum podniky. 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é má 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 podniku. Metodologie SADT (strukturální analýza a návrh), rodina standardů IDEF a algoritmické jazyky v srdci 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í. Volba podnikového procesu pro modelování a jeho smysluplný popis, tabulkový formát pro jeho popis.

semestrální práce, 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 pracovní metody Microsoft Visio. Interakce designéra s aplikacemi.

kontrolní práce, přidáno 19.12.2010


Podstata, význam a metodologie 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ím účelem popisu UML. Popis hlavních komponent souvisejících s Microsoft Visio. Vytváření diagramů tříd v aplikaci Microsoft Visio 2010 Struktura systému, її třída, їх atributy a operátory.

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


Návrh lokální sítě. Volba 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 rozvoj 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. Softwarová analýza k němu. Testování přijatého balíčku msi.

semestrální práce, přidáno 14.03.2013


Srovnávací analýza hotelové informační systémy. Analýza a výběr CASE nástrojů pro modelování podnikových procesů. vizuální a matematický model obor, 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 AutoConnect v aplikaci Office Visio 2007. Funkce pravděpodobnosti protokolování. Graf pravděpodobnosti selhání verze softwaru. Vizuální modelování v UML. Obecná forma diagramy tříd.

V této lekci se naučíte vytvářet jednoduché (diagram shora dolů, diagram sledování dat, diagram plánování procesů atd.) a funkční blokové diagramy (zobrazující vztah 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, konektory a odkazy.

Cvičení 1

Rýže. 3.3.Jednoduché blokové schéma (krok 3)

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

9. Tab Domov ve skupině Servis vybrat nástroj Ukazatel.

• Klikněte na tvar, do kterého chcete zadat text.
• Zadejte požadovaný text.

Poznámka:

1. 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.
2. Chcete-li obrázek oddálit, stiskněte kombinaci kláves na klávesnici + a klepněte pravým tlačítkem na tvar, dokud nedosáhnete požadovaného měřítka.

Rýže. 3.4. Jednoduché blokové schéma (krok 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 příkaz Číslování obrázků. V otevřeném okně Číslování obrázků zadejte požadované možnosti číslování a klepněte na tlačítko OK.

Úkol 2

1. Do vývojového diagramu připraveného během úlohy 1 přidejte automatické číslování všech obrázků (viz obr. 3.6).

   Pro tohle:

   • Na kartě Pohled ve skupině Makra klikněte na kombinované tlačítko doplňky, vyberte skupinu Další řešení Visio a v něm příkaz Číslování obrázků.
   • V otevřeném okně Číslování obrázků specifikovat parametry
     • tab Všeobecné:
       • Provoz - Automatické číslování;
       • Použít na - všechny tvary;
       • Začátek v - 1;
       • Interval - 1;
       • Zaškrtněte políčko Pokračovat v číslování obrazců při 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.
2. Uložte blokové schéma.

Rýže. 3.6. Jednoduché blokové schéma (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é je nový tvar vložen. Visio vloží nový tvar mezi stávající a automaticky rozšíří vývojový diagram.

Odstraně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 tvary vývojového diagramu, postupujte takto:

1. Na kartě Pohled ve skupině Makra klikněte na tlačítko doplňky a vyberte ve skupině Další řešení Visio příkaz Číslování obrázků.
2. V otevřeném okně Číslování obrázků tab Všeobecné vyberte přepínač Přečíslujte ve stejném pořadí, označte startovní číslo pro číslování a klikněte OK.

Úkol 3

1. Upravte vývojový diagram připravený v úloze 2:
   • Smazat obrázek Dokument(Odeslat přihlášku).
   • Mezi figurami Ř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řidat tvar Proces(Zavolejte vystavovateli ohledně platby) níže Dokument(zaslat fakturu).
   • Přečíslujte tvary vývojového diagramu ve stejném pořadí, počínaje počátečním číslem - 1.
2. Uložte blokové schéma.

Rýže. 3.7. Jednoduché blokové schéma (krok 7)

Přemístění spojených tvarů

Jakmile je vytvořeno spojení tvarů vývojového diagramu, můžete je zcela přemístit a znovu vytvořit spojení. Chcete-li to provést, na kartě Konstruktér ve skupině Rozložení klikněte na kombinované tlačítko 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, rozbalovací seznam Velikost) nebo jeho orientaci ( Konstruktér, Skupina Nastavení stránky, kombinované tlačítko Orientace).

Úkol 4

Funkční blokové schéma

Účel funkčního blokového diagramu rozložení

Rozložení Funkční blokové schéma je navržen tak, aby zobrazoval vztah mezi obchodním procesem a organizačními nebo funkčními jednotkami, jako jsou oddělení odpovědná za provádění kroků tohoto 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 v 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 existující stopu na diagramu a vyberte položku z kontextové nabídky. 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 zmáčknout tlačítko Dráha. Skladba bude přidána za vybranou skladbu nebo na konec pruhu, pokud není vybrána žádná skladba.
• Ze sady prvků Tvary funkčních blokových diagramů přetáhněte trať na požadované místo na hranici jízdního pruhu.

Pro přemístění stopy:

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

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

Pro odstranění stopy:

1. Klikněte na štítek stopy, kterou chcete odstranit.
2. Stiskněte klávesu na klávesnici.

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

Často dostávám otázku – co číst o obchodních procesech?
Jedna z nejlepších stránek na Runetu 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 u něj.

Ale pokud mluvíme o knihách, mohu s jistotou říci nejlepší kniha o podnikových procesech je kniha napsaná Repinem a Yeliferovem: "Obchodní procesy společnosti. Konstrukce, analýza, regulace".

Popis obchodních procesů: snaha o jednoduchost.

Článek se zabývá problematikou výběru notace pro popis procesů za účelem následné regulace. Jsou vzájemně porovnávány často používané zápisy Work Flow, např.: "Jednoduchý vývojový diagram" v MS Visio, "Procedura" Business Studia, zápis ARIS eEPC a další.

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

Pro obchodní analytiky firem jsou teze diskutované v článku vážným důvodem k zamyšlení nad tím, jak efektivní jsou jejich rozvojové přístupy. grafická schémata organizační procesy.

Úvod

Jedním z nejdůležitějších cílů pro tvorbu 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. Pro ně je velmi důležitá jednoduchost a přehlednost schémat. Složitá, matoucí schémata obsahující mnoho různých symbolů jsou lidmi špatně vnímána, což ztěžuje jejich praktické použití. Pro praktické účely je proto důležitá správná volba a použití zápisu (metody) pro popis procesů. Podle jakých kritérií by měl být takový zápis vybrán? Jak porovnat různé zápisy mezi sebou? Podívejme se na některé populární zápisy a pokusme se na tyto otázky odpovědět.

Porovnání notace

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

1. "Jednoduchý vývojový diagram" (se zobrazením pohybu dokumentů pomocí bloku "Rozhodnutí");
2. "Jednoduché blokové schéma" (bez zobrazení pohybu dokumentů, bez použití bloků "Solution");
3. "Postup" systému Business Studio (jeden z možnosti zastoupení);
4. 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 notaci "Jednoduchý vývojový diagram" v MS Visio (s pohybem dokumentů, pomocí bloku "Řešení").

Na schématu Obr. 1. Posloupnost operací procesu v čase je znázorněna tlustými šipkami a pohyb dokumentů je znázorněn tenkými tečkovanými šipkami. Bloky "Solution" 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žití „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é. Jsou to spíše výroky pro rozhodování za nějaké podmínky. Ale koneckonců vyvíjíme procesní diagram pro lidi, a ne píšeme počítačový program ve speciálním jazyce. V počítačový program"diamant" by byla plnohodnotná operace pro porovnávání podmínek atp. Ale na procesním diagramu musíte zobrazit 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) popište logiku ve formě diagramu kroků odpovídajícího dílčího procesu s přechodem na úroveň níže;
c) popsat logiku v textu (v textových atributech operace) a následně ji uvést do plánu provádění procesu.

Formulujme „plusy“ a „mínusy“ výše uvedeného (obr. 1.) způsobu použití „diamantů“.

"Jednoduchý vývojový diagram" v MS Visio (s pohybem dokumentů, pomocí bloku "Řešení")
"Profesionálové"	"mínusy"
Vizuální zobrazení "logiky" volby určitých výstupů procesu. Zaměření pozornosti interpreta na rozhodovací bod / větvení procesu v závislosti na podmínkách.	Odstranění rozhodovací logiky „mimo“ procesní provoz (nesprávné z hlediska formálního rozkladu procesů). Dokumentovat proces je nepohodlné (při vytváření textového popisu operace musíte duplikovat „kosočtverce“ textem). Procesní diagram je přetížen informacemi. „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 v tomto schématu je o 24 grafických prvků méně než na schématu na Obr. 1. Schéma Obr. 2. vypadá mnohem jednodušeji. Z grafických prvků neoslní, ale z hlediska informativnosti je toto schéma celkem srozumitelné a dostupné koncovému uživateli. Pokud jsou pro každou operaci procesu požadavky na její implementaci popsány v textu, pak kombinací tabulkového a grafickou podobu zastupování, je možné adekvátně popsat postup provedení procesu pro zaměstnance společnosti.

Rýže. 2. Diagram procesu v notaci "Jednoduchý vývojový diagram" v MS Visio (bez pohybu dokumentů, bez použití bloku "Rozhodnutí").

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

Obecně platí, že použití schémat ve formátu podobném tomu, který je znázorněn na Obr. 2 je vhodný jak pro vývojáře, tak pro zaměstnance pracující podle těchto schémat.

Na Obr. 3. je prezentován procesní diagram vytvořený v zápisu "Procedura" modelovacího prostředí Business Studio. Schéma má několik funkcí. Jednak bloky „Rozhodnutí“ se nepoužívají standardním způsobem – nikoli jako grafický prvek pro zobrazení otázky a větvení, ale jako plnohodnotná operace rozhodovacího procesu. V Business Studiu má „kosočtverec“ 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ím "kosočtverce" (místo čtyřúhelníku) je diagram přehlednější. Přitom jakékoliv textové informace: popis, začátek, konec, požadavek na termín atd.

Druhý rys procesního diagramu znázorněného na Obr. 3., je použití šipek. Chcete-li zobrazit sled operací, můžete použít šipku s jediným hrotem - šipku "přednost". Pro zobrazení pohybu dokumentů můžete použít šipku se dvěma hroty. Ale právě v Business Studiu můžete použít pouze jeden typ šipky – šipky „nadřazenosti“. Zároveň se můžete vázat na pojmenované šipky požadované množství dokumenty, které jsou definovány v adresáři objektů činnosti. Tento přístup umožňuje:

• výrazně snížit počet grafických prvků na 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 nahrát do předpisů všechny potřebné informace.

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

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

V případě použití Business Studia lze zápis "Procedura" použít 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é operace procesu se nevešly do diagramu. Tento neúplný diagram nejjednoduššího procesu vytvořený 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 zobrazené na Obr. 1-3. Složitost tvorby takového schématu je také výrazně vyšší.

Procesní diagram v notaci ARIS eEPC (vestavěný v Business Studiu)
"Profesionálové"	"mínusy"
Při vytváření schématu 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. Zaměstnanci by měli mít zvláštní dovednosti a zkušenosti s interpretací takových schémat. 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 volba a použití notace ARIS eEPC není z pohledu autora článku optimálním řešením. Za pozornost stojí vizuálnější a intuitivně srozumitelnější zápis popisů procesů. Někomu se však může zdát zápis ARIS eEPC přehledně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 „spustitelných“ procesů, tzn. procesy podporované systémem BPM.

Váš názor na používání BPMN 2.0. akcie A.A. Belaichuk - výkonný ředitel Společnost "Business Console":

Na Obr. 5 ukazuje stejný proces v notaci BPMN. Jak vidíme, tento obrázek je podobný obrázku 1: v zápisu BPMN jsou úkoly reprezentovány obdélníky, vidličkami - kosočtverci, daty - ikonou podobnou dokumentu. Kontrolní toky jsou plné čáry, datové toky jsou přerušované. Je třeba poznamenat, že v tomto diagramu je zahrnuta pouze malá část zápisu BPMN: pouze jeden typ vidlice z 5 dostupných v paletě, jeden typ úloh z 8. Kromě širší palety je tato notace Vyznačuje se schopností modelovat nejen izolovaný pracovní tok, ale také několik procesů vzájemně interagujících 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 to, že ji lidé budou číst, ale také na přímé provedení speciálním software- "motor" BPM-systém. Zároveň, jak ukazuje tento příklad, při použití omezené podmnožiny palety není BPMN o nic složitější než známý 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. Schéma je postaveno na principech "Jednoduchého blokového diagramu" - 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í schématu na Obr. 6, obchodní analytici evidentně „bojovali“ o viditelnost a maximální přehlednost pro běžného uživatele. Snažili se minimalizovat, nebo dokonce eliminovat textové komentáře k procesním diagramům. Účinkující si jednoduše vytiskli schéma formátu A3, při čtení kterého 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 za účelem předat maximum užitečných informací realizátorům procesu.

závěry

Je tedy zřejmé, že při popisu procesů je třeba usilovat o jednoduchost a srozumitelnost 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í (výkladu) schémat běžnými zaměstnanci;
• nemožnost (obtížnost) organizace práce na popisu procesů zaměstnanci útvarů, 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.);

Nezahlcujte proto procesní diagram různými grafickými prvky. Ale pokud je používáte, je lepší, když je nosíte 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ů NOU HPE "IEF "Synergie", zakladatel portálu www.FineXpert.ru

Právě tyto jednoduché principy se snažím předat vedoucím podniků, které fascinují krásné prezentace. softwarových produktůčasto zapomínají, že jednoduchý kontrolní seznam je často lepší než 10 stran předpisů.

Laboratorní práce №1

organizační design

Teoretické zdůvodnění

Podnikatelský proces je stabilní, účelný soubor vzájemně souvisejících činností (jinými slovy sled prací), který pomocí určité technologie přeměňuje vstupy na výstupy, které mají pro spotřebitele hodnotu.

Pro řešení různých obchodních problémů je nutné procesy detailně a vizuálně popsat. Tedy stavět jejich modely. Modely jsou určeny pro Detailní popis operace prováděné postupně v čase pomocí určité technologie.

Obrázek 1.1 - Model "proces"

Existují různé možnosti grafického, tabulkového, textového popisu procesů. Podívejme se, jak vytvořit grafický diagram obchodního procesu pomocí softwarového nástroje Microsoft Visio. V první řadě se sluší říci, že produkt Visio není součástí standardního balíku Microsoft Office.

Metodické pokyny pro výkon práce:

Program spustíme pomocí tlačítka "Start" nebo pomocí zástupce na ploše.

Obrázek 1.2 - Hlavní okno programu MS Visio 2010

Obrázek 1.3 - Hlavní okno programu MS Visio 2003

První věc, kterou po spuštění programu uvidíme, je okno s výzvou k výběru typu grafické konstrukce, kterou potřebujeme z navržených kategorií. Pro naše účely vybíráme kategorii „Obchodní procesy“. Zde uvidíme různé varianty diagramů používaných k popisu procesů i vývojových diagramů. Například tok dat nebo práce; interfunkční diagramy.

Z navrhovaných možností pro popis procesů v nabídce vyberte možnost EPC Diagram.

Nový soubor lze vytvořit také v provozním režimu s jinými otevřenými soubory prostřednictvím hlavního menu. Vyberte Soubor – Nový (Nový) – Obchodní proces (Obchodní proces) – a typ, který potřebujeme – Diagram ePC.
Nabídka vlevo obsahuje objekty, které použijeme při sestavování procesního diagramu.

- Událost

‒ Funkce

‒ Účinkující

A logické operátory: a, výhradní nebo, nevýhradní nebo.

Obrázek 1.4 - Objekty pro sestavení procesního diagramu

Použití softwarového nástroje Microsoft Visio je pohodlné, jednoduché a cenově dostupné pro vytváření grafických diagramů obchodních procesů.

V dalším cvičení si podrobně rozebereme pravidla pro konstrukci obvodů v tzv. epC notaci - tedy grafickém modelovacím jazyku.

Cvičení 1. Pravidla pro konstrukci procesních diagramů v notaci epC

Nacházíme se v softwarové sadě Visio a díváme se na reprezentaci obchodních procesů nazvanou Event-driven Process Chain – neboli EPC. Systém tohoto typu pohodlné, snadno čitelné a aktivně používané v praxi. Pojďme podrobně analyzovat, jak správně sestavit procesní diagram. Využijeme k tomu objekty, které se nacházejí v menu vlevo.

Chcete-li to provést, kliknutím pravým tlačítkem myši se dostaneme do nabídky, vybereme "formát", "Vyplnit" - a změníme barvu na světlejší. Také ve vlastnostech objektu lze změnit šrafování, typ a tloušťku vrstevnice, stín.

Lze je převzít z panelu nástrojů vlevo nebo z ovládacího panelu. V případě potřeby můžete také upravit jejich vlastnosti. Nejčastěji je spojnice mezi objekty vyznačena černě a tečkovaně. Pro lepší viditelnost můžete šipku zvětšit.

Pokusme se vybudovat určitý řetězec akcí. Abychom nenastavovali vlastnosti objektu pokaždé, použijeme funkci kopírování. Chcete-li to provést, vyberte objekt pravým tlačítkem myši, klikněte na „kopírovat“ a poté na „vložit“. Další objekty lze odstranit pomocí tlačítka na panelu nástrojů nebo klávesy Delete na klávesnici.

V praxi každé dílo vykonává nějaká osoba, performer. Chcete-li určit účinkujícího, vyberte objekt. Například žlutý ovál. A umístíme jej nutně vpravo od Funkce, nezapomeneme uvést organizační jednotku. Může to být oddělení, skupina, oddělení, nebo jen pozice vystupujícího. Náš objekt spojujeme s ostatními pomocí komunikační linky. V tomto případě by měla být čára rovná - bez šipek začátku a konce.

Možnosti

1. Rezervace vstupenek.

2. Nákup prostřednictvím internetového obchodu.

3. Koupě bytu.

4. Bankovní úvěry.

5. Připojení kabelové televize.

6. Pronájem obchodních prostor.

7. Jmenování k lékaři.

8. Údržba.

9. Hotel.

10. Pojišťovna.

11. Knihovna.

12. Kurzy pro pokročilé.

13. Nákladní doprava.

14. Půjčovna aut.

15. Investování volných finančních prostředků.

2. Pomocí varianty podniku uvedené v prvním úkolu vytvořte organizační schéma na nové stránce:

- ukládat a zobrazovat informace o zaměstnancích, odděleních, divizích v organizačních schématech;

- založit vzhled organizační schéma.

Příloha 1

Kontrola správnosti schématu

TP1 Právní plnění smlouvy

Pravidlo 1: Funkční diagram EPC musí začínat alespoň jednou počáteční událostí (událost spuštění může následovat rozhraní procesu) a končit alespoň jednou událostí ukončení (událost end může předcházet rozhraní procesu).

Nebyly nalezeny žádné chyby.

Pravidlo 2: Jak proces postupuje, události a funkce se musí střídat (událost a funkci lze propojit pomocí operátorů).

Nebyly nalezeny žádné chyby.

Pravidlo 3: Události a funkce musí obsahovat právě jedno příchozí a jedno odchozí spojení, které odrážejí průběh procesu.

Nebyly nalezeny žádné chyby.

Pravidlo 4: Diagram by neměl obsahovat nepojmenované odkazy.

Nebyly nalezeny žádné chyby.

Pravidlo 5: Po jedné události nesmí následovat operátor „OR“ nebo „XOR“.

Nebyly nalezeny žádné chyby.

Pravidlo 6: Každý operátor sloučení musí mít alespoň dva příchozí spojení a pouze jeden odchozí, operátor větvení musí mít pouze jeden příchozí odkaz a alespoň dva odchozí. Operátoři nemohou mít více příchozích a více odchozích připojení současně.

Nebyly nalezeny žádné chyby.

Pravidlo 7: Operátoři mohou kombinovat nebo větvit pouze prvky stejného typu. Slučování nebo větvení funkcí a událostí současně není možné.

Nebyly nalezeny žádné chyby.

Pravidlo 8: Každá funkce musí mít vztah „výkon“ s alespoň jedním a až třemi subjekty.

Nebyly nalezeny žádné chyby.

Pravidlo 9: Na diagramu by stejná událost měla být přítomna pouze jednou.

Nebyly nalezeny žádné chyby.

Laboratoř #1

Úkol popsat obchodní procesy pomocí MS Visio.

Při modelování procesu ve Visiu na to pamatujte hlavním účelem je zobrazit logiku procesu, jeho účastníky a akce, které provádějí. V souladu s tím, abychom zobrazili logiku procesu, používáme události a logické vazby mezi nimi, ukazujeme účastníkům pomocí stop rolí, jejich akce - pomocí prvků typu „proces“. Všechny ostatní aspekty (dokumenty, zdroje) by měly být zobrazeny tak, aby nebránily pochopení logiky, pro úplné odhalení těchto aspektů procesu je lepší použít textový nebo tabulkový popis.

Pro účely modelování budeme v tomto příkladu uvažovat o zjednodušeném procesu prodeje produktu vlastní výroby.

Přímé modelování je nejlepší začít upřesněním názvu a vyjasněním hranic procesu. Hranice mohou být okamžitě fixovány formou událostí na diagramu. V našem příkladu by hraniční události byly „Identifikována potřeba zákazníka“ a „Potřeba podpořena vzájemným závazkem“ (viz obrázek 3).

Rýže. 3. Název a hranice procesu

Pro snadnější čtení diagramů by měl popis procesu začínat v levém horním rohu (viz obr. 4). Porušení tohoto pravidla je nežádoucí, ale možné, pokud je z nějakého důvodu původně nastaveno pořadí umělců / skladeb a první zakázky v rámci procesu patří ke skladbě umístěné uprostřed nebo dole.

Každá práce/postup v procesním diagramu by měl být zarámován jako integrální blok s logickými hranicemi ve formě událostí a dokumentů. Tyto logické hranice vám umožní lépe pochopit a lépe strukturovat proces.

Strukturování popsaného procesu, pokud nebylo provedeno předem, je vhodné provést na základě pochopení toho řetězce mezivýsledků (událostí) které je nutné dosáhnout procesní cíle. Tento řetězec je implementován krok za krokem přechodem od počáteční k závěrečné události procesu. Při formulaci událostí je žádoucí operovat objekty a jejich stavy(„identifikována potřeba“, „objednávka zpracována“ atd.).

Zjednodušený příklad popisu procesu je uveden na Obr. 5.

Rýže. 5. Zjednodušený příklad popisu procesu

Ve schématu jsou dva bloky („Příprava návrhu smlouvy“ a „Zařazení zakázky do plánu výroby“) označeny jako „podprocesy“. To znamená, že pro ně existují odpovídající schémata rozkladu - podrobné popisy těchto dílčích procesů na samostatných stránkách stejného souboru Visio nebo v jiných souborech.