Notace ARIS EPC používaná k modelování obchodních procesů v sadě nástrojů ARIS je posloupnost událostí a funkcí, které odrážejí logiku provádění vzájemně souvisejících akcí zaměřených na dosažení určitého výsledku.

Model ARIS EPC je určen k popisu algoritmu provádění obchodních procesů jako sekvence funkcí řízených událostmi. Model ARIS EPC se zaměřuje na posloupnost provádění funkcí ak popisu podmínek v modelu obchodních procesů se používají události a pravidla, která mohou popsat složité algoritmy provádění obchodních procesů.

Funkce v modelu ARIS EPC jsou spouštěny událostmi, jako je "Faktura přijata ke schválení", a ukončeny událostmi, jako je "Faktura schválena" nebo "Faktura neschválena". Pokud v důsledku provedení funkce existuje pouze jedna možnost dalšího provádění obchodního procesu, tzn. v důsledku toho se vygeneruje pouze jedna událost, po které následuje další funkce, událost mezi těmito funkcemi se nemusí vykreslit.

Model obchodních procesů v notaci ARIS EPC nutně začíná a končí jednou nebo více událostmi nebo rozhraními k jiným modelům obchodních procesů. Pro zobrazení rozhraní se používají speciální objekty "Procesní rozhraní" - typ objektu je "Funkce".

Při vytváření ARIS EPC modelu mohou nastat situace, kdy stejný dokument je odchozí pro jednu funkci a příchozí pro další. V těchto případech je pro zlepšení ergonomie modelu přijatelné použít jednu reprezentaci dokumentu s jedním příchozím odkazem (z funkce, ve které je vytvořen nebo opraven) a jedním odchozím odkazem (na funkci, ve které je použit) .

Model EPC nelze odpojit, tzn. umístění na modelu, jeden objekt, který nesouvisí se zbytkem, je chyba.

Uspořádání dokumentů ve vztahu k funkcím je obvykle následující, vlevo nahoře - příchozí dokumenty, vlevo dole - odchozí dokumenty, účinkující jsou zpravidla umístěni vpravo od funkce.

Na modelu ARIS EPC jsou uvedeny následující informace:

• provedené funkce
• funkční informační zdroje (příchozí/odchozí dokumenty)
• Události
• procesní rozhraní
• logické operátory
• účinkující (pozice, obchodní role)
• Informační systémy

Pravidla pro pojmenování událostí v ARIS EPC

Název události (Událost) musí obsahovat podstatné jméno a popis změny stavu ve tvaru slovesa. Příklad: "Obchod uzavřen".

Pravidla pro pojmenování funkcí v ARIS EPC

Chcete-li pojmenovat funkci (Function), musíte použít její skutečný název. Název se musí skládat ze dvou částí – slovesného podstatného jména, které popisuje funkci, kterou má vykonávat, a podstatného jména, které zobrazuje objekt, na kterém se vykonává. Název funkce se skládá z krátkého názvu objektu začínajícího velkým písmenem, např. „Vyhledat kontakty na zákazníky“.

Pravidla pro pojmenování rolí/pozic v ARIS EPC

Název obchodní role (Person Type) musí odpovídat podstatě povinností přidělených vykonavateli. Název zpravidla obsahuje frázi „Zodpovědný za ...“. Pracovní pozice (Pozice) se píší v souladu s tabulkou obsazení.

Konvence pojmenovávání dokumentů

Objekt odpovídá dokumentu (Information Carrier) (v papírové a/nebo elektronické podobě). Chcete-li dokumenty pojmenovat (bez ohledu na použitý symbol), musíte použít jejich skutečné jméno.

Pravidla pojmenování pro informační systémy v ARIS EPC

Pro názvy informačních systémů (typ aplikačního systému) by měly být použity jejich zavedené názvy.

Pravidla pro pojmenování rozhraní procesu

Rozhraní (rozhraní procesu) zobrazuje odkaz na sousední proces. Název procesního rozhraní odpovídá názvu modelu, který popisuje přilehlou část obchodního procesu. Rozhraní lze použít k odkazování na modely obchodních procesů, které nejsou součástí popsaného obchodního procesu.

Každá věc je formou projevu nekonečné rozmanitosti.

Kozma Prutkov

Úvod do notace eEPC

V současné době existuje mnoho různých principů grafického znázornění obchodních procesů, nazývaných notace. Proč je jich mnoho? Tuto otázku si po desetiletí klade každý, kdo stojí před potřebou popsat podnikové procesy. Podívejme se na důvody. Jsou tři (podle mého názoru):

• -Různé úkoly. Ne všechny zápisy jsou stejně vhodné pro řešení různých problémů. Například zápis může být vhodný pro obchodní proces nejvyšší úrovně a vůbec ne vhodný pro popis pracovního postupu.

Různí vývojáři takových notací. V různých dobách se různí vývojáři snažili přijít s novými principy pro popis obvodů. Udělali to z dobrého úmyslu, když se v praxi setkali se situací, kdy jimi použitý zápis nemohl odrážet potřebné jemnosti (nebo ne zcela jasně). Někdy se v procesu evoluce takové zápisy staly jakoby paralelními, tzn. vypadat jinak, ale řešit stejné úkoly.

Touha vyniknout. Tehdy se z neznámých důvodů náhle objeví nový zápis, který sám o sobě nevyniká ničím, ale z nějakého důvodu je svým tvůrcem propagován jako nejdokonalejší know-how. To se stále děje.

Účelem tohoto článku není zvažovat všechny druhy zápisů (záměrně je nejmenuji), ale pozastavit se nad podrobným popisem zápisu, který jsem pro své projekty zvolil v procesu dlouhého hledání nejoptimálnější možnosti. .

Pokud by někoho zajímalo, co jsou další zápisy a k čemu slouží, plánuji to udělat v dalším článku, který se bude jmenovat "Pojďme si povídat o zápisech", ale to je zatím v plánu.

Je čas začít náš příběh o velmi zajímavém, jednoduchém a praktickém zápisu eEPC (v překladu: rozšířený popis řetězce událostí procesů). V jeho doslovném překladu je také odhalen hlavní účel: popis řetězce obchodních procesů. Hlavní „trik“ notace je v jejím principu „události“, kterou se budeme podrobně zabývat.

Jaké jsou výhody zápisu eEPC:

1. Za prvé, toto není úplně čistý zápis. Tito. pokud v některých zápisech existuje rigidní soubor prvků a pravidel pro jejich použití (jinak se vše zamotá), pak vám princip eEPC umožňuje přidávat vlastní prvky. Jak se poskytuje? Samozřejmě existuje určité "jádro", kolem kterého je vše postaveno, tzn. soubor jasných pravidel, podle kterých se schéma buduje a podle kterých se pak čte. Navíc můžete přidat vlastní prvek, zahrnout pravidla pro jeho použití do vlastního podnikového standardu (vyloučit amatérskou činnost, která může schéma zmást a zkomplikovat jeho čitelnost) a je to! To je velmi důležitý bod. Kromě toho si ve svém podnikovém standardu můžete nastavit jakákoli další omezení a pravidla.
2. eEPC obsahuje prvky logiky. To vám umožňuje vytvářet schémata s podmínkami, které jsou nezbytné k popisu činnosti („pokud je smlouva dohodnuta, pak ...., jinak ...“).
3. Jednoduchost prvků umožňuje kreslit schémata jak v softwarových produktech, tak i jakýmkoli jiným způsobem, a to i na papíře, nespletete se.
4. eEPC je tak snadné se naučit a pochopit, že jej lze použít v reálném životě, nejen na sezení prachu ve skříni. Naučit se pravidla zabere asi 2 hodiny (pokud si to student přeje).

Samozřejmě, jako všechno na tomto světě, má své nevýhody. Ale racionální používání je snižuje na minimum. Hlavní nevýhodou je podle mě fakt, že pokud používáme jednoduché nástroje (tedy programy pro kreslení diagramů, a ne pro modelování podnikových procesů), tak nemáme jedinou databázi objektů. Navíc je obtížné ovládat vstupy a výstupy (je nutné je ovládat, tedy případně vymyslet způsob takového ovládání). Ale na druhou stranu použití komplexních nástrojů pro modelování podnikových procesů stojí docela působivé částky a projekt s jejich využitím se měří v milionech. A tak máme velmi ekonomický a srozumitelný nástroj. Přesněji řečeno, tento nedostatek se týká konkrétně způsobu popisu, který uvažuji, tzn. pomocí MS Visio nebo podobného softwaru. Pokud používáte specializované systémy pro popis obchodních procesů, které podporují objektové databáze, lze se této nevýhodě vyhnout. No, je čas začít...

Hlavní „jádro“ notace eEPC

Jak jsem již zmínil, v doslovném překladu zkratky eEPC se skrývá pojem eventfulness. To je velmi důležitý bod, na kterém je postaven celý princip konstrukce obvodu. Existují tedy dva klíčové pojmy: „Událost“ a „Funkce“. Když se někdo poprvé pokouší nakreslit svůj proces ve formě eEPC diagramu, často vyvstává otázka, jaký je rozdíl mezi událostí a funkcí? To musí být jasně pochopeno, jinak získáte nepředvídatelný výsledek. Takže: událost je fakt, že se něčeho dosáhlo, a nemá trvání v čase, nebo tento čas má tendenci k nule (nebo na tom nezáleží). Navíc událost vždy způsobí potřebu provést funkci a provedení funkce vždy skončí událostí. Dovolte mi to vysvětlit na příkladu. Zvoní telefon. Manažer zvedl telefon. V tomto případě je „Telefon zvoní“ událostí. Telefonní rozhovor je funkce. Konverzace je ukončena (zavěšeno) - opět událost. Je tedy sledován řetězec událostí: Hovor - konverzace - konec hovoru. A konec hovoru bude s největší pravděpodobností vyžadovat provedení nové funkce: záznam výsledku hovoru atd.

Zkusme to nakreslit. Nejprve musíte zjistit, jak se zobrazují prvky „Událost“ a „Funkce“.

Tyto dva jednoduché prvky tvoří základ pravidel pro popis obchodních procesů v notaci eEPC. Myslím, že musím říct pár slov o použitých barvách. Pokud jste se setkali s popisem procesů v jiných zápisech, zpravidla byly černobílé. A to je správně, neměla by existovat výslovná závislost obsahu na barvě, protože diagram lze nakreslit tužkou na papír, vytisknout na černobílé tiskárně atd. V tomto případě (v eEPC nation) se historicky vyvinulo, že prvky mají určité barvy. Neříkám, že to bylo nutné, ale návyk se vyvíjí a vnímání v elektronické podobě je lepší – hned vidíte, co je co. Tyto barvy lze považovat za doporučení. Proč jsou takoví? Nejsem si přesně jistý, ale zdá se mi, že ARIS, když ve svém produktu udělal podporu pro zápis eEPC, dal jim takové barvy, "zakořenily". Mimochodem, někdy se tento zápis nazývá také "ARIS", "ARIS EPC", což není úplně správné, protože ARIS tuto notaci nevynalezl, ale podpořil ji ve svém programu pro modelování obchodních procesů. Obecně doporučuji používat barvy. Hlavní věc je, že samotná forma prvků by neměla být stejná (tj. lišit se pouze barvou), protože v černé a bílé to může být matoucí. Existují i ​​další pravidla, která umožňují dát diagramu eEPC „štíhlost“, budeme o nich mluvit.

Takže existuje událost, existuje funkce. jak spolu souvisí?

Vidíme, že událost1 vedla k nutnosti provést určitou funkci, která skončila událostí2. Pokud se použije na příklad s telefonním hovorem, bude to vypadat takto:

Odkaz událost - funkce - událost se obvykle zobrazuje shora dolů v jednom řádku nebo zleva doprava. Směr řetězu je vyznačen spojovacími čarami se šipkami. Aby bylo schéma vizuálnější, obsahuje zápis několik dalších standardních prvků:

• Pozice (umělec). Ten, kdo tuto funkci vykonává
• Informace. Jakákoli informace použitá k provedení jiné funkce než dokumentární informace. Například telefonní hovor, pokyny k provedení operace atd.
• Dokument. Prvek "Dokument" je určen k zobrazení informačních médií (papírových nebo elektronických). Tito. prezentace informací v určité struktuře.
• Program (aplikace). Software použitý k provedení funkce.

Všechny ostatní prvky jsou pomocné a prakticky nejsou regulovány požadavky samotného eEPC. Neexistují však žádné překážky pro přidávání vlastních prvků. Hlavní je to opravit v interní normě, aby bylo společné chápání toho, jak vypadají a proč se používají. Takové rozšíření neporušuje požadavky, pokud není porušeno spojení událost-funkce-událost, a má pouze zlepšit vnímání informací nebo přizpůsobit pravidla popisu některým oborovým specifikům. Přidal jsem vlastní sadu prvků, o kterých pojednám níže.

