Odoslanie dobrej práce do databázy znalostí je jednoduché. Použite nižšie uvedený formulár

Študenti, postgraduálni študenti, mladí vedci, ktorí pri štúdiu a práci využívajú vedomostnú základňu, vám budú veľmi vďační.

Uverejnené dňa http://www.allbest.ru

Úvod

Modelovanie podnikových procesov v kontexte modernizácie ekonomiky a manažmentu je relevantnou oblasťou, ktorá pomáha optimalizovať procesy činností organizácie a zlepšovať výkonnosť podniku. Keď hovoríme o modelovaní podnikových procesov, budeme používať terminológiu niekoľkých oblastí vedomostí súvisiacich s ekonómiou, informatikou a modelovaním zložitých systémov. Poďme si preto definovať základné definície a pojmy.

Podnikový proces je definovaný ako logicky ukončený reťazec vzájomne prepojených a opakujúcich sa činností, v dôsledku ktorých sa zdroje podniku využívajú na spracovanie objektu (fyzicky alebo virtuálne) s cieľom dosiahnuť určité merateľné výsledky alebo vytvoriť produkty na uspokojenie interných alebo externých zákazníkov. .

Pojem „modelovanie“ má dva hlavné významy. Po prvé, modelovanie sa chápe ako proces konštrukcie modelu ako akejsi reprezentácie (obrazu) originálu, odrážajúceho jeho najdôležitejšie vlastnosti a vlastnosti. Ak je model už vytvorený, potom je modelovanie procesom výskumu (analýzy) fungovania systému, alebo skôr jeho modelu. Základným účelom modelovania podnikových procesov je popísať skutočný priebeh podnikových procesov podniku. V tomto prípade je potrebné určiť, čo je výsledkom procesu, kto a aké úkony vykonáva, aké je ich poradie, aký je pohyb dokumentov počas procesu, ako aj nakoľko je proces spoľahlivý (pravdepodobnosť neúspešného vykonania) a ako ho možno v budúcnosti rozšíriť/upraviť.

Zabezpečenie transparentnosti priebehu obchodných procesov je dôležité, pretože len v tomto prípade vlastník obchodného procesu (zamestnanec spoločnosti, ktorý riadi priebeh obchodného procesu a je zodpovedný za jeho výsledky a efektívnosť), obchodný analytik, manažment a ďalší zainteresovaní strany budú mať jasnú predstavu o tom, ako je práca organizovaná. Pochopenie toku existujúcich podnikových procesov umožňuje posúdiť ich efektívnosť a kvalitu a je nevyhnutné pre rozvoj podnikovej IT infraštruktúry. Úspešný vývoj aplikačných systémov, ktoré podporujú vykonávanie obchodných procesov od začiatku do konca, je možný len vtedy, keď sú samotné procesy jasne a do detailov pochopené.

Model podnikových procesov je jeho formalizovaný (grafický, tabuľkový, textový, symbolický) popis, ktorý odráža skutočnú alebo navrhovanú činnosť podniku.

Problém tejto práce na kurze znie takto: aké praktické sú diagramy navrhnuté v MS Visio na použitie (jednoduchosť, vizuálne a informatívne).

Predmetom je obchodné modelovanie.

Predmetom bude: modelovanie podnikových procesov podniku poskytujúceho služby cestnej dopravy v MS Visio.

Na základe problému si definujme cieľ: určiť, ako praktické je použitie diagramov navrhnutých v MS Visio na príklade dopravnej spoločnosti (TC) EcoTrans LLC.

Na dosiahnutie tohto cieľa je potrebné vyriešiť nasledujúce úlohy:

Nájdite a študujte metodiky modelovania obchodných procesov;

Oboznámte sa s obchodnou grafikou v MS Visio;

Analyzujte obchodné procesy spoločnosti TC LLC "EcoTrans"

Opíšte obchodné procesy spoločnosti TC LLC „EcoTrans“ pomocou obchodného modelovania v aplikácii Microsoft Visio

Na modelovanie obchodných procesov je možné použiť rôzne metódy. Metóda alebo metodológia modelovania zahŕňa postupnosť akcií, ktoré sa musia vykonať na vytvorenie modelu, t. j. postup modelovania a použitý zápis (jazyk). V tejto práci na kurze budú použité metodiky IDEF0, IDEF3 na modelovanie obchodných procesov.

1. Metodiky opisu predmetnej oblasti

Proces obchodného modelovania je možné implementovať v rámci rôznych techník, ktoré sa líšia predovšetkým svojim prístupom k tomu, čo je modelovaná organizácia. V súlade s rôznymi predstavami o organizácii sa metódy zvyčajne delia na objektové a funkčné (štrukturálne).

Objektové metódy považujú modelovanú organizáciu za množinu interagujúcich objektov – výrobných jednotiek. Objekt je definovaný ako hmatateľná realita – objekt alebo jav, ktorý má jasne definované správanie. Účelom použitia tejto techniky je identifikovať objekty, ktoré tvoria organizáciu, a rozdeliť medzi ne zodpovednosti za vykonané akcie.

Funkčné techniky, z ktorých najznámejšia je technika IDEF0, považujú organizáciu za súbor funkcií, ktoré transformujú prichádzajúci tok informácií na výstupný tok. Proces konverzie informácií spotrebúva určité zdroje. Hlavným rozdielom od objektovej metódy je jasné oddelenie funkcií (metód spracovania údajov) od samotných údajov.

Z hľadiska obchodného modelovania má každý z prezentovaných prístupov svoje výhody. Objektový prístup umožňuje vybudovať systém, ktorý je odolnejší voči zmenám a lepšie zodpovedá existujúcim štruktúram organizácie. Funkčné modelovanie funguje dobre v prípadoch, keď je organizačná štruktúra v procese zmien alebo je vo všeobecnosti zle formovaná. Prístup z vykonávaných funkcií interpreti intuitívne lepšie chápu, keď od nich dostávajú informácie o svojej aktuálnej práci.

1.1 Pochopenie rodiny štandardov IDEF

Jedným z najdôležitejších cieľov pri príprave projektu budovania informačného systému je jasné a správne pochopené vyjadrenie problému. Na dosiahnutie tohto cieľa je potrebné preskúmať všetky prebiehajúce finančné a ekonomické procesy a im zodpovedajúce toky informácií v podniku, identifikovať tie, ktoré by mali byť najskôr reorganizované, t.j. vybudovať takzvaný biznis model. Takéto komplexné prieskumy podnikov sú vždy zložité a výrazne sa líšia od prípadu k prípadu. Na riešenie takýchto problémov modelovania zložitých systémov existujú osvedčené metodiky a štandardy. Tieto štandardy zahŕňajú rodinu metodík IDEF. S ich pomocou môžete efektívne zobrazovať a analyzovať vzorce aktivity širokej škály komplexných systémov v rôznych kontextoch. Zároveň si šírku a hĺbku skúmania procesov v systéme určuje samotný vývojár, čo umožňuje nepreťažovať vytvorený model zbytočnými dátami.

Metodika IDEF bola vytvorená v rámci programu priemyselnej informatizácie ICAM (Integrated Computer Aided Manufacturing) realizovaného v USA, pri implementácii ktorého bola identifikovaná potreba vývoja metód na analýzu interakčných procesov vo výrobných systémoch. Odtiaľ pochádza názov tejto rodiny štandardov – Icam DEFINition – IDEF.

V súčasnosti rodina IDEF zahŕňa nasledujúce štandardy:

IDEF0 - metodológia funkčného modelovania. Pomocou vizuálneho grafického jazyka IDEF0 sa skúmaný systém javí vývojárom a analytikom vo forme súboru vzájomne súvisiacich funkcií (funkčných blokov – v zmysle IDEF0). Modelovanie IDEF0 je spravidla prvým krokom pri štúdiu akéhokoľvek systému;

IDEF1 je metodológia modelovania informačných tokov v rámci systému, ktorá vám umožňuje zobraziť a analyzovať ich štruktúru a vzťahy;

IDEF1X (IDEF1 Extended) - metodika budovania relačných štruktúr. IDEF1X patrí k typu metodológií „entity-relationship“ (ER - Entity-Relationship) a spravidla sa používa na modelovanie relačných databáz relevantných pre daný systém;

IDEF2 je metodika pre dynamické modelovanie vývoja systémov. Kvôli veľmi vážnym ťažkostiam pri analýze dynamických systémov sa od tohto štandardu prakticky upustilo a jeho vývoj sa zastavil v počiatočnom štádiu.

IDEF3 je metodika dokumentovania procesov prebiehajúcich v systéme, ktorá sa využíva napríklad pri štúdiu technologických procesov v podnikoch. IDEF3 popisuje scenár a postupnosť operácií pre každý proces. IDEF3 má priamy vzťah s metodikou IDEF0 - každá funkcia (funkčný blok) môže byť reprezentovaná ako samostatný proces pomocou IDEF3;

IDEF4 je metodika pre budovanie objektovo orientovaných systémov. Nástroje IDEF4 vám umožňujú vizuálne zobraziť štruktúru objektov a základné princípy ich interakcie, čím vám umožňujú analyzovať a optimalizovať komplexné objektovo orientované systémy;

IDEF5 je metodológia pre ontologický výskum komplexných systémov. Pomocou metodiky IDEF5 možno ontológiu systému popísať pomocou špecifického slovníka pojmov a pravidiel, na základe ktorého možno vytvoriť spoľahlivé výpovede o stave posudzovaného systému v určitom časovom bode. Na základe týchto tvrdení sa vyvodzujú závery o ďalšom vývoji systému a vykonáva sa jeho optimalizácia.

Podrobnejšie zvážime štandardy, ktoré sa budú vyžadovať pri popise obchodných procesov v tejto práci: IDEF0, IDEF3.

Funkčná metóda IDEF0.

Účelom techniky je zostaviť funkčný diagram skúmaného systému, popisujúci všetky potrebné procesy s presnosťou dostatočnou na jednoznačné modelovanie činnosti systému.

Metodika je založená na štyroch hlavných pojmoch: funkčný blok, oblúk rozhrania, dekompozícia, slovník.

a) Activity Box predstavuje určitú špecifickú funkciu v rámci posudzovaného systému. Podľa požiadaviek normy musí byť názov každého funkčného bloku formulovaný vo verbálnej nálade (napríklad „produkovať služby“). Na diagrame je funkčný blok znázornený ako obdĺžnik (obrázok 1.1). Každá zo štyroch strán funkčného bloku má svoj špecifický význam (úlohu) a:

Horná strana je nastavená na "Ovládanie";

Ľavá strana je nastavená na "Vstup";

Pravá strana je nastavená na Výstup;

Spodná strana má význam „Mechanizmus“.

Toto označenie odráža určité systémové princípy: vstupy sa premieňajú na výstupy, kontrolujú limity alebo predpisujú podmienky na vykonávanie transformácií, mechanizmy ukazujú, čo a ako funkcia vykonáva.

Každý funkčný blok v rámci jedného posudzovaného systému musí mať svoje jedinečné identifikačné číslo.

Obrázok 1.1 - Funkčný blok

b) Šípka rozhrania predstavuje prvok systému, ktorý je spracovaný funkčným blokom alebo inak ovplyvňuje funkciu reprezentovanú týmto funkčným blokom. Oblúky rozhrania sa často nazývajú toky alebo šípky.

Pomocou oblúkov rozhrania sa zobrazujú rôzne objekty, ktoré do tej či onej miery určujú procesy prebiehajúce v systéme. Takýmito objektmi môžu byť prvky reálneho sveta (súčiastky, autá, zamestnanci atď.) alebo toky údajov a informácií (dokumenty, údaje, inštrukcie atď.).

V závislosti od toho, na ktorú stranu funkčného bloku sa tento oblúk rozhrania hodí, sa nazýva „prichádzajúci“, „odchádzajúce“ alebo „riadiaci“.

Treba poznamenať, že každý funkčný blok musí mať podľa požiadaviek normy aspoň jeden oblúk ovládacieho rozhrania a jeden výstupný. Je to pochopiteľné – každý proces musí prebiehať podľa nejakých pravidiel (zobrazených riadiacim oblúkom) a musí priniesť nejaký výsledok (odchádzajúci oblúk), inak jeho uvažovanie nemá zmysel.

Povinná prítomnosť oblúkov ovládacieho rozhrania je jedným z hlavných rozdielov medzi štandardom IDEF0 a ostatnými metodikami tried DFD (Data Flow Diagram) a WFD (Work Flow Diagram).

c) Rozklad je základnou koncepciou štandardu IDEF0. Princíp rozkladu sa používa pri rozdeľovaní komplexného procesu na jeho jednotlivé funkcie. V tomto prípade úroveň podrobnosti procesu určuje priamo vývojár modelu.

Dekompozícia umožňuje postupne a štruktúrovane prezentovať model systému vo forme hierarchickej štruktúry jednotlivých diagramov, čím je menej preťažený a ľahšie stráviteľný.

Model IDEF0 vždy začína pohľadom na systém ako jeden celok – jeden funkčný blok s oblúkmi rozhrania presahujúcimi zvažovanú doménu. Takýto diagram s jedným funkčným blokom sa nazýva kontextový diagram a je označený identifikátorom „A-0“ (obrázok 1.2).

Obrázok 1.2 - Príklad kontextového diagramu

Vysvetľujúci text pre kontextový diagram by mal naznačovať účel zostavenia diagramu vo forme stručného popisu a zaznamenať uhol pohľadu.

Definovanie a formalizácia cieľa vývoja modelu IDEF0 je mimoriadne dôležitý bod. V skutočnosti cieľ definuje relevantné oblasti v skúmanom systéme, na ktoré je potrebné sa zamerať ako prvé. Ak napríklad modelujeme činnosť podniku s cieľom vybudovať v budúcnosti informačný systém založený na tomto modeli, potom tento model bude výrazne odlišný od toho, ktorý by sme vyvinuli pre ten istý podnik, ale s cieľom optimalizácie dodávateľských reťazcov.

Hľadisko určuje hlavný smer vývoja modelu a požadovanú úroveň detailov. Jasná fixácia pohľadu umožňuje vyložiť model odmietnutím detailov a študovať jednotlivé prvky, ktoré nie sú potrebné, na základe zvoleného pohľadu na systém. Napríklad funkčné modely toho istého podniku z pohľadu hlavného technológa a finančného riaditeľa sa budú výrazne líšiť v smere ich detailovania. Je to spôsobené tým, že finančného riaditeľa v konečnom dôsledku nezaujímajú aspekty spracovania surovín na výrobných strojoch a hlavný technológ nepotrebuje nakreslené schémy finančných tokov. Správna voľba uhla pohľadu výrazne skracuje čas strávený stavbou finálneho modelu.

Počas procesu rozkladu je funkčný blok, ktorý predstavuje systém ako celok v kontextovom diagrame, podrobne opísaný v inom diagrame. Výsledný diagram druhej úrovne obsahuje funkčné bloky, ktoré zobrazujú hlavné podfunkcie funkčného bloku kontextového diagramu a vo vzťahu k nemu sa nazýva Child diagram (každý z funkčných blokov patriacich do podradeného diagramu sa zodpovedajúcim spôsobom nazýva Child Box). . Funkčný blok predka sa nazýva rodičovský blok vo vzťahu k podradenému diagramu (Parent Box) a diagram, ku ktorému patrí, sa nazýva rodičovský diagram (Parent Diagram). Každá z podfunkcií podriadeného diagramu môže byť ďalej podrobná podobným rozkladom jej zodpovedajúceho funkčného bloku. Je dôležité poznamenať, že v každom prípade rozkladu funkčného bloku sú všetky oblúky rozhrania vstupujúce alebo vychádzajúce z tohto bloku fixované na podradenom diagrame. Tým sa dosiahne štrukturálna integrita modelu IDEF0. Princíp rozkladu je názorne znázornený na obrázku 1.3. Mali by ste venovať pozornosť vzťahu medzi číslovaním funkčných blokov a diagramov - každý blok má na diagrame svoje jedinečné sériové číslo (číslo v pravom dolnom rohu obdĺžnika) a označenie v pravom rohu označuje číslo podriadeného diagramu pre tento blok. Neprítomnosť tohto označenia naznačuje, že pre tento blok nedochádza k rozkladu.

Často sa vyskytujú prípady, keď jednotlivé oblúky rozhrania nemá zmysel ďalej zvažovať v podriadených diagramoch pod určitou úrovňou v hierarchii, alebo naopak - jednotlivé oblúky nemajú praktický zmysel nad určitou úrovňou. Napríklad nemá zmysel zobrazovať oblúk rozhrania znázorňujúci „diel“ na vstupe do funkčného bloku „Proces na sústruhu“ na diagramoch vyšších úrovní – tým sa diagramy len preťažia a sťaží sa ich porozumenie. Na druhej strane môže vzniknúť potreba zbaviť sa jednotlivých „koncepčných“ oblúkov rozhrania a nedetailovať ich nad určitú úroveň. Na vyriešenie takýchto problémov poskytuje štandard IDEF0 koncept tunelovania. Označenie Arrow Tunnel dvoch zátvoriek okolo začiatku oblúka rozhrania znamená, že oblúk nebol zdedený z funkčného nadradeného bloku a objavuje sa (z „tunela“) iba v tomto diagrame. Na druhej strane, rovnaké označenie okolo konca (šípky) oblúka rozhrania v bezprostrednej blízkosti bloku prijímača znamená skutočnosť, že tento oblúk nebude zobrazený a zohľadnený v podradenom diagrame tohto bloku. Najčastejšie sa stáva, že jednotlivé objekty a ich zodpovedajúce oblúky rozhrania sa na niektorých medzistupňoch hierarchie neberú do úvahy - v tomto prípade sú najprv „ponorené do tunela“ a potom, ak je to potrebné, „vrátené z tunela“ .

d) Slovník. Pre každý z prvkov IDEF0 – diagramy, funkčné bloky, oblúky rozhrania – existujúci štandard vyžaduje vytvorenie a udržiavanie súboru vhodných definícií, kľúčových slov, naratívnych vyhlásení atď., ktoré charakterizujú objekt zobrazený prvkom. Tento súbor sa nazýva glosár a je popisom podstaty daného prvku. Slovník pojmov harmonicky dopĺňa vizuálny grafický jazyk a poskytuje diagramom potrebné dodatočné informácie.

Štandard procesnej dokumentácie IDEF3.

IDEF3 je štandard pre dokumentáciu technologických procesov vyskytujúcich sa v podniku a poskytuje nástroje na vizuálne štúdium a modelovanie ich scenárov. Scenár (Scenario) je v tomto prípade popis postupnosti zmien vlastností objektu v rámci posudzovaného procesu (napríklad popis postupnosti etáp spracovania dielu v dielni a zmena jeho vlastností po prechode každým stupňom).

Dokumentačné a modelovacie nástroje IDEF3 vám umožňujú vykonávať nasledujúce úlohy:

Zdokumentujte dostupné údaje o technológii procesu, identifikované povedzme v procese rozhovoru s kompetentnými zamestnancami zodpovednými za organizáciu daného procesu;

Identifikovať a analyzovať body vplyvu súvisiacich tokov dokumentov na scenár technologického procesu;

Identifikovať situácie, v ktorých sa vyžaduje rozhodnutie, ktoré ovplyvňuje životný cyklus procesu, napríklad zmena konštrukčných, technologických alebo prevádzkových vlastností konečného produktu;

Podporovať optimálne rozhodovanie pri reorganizácii technologických procesov.

V štandarde IDEF3 existujú dva typy diagramov, ktoré predstavujú opis toho istého procesného scenára z rôznych perspektív. Diagramy patriace do prvého typu sa nazývajú diagramy opisu toku procesov (PFDD) a druhý typ sa nazývajú diagramy siete prechodu objektov (OSTN).

Predpokladajme, že potrebujete opísať proces lakovania dielu vo výrobnej dielni v podniku. PFDD diagramy dokumentujú postupnosť a popis fáz spracovania dielu v rámci skúmaného technologického procesu. Diagramy OSTN sa používajú na znázornenie transformácií dielov, ktoré sa vyskytujú v každej fáze spracovania.