Stále musíte zjistit, jak by měly být uvažované prvky umístěny. Všechny tyto prvky musí nějak souviset s funkcí. Je obecným pravidlem, že s událostí není spojen žádný jiný prvek než funkce. Tito. všechny tyto prvky musí být spojeny šipkami s funkcí. Pokud jde o šipky a jejich směry: obecně se uznává, že pokud neexistuje žádný směr pro přenos informací, zobrazí se místo šipky pouze čára. Pokud informace vstoupí (vstoupí na vstup), tak směr šipky je od objektu k funkci, pokud vystoupí, tak naopak.

Ještě pár slov o umístění těchto prvků na diagramu a můžeme překreslit náš diagram, specifikující provedení funkce zpracování volání. Neexistují žádné striktní požadavky na uspořádání prvků, ale je zvykem je zobrazovat ve všech schématech stejně (pro jednotnost a harmonii schématu). Pro sjednocení vnějšího pohledu na grafická schémata podnikových procesů je nutné taková pravidla zafixovat v interní normě a dodržovat je. O něco později k tomu dám několik doporučení. Nyní překreslíme náš diagram:

Vidíme, že operátor zpracovává příchozí hovor, jedná v souladu s pravidly pro zpracování příchozích hovorů a používá k tomu CRM program. Nejsou používány příchozí ani odchozí dokumenty.

Jak jsem již zmínil, jednou ze silných stránek zápisu jsou prvky logiky. Zároveň je to jeden z nejtěžších okamžiků na pochopení. Proto nejprve uvedu příklad a poté se budeme samostatně zabývat prvky logiky.

Náš příklad budiž takový: má-li klient zájem, obchodní manažer s ním dále spolupracuje a podá obchodní nabídku, kterou zašle poštou pomocí poštovního klienta MS Outlook. Pokud není zájem, je zpracování hovoru dokončeno. V reálném životě by bylo hezké používat pravidla ukončení hovorů, ale tohle jsem mimochodem já, když to zjednodušíme. Co se stane:

Prvky logiky ve schématech zápisu eEPC

Prvky logiky jsou jednoduché, ale existují určité zvláštnosti a pravidla, aby schéma bylo logické a jednoznačně interpretovatelné. Nejdůležitější pravidlo, které je třeba dodržovat na 100%: logická rozhodnutí lze činit pouze tehdy, když je funkce vykonávána. Tito. po nějaké události nemůže dojít k rozvětvení. Proč? Protože v tomto případě odporuje samotnému konceptu události – je jednoduchá a okamžitá, bez času provedení. Pokud například zazvonil telefon a člověk sedí a přemýšlí, zda telefon zvednout nebo ne, teoreticky to již bude funkce, kde se rozhodne. Ale v praxi, včetně zdravého rozumu, porušuje pravidla pro zpracování hovorů, tk. za zpracování těchto hovorů je mu vyplácen plat a zde není o čem polemizovat (obecně, jak je znázorněno na diagramu).

Celkem se rozlišují 3 prvky logiky:

• I. Když se dějí dvě nebo více událostí současně;
• NEBO. Kdy může nastat jedna nebo více událostí, ale musí nastat alespoň jedna;
• EXKLUZIVNÍ NEBO. Buď jedno nebo druhé. Tito. dvě možnosti současně nejsou možné.

Jak vidíte, existují dvě možnosti grafického znázornění logických prvků. Nejsou jiní, úplně jiní. Přinesl jsem je oba, protože. V praxi lze obě možnosti vidět v různých zdrojích. Který z nich použijete, je na vás. Ten první se mi líbí víc.

Nyní se musíme vypořádat s použitím logických prvků. Nejprve se podíváme na možnosti, se kterými se setkáváme, a poté přejdeme k příkladu. Pojďme analyzovat každý prvek zvlášť.

Logický prvek "AND". Když funkce vyžaduje spuštění více událostí současně:

Příklad: Pokud je vykazovací období uzavřeno (událost 1) a nadešel termín pro podání hlášení vedoucímu (událost 2), zaměstnanec vypracuje měsíční hlášení.

Spojení prvků, pokud během provádění funkce dojde k několika událostem:

Příklad: Byla dokončena nějaká práce se zákazníkem. Současně byly zaznamenány dvě události: došlo k odsouhlasení vzájemných vyrovnání (událost 1), k podpisu zákona (událost 2). V praxi se to používá zřídka. Zpravidla, pokud je mnoho akcí kombinováno v jedné funkci

Spojení prvků, pokud během provádění několika funkcí dojde k události:

Příklad: Skladník vyzvedl objednávku (funkce 1), operátor vypsal doklady (funkce 2), zboží je připraveno k expedici (událost).

Spojení prvků, pokud výskyt jedné události vede k provedení několika funkcí:

Příklad: Došla zásilka zboží (událost). Současně začíná expedice zboží dříve objednaného zákazníky a umístění zbývajícího zboží na sklad.

Logický prvek "OR".

Spojení prvků, pokud jedna z událostí může způsobit provedení funkce:

Příklad: Žádost přijatá telefonicky (událost 1) nebo žádost doručená e-mailem (událost 2) bude mít za následek nutnost jejího zpracování.

Spojení prvků, pokud jedna funkce může spustit alespoň jednu událost:

Příklad: Faktura byla připravena a odeslána k odeslání zákazníkovi. Faktura může být zaslána poštou (událost 1), faxem (událost 2).

Logický prvek "EXCLUSIVE OR".

Spojení prvků, když je k provedení funkce potřeba pouze jedna z událostí:

Příklad: Zákazník přišel osobně do prodejny (událost 1) nebo provedl objednávku přes internet (událost 2). Zboží je potřeba odeslat (funkce 1).

Spojení prvků, pokud v důsledku provedení funkce dojde alespoň k jedné z následujících událostí:

Příklad: Rozhodnutí je buď učiněno, nebo ne.

Spojení prvků, pokud k události dojde po provedení jedné a pouze jedné z funkcí.

Příklad: Zboží bylo dodáno (událost 1) buď vlastní dopravou (funkce 1) nebo přepravní společností (funkce 2)

Správná aplikace logických prvků vyžaduje určitou praxi. Ale není to nic těžkého. Je třeba poznamenat, že ne všechny uvažované kombinace jsou v praxi široce používány (obecně je to dáno způsobem myšlení analytika). Pokuste se aplikovat prvky logiky v praxi. Pokud budou potíže, napište mi, pokusím se pomoci.

Rozšíření notace o vlastní prvky

Jak jsem řekl, eEPC není přesně zápis, ale pravidla popisu. A tato pravidla nezakazují přidávání vlastních prvků do schématu. Hlavní věc je, že tyto prvky jsou srozumitelné a existuje dokument, kde jsou taková rozšíření prvků opravena. Využívám například následující doplňkové prvky, které vznikly postupně v procesu popisu reálných procesů pro různé úlohy, od jednoduchého popisu až po nastavení úloh pro automatizaci.

Datový soubor. Používá se, když je datový soubor vytvořen jako výsledek operace nebo je soubor použit k provedení operace.

Databáze. Používá se k popisu informačních toků mezi automatizovanými systémy.

Kartotéka. Slouží k zobrazení papírové kartotéky nebo archivu.

oběh materiálu. Používá se k označení příchozích a odchozích materiálových toků a také zdrojů spotřebovaných během provádění procesu. Materiálový tok se zobrazuje vlevo od průvodních dokumentů.

informační shluk. Používá se k označení strukturovaných informací (reprezentace entit). Diagram lze použít k odkazování na dokumenty generované programově pomocí vlastních aplikací. V tomto případě je prvek "Cluster" umístěn vlevo od odpovídajícího dokumentu. Tito. označuje, že uživatel nejen vytvořil papírový dokument, ale také vytvořil jeho instanci v programu.

Konvence o pravidlech pro umísťování obrazců do diagramu

Samotný zápis eEPC neklade striktní požadavky na uspořádání prvků vůči sobě, i když je zvykem kreslit diagram shora dolů nebo zleva doprava. Pokud to není sjednoceno v případě práce několika specialistů, může se ukázat jako „vinaigrette“. Abyste tomu zabránili, doporučuje se vyvinout a schválit vlastní pravidla pro uspořádání prvků. Dodržuji (a doporučuji) následující pravidla:

• Posloupnost událostí a funkcí je uspořádána shora dolů (lépe) nebo zleva doprava (pokud není dostatek místa);
• Prvky označující účinkující jsou umístěny napravo od funkcí;
• Příchozí dokumenty v levé horní části funkcí; směr šipky od dokumentů k funkci;
• Odchozí dokumenty v levé dolní části funkcí; směr šipky od funkce k dokumentům;
• Prvek "Informace" se nachází v pravé dolní části funkce. Při nedostatku místa je povoleno libovolné uspořádání, co nejblíže funkci;
• Prvek "Aplikace" se nachází v pravé horní části funkcí. (pokud se k tomu používají souborová úložiště, která nejsou sestavami, zobrazují se podobně). Komunikace bez šipky.
• Prvky "Databáze" a "Soubor karty" jsou umístěny libovolně;
• Prvek "Tok materiálu" je umístěn vlevo od doprovodných dokumentů s odkazem na dokument čárou bez šipky;
• Prvek "Cluster", je-li použit v kombinaci s postavou "Dokument" k označení dokumentu v elektronické podobě, je umístěn vlevo od odpovídajícího dokumentu.

Například: Mzdová kalkulačka vypočítá mzdy na základě dokumentů „Brigádní oblečení“, které mu byly poskytnuty. Zároveň se řídí dokumentem „Předpisy o mzdách“, výpočet se provádí v programu „1C: ZiK“. Výsledkem výpočtu je dokument "Vedomosti".

Identifikace prvků v diagramu

Jak víte, kompetentní přístup k popisu podnikových procesů zahrnuje jejich identifikaci, tzn. kdy každý proces má své vlastní kódové jméno. Podle toho mají jednotlivé funkce v rámci procesu také svá vlastní jména a identifikátory.

Obrázky "Dokument" a "Funkce" podléhají povinné identifikaci ve schématu.

Dokument se identifikuje uvedením kódu hlášení nebo dokladu v levém horním rohu podle rejstříku. Doklady přijaté od dodavatelů zboží a služeb (příchozí) jsou identifikovány pouze jménem.

Funkce je identifikována uvedením pořadového čísla funkce pro danou skupinu procesů. Tito. číslo funkce vždy začíná kódem procesní skupiny. Problematika identifikace procesních skupin přesahuje rámec tohoto článku, budeme je zvažovat samostatně. Kromě toho byste se měli naučit, jak identifikovat procesy, než je začnete popisovat, jinak může být touha popsat všechny činnosti společnosti v jednom diagramu, jak se to někdy snaží dělat.

Proto nyní ukážu pouze na příkladu, jak to lze znázornit v diagramu. Vraťme se k příkladu zpracování hovorů. Předpokládejme, že jsme obchodnímu oddělení přiřadili kód „04“, procesu zpracování příchozího kontaktu kód „VK“. Poté bude mít schéma následující podobu (identifikace je pro přehlednost zvýrazněna červeně). Kód dokladu zároveň udává pořadové číslo dokladu v obecné evidenci dokladů (i tomu se budeme věnovat samostatně, až se dostaneme k přehledu systému správy dokumentů).

Zobrazení zpětné vazby

Při sestavování modelů se často stává nutností cyklicky procházet procesem podle nějaké podmínky nebo potřeby zobrazovat aktivity osob s rozhodovací pravomocí. V tomto případě mluvíme o zpětné vazbě. Pro zobrazení zpětné vazby řízení se používá princip „přímého zařazení“ do procesu doplňkové regulační funkce s následným větvením (pomocí logického prvku XOR). Například:

Textový popis procesů

Bez ohledu na to, jak moc se snažíme zobrazit obchodní proces na diagramu, nebude možné dosáhnout úplných detailů, jinak můžete uvíznout v nekonečných řetězcích prvků a podmínek. Aby k tomu nedocházelo, stejně jako k přidání informací k popisu procesu, které nelze zobrazit graficky, je popis doplněn o textový doprovod. K tomu jsou vyvinuty různé textové šablony, které se vyplňují během procesu popisu. Formy takových šablon mohou být různé, zahrnují samostatné části popisující vstupy a výstupy, spotřebované zdroje, použitý software atd.

V nejjednodušším případě může šablona popisu obchodního procesu vypadat takto:

Obchodní proces:	Zpracování příchozího kontaktu	04.VK
Procesní funkce:
název	Popis	Číslo na schématu
Obsluha příchozích hovorů	Při příchozím hovoru operátor zpracuje hovor v souladu s pravidly pro zpracování příchozích hovorů. Identifikuje zájem klienta, poskytne informace o službách	04.VK.01
Tvorba obchodní nabídky	V případě zájmu klienta předá operátor kontakt na obchodního manažera. Obchodní manažer zpracuje obchodní nabídku a zašle ji klientovi e-mailem	04.VK.02
Procesní indikátory:
název	Metoda hodnocení/měření
Počet selhání	databázové statistiky

Tak důležitá témata jako shromažďování informací, zdůrazňování obchodních procesů, dekompozice a zvýraznění ukazatelů zůstala mimo rozsah tohoto článku. Určitě se těmto otázkám budeme věnovat v budoucích číslech.