Na nasledujúcom príklade si popíšeme, ako grafické nástroje IDEF3 umožňujú dokumentovať vyššie uvedený výrobný proces lakovania dielu. Vo všeobecnosti tento proces pozostáva priamo zo samotného lakovania, vykonávaného na špeciálnych zariadeniach, a z etapy kontroly kvality, ktorá určuje, či je potrebné diel prelakovať (v prípade nesúladu s normami a zistiť chyby) alebo poslať na ďalšie spracovanie.

Obrázok 1.4 ukazuje diagram PFDD, ktorý je grafickým znázornením scenára spracovania dielov. Obdĺžniky v diagrame PFDD sa nazývajú jednotky správania (UOB) a predstavujú udalosť, štádium procesu alebo rozhodnutie. Každý UOB má svoje meno, zobrazené v slovesnej nálade a jedinečné číslo. Šípky alebo čiary predstavujú, ako sa súčiastka počas procesu pohybuje medzi blokmi UOB.

Obrázok 1.4 - PFDD diagram scenára spracovania dielov

Objekt označený J1 sa nazýva Junction. Križovatky sa používajú na znázornenie logiky toho, ako šípky (vlákna) interagujú pri zlučovaní a vetvení, alebo na zobrazenie viacerých udalostí, ktoré môžu alebo musia byť dokončené pred začatím ďalšej práce. Sú tu priesečníky pre zlučovanie (Fan-in Junction) a vetvenie (Fan-out Junction) šípok. Priesečník nemožno použiť na zlúčenie aj rozvetvenie. Pri pridávaní križovatky do diagramu musíte určiť typ križovatky. Klasifikácia možných typov križovatiek je uvedená v tabuľke 1.

Tabuľka 1 - Klasifikácia typov križovatiek

názov	Význam v prípade zlučovania šípok (Fan-in Junction)	Význam v prípade rozvetvených šípok (Fan-out Junction)
Asynchrónne AND	Všetky predchádzajúce procesy musia byť dokončené	Všetky nasledujúce procesy musia byť spustené
	Všetky predchádzajúce procesy sú dokončené súčasne	Všetky nasledujúce procesy prebiehajú súčasne
	Jeden alebo viac predchádzajúcich procesov sa musí ukončiť	Musí byť spustený jeden alebo viacero z nasledujúcich procesov
	Jeden alebo viac predchádzajúcich procesov sa ukončí súčasne	Jeden alebo viacero z nasledujúcich procesov beží súčasne
XOR (exkluzívny OR)	Bol dokončený iba jeden predchádzajúci proces	Len jeden ďalší proces začína

Scenár zobrazený v diagrame možno opísať takto:

Diel prichádza do lakovne pripravený na lakovanie. Počas procesu lakovania sa pri vysokej teplote nanáša jedna vrstva emailu. Potom sa diel vysuší, po ktorom začne fáza kontroly kvality nanesenej vrstvy. Ak skúška potvrdí nedostatočnú kvalitu nanesenej vrstvy (nedostatočná hrúbka, heterogenita a pod.), tak dielec opäť prechádza lakovňou. Ak diel úspešne prejde kontrolou kvality, odošle sa do ďalšej dielne na ďalšie spracovanie.

Každý funkčný blok UOB môže mať postupnosť rozkladov, a preto môže byť podrobný s akoukoľvek požadovanou presnosťou. Rozkladom rozumieme reprezentáciu každého UOB pomocou samostatného diagramu IDEF3. Môžeme napríklad rozložiť Paint Part UOB tak, že ho predstavíme ako samostatný proces a vytvoríme preň vlastný diagram PFDD. V tomto prípade sa tento diagram bude nazývať podriadený diagram vo vzťahu k diagramu znázornenému na obrázku 1.4 a ten, respektíve rodičovský. Čísla UOB podradených diagramov majú priebežné číslovanie, t.j. ak má nadradený UOB číslo „1“, potom bloky UOB pri jeho rozklade budú mať čísla „1.1“, „1.2“ atď. Aplikácia princípu dekompozície v IDEF3 umožňuje popísať procesy štruktúrovaným spôsobom s akoukoľvek požadovanou úrovňou detailov.

Ak sú diagramy PFDD technologickým procesom „z pohľadu pozorovateľa“, potom ďalšia trieda diagramov IDEF3 - OSTN nám umožňuje uvažovať o rovnakom procese „z pohľadu objektu“. Obrázok 1.5 znázorňuje proces lakovania v zmysle OSTN diagramu. „Stavy objektu“ (v našom prípade časti) a „Zmena stavu“ sú kľúčové pojmy diagramu OSTN. Stavy objektov sú zobrazené ako kruhy a ich zmeny ako smerované čiary. Každý riadok má prepojenie na zodpovedajúci funkčný blok UOB, ktorý viedol k zmene stavu objektu, ktorý zobrazuje.

Obrázok 1.5 - Proces lakovania z pohľadu schémy OSTN

2. Nástroje modelovania podnikových procesov

Existuje mnoho nástrojov na popis biznis procesov: BPWin, ERWin, PowerDesigner, Business Studio, ELMA BPM, Visual Paradigm a iné.

K vyššie uvedenému zoznamu môžete dodať, že patrí do poprednej rodiny kancelárskych produktov vyrábaných lídrom v softvérovom priemysle – Microsoft Visio. Samozrejme, nie je až taký funkčný z pohľadu modelovania podnikových procesov, ale je veľmi obľúbený a rozšírený vďaka relatívne nízkej cene.

2.1 Technické vlastnosti. Úložisko dát

Technicky je Visio desktopová aplikácia, ktorá manipuluje s jednotlivými súbormi (dokumentmi). Dokument Visio obsahuje jeden alebo viacero diagramov usporiadaných na jednej alebo viacerých stranách. Každý dokument obsahuje množinu symbolov (zodpovedajúcich objektom modelu) a konektorov (zodpovedajúcich spojeniam), pričom symboly môžu mať okrem názvov aj ďalšie atribúty, ktoré definuje používateľ počas procesu modelovania.

V prípade potreby je možné sadu symbolov dodaných s produktom rozšíriť o symboly vytvorené používateľmi. Neexistujú žiadne globálne obmedzenia týkajúce sa pravidiel a možnosti vytvárať spojenia medzi určitými typmi symbolov v produkte, má však mechanizmus pre takzvané šablóny diagramov, ktorých použitie umožňuje obmedziť množinu priamo dostupných symbolov. na príslušnom paneli nástrojov počas procesu modelovania. Šablóny môžu vytvárať používatelia a produkt sa dodáva so sadou hotových šablón (obrázok 2.1).

Súbor modelov popisujúcich činnosť podniku je spravidla súborom jednotlivých súborov, pričom v prípade pomerne veľkých podnikov a komplexného popisu činností môže byť počet takýchto súborov aj niekoľko tisíc. Technické prostriedky na zabezpečenie vzťahov medzi modelmi uloženými v rôznych súboroch nie sú implementované na úrovni produktu, hoci produkt poskytuje nástroje na samostatnú implementáciu takýchto vzťahov (o nich bude reč neskôr). Preto si používanie Visia v takýchto prípadoch, najmä v podmienkach neustále sa meniacich procesov, vyžaduje značné náklady na udržanie tak pôsobivého súboru modelov.

Obrázok 2.1 - Sada hotových šablón MS Visio

2.2 Podporované metodológie a notácie

Keďže množinu symbolov a šablón Visia je možné ľubovoľne rozširovať a samotný produkt neznamená globálne obmedzenia možností používania symbolov a prepojení medzi nimi, popis obchodných procesov pomocou Visia je možné formálne vykonať v rámci takmer akéhokoľvek metodiky. Zároveň produktový balík v ľubovoľnej edícii (Standard, Professional) obsahuje sadu vzorových šablón pre najbežnejšie zápisy, ako sú diagramy toku dát, pridané diagramy reťazca kvality, Event-driven Process Chain, IDEF0, diagramy typu SwimLane , ako aj šablóny na modelovanie organizačných štruktúr firiem.

3. Analýza predmetu EcoTrans LLC

Dopravná spoločnosť EcoTrans LLC bola založená v roku 2008. Prvé prepravné služby boli poskytnuté spotrebiteľom podnikajúcim v regióne Oryol. Mnohé z najväčších podnikov v regióne uzatvorili so spoločnosťou dlhodobé zmluvy na prepravu tovaru a osôb. Pre spoločnosť EcoTrans LLC sa služby nákladnej dopravy (región Oryol) v rámci regiónu stali úspešným začiatkom ďalšieho rozvoja. Dnes sa geografia dopravnej obslužnosti posunula ďaleko za hranice nášho rodného kraja. Rozšírenie geografie jej aktivít si vyžiadalo zvýšenie počtu moderných nákladných vozidiel, takže na rozvoz tovaru dnes využíva nielen vlastný rozsiahly vozový park, ale aj vozidlá partnerov.

EcoTrans LLC zabezpečuje nielen prepravu nákladu po celom Rusku, ale klientom poskytuje aj súvisiace služby, ako je špedícia a poistenie nákladu.

a) Špedícia. Táto služba umožňuje klientovi nielen uľahčiť proces prepravy nákladu, ale aj znížiť jeho náklady. Špedícia pozostáva z niekoľkých druhov služieb:

Príprava potrebných dokumentov. Nákladné listy, colné vyhlásenia, doklady poisťovne atď. dokumenty, ako aj ich podpisovanie, sa už klienta netýkajú;

Výber vozidla. Zohľadňuje sa hmotnosť nákladu, jeho rozmery a trasa;

Plánovanie trasy. Vyberie sa najrýchlejší a najbezpečnejší dopravný vzor;

Riešenie ďalších problémov, ktoré sa vyskytnú na trase.

b) Poistenie nákladu. Nákladu sa po ceste môže stať čokoľvek. Môže byť poškodený, pokazený, odcudzený atď. Na elimináciu týchto rizík poisťovne poisťujú náklad, prepravné náklady na jeho doručenie a dokonca aj nejakú časť očakávaného zisku.

Poslaním spoločnosti EcoTrans LLC je poskytovať klientom vysokokvalitné, vysoko profesionálne dopravné služby s cieľom nadviazať dlhodobé partnerstvá s existujúcimi spotrebiteľmi a prilákať nových.

3.1 Organizačná štruktúra spoločnosti EcoTrans LLC