"Čím jasněji jsou informace přenášeny, tím rychleji a přesněji je vnímá ten, komu jsou určeny." Tuto pravdu již dlouho aktivně využívají marketéři, pedagogové a výzkumníci. Stranou nezůstali ani manažeři. Tento článek pojednává o notaci EPC jako o jedné z nejpopulárnějších moderních metod, která vám umožňuje učinit popis složité práce nejen pohodlným, ale také mnohem přesnějším a srozumitelnějším pro všechny účastníky projektu nebo procesu.

Historie vzniku standardů grafického modelování

Nyní, kdy tempo vývoje všech procesů ve společnosti roste a systémy se stávají stále složitějšími, je management, jakožto umění ovlivňování lidí, nucen také získat schopnost systémového řízení, podobně jako řízení inženýrských systémů. Na počátku 90. let minulého století se slovo „ reengineering Michael Hammer a James Champy poprvé představili tuto definici ve své knize Reengineering the Corporation.". A po něm se objevil koncept „inženýrství“ podnikání. Jestliže první je redesign podnikových procesů, pak druhý je návrh efektivního organizačního systému od nuly.

Tento trend naznačuje, že se již dlouhou dobu a poměrně úspěšně hledají metody popisu a dokonce konstrukce organizace jako systému. Považujeme-li management nejen za umění, ale i za vědu, pak jako každá jiná vědní disciplína potřebuje svůj specifický zápis, aby si zafixoval vzorce a zákony. Taková systémová řešení úspěšně využívají inženýři v mnoha oblastech činnosti, chemici, fyzici, matematici atd.

Socioekonomický systém, kterým je organizace, je mnohem rozmanitější než přírodní vědy a dosud nebyla nalezena jediná forma psaní „axiomů“, manažerských vzorců. Ale cesta byla položena. A začíná to známými vývojovými diagramy, které nám umožňují popsat postup k dosažení daného výsledku. Ale bohužel, vizuální možnosti vývojového diagramu jsou velmi omezené a neumožňují zobrazit celou řadu prvků procesu řízení podniku.

K dnešnímu dni existuje poměrně mnoho možností vývojových diagramů, které lze použít k zobrazení interakce lidí a systémů v procesu tvůrčí činnosti. Jsou kombinovány do sad nástrojů, aby mohly úplněji popsat všechny aspekty podniku. Takové nástroje se nazývají metodologie modelování. Nejúplnější a nejznámější jsou tři z nich:

• ARIS (architektura integrovaných informačních systémů);
• SADT (technika strukturované analýzy a návrhu);
• UML (Unified Modeling Language).

(Klikni pro zvětšení)

Pro úplný a komplexní popis činnosti podniku je nutné použít různé grafické standardy, které jsou zakotveny v metodice a nazývají se notace. Ale k vyřešení úzkých problémů stačí vybrat notaci, která byla vynalezena pro odpovídající popis. Výše je vám představen jeden z grafických typů notací, o kterých bude řeč v tomto článku.

Vlastnosti zápisu EPC

Modelovací notace EPC (Event-driven Process Chain) je zaměřena na vytváření interakčních algoritmů v procesu provádění konkrétní úlohy. Jeho hlavní prvky jsou:

• události, které zahajují nebo ukončují práci;
• akce (práce), které převádějí systém z jednoho stavu do druhého;
• vykonavatelé díla;
• zdroje a výsledky práce (vstupy a výstupy).

Tato notace je nedílnou součástí metodologie ARIS, jejímž autorem je Wilhelm-August Scheer, vyvinutá na počátku 90. let. Na konci předchozí části je na obrázku uveden přehled procesu standardizace práce pomocí notace EPC. Zvažte vlastnosti popisu obchodních procesů organizace pomocí tohoto zápisu. I bez ponoření do podstaty schématu střídání červených a zelených prvků okamžitě upoutá pozornost - to je řetězec událostí a procesů, které jsou vlastní názvu notace. Složení prvků modelu je určeno čtyřmi hlavními polohami.

Je pravděpodobné, že v průběhu popisu procesního modelu budeme aplikovat informační systém. Poté jej můžeme zobrazit pomocí speciálních tříúrovňových sad prvků ( oranžová barva).

1. IS - informační systém.
2. modul IS.
3. Funkce IS.

Databáze mají tradičně svůj vlastní obraz – v podobě válce. I když se mi zdá nemožné je dnes používat bez informačního systému a systému bez databáze. Pro zobrazení logiky přechodů mezi funkcemi se používají logické operátory, které pomáhají upřesnit podmínky pro provádění paralelní práce nebo výskyt událostí. Zobrazují možnosti pro sloučení nebo větvení funkcí i událostí. Existují pouze tři logické operátory: "AND", "OR" a "XOR". Různé systémy mohou používat různá grafická označení.

Zápis a použití logických operátorů v zápisu EPC

Algoritmus grafu EPC

Jak vidíme, nepochybnou výhodou tohoto zápisu je intuitivní sada prvků a pravidel pro konstrukci diagramů. Pro tvorbu procesních diagramů se doporučuje používat speciální programy pro procesní modelování. Pro EPC je to především systém ARIS. Je to ale drahé a poměrně komplikované a nepoužívá se pro malé periodické projekty k zefektivnění činnosti oddělení.

Jednoduchost a oblíbenost zápisu podnítila vznik dalších nástrojů pro kreslení podnikových procesů, včetně zápisu EPC. Nejjednodušší z nich je Visio - jedna ze šablon v něm se nazývá „EPC Diagram“. Nejužitečnějším nástrojem je pro mě systém Business Studio. V něm lze kromě možnosti nakreslit proces automaticky generovat dokument (Procesní pravidla) a pracovní pokyny pro jeho účastníky, což značně usnadňuje rutinní část procesu tvorby výkonových standardů.

Barvy a označení sekundárních prvků v různých programech se mohou mírně lišit, ale vždy jsou dodržována obecná pravidla. Příklad zápisu EPC uvedený v první části článku odráží zjednodušený algoritmus pro práci s tímto zápisem. Pojďme si to rozebrat krok za krokem.

Po dokončení všech kroků získáme podrobný plán provedení procesu, srozumitelný jeho umělcům. A jasně označené události a výsledky umožňují nastavit kontrolní body pro všechny významné fáze procesu. A znovu vás odkazuji na příklad vizuálního modelu zveřejněný na začátku článku.

Výhody a nevýhody zápisu EPC

Použití EPC má kromě jednoduchosti a dostupnosti následující výhody.

1. Umožňuje zobrazit všechny významné organizační prvky na jednom diagramu (na rozdíl od jednoduchého vývojového diagramu).
2. Lze jej použít na různých úrovních modelu - k popisu jak globálních procesů, tak k vytvoření detailních instrukcí, protože každý funkční blok se může stát dílčím procesem.
3. Je snadné provést komplexní paralelizaci procesu, protože můžete zadat libovolný počet událostí do jednoho řádku.

Tento zápis se přitom nestal jedním a jen díky následujícím nedostatkům.

1. Potřeba vymýšlet události pro každou i menší akci značně komplikuje schéma.
2. Organizační mezery jsou pravděpodobně způsobeny nepohodlným sledováním úkolů.
3. Kvalitní předepsání vstupů a výstupů vede k přetížení obvodu obdélníky, šipkami, které se začnou protínat a tím dále komplikují vnímání obvodu.
4. Při paralelizaci práce je velmi obtížné reflektovat interprety. Pokud jedna osoba vykonává skupinu funkcí, obrázek se pomocí šipek zkomplikuje. Pokud je více účinkujících nebo nechceme kreslit dlouhé šipky, musíme „ovály“ duplikovat s účinkujícími. To vše může velmi brzy vést k naprostému zmatku na okruhu.

Ze své zkušenosti mohu říci, že místní pracovní postupy nakreslené v tomto zápisu jsou pro vývojáře i uživatele návodu celkem pohodlné. Zápis je vhodný i pro projektové manažery, protože jim umožňuje vizuálně plánovat rozložení práce v projektu v jazyce, který je pro různé účastníky projektu intuitivní. A pro vývoj složitějšího víceúrovňového modelu podniku jsou vhodnější jiné modelovací zápisy, které budeme zvažovat v následujících článcích.

Poznámky pro podnikání

Článek byl publikován v časopise „Management News“ v lednu 2012.

Hudba nás svázala
Stal se naším tajemstvím

Všechny epigrafy k tomuto článku jsou převzaty z písně „Hudba nás spojila“ od skupiny Mirage.

V klasické hudbě je hudebník nástrojem v rukou skladatele a hraje noty. V populární hudbě si hudebníci nejčastěji píší hudbu sami a umění improvizace vůbec nezahrnuje noty. Pravda, slavné improvizace, které se staly klasickými, se pak přenesou do not a ty mají nový život: změní se aranžmá, přidá se nový zvuk a nálada.

Stejně tak podnikání, které vyrostlo jako zručná improvizace, aby se posunulo na novou úroveň, vyžaduje uvedení faktů na papír, aby bylo možné analyzovat, co se děje, a přijímat rozhodnutí pro zlepšení.

V poslední době stále častěji najdete popisy podnikových procesů (BP), jak se říká, "na vlastní pěst". Tato okolnost mě přiměla napsat tento článek. Bohužel většina dokumentů, které byly náhodou spatřeny, byla pro vážnou věc málo užitečná. Nedá se říct, že by se nějak zásadně mýlily, ale řada opomenutí je zkazila natolik, že se na jejich existenci chtělo hned zapomenout. Jaká jsou tato opomenutí a jak se s nimi vypořádat, na to přijdeme v průběhu tohoto článku, postupně se přibližujeme k podstatě problému. Budeme se snažit vyhnout velkému množství technických detailů, ale úplně se jim vyhnout nemůžeme, protože. předmět rozhovoru si to žádá.

Jsem sám sebou
Nemohu najít všechny odpovědi

Tento článek je určen těm, kteří chtějí ušetřit na popisu obchodních procesů tím, že svěří přípravu dokumentu interním specialistům. Ostatně popis obchodních procesů není pro firmu povinná věc a vše funguje i bez něj. Ale v každé stabilní společnosti existuje mechanismus pro přenos pravomocí, říká se tomu „popisy práce“. Pokud je podnikání složité a pozice je klíčová, pak je užitečné nakreslit popisy práce, aby byly srozumitelnější. Kumulace podnikových procesů v obecném popisu je nezbytná pro zpřehlednění obchodu, zejména pro jeho prodej.

Dokument „Popis BP“ se stává obzvláště relevantním, jakmile je potřeba reorganizace (nebo, jak je nyní módní říkat – reengineering) společnosti. V tomto případě se dokument používá k:

1. Na něm, stejně jako na bitevní mapě, označte podstatu plánovaných transformací,
2. Seznamte účastníka s aktuálními transformacemi,
3. S perem a ne na prstech dejte úkol vedoucím oddělení a externím specialistům.

Vlastní příprava dokumentu má výhody:

• Vyjde to levněji;
• Interní specialista, který se lépe orientuje v postupech svého rodného podnikání.

Konzultant třetí strany bude muset nejprve prostudovat terminologii a klíčové vlastnosti předmětu, průmyslové standardy. To chce čas. Pravda, ví lépe, jak a co popsat. Existují určitá pravidla, obecně uznávané notace a speciální software. Příklad takového zápisu je vidět na Obr. 1 a Obr. 2.

Zápis IDEF0

Obr. 1.

Příklad popisu BP pomocí IDEF0

Obr.2.

Nepoučujte nás

Nepoučuj mě
Mami, je to zbytečné

Je tohle to, co potřebujeme? - Ředitel se zeptá, rozumně předpokládá, že dodržení všech norem výrazně prodraží výsledek. Jeden z ředitelů, které jsem znal, uvažoval takto: „Pozvat externího specialistu je drahá záležitost, ale naše úkoly jsou jednoduché – proč potřebujeme všechny tyto zápisy. A to je to, co musíte zaplatit.“

Souhlasím, pokud jsou úkoly jednoduché, proč oplotit zahradu. A pokud jsou složité, pak je nutné zjednodušovat a nekomplikovat nóbl notaci. Koneckonců, neexistují žádné zjevné výhody z použití krásných háčků. Pokud neexistují žádné zjevné, neznamená to, že žádné nejsou. Tato pravidla a zápisy nejsou vymyšleny proto, aby se poradce nenudil... Kdo podniká, moc dobře ví, že ne všechno užitečné je samozřejmé. Nuže, hledejme skryté pozitivum a za tím se podíváme do historie vydání.

Trh s popisy PSU existuje již velmi dlouho. Během poslední dekády a půl však udělal rychlý průlom, a to díky vzniku nového odvětví – automatizace účetnictví a řízení v podnicích. Rostoucí trh dal šanci nováčkům, kteří přišli s novými notacemi, aby prorazili a obsadili své místo. Například na ruském trhu v posledních letech masivní reklamní a informační kampaně IDS Scheer (hlavního dodavatele ARIS - viz obr. 3) vytvořily vrstvu specialistů na popisy automatizovaných procesů.