V spoločnosti EcoTrans LLC sú generálnemu riaditeľovi podriadení: hlavný účtovník, hlavný inžinier, elektrotechnik, správca systému. Účtovník podáva správy hlavnému účtovníkovi. Skladník sa hlási účtovníčke. Hlavnému inžinierovi sú podriadení: skladník, mechanik, zdravotnícky pracovník, dispečer. Dispečerovi sú podriadení: mechanici, vodiči áut, vodiči autobusov, vodiči vysokozdvižných vozíkov. Mechanikovi sú podriadení: vodiči áut, vodiči autobusov, vodiči vysokozdvižných vozíkov.

3.2 Obchodný proces “Preprava nákladu”

Obchodný proces „Nákladná preprava“ zahŕňa:

1 Prijatie žiadosti. Zákazník odošle požiadavku dispečerovi a ten ju akceptuje.

2 Uzavretie dohody. Medzi objednávateľom a riaditeľom je uzatvorená zmluva, na základe ktorej sa preprava realizuje.

3 Kontrola existencie zmluvy. Dispečer skontroluje existenciu zmluvy.

4 Spracovanie žiadosti. V súlade s technickými vlastnosťami vozidla dispečer na základe žiadosti, s prihliadnutím na rozmery, hmotnosť nákladu a prepravné podmienky, prideľuje vozidlá.

5 Vystavenie nákladného listu. Dispečer zavolá vodičovi, informuje ho o nadchádzajúcom lete a trase a vystaví nákladný list.

6 Absolvovanie lekárskej prehliadky. Vodič sa podrobuje lekárskej prehliadke.

7 Označte pri absolvovaní lekárskej prehliadky. Zdravotnícky pracovník zisťuje obsah alkoholu a psychotropných látok v organizme, zdravotný stav: meria pulz, krvný tlak, teplotu, zisťuje mieru únavy a kvalitu spánku. Ak je lekárska prehliadka úspešná, zdravotnícky pracovník zapíše značku na nákladný list.

8 Denná údržba vozidla. Vodič vykonáva každodennú údržbu vozidla. Kontroly: kompletnosť auta, hladina chladiacej kvapaliny a mazacích kvapalín, tesnosť systémov auta, stav a upevnenie kolies, činnosť brzdových systémov, svetelné a zvukové alarmy.

9 Vyznačte prevádzkyschopnosť vozidla na nákladnom liste. Vodič zapíše do nákladného listu známku o kontrole vozidla.

10 Kontrola vozidla. Vodič dáva vozidlo na kontrolu mechanikovi. Mechanik kontroluje vozidlo. Kontroly: tesnosti a činnosti brzdových systémov, systémov napájania, chladiacich systémov, výfukových systémov; prevádzkyschopnosť riadenia, vonkajších osvetľovacích zariadení, stieračov čelného skla; upevnenie kolies; dostupnosť lekárničky, hasiaceho prístroja a výstražného trojuholníka.

11 Vyznačte prevádzkyschopnosť vozidla na nákladnom liste. Mechanik uvedie na nákladnom liste poznámku o prevádzkyschopnosti vozidla.

12 Nákladná doprava. Vodič odíde na linku, vyzdvihne náklad na určenom mieste a doručí ho príjemcovi.

13 Príjem dokumentov . Vodič si vyzdvihne dodacie listy od zákazníka.

14 Vráťte sa z čiary. Vodič z linky sa vracia do garáže.

15 Kontrola vozidla. Pri návrate z linky vodič poskytne vozidlo na kontrolu mechanikovi.

16 Poznámka o stave vozidla na nákladnom liste. Mechanik zaznamená stav vozidla do nákladného listu.

17 Odovzdávanie dokladov účtovnému oddeleniu. Faktúry predkladá vodič účtovnému oddeleniu.

18 Vystavovanie dokladov účtovným oddelením. Účtovné oddelenie vystavuje doklady: potvrdenie o vykonaní práce, faktúru, faktúru na úhradu.

19 Platba za služby zákazníkom. Účtovníctvo odovzdá vystavené doklady na úhradu odberateľovi. Zákazník platí za poskytnutú službu.

3.3 IT infraštruktúra

modelovanie informačnej siete

Architektúra siete je kombináciou topológií, metód prístupu k médiám a protokolov potrebných na vytvorenie funkčnej siete.

LAN - lokálna sieť (LAN, local area network).

V organizácii EcoTrans LLC je LAN vytvorená podľa „hviezdnej“ topológie.

IS objektu prieskumu využíva adresárovú službu spoločnosti Microsoft Corporation - Active Directory. Táto služba sa používa na reguláciu zásad skupiny domén. Domény majú hierarchickú štruktúru.

V hardvérovej časti IS objektu: 2 servery; 16 pracovných staníc.

Softvér EcoTrans LLC: operačný systém Windows XP Service Pack 2/3, MS Office 2007, antivírusový softvér - Panda Antivirus Platinum, právnická osoba platiteľa dane, 1C: Účtovníctvo, 1C: Mzdy a personál, PP "Adresár certifikátov", CIPF Crypto About CSP, PP "STEC-Trust". AWS "TRUST-Client", Systém "STEC-Trust". Pracovná stanica poistenca, Pomôcka pre Fond sociálneho poistenia, Dokumenty PU 5, CheckXML, Canon Solution Menu, ABBYY FineReader Professional Edition, Total Commander, WinDjView, Adobe Acrobat Professional, WinRAR a iné.

4. Popis obchodných procesov spoločnosti TC LLC „EcoTrans“ pomocou obchodného modelovania v programe Microsoft Visio

4.1 Zostavenie modelu v notácii IDEF0 a jeho rozklad

Vytvorme model spoločnosti TC LLC „EcoTrans“ pomocou metodiky IDEF0. Najprv zostavme kontextový diagram obchodného procesu „Nákladná preprava“ (obrázok 4.1). Podľa notácie IDEF0 nazvime tento funkčný blok „Transport cargo“.

Obrázok 4.1 - Kontextový diagram procesu „Preprava nákladu“.

Následne obchodný proces „Preprava nákladu“ rozdelíme na komponenty: „Spracovanie žiadosti“, „Uzavretie zmluvy“, „Príprava na prepravu tovaru“, „Príprava dokladov potrebných na prepravu tovaru“, „Vykonanie prepravu tovaru“. Podľa toho rozložíme funkčný blok „Prepravný náklad“ (obrázok 4.2).

Obrázok 4.2 - Schéma rozkladu procesu „Preprava nákladu“.

Pozrime sa bližšie na obchodné procesy: „Spracovanie aplikácií“ (obrázok 4.3); „Príprava na prepravu nákladu“ (obrázok 4.4); „Evidencia dokumentov potrebných na prepravu tovaru“ (obrázok 4.5); „Preprava nákladu“ (obrázok 4.6).

Obrázok 4.3 - Schéma rozkladu procesu „Spracovanie aplikácie“.

Obrázok 4.4 - Schéma rozkladu procesu „Príprava na prepravu nákladu“.

Obrázok 4.5 - Schéma rozkladu procesu „Evidencia dokumentov potrebných na prepravu tovaru“

Obrázok 4.6 - Schéma rozkladu procesu „Preprava nákladu“

4.2 tVytvorenie modelu v notácii IDEF3

Teraz zostavíme model TC LLC "EcoTrans" pomocou metodiky IDEF3. Dekompozícia procesu „Preprava nákladu“ je znázornená na obrázku 4.7

Obrázok 4.7 - PFDD diagram rozkladu procesu „Preprava nákladu“.

Symbol „“ znamená „exkluzívne OR“, známe tiež ako „XOR“ (exkluzívne OR).

Záver

Pri štúdiu témy „Popis obchodných procesov podniku poskytujúceho služby cestnej dopravy v MS Visio“ sa zistila dôležitosť popisu obchodných procesov pre optimalizáciu procesov podniku.

Popis obchodných procesov je možný rôznymi spôsobmi: textovým, tabuľkovým, grafickým. Na ich popis existuje množstvo metodík (IDEF0, IDEF3, DFD, WORKFLOW, UML, ARIS a iné) a nástrojov (BPWin, ERWin, PowerDesigner a iné).

Pre popis obchodných procesov spoločnosti TC LLC „EcoTrans“ v grafickej podobe boli zvolené metodológie modelovania obchodných procesov IDEF0, IDEF3. Modelovanie bolo realizované pomocou produktu spoločnosti Microsoft – Visio. Tento program má pripravenú šablónu na modelovanie v notácii IDEF0, ale pre IDEF3 sme si museli vytvoriť vlastnú sadu prvkov. To potvrdzuje nízku funkčnosť, ale zároveň absenciu globálnych obmedzení v procese návrhu.

Pridanie grafického popisu k jednoduchému textovému popisu obchodných procesov spoločnosti EcoTrans LLC im poskytlo prehľadnosť. Výsledkom bolo viac príležitostí pre systémovú analýzu a optimalizáciu aktivít spoločnosti.

Ak vezmeme do úvahy dostupnosť programu Microsoft Visio pre ruského používateľa, jeho jednoduchosť použitia a vezmeme do úvahy vznikajúce výhody grafického modelovania obchodných procesov, možno tvrdiť, že diagramy navrhnuté v MS Visio sú dostatočne praktické. pre veľký počet používateľov.

Literatúra

1 Golichev V.D., Golicheva N.D., Gusarova O.M. a iné Aktuálne otázky ekonomiky a manažmentu v kontexte modernizácie. Kolektívna monografia. - Smolensk: Smolgortypografia, 2014. - 212 s.

2 Gusárová O.M. Modelovanie obchodných výsledkov v organizačnom manažmente // Perspektívy rozvoja vedy a vzdelávania. - Tambov: Business-Science-Society, 2014. - s. 42-43.

Uverejnené na Allbest.ru

...

Podobné dokumenty

Vykonanie predprojektového prieskumu podniku. Budovanie modelu organizačnej a funkčnej štruktúry podniku. Vytvorenie organizačnej schémy v MS Visio. Zoznam a štruktúra dokumentov, ktoré má informačný systém generovať.

praktické práce, pridané 14.02.2012

Modelovanie podnikových procesov ako prostriedok hľadania spôsobov optimalizácie činnosti podniku. Metodológia SADT (Structural Analysis and Design), rodina štandardov IDEF a algoritmické jazyky sú základom metodík modelovania obchodných procesov.

abstrakt, pridaný 14.12.2011

Architektúra integrovaných informačných systémov ARIS ako metodika modelovania podnikových procesov, výhody a nevýhody použitia. Výber podnikového procesu pre modelovanie a jeho zmysluplný popis, tabuľkový formát pre jeho popis.

kurzová práca, pridané 19.06.2015

Účel programu Microsoft Visio. Súbory obrázkov predmetov určitých typov. Požiadavky na softvér. Vlastnosti používateľského rozhrania. Funkcie, operácie a techniky Microsoft Visio. Interakcia dizajnéra s aplikáciami.

test, pridaný 19.12.2010

Podstata, význam a metodika modelovania podnikových procesov. História vývoja metodológií modelovania. Systematizácia poznatkov o firme a jej obchodných procesoch vo vizuálnej grafickej podobe pre analytické spracovanie získaných informácií.

abstrakt, pridaný 29.04.2009

Hlavný význam popisu UML. Popis hlavných komponentov používaných v programe Microsoft Visio. Tvorba diagramov tried v programe Microsoft Visio 2010. Revízia vygenerovaného modelu pri úpravách systému. Štruktúra systému, jeho triedy, jeho atribúty a operátory.

praktické práce, doplnené 07.05.2014

Návrh lokálnej počítačovej siete. Výber topológie siete, architektúry a štruktúry systému. Analýza informačných tokov v distribuovanom systéme, výber simulačného systému. Stanovenie nákladov na vytvorenie a vývoj systému.

práca, pridané 21.05.2015

Správa vzdialenej konfigurácie a inštalácie softvéru. História vývoja VMware ThinApp. Vytvorenie automatického inštalačného balíka pre Microsoft Office Visio Professional 2007. Analýza jeho softvéru. Testovanie výsledného balíka msi.

kurzová práca, pridané 14.03.2013

Porovnávacia analýza hotelových informačných systémov. Analýza a výber CASE nástrojov pre modelovanie podnikových procesov. Vizuálne a matematické modely predmetu, výber architektúry a platformy informačného systému, budovanie databázy.

práca, pridané 20.07.2014

Prostredie Microsoft Visio: koncept, hlavné funkcie. Funkcia automatického pripojenia v aplikácii Office Visio 2007. Funkcia pravdepodobnosti logovania. Graf pravdepodobnosti zlyhania verzie softvéru. Vizuálne modelovanie v UML. Celkový pohľad na diagram tried.

Pracovné postupy sú dôležitou a takmer povinnou súčasťou portálu SharePoint, sú základom toku dokumentov a mnohých ďalších obchodných procesov. Nie je prekvapujúce, že existujú systémy ako Nintex, ktoré sa snažia rozšíriť a doplniť možnosti štandardných pracovných postupov.

Z mojej skúsenosti s prácou s Nintexom môžem povedať, že tento systém nie je bez nevýhod: vysoká cena, periodické chyby, všeobecná pomalosť systému (hoci je to typické pre všetky SharePointy) – to všetko ma núti používať štandardný mechanizmus workflow . Nintex má však dôležitú výhodu – vizualizáciu diagramu a aktuálneho stavu procesu. Vďaka tomu je tvorba workflow zjednodušená a môžu ich vytvárať aj ľudia, ktorí majú do programovania dosť ďaleko (správcovia obsahu, business analytici a pod.). SharePoint 2010 má podobnú schopnosť vytvárať pracovný tok založený na vizuálnom diagrame pomocou Visio 2010 a SharePoint Designer 2010.

Vytvorte diagram v programe Visio

Visio 2010 má novú šablónu – Microsoft SharePoint Workflow (prítomná iba v prémiovej edícii Visia). Diagram získaný z tejto šablóny je možné exportovať do aplikácie Designer pre ďalšiu prácu.
Otvorte teda Visio a vyhľadajte šablónu v kategórii Vývojový diagram.

Po otvorení šablóny budú prvky diagramu umiestnené vľavo - podmienky, akcie, začiatok a koniec (snímka obrazovky zobrazuje iba „rýchle“ akcie, vo všeobecnosti ich je oveľa viac):

Teraz premýšľame cez logiku obchodného procesu a zostavíme diagram pomocou potrebných prvkov. Urobil som napríklad jednoduchý proces schvaľovania firmy:

existujú 2 zoznamy – „Doručená pošta“ a „Zodpovedný“
v zozname „Zodpovední“ sú kategórie žiadostí (návrh/otázka/sťažnosť atď.) a zodpovedajúce zodpovedné osoby
používateľ vytvorí položku v priečinku Doručená pošta a určí kategóriu
pracovný postup nájde osobu zodpovednú za túto kategóriu a vytvorí pre ňu úlohu
zodpovedná osoba zareaguje na úlohu a zmení sa stav požiadavky v zozname doručenej pošty

Samozrejme, je ťažké to pochopiť slovami, takže vám okamžite dám hotový diagram pracovného postupu:

Pri vytváraní diagramu nie je nič zložité, stačí si predstaviť logiku obchodného procesu. Označenia prvkov sú celkom prehľadné, ikony zabraňujú zámene. Po vytvorení exportujte proces do súboru pre SharePoint Designer:

Naviazanie procesu na údaje v SharePoint Designer

Otvorte aplikáciu Designer, pripojte sa k požadovanej lokalite a prejdite do priečinka Workflows. Na páse s nástrojmi kliknite na tlačidlo „Importovať z Visia“ a zadajte súbor s uloženým diagramom. Napíšeme názov pracovného postupu a zoznam, na ktorý ho naviažeme (v tomto prípade „Doručená pošta“). Návrhár sám vygeneruje kód a komentáre k nemu, všetko, čo musíme urobiť, je označiť polia, z ktorých získame údaje (konkrétne v tomto prípade som mal menšie problémy kvôli použitiu poľa typu Lookup, ale zvyčajne; všetko je jednoduché):

Po dokončení pracovného postupu prejdite na nastavenia. Tam uvedieme nevyhnutnú podmienku spustenia (spustí sa automaticky pri vytvorení prvku) a tiež zaškrtneme možnosť „Zobraziť vizualizáciu pracovného toku na stavovej stránke“ (na kolekcii lokalít musíte aktivovať funkcie SharePoint Server Enterprise). To je presne to, prečo sa oplatí vytvárať pracovné postupy vo Visiu. Teraz poďme na lokalitu, vytvorte ľubovoľnú položku v zozname Doručená pošta, prejdite do zoznamu úloh a dokončite úlohu a potom otvorte okno stavu pracovného toku:

Vidíme teda celkom pekný diagram pracovného toku, ktorý označuje všetky dokončené fázy. Ak by sa proces v ktorejkoľvek fáze zastavil (napríklad čakal na schválenie od nás), bolo by to zaznamenané aj na diagrame. Vďaka tomu bude každý užívateľ vidieť, v akom štádiu schvaľovania sa jeho žiadosť nachádza.

Záver

Ako zhrnutie uvediem pozitívne a negatívne aspekty používania Visia na vytváranie pracovných postupov (podľa môjho subjektívneho názoru).
Výhody:

Jednoduché vytváranie, nemusíte byť programátor
Používateľ môže ľahko zobraziť a pochopiť stav požiadavky

mínusy:

Vyžaduje SharePoint Enterprise Server a Visio Premium

Často dostávam otázku – čo čítať o obchodných procesoch?
Jedna z najlepších stránok na ruskom internete je www.klubok.net. Sám som „vyrástol“ na fóre a článkoch na tejto stránke. Mnohé články nestratili na aktuálnosti ani teraz. Odporúčam začať s ním študovať.

Ale ak hovoríme o knihách, môžem s istotou povedať, že najlepšia kniha o obchodných procesoch je kniha napísaná Repinom a Eliferovom: „Podnikové procesy, analýza, regulácia“.

Popis obchodných procesov: snaha o jednoduchosť.

Článok rozoberá problematiku výberu notácie pre popis procesov za účelom následnej regulácie. Porovnávajú sa často používané zápisy pracovného toku, ako napríklad: „Simple Flow Diagram“ v MS Visio, „Procedúra“ v Business Studiu, zápis ARIS eEPC a iné.

Pri porovnávaní zápisov sa hlavný dôraz kladie na vytváranie procesných diagramov, ktoré sú jednoduché a zrozumiteľné pre zamestnancov organizácie.

Pre podnikových analytikov spoločností sú tézy diskutované v článku vážnym dôvodom na zamyslenie sa nad tým, aké efektívne sú prístupy, ktoré používajú na vytváranie grafických diagramov organizačných procesov.

Úvod

Jedným z najdôležitejších cieľov vytvárania grafických procesných diagramov je ich následné použitie v regulačných dokumentoch organizácie. Spravidla tieto schémy používajú zamestnanci, ktorí nie sú vyškolení v zložitých notáciách, nemajú zručnosti systémovej analýzy atď. Jednoduchosť a prehľadnosť schém je pre nich veľmi dôležitá. Zložitým, mätúcim diagramom obsahujúcim veľa rôznych symbolov ľudia zle rozumejú, čo sťažuje ich použitie v praxi. Preto je pre praktické účely dôležité správne vybrať a použiť notáciu (metodiku) na popis procesov. Aké kritériá by sa mali použiť na výber takéhoto zápisu? Ako porovnať rôzne zápisy medzi sebou? Pozrime sa na niekoľko populárnych zápisov a pokúsme sa odpovedať na tieto otázky.

Porovnanie zápisov

Na porovnanie boli zvolené nasledujúce zápisy popisu procesu:

„Jednoduchý vývojový diagram“ (zobrazenie pohybu dokumentov pomocou bloku „Riešenie“);
„Jednoduchý blokový diagram“ (bez zobrazenia pohybu dokumentov, bez použitia blokov „Riešenie“);
„Postup“ systému Business Studio (jedna z možných možností prezentácie);
ARIS eEPC.

Ako testovací prípad bol zvolený jednoduchý a intuitívny proces. Výsledky opisu tohto procesu sú uvedené na obr. 1-4.