Použití notace ARIS vyžaduje velké množství detailů v obchodních procesech.

Obr.3.

Zavedení třídních systémů ERP (řízení zdrojů), CRM (vztahy se zákazníky), MRP (plánování výroby) nevyhnutelně vede ke změně procesů, a pokud to není předem naplánováno, může být výsledek horší, než byste chtěli. Automatizace je navíc práce s informacemi, což znamená, že je užitečné vědět, jaké informace kdo generuje, odkud a kam směřují. Ale speciální zápisy pro zavedení automatizace se u nás neujaly a používají se jen zřídka.

Popis obchodních procesů v Rusku je relativně nedávným trendem, navzdory působivému počtu GOST v této oblasti (3.1109, 34, ISO atd.). Nyní, s kvalitou popisu jejich vlastních obchodních procesů, to jde nejlépe v bankách. Faktem je, že na rozdíl od jiných komerčních struktur je banka infrastrukturní organizací, a proto se nachází v přísném rámci regulací definovaných zákonem. Banka funguje na principu každodenního řízení. V důsledku toho se i zjednodušený popis obchodních procesů banky (v ruštině bez použití notací) ukazuje jako podrobnější, protože spoléhá na základy postavené na množství předpisů, které definují standardy, terminologii, role a pravidla. Tyto standardy jsou běžným jazykem v bankovním prostředí a popis obchodních procesů bude snadno čitelný pro každého specialistu.

V komerčních strukturách vyžaduje popis obchodních procesů předběžný slovníček pojmů. A když to začne připravovat a koordinovat, mnozí se potýkají s tím, že stejné věci v různých odděleních se nazývají odlišně. Když půjdeme do detailů, ukáže se, že různá jména skutečně nesou různé odstíny významu. Harmonizace terminologie je jedním z časově nejnáročnějších procesů pro popis BP. Je důležité tento proces spustit a spustit. Většinu práce mohu převzít z vlastních divizí společnosti, protože nutnost regulace jejich činnosti vede k větší organizaci procesů a postupů.

Pokud je pro automatizaci vyžadován popis, je možný i opačný postup. Změna podnikových procesů probíhá souběžně s implementací informačního systému a popis nových podnikových procesů se provádí „za horka“ a je v souladu se systémovou dokumentací.

houpačka

Všechno jsem zapomněl
Byli jsme učeni tolik let

Kupodivu, ale pro malé a střední podniky je důležitější výběr notace a správnost popisu. Velké společnosti mívají větší elasticitu procesů díky zaměnitelnosti zaměstnanců. U malého podniku, kde je provádění kritických bodů omezeno na 2–3 osoby s rozhodovací pravomocí, může nesprávné naznačení cesty procesu vést k zásadně špatné koncepci řešení. Protože výsledek je kritický, nástroj je také důležitý, ale jak jej vybrat?

Každý zápis je přizpůsoben konkrétnímu okruhu úloh. Nejnaléhavějším úkolem bude změna podnikových procesů v rámci projektu automatizace řízení. Pro tyto účely existuje dobrá sada nástrojů, která se široce používá: jsou to ruské GOST, stejné ARIS a IDEF, stejně jako EPC (obr. 4 a obr. 5).

EPC notace

Obr.4.

Popis obchodního procesu pomocí EPC

Obr.5.

Pokud je kniha psána v určitém jazyce, pak je nejdůležitější mít čtenáře, který tento jazyk zná a umí jej číst. Na základě toho je nejběžnější standard pro popis BP nejlepší.

Při výběru notace je důležitým kritériem také schopnost používat známý softwarový nástroj. Například Microsoft Business Solution v roce 2002 nabízel notaci On-Target pro informační systém Navision spolu se speciálním softwarovým řešením. To je ten případ, kdy je lepší zvolit něco jiného – nejen to, On-Target notaci nikdo nezná, ale i softwarové prostředí zabere čas na její prostudování. Za pozitivní příklad bych označil použití notace IDEF a programu Visio, který je velmi rozšířený a má potřebnou sadu nástrojů pro kreslení diagramů IDEF (obr. 6).

Obchodní procesy IDEF vytvořené ve Visiu

Obr.6.

Popis BP lze samozřejmě provést jednoduše slovy, stejně jako nakreslit pomocí různých symbolů (z vlastního vynálezu), jak se zdá být srozumitelné. Mít takový popis je lepší než nic, ale normy jsou stále užitečné.

Plnost a hloubka zvuku

Nevím, co mě sem táhne

1. trvat dlouho
2. některé detaily se během vytváření dokumentu změní.

Častou chybou je pokus přizpůsobit popisy zápisu. Zkuste například popsat procedury ve formátu ARIS, tzn. k dosažení zjevné redundance v popisu, když to není vyžadováno.

Častější chybou je však nedostatečná hloubka dokumentu. V důsledku toho je získán formální dokument, který není vhodný pro práci, protože všechny důležité detaily musí být vyjasněny v procesu.

Melodie je sled zvuků, nikoli tónů

zapomeň na tento den
Nikdo nepotřebuje bojovat

Takže můžete popsat BP a jen slovy, bez jakýchkoliv poznámek. S notací je to samozřejmě správnější, ale to není důležité. Popis BP není konečný produkt, ale pouze nástroj pro nové úspěchy. To znamená, že musí být přizpůsoben pro další aktivní použití. Hlavním problémem většiny dokumentů typu „udělej si sám“ je nepohodlí při jejich používání. Jeden takový dokument se například skládal z popisu vytvořeného v Microsoft Word a nákresů vytvořených v PowerPointu, skákání z programu do programu bylo strašně nepohodlné, zabralo to spoustu času, než to všechno převést do jednoho dokumentu. Ukazuje se, že dokument by měl mít následující vlastnosti:

1. Mít jasné pořadí a seskupení sekcí, tzn. být konceptuálně holistický (obvykle to znamená, že pokud jste koncept, pak jste se naučili, jak jej používat);
2. Jasně identifikujte obchodní jednotky a dejte jim srozumitelné názvy a číslování;
3. Jasně identifikovat obchodní procesy a také jim dát jasný název a číslování;
4. Prvky by měly být očíslovány tak, aby nedocházelo k záměně (to značně usnadňuje vyhledávání): například oddělení č. 1 by mělo mít v dokumentu číslo Otd001 a obchodní proces č. 1 by mělo mít číslo BP001;
5. Dokument musí mít obsahovou část se stromovou strukturou;
6. Firma je integrální organismus a žádný obchodní proces nevisí ve vzduchu – vždy je propojen s ostatními obchodními jednotkami, s obchodními jednotkami a odděleními. K zobrazení těchto odkazů lze použít hypertextové odkazy – usnadní to vyhledávání informací a přechod z jednoho objektu na druhý.