Ryža. 1. Diagram procesu v zápise „Jednoduchý vývojový diagram“ v MS Visio (s pohybom dokladov pomocou bloku „Rozhodnutie“).

V diagrame Obr. 1. Postupnosť operácií procesu v priebehu času je znázornená pomocou hrubých šípok a pohyb dokumentov je znázornený pomocou tenkých bodkovaných šípok. Bloky roztoku sa používajú klasickým spôsobom. Zobrazujú informácie (otázky), od ktorých „závisí“ ďalší priebeh procesu. Tento prístup k používaniu „diamantov“ je veľmi bežný. V skutočnosti by však celá logika rozhodovania a tvorba určitých výstupov (dokumentov) mala byť obsiahnutá v operáciách procesu. Ak sa nad tým zamyslíte, hodnota (význam) kreslenia týchto „diamantov“ nie je zrejmá. Aké sú tieto objekty: operácie procesov, udalosti? Zdá sa, že nie je ani jedno, ani druhé. Sú to skôr operátori, ktorí sa rozhodujú na základe nejakej podmienky. Ale vyvíjame procesný diagram pre ľudí a nie písanie počítačového programu v špeciálnom jazyku. V počítačovom programe by bol „diamant“ plnohodnotnou operáciou na porovnávanie podmienok atď. Procesný diagram však musí zobrazovať skutočné objekty - procesy vykonávané ľuďmi, dokumenty, informačné systémy atď. Premýšľajte o tom: je správne zobrazovať „diamanty“ oddelene od operácie procesu na diagrame? Namiesto toho môžete:

a) opísať logiku rozhodovania vo forme sledu operácií na diagrame posudzovaného procesu;
b) opísať logiku vo forme diagramu krokov zodpovedajúceho podprocesu s prechodom na nižšiu úroveň;
c) popísať logiku textom (v textových atribútoch operácie) a následne ju zobraziť v predpisoch na vykonávanie procesov.

Sformulujme si „výhody“ a „proti“ metódy používania „diamantov“ diskutovanej vyššie (obr. 1).

"Jednoduchý vývojový diagram" v MS Visio (s pohybom dokumentu, pomocou bloku "Riešenie")
"profíci"	"mínusy"
Vizuálne zobrazenie „logiky“ výberu určitých procesných výstupov. Zameranie pozornosti interpreta na rozhodovací bod/rozvetvenie procesu v závislosti od podmienok.	Posúvanie logiky rozhodovania „mimo“ chod procesu (nesprávne z pohľadu formálneho rozkladu procesov). Je nepohodlné dokumentovať proces (pri vytváraní textového popisu operácie musíte „kosočmene“ duplikovať textom). Procesný diagram sa stáva informačným preťažením. „Diamanty“ sa často používajú príliš formálne, bez skutočnej potreby.

Na obr. 2. ukazuje príklad toho istého procesu, len opísaný bez použitia blokov a dokumentov „Riešenie“. Je ľahké skontrolovať, že tento diagram má o 24 menej grafických prvkov ako diagram na obr. 1. Schéma Obr. 2. vyzerá oveľa jednoduchšie. Grafické prvky neoslnia oči a z hľadiska informačného obsahu je tento diagram celkom zrozumiteľný a dostupný pre koncového užívateľa. Ak pre každú procesnú operáciu popíšete textovo požiadavky na jej implementáciu, tak kombináciou tabuľkových a grafických prezentačných foriem celkom primerane popíšete postup pri realizácii procesu pre zamestnancov firmy.

Ryža. 2. Diagram procesu v zápise „Jednoduchý vývojový diagram“ v MS Visio (bez pohybu dokumentu, bez použitia bloku „Rozhodnutie“).

„Pre“ a „proti“ grafického znázornenia procesu vo forme znázornenej na obr. 2. sú zobrazené nižšie.

Vo všeobecnosti platí, že použitie diagramov vo formáte podobnom tým, ktoré sú uvedené na obr. 2 je vhodný pre vývojárov aj zamestnancov pracujúcich na týchto schémach.

Na obr. 3. Zobrazí sa procesný diagram vytvorený v zápise „Procedúra“ modelovacieho prostredia Business Studio. Schéma má niekoľko funkcií. Po prvé, bloky „Rozhodnutie“ sa nepoužívajú štandardným spôsobom – nie ako grafický prvok na zobrazenie otázky a vetvenia, ale ako plnohodnotná procesná operácia spojená s rozhodovaním. V Business Studio má „diamant“ takmer všetky atribúty plnohodnotného procesu, ale nedá sa rozložiť (možno to vývojári systému časom umožnia). Použitím „diamantu“ (namiesto štvoruholníka) je diagram vizuálnejší. Zároveň môžete do atribútov „diamantu“ zadať ľubovoľné textové informácie: popis, začiatok, dokončenie, požiadavky na termín atď.

Druhým znakom procesného diagramu znázorneného na obr. 3., je použitie šípok. Ak chcete zobraziť postupnosť operácií, môžete použiť šípku s jedným hrotom - šípku „nadradenosť“. Na zobrazenie pohybu dokumentu môžete použiť obojstrannú šípku. V Business Studio však môžete použiť iba jeden typ šípok - šípky „prednosti“. Zároveň je možné na pomenované šípky prepojiť potrebný počet dokumentov, ktoré sú definované v adresári objektov aktivít. Tento prístup umožňuje:

výrazne znížiť počet grafických prvkov v procesnom diagrame a zároveň:
zobraziť potrebné informácie o došlých a odoslaných dokladoch v procesných predpisoch.

Bez toho, aby sme diagram zahltili zbytočnými prvkami, môžeme napriek tomu celý proces opísať a nahrať všetky potrebné informácie do predpisov.

„Pre“ a „proti“ grafického znázornenia procesu vo forme znázornenej na obr. 3. sú zobrazené nižšie.

Ryža. 3. „Postup“ systému Business Studio (možnosť s netradičným využitím blokov „Riešenie“).

Keď používate Business Studio, zápis procedúry možno použiť mierne odlišnými spôsobmi. Autor článku sa prikláňa k prístupu prezentovanému na obr. 3.

Na obr. Obrázok 4 ukazuje diagram posudzovaného procesu, vyvinutý v notácii ARIS eEPC. Všimnite si, že niektoré procesné operácie sa nezmestili do diagramu. Tento čiastočný diagram jednoduchého procesu napísaný v notácii ARIS eEPC obsahuje štyri logické príkazy a osem udalostí! Osoba, ktorá číta diagram, musí byť schopná správne interpretovať všetky tieto logické operátory. Bez špeciálneho školenia a určitých zručností pri čítaní takýchto diagramov je nepravdepodobné, že bežný zamestnanec bude schopný pochopiť logiku daného procesu bez podrobného textového popisu alebo pomoci kvalifikovaného obchodného analytika.

Všimnite si, že procesný diagram v notácii ARIS eEPC zaberá podstatne viac miesta ako diagramy uvedené na obr. 1-3. Zložitosť vytvorenia takejto schémy je tiež výrazne vyššia.

Procesný diagram v notácii ARIS eEPC (postavená v Business Studio)
"profíci"	"mínusy"
Pri vytváraní diagramu sa zachováva prísna, formálna logika procesu. Všetky udalosti, ktoré sa vyskytnú počas procesu, sú jasne definované.	Ťažkosti s vnímaním. Značná zložitosť tvorby schémy. Personál musí mať špecializované zručnosti a skúsenosti s interpretáciou takýchto diagramov. Redundancia informácií. Zaberá príliš veľa miesta, čo je pre dokumentáciu nepohodlné.

Vo všeobecnosti, ak sa nechystáte kupovať SAP R/3, tak výber a používanie notácie ARIS eEPC nie je z pohľadu autora článku optimálnym riešením. Stojí za to venovať pozornosť zápisom na popis procesov, ktoré sú pre interpretov viac vizuálne a intuitívne. Niektorým sa však môže zdať zápis ARIS eEPC vizuálnejší a zrozumiteľnejší. Do istej miery je to vec vkusu.

Ryža. 4. Diagram procesu v notácii ARIS eEPC (vytvorený v Business Studiu).

Popis procesu pre následné automatizačné účely

Je zaujímavé pozrieť sa na príslušný procesný diagram, ak je popísaný v zápise BPMN 2.0. Tento zápis má opísať „vykonávanie“ procesov, t.j. procesy podporované systémom BPM.

Váš názor na používanie BPMN 2.0. akcie A.A. Belaichuk - generálny riaditeľ spoločnosti "Business Console":

Na obr. Obrázok 5 znázorňuje rovnaký proces v zápise BPMN. Ako vidíme, tento obrázok je podobný obrázku 1: v zápise BPMN sú úlohy zobrazené ako obdĺžniky, vidlice ako kosoštvorce a údaje ako ikona podobná dokumentu. Kontrolné toky sú plné čiary, toky údajov sú bodkované.

Je potrebné vziať do úvahy, že tento diagram používa iba malú časť zápisu BPMN: v palete je k dispozícii iba jeden typ vidlice z 5, jeden typ úlohy z 8. Okrem širšej palety je tento zápis vyznačuje sa schopnosťou modelovať nielen izolovaný pracovný tok, ale aj niekoľko procesov, ktoré navzájom interagujú prostredníctvom správ alebo údajov. Tento zápis je navyše prísnejší: definuje nielen ikony, ale aj pravidlá, podľa ktorých sa môžu navzájom kombinovať. Potreba takýchto pravidiel je diktovaná skutočnosťou, že notácia BPMN je zameraná nielen na skutočnosť, že ju budú čítať ľudia, ale aj na priame vykonávanie pomocou špeciálneho softvéru - „motora“ systému BPM.

Zároveň, ako ukazuje tento príklad, pri použití obmedzenej podmnožiny palety sa BPMN ukáže byť o nič komplikovanejšie ako konvenčný vývojový diagram. Pre tých, ktorí chcú BPMN zvládnuť profesionálne, odporúčame špecializované školenie www.bpmntraining.ru.

Ryža. 5. Diagram procesu v zápise BPMN 2.0.

Životná prax