V tomto případě můžete použít jakýkoli textový editor, který podporuje hypertextové odkazy.

Někdo si myslí, že v profesionální hudební skupině stačí mít jednoho nebo dva opravdové muzikanty. S tím nebude souhlasit žádný upřímný znalec hudby. Tyto rozhovory vznikají kvůli nedostatku profesionálů a kreativních jedinců.

Firmy mají podobné výzvy. Dobrých specialistů, kteří znají svou firmu od hlavy až k patě, je málo a jsou velmi vytížení. Vlastní analýzou obchodních procesů šetříme peníze a možná i čas. Ale ne vždy je možné odtrhnout ty nejlepší pro popis PSU. Rutinu můžete svěřit účinkujícím s nižší hodností, ale pak hrozí zdržení procesu. Neznalost zásad tvorby takových dokumentů s sebou nese riziko neúčinnosti (výsledek je nepoužitelný, je to stejné jako jeho absence).

Nejvyšší kvalita a rychlost přípravy dokumentu je možná v alianci, klíčovém specialistovi a zkušeném konzultantovi. Výsledkem bude dohodnutý jazyk pro popis obchodních procesů (tedy terminologie podnikání firmy) a samotný popis do detailu dostačující k řešení dalších problémů.

V odpověď opakuji veškeré přesvědčování
Nerozdělíme se, ne

Připomínáme, že všechny epigrafy k tomuto článku jsou převzaty z písně "Music Tied Us" od skupiny Mirage

Externí konzultant napíše dokument v notačním jazyce, kterému ostatní konzultanti rozumí a který je pro daný případ často vhodnější. Nechápete všechny tyto háčky? Ale tyto zápisy nejsou vůbec těžké, možná stojí za to se je naučit?

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).

Události a funkce v průběhu procesu se musí střídat. O dalším průběhu procesu rozhodují funkce.

Doporučený počet funkcí v diagramu není větší než 20. Pokud počet funkcí v diagramu výrazně překročí 20, pak existuje možnost, že procesy na nejvyšší úrovni jsou nesprávně identifikovány a model je třeba opravit.

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

Události a příkazy obklopující funkci v překryvném diagramu musí být počáteční/výsledkové události a příkazy v diagramu rozkladu funkce.

Diagram by neměl obsahovat objekty bez jediného spojení. 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 odchozích připojení současně. Pokud má operátor příchozí spojení z prvku „událost“, pak musí mít odchozí připojení k prvku „funkce“ a naopak. Po jedné události nesmí následovat operátory „OR (OR)“ nebo „XOR (Exclusive OR)“. Operátoři mohou slučovat nebo větvit pouze funkce nebo pouze události.

Rýže. 2.62 Příklad procesního diagramu v notaci EPC

Rýže. 2.63 Příklad přijatelné situace 3	Rýže. 2.64 Příklad přijatelné situace 4

Příklad neplatné situace.

Rýže. 2.65 Příklad nepřijatelné situace

Statistické metody řízení procesů

Jsou uvedeny příklady nejoblíbenějších metod statistické analýzy a navržen mechanismus jejich vyhodnocení.

Analýza Paretových grafů

V průmyslových podnicích neustále vznikají nejrůznější problémy: výskyt závad, poruchy zařízení atd. Ve většině případů naprostá většina vad a souvisejících ztrát vzniká z relativně malého počtu příčin, přičemž podíl nákladů na materiál je cca 70 - 80 %. Chcete-li zjistit, které z těchto příčin nebo faktorů jsou hlavní, je vytvořen Paretův diagram.

Paretův diagram je nástroj, který umožňuje objektivně prezentovat a identifikovat hlavní příčiny ovlivňující zkoumaný problém. Existují dva typy Paretových diagramů: podle výsledků činnosti a podle příčin.

Tabulka výkonu je navržena tak, aby identifikovala hlavní problém a odráží následující nežádoucí výsledky výkonu:

Náklady: objem ztrát, náklady;

· Bezpečnost: nehody, nehody;

· Dodací podmínky: nedodržení termínů, nedostatek zásob.

Tabulka Cause Pareto Chart odráží příčiny problémů, které vznikají během výroby:

· Vykonavatel práce: směna, kolektiv atd.;

· Vybavení: stroje, agregáty, nástroje atd.;

· Pracovní metody: sled operací, výrobní podmínky;

· Měření: přesnost, reprodukovatelnost, stabilita.

Konstrukce Paretova diagramu se skládá z následujících kroků.

Fáze 1. Určete, jaké problémy je třeba prošetřit a jak sbírat data; jak je klasifikovat. Nastavte způsob sběru dat a období.

Krok 2: Vytvořte kontrolní seznam pro záznam dat se seznamem typů shromažďovaných informací.

Krok 3. Vyplňte vstupní list a vypočítejte součty.

Krok 4. Vytvořte šablonu tabulky pro kontroly dat a poskytněte v ní graf pro součty pro každý kontrolovaný prvek jednotlivě, akumulovaný součet počtu defektů, procenta z celku a nashromážděná procenta. Uspořádejte data podle důležitosti.

Tabulka 3.1.1 Vytvoření Paretova diagramu

Kód závady	Počet závad	Kumulativní součet počtu defektů	Procento vad	Naběhlý úrok
Celkový		-		-

Krok 5. Nakreslete jednu vodorovnou a dvě svislé osy. Svislé osy: na levé ose použijte stupnici s intervalem od 0 do čísla odpovídajícímu celkovému součtu; na pravé ose - stupnice s intervalem od 0 do 100 %. Vydělte vodorovnou osu počtem ovládaných prvků.

Rýže. 3.1.1 Paretův diagram

Krok 6. Sestavte sloupcový graf, kde každý typ manželství má svůj vlastní obdélník.

Krok 7. Nakreslete kumulativní čáru.

Při vytváření diagramu byste měli věnovat pozornost následujícím bodům:

· Diagram je nejúčinnější, pokud je počet faktorů 7 - 10;

· Při zpracování dat je nutné je stratifikovat podle jednotlivých parametrů (doba vzorkování dat, typ výrobků, šarže materiálů, operátor atd.);

· Pokud je faktor „ostatní“ příliš velký, měla by se analýza obsahu tohoto faktoru opakovat;

 Graf by měl být prováděn systematicky. Pareto pro stejný proces, který vám umožní sledovat trend v počtu defektů pro každý faktor (obr. 3.1.1).