Na obr. Obrázok 6 zobrazuje fragment procesného diagramu vyvinutého obchodnými analytikmi veľmi špecifickej spoločnosti v notácii, ktorú vymysleli. Diagram je zostavený na princípoch „Jednoduchého blokového diagramu“ – blok „Solution“ sa používa v klasickej verzii. Okrem toho schéma zobrazuje mnoho ďalších symbolov používaných neštandardným spôsobom.

Pri vytváraní diagramu na obr. 6, obchodní analytici očividne „bojovali“ o prehľadnosť a maximálnu zrozumiteľnosť pre bežného používateľa. Snažili sa minimalizovať, či dokonca eliminovať textové komentáre k procesným diagramom. Účinkujúci boli jednoducho vytlačení schémou formátu A3, po prečítaní ktorej bolo všetko okamžite jasné: čo robiť, ako, aké dokumenty použiť atď.

Zvažovaná schéma samozrejme nie je príkladom jednoduchosti a jasnosti. Bol však vytvorený tak, aby sprostredkoval maximálne užitočné informácie tým, ktorí sú zapojení do procesu.

závery

Je teda zrejmé, že pri popise procesov sa treba snažiť o jednoduchosť a prehľadnosť pre zamestnancov.
Použitie zložitých formalizovaných zápisov pri popise procesov vedie k:

ťažkosti pri používaní (interpretácii) diagramov bežnými zamestnancami;
nemožnosť (náročnosť) organizácie práce na opis procesov zamestnancami oddelení, ktorí neprešli špeciálnym školením;
výrazné zvýšenie nákladov na pracovnú silu obchodných analytikov pri vytváraní schém;
ďalšie ťažkosti pri dokumentovaní obvodov (veľký objem atď.);

Preto by ste nemali zahlcovať diagram procesu rôznymi grafickými prvkami. Ale aj keď sa používajú, je lepšie, aby niesli užitočné informácie pre zamestnancov a neboli len dôsledkom formálneho použitia modelovania.

V.V. Repin, Ph.D., docent, výkonný riaditeľ BPM Consulting Group LLC, vedúci. Katedra riadenia podnikových procesov Národnej vzdelávacej inštitúcie vyššieho odborného vzdelávania „IEF „Synergy“, zakladateľ portálu www.FineXpert.ru

Práve tieto jednoduché princípy sa snažím sprostredkovať biznis lídrom, ktorí očarení krásnymi prezentáciami softvérových produktov často zabúdajú, že jednoduchý kontrolný zoznam je často lepší ako 10 strán predpisov.

Táto lekcia hovorí o vytváraní jednoduchých (zhora nadol, sledovanie údajov, plánovanie procesov atď.) a funkčných vývojových diagramov (zobrazujúcich vzťahy medzi obchodným procesom a oddeleniami).

Jednoduchá bloková schéma

Šablóna Simple Flowchart je určená na navrhovanie vývojových diagramov, diagramov zhora nadol, diagramov sledovania údajov, diagramov plánovania procesov a diagramov štrukturálnej prognózy. Šablóna obsahuje potrebné tvary, spojovacie čiary a odkazy.

Cvičenie 1

Ryža. 3.3.Jednoduchý vývojový diagram (3. fáza)

8. Zadajte text do tvarov vývojového diagramu (pozri obrázok 3.4). Ak chcete zadať text do tvaru, postupujte takto:

9. Na karte Domov v skupine servis vyberte nástroj Ukazovateľ.

Kliknite na tvar, kam chcete zadať text.
Zadajte požadovaný text.

Poznámka:

Ak chcete obrázok priblížiť, stlačte klávesovú skratku + a kliknite ľavým tlačidlom myši na tvar, kým nedosiahnete požadovanú mierku.
Ak chcete zmenšiť mierku obrázku, stlačte klávesovú skratku + a kliknite pravým tlačidlom myši na tvar, kým nedosiahnete požadovanú mierku.

Ryža. 3.4. Jednoduchý vývojový diagram (4. fáza)

Číslovanie obrázkov v blokovej schéme

Visio dokáže číslovať tvary vo vývojovom diagrame. Ak chcete zadať možnosti číslovania, na karte vyhliadka v skupine Makrá kliknite na tlačidlo Doplnky a vyberte v skupine Ďalšie riešenia Visio tím Číslovanie obrázkov. V okne, ktoré sa otvorí Číslovanie obrázkov zadajte požadované parametre číslovania a kliknite na tlačidlo OK.

Úloha 2

Do vývojového diagramu pripraveného počas úlohy 1 pridajte automatické číslovanie všetkých obrázkov (pozri obr. 3.6).
Pre to:
- Na karte vyhliadka v skupine Makrá kliknite na tlačidlo zoznamu Doplnky, vyberte skupinu Ďalšie riešenia Visio a v ňom príkaz Číslovanie obrázkov.
- V okne, ktoré sa otvorí Číslovanie obrázkovšpecifikovať parametre
  - na karte Sú bežné:
    - Obsluha - Automatické číslovanie;
    - Použiť na - Všetky tvary;
    - Začnite od - 1;
    - Interval - 1;
    - Začiarknite políčko Pokračovať v číslovaní tvarov pri ich presúvaní na stranu.
  - Na karte Okrem toho:
    - Číslo miesta – pred text tvaru;
    - Poradie číslovania: zľava doprava, zhora nadol;
    - Začiarknite políčko Vylúčte spojovacie vedenia.
  - Kliknite na tlačidlo OK.
Uložte vývojový diagram.

Ryža. 3.6. Jednoduchý vývojový diagram (krok 6)

Zmena vývojového diagramu

Pridanie tvaru medzi dva ďalšie tvary

Ak chcete pridať nový tvar medzi dva ďalšie tvary vývojového diagramu, presuňte nový tvar na spojnicu, ktorá spája tvary, medzi ktoré vkladáte. Visio vloží nový tvar medzi existujúce a automaticky rozšíri vývojový diagram.

Odstránenie tvaru

Ak chcete odstrániť tvar z vývojového diagramu, vyberte tvar a kliknite na klávesnici.

Prečíslovanie čísel

Ak chcete prečíslovať obrázky vo vývojovom diagrame, postupujte takto:

Na karte vyhliadka v skupine Makrá kliknite na tlačidlo Doplnky a vyberte v skupine Ďalšie riešenia Visio tím Číslovanie obrázkov.
V okne, ktoré sa otvorí Číslovanie obrázkov na karte Sú bežné vyberte prepínač Prečíslujte v rovnakom poradí, Uveďte prosím štartovné číslo pre číslovanie a kliknite OK.

Úloha 3

Upravte vývojový diagram pripravený v úlohe 2:
- Odstráňte tvar Dokument(Odoslať prihlášku).
- Medzi figúrkami Riešenie(Žiadosť je vyplnená správne) a Dokument(Submit odmietnutie) umiestnite figúrku Proces(Preposlať asistentovi veľtrhu).
- Pridajte tvar Proces(Zavolajte vystavovateľovi ohľadom platby) nižšie Dokument(poslať faktúru).
- Prečíslujte obrázky blokového diagramu v rovnakom poradí, počnúc štartovným číslom - 1.
Uložte vývojový diagram.

Ryža. 3.7. Jednoduchý blokový diagram (krok 7)

Preusporiadanie spojených tvarov

Po pripojení tvarov vývojového diagramu ich môžete úplne preusporiadať a preusporiadať pripojenia. Ak to chcete urobiť, na karte Konštruktér v skupine Rozloženie kliknite na tlačidlo zoznamu Zmeňte rozloženie stránky a vyberte požadované rozloženie.

Ak zmeníte rozloženie vývojového diagramu, nemusí sa zmestiť na stranu dokumentu. V takom prípade zmeňte veľkosť strany (tab Konštruktér, skupina Nastavenia stránky, tlačidlo zoznamu veľkostí) alebo jeho orientáciu (tab Konštruktér, skupina Nastavenia stránky, tlačidlo zoznamu Orientácia).

Úloha 4

Funkčná bloková schéma

Účel rozloženia Funkčná bloková schéma

Rozloženie Funkčná bloková schéma je určený na zobrazenie vzťahu medzi obchodným procesom a organizačnými alebo funkčnými jednotkami, ako sú napríklad oddelenia zodpovedné za vykonávanie krokov v tomto procese.

Pruhy vo vývojovom diagrame predstavujú funkčné jednotky, ako sú oddelenia, pozície alebo iné funkcie. Každý tvar predstavujúci krok procesu je umiestnený v stope funkčnej jednotky zodpovednej za tento krok.

Úloha 5

Pridávanie, presúvanie, mazanie stopy

Pre prílohy stopy do funkčného blokového diagramu, vykonajte jeden z nasledujúcich krokov:

Kliknite pravým tlačidlom myši na stopu na diagrame a vyberte Predtým vložte "Track". alebo Potom vložte "Track"..
Umiestnite kurzor myši nad roh jednej z stôp. Kliknite na modrú šípku, ktorá sa zobrazí Vložte tvar cesty.
Na karte Funkčná bloková schéma v skupine Vložiť kliknite na tlačidlo Sledovať. Skladba sa pridá za zvolenú skladbu alebo na koniec pásu, ak skladba nie je vybratá.
Zo súboru prvkov Tvary funkčných blokových diagramov potiahnite stopu na požadované miesto na okraji pásu.

Pre pohyby stopy:

Kliknutím na názov skladby, ktorú chcete presunúť, ju zvýraznite. Ukazovateľ myši sa zmení na ikonu presunu.
Potiahnite stopu na požadované miesto.

Figúrky umiestnené na dráhe sa budú pohybovať spolu s ňou. Ak chcete skontrolovať, či je tvar na stope alebo len na nej, vyberte tvar. Ak je figúrka na dráhe, farba dráhy sa zmení na žlto-oranžovú. Ak sa dielik nenachádza na dráhe, ale treba ju tam umiestniť, trochu ním pohnite a dráha ho identifikuje.

Pre odstránenie stopy:

Kliknite na označenie skladby, ktorú chcete odstrániť.
Stlačte kláves na klávesnici.

Poznámka. Odstránením stopy sa odstránia aj všetky tvary, ktoré obsahuje.

Tento článok pokračuje v sérii publikácií venovaných nástrojom, ktoré môžu ruské spoločnosti použiť na riešenie problémov modelovania a zlepšovania obchodných procesov bez významných rizík. Pripomeňme, že predchádzajúci článok tejto série hovoril o produktoch spoločnosti IDS Scheer, ktorá zaujíma najvyššie priečky v hodnotení analytických spoločností. Dnes si povieme niečo o produkte inej cenovej kategórie, nie až tak funkčnom z pohľadu modelovania podnikových procesov, ale veľmi populárnom a rozšírenom – Microsoft Visio.

A opäť názor analytikov...

Nízke náklady spoločnosti Visio spolu s faktormi, ako je napríklad členstvo v poprednej rodine kancelárskych produktov od lídra v softvérovom priemysle, viedli k jej veľmi významnému podielu na trhu s nástrojmi na modelovanie obchodných procesov (34 % podľa Gartner) a vysokým hodnoteniam v správach analytikov. . Analytická spoločnosť Gartner teda tento produkt zaraďuje medzi lídrov na trhu (obr. 1).

Ryža. 1. Poprední výrobcovia nástrojov analýzy podnikových procesov
(zdroj: Blechar M. Magic Quadrant for Business Process Analysis Tools,
2H07-1H08 - Výskumná poznámka spoločnosti Gartner G00161090, 23. septembra 2008)

Podľa Gartnera je Visio jedným z najlepších nástrojov pre tie spoločnosti, ktoré len začínajú modelovať a analyzovať svoje obchodné procesy a zameriavajú sa predovšetkým na ich vizualizáciu. V procese rozvoja tejto oblasti vo firme však býva tento produkt nahradený funkčnejším nástrojom.

Visio na ruskom trhu

Na ruskom trhu je Visio prezentované rovnakým spôsobom ako ostatné kancelárske produkty spoločnosti Microsoft, to znamená, že je dostupné vo všetkých regiónoch prostredníctvom veľmi rozvinutej partnerskej siete. Prostredníctvom nej sa poskytujú podporné služby, technická podpora a školenia v ruštine. Ruská verzia tohto nástroja existuje už pomerne dlho. Existujú knihy o produkte a riešeniach na ňom založených (vrátane nástrojov na modelovanie obchodných procesov; tieto nástroje sú však predmetom samostatnej diskusie, pretože ich dostupnosť, možnosti a ceny sa výrazne líšia od dostupnosti, možností a cien pôvodného produktu ).

Vlastnosti produktu

Technické vlastnosti. Úložisko dát

V prípade potreby je možné sadu symbolov dodaných s produktom rozšíriť o symboly vytvorené používateľmi. Neexistujú žiadne globálne obmedzenia týkajúce sa pravidiel a možnosti vytvárať spojenia medzi určitými typmi symbolov v produkte, má však mechanizmus pre takzvané šablóny diagramov, ktorých použitie umožňuje obmedziť množinu priamo dostupných symbolov. na príslušnom paneli nástrojov počas procesu modelovania. Šablóny môžu vytvárať používatelia a produkt je dodávaný so sadou hotových šablón (obr. 2).

Ryža. 2. Šablóny diagramov zahrnuté v programe Visio

Podporované metodológie a notácie

Pokiaľ je možné množinu symbolov a šablón Visia ľubovoľne rozširovať a samotný produkt neznamená globálne obmedzenia možností používania symbolov a prepojení medzi nimi, popis obchodných procesov pomocou Visia možno formálne vykonávať v rámci takmer akúkoľvek metodiku. Zároveň produktový balík v ľubovoľnej edícii (Standard, Professional) obsahuje sadu vzorových šablón pre najbežnejšie zápisy, ako sú diagramy toku dát, pridané diagramy reťazca kvality, Event-driven Process Chain, IDEF0, diagramy typu SwimLane , ako aj šablóny na modelovanie organizačných štruktúr podnikov (obr. 3 a 4).

Ryža. 3. Procesný model Swim Lane

Ryža. 4. Model typu EPC (Event-driven Process Chain).

Dokumentácia procesov a vytváranie riešení založených na Visio

Microsoft Visio obsahuje prostredie na vykonávanie kódu Visual Basic for Applications, ktoré vám umožňuje písať kód počas práce používateľa a vytvárať ho pomocou vývojového prostredia (obrázok 5).

Ryža. 5. Vývojové prostredie VBA v programe Microsoft Visio

Na prístup k údajom modelu poskytuje Visio zodpovedajúci objektový model, ktorý je dostupný prostredníctvom rozhraní COM z runtime kódu VBA v rámci samotnej aplikácie, ako aj z externých aplikácií. Všimnite si, že programovací jazyk aj objektové modely všetkých aplikácií balíka Microsoft Office vrátane Visia sú dobre zdokumentované. To znamená, že s určitou zručnosťou programovania VBA môže používateľ vytvárať zostavy akejkoľvek zložitosti, vytvárať nástroje na prenos údajov medzi Visiom a inými modelovacími nástrojmi, vytvárať modely vytváraním riešení založených na aplikáciách tejto rodiny a rozširovať funkčnosť modelovania. samotný nástroj a vytváranie rôznych riešení (napríklad pre simulačné modelovanie, automatizované publikovanie modelov na internete a iné úlohy).

Okrem VBA môžete použiť integračné nástroje Visia s aplikáciami Microsoft Office na dokumentovanie procesov, ako je vkladanie diagramov Office Visio 2007 do dokumentov Microsoft Office ako ilustrácie a vytváranie diagramov Visia 2007 priamo v týchto aplikáciách, nástroje na vytváranie kalendárov vo Visiu 2007 pomocou Údaje aplikácie Office Outlook 2007, nástroje na prepojenie grafov z programu Visio 2007 s tabuľkami programu Excel 2007 alebo databázami programu Access 2007 na integráciu zdrojov údajov a komponentov grafov, nástroje na generovanie grafov a Ganttových diagramov v programe Visio 2007 importovaním relevantných údajov z programu Project 2007, nástroje na export informácií obsah Ganttových diagramov a grafov Visio 2007 v Office Project 2007, nástroj na vytváranie organizačných diagramov založený na globálnom adresári Exchange.

Ďalšími zaujímavými funkciami pre dokumentovanie procesov sú možnosť ukladať prácu ako webové stránky, ktorú poskytuje najnovšia verzia Visia, ako aj možnosť dynamicky vymieňať procesné dáta s inými aplikáciami pomocou štandardizovaných výmenných formátov založených na XML, ako sú ODX a BPEL.

Obmedzenia a možné problémy

Fráza „v rámci takmer akejkoľvek metodológie“ použitá v jednej z predchádzajúcich častí článku neznamená, že Visio je najlepším nástrojom na modelovanie a analýzu obchodných procesov. Na rozdiel od rodiny produktov ARIS teda Visio explicitne nerieši problém „čo je ten istý objekt“ – pravidlá, podľa ktorých sa rozhoduje, či dva symboly na rovnakom modeli predstavujú ten istý objekt, musia používatelia vyvinúť nezávisle a nezávisle ho dodržiavať, pričom produkt neposkytuje technické prostriedky podporujúce vyvinuté pravidlo – budú musieť byť vytvorené nezávisle pomocou existujúcich softvérových rozhraní.

Navyše, akonáhle počet modelov podnikových procesov potrebných na riešenie podnikových problémov presiahne tucet a existuje niekoľko autorov modelov, otázka obmedzenia prístupu autorov modelov k údajom sa stáva veľmi aktuálnou. Takéto rozlíšenie môžete implementovať pri používaní Visia pomocou nástrojov na riadenie prístupu k súborom, ktoré poskytuje operačný systém príslušného súborového servera, alebo pomocou systému správy dokumentov, ako je EMC Documentum. Prostriedkami na kontrolu prístupu k modelom sú v tomto prípade prostriedky na správu operačného systému alebo systému správy dokumentov, čo znamená, že úlohy obmedzenia prístupu k modelom sú v skutočnosti zverené správcovi systému.

Visio tiež neposkytuje mechanizmus pre metodologické filtre (nástroje na obmedzenie typov modelov, objektov, vzťahov dostupných pre konkrétneho používateľa alebo skupinu používateľov pre konkrétny projekt), podobne ako sú dostupné v množstve iných nástrojov (napr. , v produktoch rodiny ARIS).

Čo sa týka prostriedkov na udržanie integrity a konzistencie dát, ani v produkte nie sú zahrnuté žiadne hotové mechanizmy, ale môžete si ich vytvoriť sami pomocou vyššie uvedených softvérových rozhraní. Vývoj funkcionality, ktorá v produkte chýba, je však nákladom navyše a nie je pravda, že používanie Visia v takýchto podmienkach bude ekonomicky opodstatnené.

Porovnanie s inými produktmi

Skúsme porovnať Visio s inými modelovacími nástrojmi.

Hlavnou výhodou Visia oproti produktom spomínaných rodín je nízka cena a jednoduchosť použitia, čo z neho robí dobrý štartovací nástroj pre firmy, ktoré ešte len začali popisovať svoje biznis procesy a stále sa zaujímajú hlavne o ich vizuálnu reprezentáciu. Ďalšou výhodou tohto produktu je dokonalá integrácia s ostatnými aplikáciami Microsoft Office – kancelársky balík, ktorý je nepochybne lídrom na trhu. Dôležitou výhodou tohto produktu sú dobre zdokumentované softvérové rozhrania – vďaka nim bolo vytvorených mnoho riešení založených na Visio, vrátane drahších nástrojov na modelovanie a analýzu obchodných procesov vyvinutých partnerskými spoločnosťami Microsoftu.

Nevýhody Visia ako nástroja na modelovanie obchodných procesov sú v skutočnosti pokračovaním jeho výhod. Jednoduché použitie má za následok nedostatok funkcií, ktoré sa od takýchto nástrojov zvyčajne očakávajú, napríklad nedostatok nástrojov na obmedzenie prístupu k údajom, analýzu a kontrolu správnosti modelov, zachovanie integrity a konzistencie údajov. To znamená, že keď sa rozhodnete používať Visio vo fáze formovania procesného riadenia a analýzy obchodných procesov, v budúcnosti budete pravdepodobne musieť venovať pozornosť iným, funkčnejším modelovacím nástrojom, napríklad produktom od IDS Scheer.

V našej diskusii o nástrojoch modelovania obchodných procesov budeme pokračovať v ďalších článkoch tejto série.