Analýza podnikových procesů ve firmě Rekstan, spol. s.r.o.

Transkript

1 Mendelova univerzita v Brně Provozně ekonomická fakulta Analýza podnikových procesů ve firmě Rekstan, spol. s.r.o. Diplomová práce Vedoucí práce: Ing. Michael Štencl, Ph.D. Bc. Marek Procházka Brno, 2011

2 Na tomto místě bych rád poděkoval svému vedoucímu práce panu Ing. Michaelu Štenclovi, Ph.D. za jeho cenné připomínky a odborné rady, kterými přispěl k vypracování této diplomové práce. Dále bych rád poděkoval řediteli společnosti Rekstan, spol. s.r.o., panu Ing. Pavlu Skočovskému, za umožnění realizace práce ve firmě a za seznámení s interním fungováním ve firmě. V neposlední řadě bych rád poděkoval své rodině a všem, co mě podporovali po dobu mého studia.

3 Prohlašuji, že jsem diplomovou práci na téma Analýza podnikových procesů ve firmě Rekstan spol. s.r.o. vypracoval samostatně a v seznamu literatury jsem uvedl veškeré použité literární a odborné zdroje. Brno

4 4 Abstract Procházka, M. The analysis of business processes in the company Rekstan, spol. s.r.o. Diploma thesis. Brno, This thesis deals with analysis of business processes in the company Rekstan, spol. s.r.o. The modeling language UML is used, namely the standard profile for process modeling. Process models are developed by the CASE tool Enterprise Architect. The analysis is assessed the current state of business processes and suggesting the possibility of adjustments. Abstrakt Procházka, M. Analýza podnikových procesů ve firmě Rekstan, spol. s.r.o. Diplomová práce. Brno, Diplomová práce se zabývá analýzou obchodních procesů ve firmě Rekstan, spol. s.r.o. K modelování je použit jazyk UML, konkrétně jeho standardní profil pro procesní modelování. Modely procesů jsou vytvořeny pomocí CASE nástroje Enterprise Architect. Na základě analýzy je zhodnocen současný stav podnikových procesů a navrhnuty možnosti jejich úprav.

5 OBSAH 5 Obsah 1 Úvod a cíl práce Úvod Cíl práce Metodika Podnikové procesy Zlepšování podnikových procesů Průběžné zlepšování procesů Business Process Reengineering (BPR) Modelování podnikových procesů Standardy pro modelování podnikových procesů Business Process Management Notation Business Process Modeling Language Porovnání BPMN a UML Unified Modeling Language (UML) Historie UML Typy diagramů UML Diagram případu užití (Use Case) Diagram tříd (Class diagram) Stavové diagramy Diagram aktivit Sekvenční diagram Standardní profil UML pro modelování podnikových procesů Volba UML CASE Nástroje Procesní analýza Představení firmy Rekstan, spol. s.r.o Organizační struktura firmy Podnik a jeho okolí Sekretariát Ekonomický úsek Oddělení zpracování zakázek Zásobování Obchod a marketing

6 OBSAH Realizace zakázek Ředitelství Proces zpracování poptávky zákazníka Scénář Diagramy procesu zpracování poptávky Proces zpracování objednávky Scénář Diagramy procesu zpracování objednávky Proces zpracování faktur Scénář faktury vystavené Diagramy - faktura vystavená Scénář faktury přijaté Diagramy - faktura přijatá Zásobování Scénáře Diagramy procesu objednání zboží Diagramy procesu naskladnění zboží Diagramy tříd Třídy v procesu zpracování poptávky Třídy v procesu objednávka Třídy v procesu fakturace Třídy v procesu zásobování Reengineering vybraných procesů 65 5 Diskuze 68 6 Závěr 70 7 Literatura 71 Přílohy 72 A Diagramy tříd 73 B Návrh inovace 75

7 1 ÚVOD A CíL PRÁCE 7 1 Úvod a cíl práce 1.1 Úvod V dnešní době jsou informační technologie součástí téměř každé oblasti každodenního života a člověk si bez nich v některých případech nedokáže život vůbec představit. Tento trend platí také pro podniky, ve kterých jsou informační technologie v dnešním konkurenčním prostředí naprosto nezbytné. Je těžko představitelné, aby v současnosti podnik nepoužíval informační technologii v jakékoliv podobě. Účelné využívání informačních technologií v podniku může přinést mnoho nových informací, které jsou pro jeho existenci velmi důležité. Mít informační náskok před konkurencí může přinést mnoho výhod, protože podnik může provést kroky, které jeho méně informované rivaly vůbec nemusí napadnou. Tímto lze získat nové zákazníky, ale také si udržovat ty stálé. Získávání a uchovávání informací umožňují podnikům Informační systémy. Informační systém umožňuje shromažďovat velké množství dat, ve kterých jsou uloženy informace a v těchto datech vyhledávat a třídit je. Tato data se poté stávají zdrojem a velmi silným nástrojem k řízení podniku. Takovýto komplexní informační systém, který automatizuje veškeré podnikové procesy je ale velmi nákladný a pro některé menší společnosti se tímto stává nedostupným. Ovšem ani tyto menší firmy se neobejdou bez informačních technologií. Proto je dnes musí používat pro podporu svých činností i ty nejmenší firmy. Vhodně zvolená softwarová podpora firemních procesů může zaměstnancům firmy velmi usnadnit a zefektivnit jejich práci a společnosti tak ušetřit nemalé finanční prostředky. Každá firma má své zavedené postupy, podle kterých vykonává veškeré operace. Tyto postupy můžeme nazvat podnikovými procesy. Tyto procesy je nutné neustále přizpůsobovat a současně s rozvojem společnosti je inovovat. Zlepšování a inovace podnikových procesů je nezbytnou součástí každé firmy, která se chce dlouhodobě udržet na trhu a prosperovat v konkurenčním prostředí. Každá firma se dříve nebo později dostane do fáze, kdy je třeba zefektivnit její podnikové procesy. Může to být vlivem již výše zmíněného konkurenčního prostředí, ale také zákazníci žádají stále kvalitnější produkty a služby, čímž firmy nutí ke zlepšování podnikových procesů. Pokud firma včas nezareaguje na takovéto potřeby zákazníka, může vlivem konkurence o něj přijít. Naopak pokud firma v tržním prostředí včas zareaguje na takovéto požadavky zákazníků a zavede inovované procesy dříve než konkurence, může tím získat konkurenční výhodu oproti jejím rivalům a s tím i nové zákazníky.

8 1.2 Cíl práce Cíl práce Cílem této diplomové práce je vytvoření procesního modelu podnikových obchodních procesů společnosti Rekstan, spol. s.r.o. Jako prostředek pro tvorbu modelu bude použit jazyk UML a jeho standardní profil pro modelování podnikových procesů. Na základě vytvořeného modelu bude zhodnocen současný stav obchodních procesů ve firmě a navrženy změny pro zvýšení jejich efektivity. U navržených změn obchodních procesů bude zhodnocen jejich přínos pro firmu. Pro modelování podnikových procesů bude využit CASE nástroj Enterprise Architect ve verzi 7.5 od firmy Sparx System.

9 2 METODIKA 9 2 Metodika 2.1 Podnikové procesy Podnikový proces je souhrnem činností, transformujících souhrn vstupů do souboru výstupů (zboží nebo služeb) pro jiné lidi nebo procesy, používajíce k tomu lidi a nástroje. (Řepa, 2006, s. 15) Procesy se v běžném životě nachází všude kolem nás. Procesem může být nějaká naše činnost, kterou provádíme podle podle stejného nebo podobného schématu, například ranní vstávání, kdy si každé ráno uvařím čaj nebo kávu. Snad každý se setkal s procesem nákupu zboží v obchodě, kdy je procesem chápáno vyřízení požadavku zákazníka. Proces začíná vstupem zákazníka do prodejny, kde si vybere zboží, poté personál zboží připraví zákazníkovi, ten se zařadí do fronty u pokladny a zboží zaplatí. Opuštěním obchodu se zbožím je celý proces ukončen. Obr. 1: Schéma procesu 2.2 Zlepšování podnikových procesů Firma se může rozhodnou mezi dvěma metodami zlepšování svých podnikových procesů. Buď zvolí metodu průběžného zlepšování podnikových procesů nebo metodu Business Process Reengineering Průběžné zlepšování procesů Prvním krokem při průběžném zlepšování podnikových procesů je popis současného stavu procesu a stanovení jeho základních ukazatelů k měření, které jsou dány zejména potřebami zákazníků. Neustálým sledováním chodu procesu jsou určeny možnosti na jeho zlepšení a inovaci. Tyto možnosti je dále nutné dát do vzájemných souvislostí a poté jako celek implementovat. Neméně důležitou částí zlepšování podnikových procesů je dokumentace těchto inovací.

10 2.2 Zlepšování podnikových procesů 10 Tento způsob zlepšování podnikových procesů slouží k dosahování přírůstkového zlepšování. V posledních letec na podniky působí řada faktorů. které mají za následek, že průběžné zlepšování přestává být dostačující a potřeba zlepšování podnikových procesů akceleruje. Asi nejvýraznějším faktorem jsou nové technologie, které na trh přinášejí nové možnosti a proto již nestačí pouhé průběžné zlepšování, ale musí dojít k radikálnímu zlepšování procesů. (Řepa, 2006, s. 16) Výsledkem tohoto trendu je, že podnikům již nestačí přírůstková metoda zlepšování, ale požadují dramatické změny podnikových procesů v co nejkratším čase. Jedním z přístupů, které jsou hojně využívány při potřebě dramatických změn a dramatického zlepšení podnikových procesů je metoda Business Process Reengineering - BPR (Reengineering podnikových procesů). Následující obrázek zachycuje základní kroky průběžného zlepšování procesů. Obr. 2: Průběžné zlepšování podnikových procesů Business Process Reengineering (BPR) Business Process Reengineering je zcela jiným přístupem, než průběžné zlepšování procesů. Ve své extrémní podobě BPR předpokládá, že stávající podnikový proces (procesy) je zcela nevyhovující - nefunguje, je špatný, je třeba jej z podstaty změnit od počátku. (Řepa, 2006, s. 16) Jedná se o radikální změnu procesů, kdy při reengineeringu je možné se zcela odpoutat od současného stavu procesu a soustředit se jen na nový proces. Tato změna se netýká jen samotného procesu, ale prakticky celé firmy včetně jejich zaměstnanců, jako může být například změna jejich pozic nebo propouštění. Následující obrázek zobrazuje princip BPR. Na začátku se definuje rozsahu projektu a hlavních cílů reengineeringu. Poté následuje analýza potřeb a možností, která zahrnuje zkušenosti zaměstnanců a jejich potřeby, zkušenosti a potřeby zákaz-

11 2.3 Modelování podnikových procesů 11 níků, jiných konkurenčních podniků a možnosti nových technologií. Po této důkladné analýze dojde k vytvoření vizí budoucích procesů a u těchto procesů se promyslí vzájemné souvislosti. Na základě nové soustavy procesů se pak vytvoří plán akcí, které vedou k zavedení nově navržené soustavy procesů. Poté se musí nově navržené procesy implementovat. Obr. 3: Model zásadního reengineeringu 2.3 Modelování podnikových procesů K modelování podnikových procesů existuje řada přístupů a norem, které vznikly různými způsoby a každá zdůrazňuje jiné aspekty procesů. Některé normy jsou více exaktní, jiné zase méně, další se zaměřují především na lidskou stránku procesu, jiné dávají přednost technologické stránce. I přes odlišné přístupy k modelování podnikových procesů mají všechny normy stejnou základnu. Základními prvky každého modelu podnikových procesů jsou: proces činnost podnět vazba - návaznost Proces je vždy modelován jako struktura vzájemně navazujících činností. Platí zde princip sémantické relativity (plynoucí z toho, že primárním typem hierarchické abstrakce v procesní struktuře je agregace), podle níž obecně každá činnost může být samostatně popsána jako proces. To, zda činnost je, či není popsána jako proces, závisí na potřebě srozumitelnosti modelu, použitém nástroji, invenci a stylu autora modelu, omezení možné velikosti modelu apod., tedy nikoliv na obsahu procesu samotného. (Řepa, 2006, s. 71) Jednotlivé činnosti pak probíhají na základě definovaných podnětů, což znamená, že vznik činnosti není náhodný, ale musí existovat důvod jejího vzniku. Podněty můžou vznikat buď vně procesu nebo uvnitř procesu. Vnější podněty, které k procesu přicházejí z okolí se nazývají události. Vnitřní podněty se nazývají stav procesu.

12 2.4 Standardy pro modelování podnikových procesů 12 Činnosti procesů neprobíhají náhodně, ale jsou řazeny do vzájemných návazností. Tyto návaznosti procesů jsou popsány pomocí vazeb. Na vazbách závisí různé typové uspořádání činností v procesu, jako mohou být prosté posloupnosti činností, variantní posloupnosti činností nebo paralelismus činností. 2.4 Standardy pro modelování podnikových procesů Oblast modelování podnikových procesů je díky své velké rozsáhlosti, čerstvosti problematiky a technologiím z pohledu standardů celkem nepřehledná. Tyto příčiny a nedostatečná standardizace zapříčiňují vznik mnoho způsobů modelování podnikových procesů a tím přinášejí obtíže s jejich vzájemnou klasifikací a porovnáváním. Hlavním standardem, který definuje základní pojmy a pravidla modelování organizace je norma ISO 14258, která je dále rozpracována normou ISO Podle struktury GERAM jsou požadavky normy ISO kategorizovány do tří skupin: (Řepa, 2006) Rámce - jsou zaměřeny na celkové modelování systému a vazby modelu na reálný systém Jazyky - definují způsob modelování podnikových procesů. Patří sem dva standardy normy ISO a dva standardy nezávislých konsorcií: BPML a UML (viz dále). Moduly - jsou zaměřené na automatizaci podnikových procesů 2.5 Business Process Management Notation Jedním ze standardů pro modelování diagramů podnikových procesů a jejich grafickou prezentaci je Business Process Management Notation (BPMN). Jeho doplňkem je jazyk pro modelování a popis procesů Business Process Modeling Language (BPML), který vychází z jazyka XML (Extensible Markup Language). Za vývojem jazyka BPMN/BPML je sdružení světových firem z oboru vývoje nástrojů pro pro modelování podnikových procesů, které jsou zaštiťovány pod organizací Business Process Management Initiative (BPMI). Business Process Modeling Notation je jazykem pro oblast procesů, a tudíž je procesně orientován. Lze tedy říci, že základními stavebními prvky tohoto jazyka jsou procesy. Jazykem BPMN můžeme kromě popisu celého procesního běhu a delegování zodpovědnosti též vyjádřit vzájemné předávání zpráv mezi procesy a tak umožnit jejich synchronizaci. (Kanisová, Müller, 2007, s. 31) BPMN je konkurentem pro jazyk UML pro modelování podnikových procesů společnosti Object Management Group a je významným kandidátem pro vznik nového volně dostupného standardu pro modelování podnikových procesů, široce vy-

13 2.5 Business Process Management Notation 13 užívaného jako je dnes UML. Jazyk BPMN nabízí: modelování firemních procesů modelování webových služeb možnost definování pravidel, podmínek a vyjímek možnost definování artefaktů (vstupy/výstupy) Business Process Modeling Language Jak už jsem se zmínil, jedná se o jazyk pro modelování a popis podnikových procesů, který byl poprvé uvolněn v roce Jazyk BPML je konceptuálně zaměřen na procesy mezi obchodními partnery B2B. Základní prvky jazyka: (Řepa, 2006) činnosti - základní prvek jazyka kontexty - obecné chování všech činností procesy - proces v BPML je typ složené činnosti, která definuje vlastní kontext pro spuštění činností, v procesu obsažených. (Řepa, 2006, s. 127) vlastnosti plány transakce funkce Porovnání BPMN a UML V následující tabulce je zobrazeno porovnání sedmi vlastností obou standardů, které jsou při modelování podnikových procesů důležité.

14 2.5 Business Process Management Notation 14 Zobrazení UML standard BPMN standard Zobrazení požadavků Zobrazení procesní struktury Zobrazení obsahu procesu Zobrazení uživatelů Use Case diagram: požadavky zobrazeny jako případy užití, uživatelé jako aktéři Diagram tříd Diagram tříd: procesy jsou zobrazeny jako třídy s artefakty a atributy, aktivity jako operace Diagram tříd: každý uživatel zobrazen jako třída Není reprezentován, informace o uživatelech jsou zobrazeny jako plavecké dráhy v business process diagramu Není reprezentován Není reprezentován, Informace o každém procesu lze zjistit jedině pohledem do business proces diagramu pro každý proces Není reprezentován: jediné informace o uživatelých je ve swimlanes Zobrazení chování procesu Zobrazení informací Zobrazení instance procesu Diagram aktivit Diagram tříd Sekvenční diagram: každý proces zobrazen jako čára života Obr. 4: Tabulka srovnání UML a BPMN Business proces diagram Není reprezentován: pouze datové objekty v business proces diagramu Business proces diagram: sekvenční průběh procesu zobrazen jako subprocesy spojeny dohromady Srovnání v tabulce je z hlediska sedmi pohledů, které jsou definovány skupinou BSi. Pohledy jsou následující: (Perry, 2011) Zobrazení požadavků - zachycuje požadavky procesu a zúčastněných stran. Zobrazení informací - zobrazuje výstupy, které jsou produkovány s potřebovány v procesu a ukazuje vztah mezi nimi. Zobrazení zúčastněných stran - zúčastněné strany zapojené do tohoto procesu. Zobrazení procesní struktury - zachycuje strukturu a terminologii procesu. Zobrazení obsahu procesu - definuje obsah procesu z hlediska artefaktů a činností, které proces tvoří. Zobrazení chování procesu - zobrazuje chování procesu, jak jsou v procesu seřazeny činnosti, vstupy a výstupy a zúčastněné strany zapojené do procesu.

15 2.6 Unified Modeling Language (UML) 15 Zobrazení instance procesu - zachycuje posloupnost procesů a definuje scénář procesů. Jak je vidět v tabulce, pomocí jazyka UML lze realizovat všechny zobrazení a tedy plně model procesu. Jazyk BPMN definuje jednotné schéma, kterým je Business process diagram. BPMN nemá žádný nástroj pro strukturované modelování, a proto některé aspekty procesu nelze tímto diagramem realizovat. BPMN zobrazuje 2 pohledy velmi dobře, ale zbylé pohledy vůbec, což nám ve výsledku dává neúplný obraz procesu. 2.6 Unified Modeling Language (UML) Jazyk UML (Unified Modeling Language, unifikovaný modelovací jazyk) je univerzální jazyk pro pro vizuální modelování systémů. Přestože je nejčastěji spojován s modelováním objektově orientovaných systémů, má mnohem širší využití, což vyplývá z jeho zabudovaných rozšiřovacích mechanizmů. (Arlow, Neustadt, 2005, s. 5) Jazyk UML byl navržen proto, aby spojil nejlepší existující postupy modelovacích technik a softwarového inženýrství. Je navržen tak, aby jej mohli implementovat všechny nástroje CASE, bez jejíchž podpory se rozsáhlé softwarové systémy neobejdou. Diagramy vytvořené v jazyku UML jsou srozumitelné pro lidi, ale také jsou snadno interpretovatelné CASE nástroji. Jazyk UML nenabízí žádný druh metodiky modelování. Jazyk UML poskytuje pouze vizuální syntaxi, kterou můžeme využít při sestavování svých modelů. Unified Process (UP) už metodikou je. Sděluje nám, jaké pracovníky musíme použít, které činnosti vykonávat a co vytvořit, aby se nám podařilo sestavit model funkčního softwarového systému. Jazyk UML není svázán s žádnou konkrétní metodikou nebo životním cyklem. Lze jej použít společně se všemi existujícími metodami Historie UML Vývoj UML začal v roce 2004, kdy dva tehdejší rivalové Booch a Rumbaugh se spojili ve firmě Rational Corporation a začali spojovat své metodiky za účelem tvorby jazyka UML. Později se k nim přidal také Jacobson se svou metodikou OOSE (Object- Oriented Software Engineering). Výsledkem jejich společné práce byl vznik jazyka UML, který byl v roce 1997 sdružením OMG přijat a tím vznikl první průmyslový standard objektově orientovaného jazyka pro vizuální modelování. Od tohoto data se ostatní, konkurenční metody postupně vytrácely a veřejnost přijala jazyk UML. (Arlow, Neustadt, 2005) Jazyk UML byl poté dále vyvíjen a rozšiřován a vznikaly nové verze UML 1.1, UML 1.2, UML 1.3 (zde došlo k výraznějším změnám) a v roce 2001 vyšla

16 2.7 Typy diagramů UML 16 verze UML 1.4. V roce 2005 byla dokončena verze UML 2.0, která dodnes nebyla nahrazena novější specifikací. Standard ve verzi 2.0 se skládá z několika částí: (Arlow, Neustadt, 2005) UML 2.0 SuperStructure - část popisující jednotlivé diagramy z hlediska uživatele UML 2.0 Infrastructure - metamodel stojící v pozadí za UML, specifikovaný pomocí Meta-Object Facility (MOF) UML 2.0 Object Constraint Language (OCL) - jazyk pro specifikaci vstupních a výstupních podmínek, invariantů v jednotlivých diagramech UML 2.0 Diagram Interchange - popis XML struktur pro výměnu konkrétních modelů mezi jednotlivými modelovacími nástroji 2.7 Typy diagramů UML UML používá pro modelování 13 základních diagramů, které jsou roztříděny do skupin. Jsou to diagramy chování, diagramy interakce a digramy struktury. Já popíšu pouze několik základních diagramů, které jsou nejvhodnější pro modelování podnikových procesů Diagram případu užití (Use Case) Případ užití (use case) je metodou pro zachycení funkčních požadavků na systém. Případy užití popisují typické interakce mezi uživateli systému a samotným systémem, a předkládají nám příběh o tom, jak je systém používaný. (Fowler, 2009, s. 103) Diagram případů užití zobrazuje tedy chování systému z hlediska uživatele a popisuje způsob použití systému a jeho funkčnost. Cílem tohoto diagramu je, aby měli vývojáři přesný přehled o požadavcích uživatelů na funkčnost systému.

17 2.7 Typy diagramů UML 17 Obr. 5: Příklad diagramu případu užití Scénář Scénář případu užití je v knize UML Srozumitelně definovaný následovně: Scénář je sekvence kroků popisujících interakci mezi aktérem a systémem. (Kanisová, Müller, 2007, s. 39) Na základě definice scénáře se nám naskytla další definice případu užití:případ užití je sada scénářů, které spojuje dohromady společný cíl. (Kanisová, Müller, 2007, s. 40) Scénářů existuje více druhů. Hlavní scénář obsahuje postupy a cesty, které se provádějí při hladkém průchodu systémem. Tento scénář je pro podnik nejvýhodnější. Naproti tomu existují alternativní scénáře, které udávají další postup při zjištění různých chyb nebo mimořádných a nečekaných stavů. Alternativních scénářů může existovat více. Diagram případů užití obsahuje následující prvky: (Kanisová, Müller, 2007) Aktér - V rámci jednoho procesu může vystupovat řada aktérů. Představuje roli, ve které uživatel komunikuje se systémem. Aktér do systému data může zadávat, ale také systém aktérovi data poskytuje. Aktér nemusí být vždy člověk, jako aktér může být i externí systém, který požaduje od našeho systému jakékoliv informace. Aktér je v Use Case diagramu znázorněn graficky postavičkou člověka. Hranice systému - Hranice systému odděluje samotný systém od ostatních systémů nebo vymezuje okolí systému. V grafické podobě je znázorněno rámečkem.

18 2.7 Typy diagramů UML 18 Případ užití - v diagramu je graficky znázorněn pomocí elipsy. Je to grafické znázornění scénáře. Relace - relace jsou vztahy mezi jednotlivými prvky diagramu případu užití. Relace může být mezi Aktérem a případem užití, ale také mezi dvěma případy užití. Mezi dvěma případy užití existují dva typy relací: Include - tato relace se objevuje, pokud existuje stejná nebo podobná část scénáře vyskytující se ve více případech užití. (například vyhledat zakázku, vytvořit fakturu,...) Extend - tento typ relace rozšiřuje základní případ užití o rozšiřující případ užití, který nám udává nové chování. Základní případ užití je ale i bez rozšíření sám zcela funkční. Toto rozšíření nebývá součástí scénáře, ale pouze odkazuje na místo ve scénáři, kde může být funkčnost rozšířena, a kde přidává rozšiřující případ užití nové chování Diagram tříd (Class diagram) Diagram tříd zobrazuje statickou podobu systému. V diagramu tříd jsou zobrazeny jednotlivé třídy a vztahy mezi nimi. Každá třída je charakteristická třemi vlastnostmi, které jsou jméno třídy, atributy třídy a metody třídy. Při návrhu třídy určíme u jednotlivých atributů jejich název a typ. Skutečné hodnoty se atributům přiřazují až u skutečného objektu. Mezi třídami existují vztahy, které je navzájem propojují. Jsou to asociace, agregace, kompozice a generalizace. Hlavním prvkem diagramů tříd jsou třídy, které jsou graficky znázorněny obdélníkovou ikonou rozdělenou do tří částí. V horní částí je název třídy, v prostřední jsou její atributy a v dolní pak její metody. Obr. 6: Příklad třídy

19 2.7 Typy diagramů UML 19 Vztahy mezi třídami: (Kanisová, Müller, 2007) Agregace - vazba, která znázorňuje, že jedna třída je částí druhé třídy. Vyjadřuje nám vztah části k celku. Obr. 7: Příklad agregace Kompozice - jedná se o speciální případ agregace, kdy podřízený objekt nemůže existovat bez svého nadřízeného objektu. Obr. 8: Příklad kompozice Asociace - znázorňují vztahy mezi jednou nebo více třídami. Generalizace - generalizace se používá z důvodů opakovaného použití třídy, kdy podřízená třída (potomek) dědí od své nadřízené třídy všechny vlastnosti. Podřízenou třídu je možné dále rozšířit a k poděděným vlastnostem je možné přidat další, rozšiřující vlastnosti a operace. Obr. 9: Příklad generalizace

20 2.7 Typy diagramů UML Stavové diagramy Stavové diagramy popisují všechny možné stavy, které může nabývat konkrétní objekt systému, jinými slovy modelují chování objektu napříč všemi případy užití. Zároveň znázorňují, jak se stavy objektu mění v závislosti na událostech, které se ho dotýkají. (Kanisová, Müller, 2007, s. 85) Jedná se o diagramy, které znázorňují chování systému. Základním stavebním prvkem stavových diagramů jsou stavy objektů, které jsou dále rozšířeny o dva speciální stavy. Jedná se o počáteční stav a koncový stav diagramu. Dynamiku představují přechody mezi jednotlivými stavy a události, které přechody vyvolávají. Obr. 10: Příklad stavového diagramu Diagram aktivit Diagramy aktivit jsou užitečné tam, kde je potřeba popsat chování systému. Diagram aktivit zobrazuje sekvenci aktivit, které podporují jak sekvenční, tak paralelní chování. Diagram aktivit je v podstatě variantou stavového diagramu. (Kanisová, Müller, 2007, s. 95) Tyto diagramy modelují procesy jako aktivity a přechody mezi nimi. Diagramy aktivit obsahují následující symboly: Akce - akce neboli aktivity jsou základním prvkem stavového diagramu. Za aktivitu považujeme jakoukoliv činnost. Aktivita je dále nedělitelná. Graficky se znázorňuje pomocí obdélníku se zakulacenými rohy. Přechody - Mezi akcemi dochází k přechodům, které vzniknou vždy až po ukončení akce. Graficky jsou přechody znázorněny šipkou mezi jednotlivými akcemi.

21 2.7 Typy diagramů UML 21 Hodnocení přechodů - hodnocení přechodů je vlastně logická podmínka, která podmiňuje, zda má ke konkrétnímu přechodu dojít nebo ne. Do hodnocení přechodů vstupuje vždy jeden přechod, počet výstupních přechodů není omezený. Každý výstup má určenou podmínku. Graficky je hodnocený přechod znázorněn pomocí symbolu kosočtverce. Rozvětvení - Rozvětvení slouží k modelování paralelního chování. V přechodu se diagram rozvětví na více cest s různým chováním, které běží paralelně a poté se zase spojí do jedné cesty. Plavecké dráhy - Plavecké dráhy slouží k tomu, aby byla přesně určena osoba nebo oddělení, které jsou za konkrétní aktivity zodpovědné. Obr. 11: Příklad diagramu aktivit Sekvenční diagram Sekevnční diagram typicky zachycuje chování jednoho scénáře. Ukazuje několik vzorových objektů a zpráv, které jsou předávány mezi těmito objekty v rámci případu užití. (Fowler, 2009, s. 67) Diagram obsahuje objekty, ze kterých vede svislá čára, neboli tzv. čára života. Zprávy zasílané mezi objekty jsou zobrazeny šipkami mezi jednotlivými čárami života.

22 2.8 Standardní profil UML pro modelování podnikových procesů 22 Obr. 12: Příklad sekvenčního diagramu 2.8 Standardní profil UML pro modelování podnikových procesů Jazyk UML je vytvořen jako univerzální nástroj, to znamená, že se dá využít na modelování téměř čehokoliv. Proto je také hojně využíván při modelování podnikových procesů, které mu zajišťuje standardní profil pro modelování podnikových procesů. Toto rozšíření bylo zveřejněno ve specifikaci UML 1.1, které vzniklo v roce 1997 a dodnes se téměř nezměnilo. Toto rozšíření dává diagramu Use Case a Diagramu tříd nový význam. Use Case diagram, který je určený k popisu funkčních požadavků a uživatelského rozhraní informačního systému v klasickém modelu slouží k popisu podnikových procesů a jejich interakce s aktéry. Tento model sloužící k popisu vztahů podniku s okolím se nazývá externí model.

23 2.8 Standardní profil UML pro modelování podnikových procesů 23 Obr. 13: Příklad Use Case diagramu externího modelu Interní model (Object model) je zobrazován pomocí diagramu tříd. Diagram tříd je základním diagramem UML, slouží popisu a klasifikaci tříd objektů a jejich vzájemných vztahů. (Řepa, 2006, s. 148) V klasickém profilu slouží diagram tříd zejména k popisu vnitřní struktury organizace. Obr. 14: Příklad diagramu tříd interního modelu

24 2.9 CASE Nástroje 24 V následující tabulce jsou zobrazeny přehledy modelů a diagramů standardního profilu UML podle Erikssona. Jsou zde popsány diagramy UML, jejich význam a název v klasickém profilu UML. Model/Diagram Význam Založen na Vision Statement diagram Definice vize organizace volný text Conceptual model Definice klíčových pojmů a jejich vztahů Class diagram Goal model Definice hlavních cílů organizace a ověření jejich platnosti Object diagram Process diagram Definice podnikových procesů a jejich vztahů Activity diagram Assembly Line diagram Propojení definice podnikových procesů a objektů, jakož i souvisejících informačních Activity diagram systémů Use-Case diagram Definice požadované funkcionality podpůrných informačních systémů Use-Case diagra Resource model Popis zdrojů organizace. Zdrojem je informace Class diagram nebo věc. Organization model Definice organizační struktury Class diagram Information model Definice informační struktury - informační architektury Class diagram Statechart diagram Popis životního cyklu zdrojů Statechart diagram Sequence diagram Analýza interakcí v systému Sequence diagram Obr. 15: Modely a diagramy podle Erikssona (Řepa, 2006, s. 150) Volba UML Z požadavků společnosti Rekstan neplynulo žádné konkrétní omezení pro výběr jazyka pro modelování podnikových procesů. Pro modelování podnikových procesů byl vybrán jazyk UML. Tento jazyk byl zvolen zejména díky možnosti zobrazit kompletní pohled na proces a jeho možnosti přehledně graficky zobrazovat podnikové procesy. Tímto jazykem lze vytvořit kvalitní objektově orientovaný návrh aplikace, který je poté velmi důležitý při následné implementaci. Tento faktor byl také velmi důležitý, protože se v budoucnu plánuje, že na základě provedené analýzy a namodelování podnikových procesů bude dále vyvíjena aplikace, která zautomatizuje problematické, administrativně a časově náročné procesy. 2.9 CASE Nástroje Nástroje CASE (Computer Aided Software Engineering) slouží pro podporu analýzy a návrhu aplikací. Jedná se o automatizované nástroje, které slouží ke tvorbě rozsáh-

25 2.9 CASE Nástroje 25 lých informačních systémů a vychází z modelovacího jazyka UML. Nástroje CASE umožňují propojení jednotlivých technik UML a společný vývoj aplikací v týmu. (Kanisová, Müller, 2007) Zástupci CASE nástrojů je například Rational Rose od firmy IBM, PowerDesigner od firmy Sybase nebo například Enterprise Architect of firmy Sparx Systems, ve které bude zpracována diplomová práce. Tyto produkty jsou všechny komerční a za jejich používání je třeba zaplatit licenční poplatek. Tyto nástroje umožňují propojení jednotlivých modelů, sdílení modelů mezi členy týmu nebo generování projektové dokumentace. Existují také CASE nástroje šířené pod licencí GPL. Jmenovat můžu například Umbrello UML Modeller. Tyto nástroje ovšem nenabízí tak rozsáhlé možnosti jako komerční produkty.

26 3 PROCESNí ANALÝZA 26 3 Procesní analýza 3.1 Představení firmy Rekstan, spol. s.r.o. Společnost Rekstan, spol. s r.o. byla založena v roce 1991 jako montážní společnost se zaměřením na opravy a rekonstrukce výměníkových, redukčních a předávacích stanic pro teplárenské a městské společnosti, které jsou dodavateli tepla. Tato počáteční úzká specializace byla postupně rozšiřována o práce na rekonstrukcích topných kanálů a to především realizaci rozvodů technologií bezkanálovou - předizolovaným potrubím. S rozšířením objemu prováděných prací se společnost rozrůstala a její zaměření se rozšířilo i o stavební činnost spojené s výstavbou rodinných domků, rekonstrukci stávajících bytových zařízení, dále plynofikaci obcí, zajišťování vnitřních rozvodů plynu a ústředního vytápění.většina realizovaných akcí je prováděna tzv. na klíč, včetně všech souvisejících činností, kterými jsou např. i zkoušky a revize. Svoji dobrou prací, jejímž důkazem je i dlouhodobá bezporuchovost realizovaných zakázek, si společnost upevnila své postavení v regionu a rozšířila významně své působení i mimo něj. Ve společnosti byl zaveden systém managementu jakosti, který je již od roku 2000 certifikován a neustále zlepšován, aby plnil nejen požadavky ČSN EN ISO 9001:2009, ale byl nástrojem řízení společnosti pro plnění jejich záměrů a požadavků zákazníků. Společnost se také orientuje na ochranu životního prostředí a zavázala se dodržovat a stále zlepšovat svůj enviromentální management, díky čemuž získala certifikát ČSN EN ISO 14001:2004. Společnost má dobré předpoklady pro úspěšné plnění zakázek ve svém oboru, neboť disponuje kolektivem zkušených pracovníků, kteří plní své úkoly na vysoké úrovni a je schopná flexibilně reagovat na potřeby svých zákazníků. Výrobní sortiment a sortiment služeb: Opravy a rekonstrukce výměníkových stanic Opravy a rekonstrukce předávacích stanic Rekonstrukce topných kanálů Výstavba a rekonstrukce bytových domů Zajišťování vnitřních rozvodů tepla Organizační struktura firmy Společnost je rozdělena na několik oddělení, které jsou v podřízenosti ředitele společnosti. Každé oddělení má na starost určitou část činností při realizaci zakázek.

27 3.1 Představení firmy Rekstan, spol. s.r.o. 27 Jednotlivá oddělení mezi sebou komunikují a předávají si potřebné informace. Ekonomický úsek má na starosti vedení centrálního účetnictví pro všechny oddělení společnosti a vedení personální agendy. Obr. 16: Organizačně funkční schéma společnosti Rekstan, spol. s.r.o Podnik a jeho okolí Pokud se podíváme na podnik a jeho vztahy k okolí, dochází pravidelně ke stykům převážně se zákazníky a dodavateli stavebních technologií a materiálu. Nejlépe tento pohled vystihne Use Case diagram podniku a jeho okolí.

28 3.1 Představení firmy Rekstan, spol. s.r.o. 28 Popis aktérů Obr. 17: Use Case diagram - podnik a jeho okolí Zákazník - Jedná se o fyzickou nebo právnickou osobu, která má zájem o nabídku služeb firmy. Cílem je získat podrobnou nabídku služeb, o které projeví zájem. Pokud je s nabídkou firmy spokojen, objedná u ní služby, které po dokončení převezme. Pokud se na převzaté zakázce vyskytnou nedostatky nebo vady, má právo na reklamaci. Dodavatel - Jedná se o obchodního partnera firmy, který jí nabízí své služby a zboží. Jedná se zejména o materiál na realizaci zakázek. Dodavatel může být fyzická i právnická osoba. Pokud firma využije nabídku dodavatele, tento musí firmě objednaný materiál dodat a poté řádně vyfakturovat. Banka - jedná se o peněžní instituci, u které má firma vedený účet. Banka firmě spravuje finanční hotovost a zprostředkovává platby. Projekční firma - Jedná se o společnost, v tomto případě o fyzickou podnikající osobu, která firmě vytváří projektové dokumentace k některým zakázkám. Za své služby firmě poté fakturuje odpovídající částky.

29 3.1 Představení firmy Rekstan, spol. s.r.o. 29 Popis případů užití Poptat - Jedná se o případ užití, kdy zákazník předá firmě konkrétní dokumenty k požadované zakázce a čeká na její nabídku. Objednat - Na základě obdržené nabídky zákazník objednává u firmy požadované dílo. Převzít - Po dokončení díla zákazník od firmy přebírá hotové dílo, včetně všech dokumentů a revizních zpráv. Nabídnout - Případ užití, kdy dodavatel nabízí firmě své služby nebo zboží v konkrétních cenách. Dodat - Dodavatel firmě předá buď nabízené zboží nebo služby a tím i potřebné dokumenty (dodací list, faktura, předávací protokol). Pokud se jedná o materiál, firma toto zaeviduje do skladové agendy. Vytvořit projektovou dokumentaci - Případ užití, kdy externí projektant na základě objednávky od firmy vytvoří projektovou dokumentaci a poté ji předá se všemi náležitostmi Sekretariát Ve firmě Rekstan má sekretariát za úkol udržovat kontakt se zákazníky a dodavateli, přijímat nabídky a poptávky od zákazníků a předávat je na konkrétní oddělení firmy. Dále má toto oddělení na starosti fakturaci za přijaté služby a zboží, ale také vystavení faktur pro zákazníky na základě dodaných podkladů z ostatních oddělení. Tyto faktury musí před proplacením nebo odesláním schválit ředitel společnosti.

30 3.1 Představení firmy Rekstan, spol. s.r.o. 30 Popis aktérů Obr. 18: Use Case diagram - Sekretariát Sekretářka - Sekretářka je jediný aktér v úseku sekretariátu. Jedná se o zaměstnankyni firmy, která má za úkol udržovat kontakty s klienty, přijímat a odesílat jim všechny druhy dokumentů a zprostředkovávat komunikaci s ostatními odděleními. Dále má na starosti fakturaci a veškerou agendu s tím spojenou. Popis případů užití Zpracovat fakturu vydanou - Vytvoření faktury k již zhotovené a předané zakázce. Položky faktury jsou zpracovávané na základě smlouvy o dílo a stavebního deníku. Pokud vznikne u vydané faktury pohledávka, nejdříve je dostupnými prostředky vymáhána firmou, a až poté předána k vymáhání právnímu zástupci Předat objednávku - Předání přijaté a podepsané objednávky od zákazníka na příslušné místo a poté opětovné zaslání podepsané objednávky zákazníkovi

31 3.1 Představení firmy Rekstan, spol. s.r.o Ekonomický úsek Ekonomický úsek má v podniku na starosti kompletní vedení účetnictví mzdového i finančního a vedení personální agendy. Jsou zde zpracovávány veškeré účetní doklady ze všech oddělení firmy. Oddělení má na starosti výpočet mezd zaměstnanců, kontrolovat finanční situaci podniku a hospodářský výsledek za období, dále správu evidence zaměstnanců a veškeré náležitosti spojené se zaměstnanci. Obr. 19: Use Case diagram - Ekonomický úsek

32 3.1 Představení firmy Rekstan, spol. s.r.o. 32 Popis aktérů Účetní - účetní má ve firmě na starosti veškerou agendu spojenou s účetnictvím. Má za úkol zaevidovat a zaúčtovat veškeré účetní doklady ze všech podnikových oddělení. Dále má v popisu práce zpracování účetních závěrek a výpočet ekonomických ukazatelů pro zjištění správného hospodaření podniku. Účetní ve firmě představuje také funkci mzdové účetní, kdy má za úkol zpracovat mzdové doklady všech zaměstnanců a výplatu mezd. Personalistka - ve firmě představuje osobu zodpovědnou za veškeré činnosti spojené se správou agendy zaměstnanců, s náborem nových zaměstnanců, má na starosti uzavírání a databázi veškerých smluv se zaměstnanci. Popis případů užití Vytvořit mzdové doklady - jedná se o výpočet mezd na základě docházkových listů zaměstnanců a vytvoření příslušných dokladů, které se zaevidují do účetnictví. Na základě těchto mzdových listů jsou zaměstnancům vypláceny mzdy z firemního účtu. Zpracovat účetní doklady - případ užití zpracování účetních dokladů představuje jejich evidenci a rozdělení do příslušných účtových skupin a zápis do účetního deníku. Spravovat evidenci zaměstnanců - zde jsou v databází evidovány veškeré informace o zaměstnancích, které jsou potřebné. V evidenci se dají dohledat také data o bývalých zaměstnancích. Tato data jsou chráněná zákonem o ochraně osobních dat Oddělení zpracování zakázek V tomto úseku jsou zpracovávány veškeré obdržené poptávky od zákazníků firmy. Oddělení má za úkol zpracovat a zaevidovat tyto skutečnosti a na základě poptávky a projektové dokumentace vytvořit podrobný položkový rozpočet. Dále je třeba z projektové dokumentace odhadnout přibližnou dobu potřebnou na zhotovení zakázky. Z takto vytvořených dokumentů se poté vytvoří konkrétní nabídka, která je předána zákazníkovi.

33 3.1 Představení firmy Rekstan, spol. s.r.o. 33 Popis aktérů Obr. 20: Use Case diagram - oddělení zpracování zakázek Vedoucí úseku - vedoucí úseku má na starosti chod celého oddělení, přijímá nové poptávky, které zaeviduje a předá svým kolegům ke zpracování. Po obdržení veškerých zpracovaných částí nabídku zkompletuje, vytvoří doprovodné dokumenty a předá na odeslání k zákazníkovi. Projektant - projektant má za úkol kontrolu dodané projektové dokumentace a případně její úpravu. Na základě projektové dokumentace odhadne čas, který je

34 3.1 Představení firmy Rekstan, spol. s.r.o. 34 třeba na zhotovení díla a vytvoří podrobný rozpočet jednotlivých položek materiálu a práce. Rozpočtář - na základě dodaných dokumentů zpracovává položkový rozpočet. Pomocí vnitropodnikových tabulek a ceníků dodavatelů každou položku ocení. Popis případů užití Zpracovat poptávku - jde o případ užití, kdy vedoucí úseku přijme od zákazníka poptávku, jejíž přijetí musí potvrdit. Poté založí novou složku pro veškeré dokumenty poptávky a přidělí ji identifikační číslo. Dalším krokem ve zpracování poptávky je vytvoření nabídky, její kompletace a kontrola. Poté je nabídka se všemi náležitostmi odeslána zákazníkovi. Zkontrolovat projektovou dokumentaci, Upravit projektovou dokumentaci - projektant zkontroluje celou dodanou projektovou dokumentaci k zakázce. Pokud zjistí jakoukoliv nesrovnalost nebo nejasnost, kontaktuje zákazníka pro upřesnění. Po domluvě se zákazníkem je možné projektovou dokumentaci upravit. Vytvořit položkový rozpočet - Na základě projektové dokumentace ke konkrétní poptávce dojde k vytvoření jednotlivých položek rozpočtu a určení jejich množství. Jedná se zejména o materiálové položky a o položky pracovních úkonů Zásobování V oddělení zásobování je spravován veškerý materiál, který firma využívá pro své zakázky. Oddělení má na starosti komunikovat s dodavateli a vyjednávat podmínky pro dodávky materiálu. Pokud dojde k objednávce zboží, je buď naskladněno na centrální sklad v areálu vojenských staveb na ulici Vídeňské nebo úsek zajistí jeho dopravu přímo na místo realizace zakázky. Oddělení má na starost vedení a správu veškerých dokumentů a evidenci skladových zásob.

35 3.1 Představení firmy Rekstan, spol. s.r.o. 35 Popis aktérů Obr. 21: Use Case diagram - zásobování Vedoucí skladu - vedoucí skladu je zaměstnanec firmy, který má za úkol vést veškerou potřebnou agendu pro chod skladu. Vyjednává s dodavateli podmínky, kontroluje a eviduje množství skladovaného materiálu, vyřizuje objednávky a přebírá od dodavatelů zboží. Skladník - tuto funkci vykonává stejný pracovník jako vedoucí skladu. Skladník má v popisu práce fyzicky ukládat materiál do skladu, jeho uspořádání a poté následné vydání materiálu zaměstnancům firmy na konkrétní zakázku. Popis případů užití Objednat materiál - na základě prováděných zakázek a jejich dokumentace je objednáván materiál na jejich uskutečnění. Dochází zde ke komunikaci vedoucího skladu s dodavateli, vyjednávání dodacích a cenových podmínek a ke konečnému objednání zboží. Převzít od dodavatele - případ užití, kdy dojde k dodání objednaného zboží. Zboží je buď doručeno na sklad firmy nebo na místo konkrétní zakázky. Po dodání

36 3.1 Představení firmy Rekstan, spol. s.r.o. 36 zboží jsou vyplněny dokumenty o novém převzatém zboží, které se uloží do evidence skladu. Poté je zboží převzato skladníkem a uloženo do skladu nebo zboží převezme stavbyvedoucí, je-li doručeno přímo na stavbu. Vydat materiál - výdej materiálu na základě požadavku zaměstnance firmy. Zboží musí být přiřazeno konkrétní zakázce. Na základě údajů skladník vyplní předávací protokol a zboží vydá Obchod a marketing Toto oddělení má na starosti řídit veškeré obchodní vztahy společnosti a vytvářet smlouvy s obchodními partnery. Dále má za úkol společnost propagovat a řídit marketing Realizace zakázek Toto oddělení má za úkol zajišťovat realizaci veškerých objednaných zakázek. Ke každé zakázce je veden stavební deník, do kterého jsou zaznamenávány postupy prací a spotřebovaný materiál podle skutečnosti. Vedení záznamů v deníku má na starosti stavbyvedoucí Ředitelství Jde o nadřízený orgán všem střediskům podniku. Je reprezentován ředitelem společnosti, který má veškeré rozhodovací pravomoci a řídí chod celé firmy.

37 3.2 Proces zpracování poptávky zákazníka Proces zpracování poptávky zákazníka V tomto procesu dochází ke zpracování poptávek od zákazníků. Zákazník odešle poptávku, která je přijata v podniku pracovníkem sekretariátu. Zákazník po předešlé domluvě dodá podklady pro poptávku buď osobně ve firmě nebo pomocí elektronické pošty. Vždy je nutné k zakázce přidat veškeré podklady v písemné podobě. Nejdůležitější částí k vytvoření nabídky je předání projektové dokumentace. Firma nemá vlastní projekční oddělení, je tedy nutné tyto podklady dodat ke každé poptávce. Jakmile jsou dodány veškeré podklady od zákazníka, je poptávka předaná na oddělení zpracování poptávek od zákazníků, kde ji převezme vedoucí úseku, který je za celou zakázku zodpovědný. Vedoucí úseku potvrdí zákazníkovi přijetí poptávky a založí novou složku s identifikačním číslem pro veškeré podklady k této poptávce. Složku založí jak fyzicky pro písemné podklady, tak na síťovém pevném disku, kam se budou ukládat veškeré elektronické podklady. Poté jsou dokumenty předány projektantovi, který zkontroluje projektovou dokumentaci a zjistí, zda je podnik schopný zakázku technologicky zvládnout. Pokud narazí na jakékoliv nesrovnalosti, kontaktuje zákazníka, se kterým tyto nejasnosti řeší, případně projektovou dokumentaci mírně upraví po dohodě. Poté dochází k vytváření položkového rozpočtu. Projektant na základě projektové dokumentace vytvoří jednotlivé položky rozpočtu a přiřadí k nim konkrétní množství. Rozpočet má dvě části, první vystihuje veškerý materiál potřebný k realizaci zakázky a druhá veškeré nezbytné pracovní činnosti. Takto vytvořený položkový rozpočet je předán rozpočtáři, který jednotlivým položkám přidá konkrétní peněžitou sumu. Ceny za materiál získává z aktuálních ceníků od dodavatelů společnosti. Ohodnocení výkonů a práce je dáno podnikovými tabulkami pro konkrétní činnosti. Takto vytvořený položkový rozpočet je předán zpět vedoucímu úseku, který jej zkontroluje a přidá do složky s nabídkou. Veškeré podklady vypracované nabídky pro zákazníka jsou předány zpět na sekretariát, kde zaměstnankyně předá podklady nabídky na schválení řediteli firmy. Pokud ředitel nabídku schválí, je zaslána zákazníkovi. Pokud zákazníkovi nabídka vyhovuje, předá ji firmě zpět ve formě objednávky na vyhotovení díla. Proces předání objednávky od zákazníka s veškerými náležitostmi bude popsán v dalším popisu procesu, který se bude věnovat objednávkám zákazníků Scénář Hlavní scénář zpracování poptávky zákazníka Vedoucí úseku zpracování zakázek: 1. Přijme poptávku od zákazníka 2. Potvrzení přijetí poptávky zákazníkovi 3. Založení nových složek pro nabídku

38 3.2 Proces zpracování poptávky zákazníka Zpracování projektové dokumentace - viz scénář Zpracování projektové dokumentace 5. kompletace nabídky pro zákazníka 6. schválení nabídky ředitelem společnosti - viz scénář Schválení nabídky 7. odeslání nabídky zákazníkovi Hlavní scénář Schválení nabídky Ředitel společnosti: 1. Přijme vypracovanou nabídku a) Schválí nabídku b) Zamítne nabídku a Use case končí Hlavní scénář zpracování projektové dokumentace Projektant: 1. kontrola projektové dokumentace a založení rozpočtu 2. pokud podnik zakázku nedokáže technologicky nebo kapacitně zvládnout, Use case je ukončen 3. pro každou položku projektové dokumentace se provede kontrola a) Pokud jsou položky standardní, pokračuje se bodem 4 b) Pokud je položka nesrozumitelná, kontaktuje zákazníka a konzultuje položku dojde-li k dohodě se zákazníkem, pokračuje se bodem 4 nedojde-li k dohodě, případ užití končí a oznámí se skutečnost vedoucímu 4. Vytvoření položkového rozpočtu podle scénáře Vytvoření položkového rozpočtu Hlavní scénář vytvoření položkového rozpočtu 1. Založení položkového rozpočtu 2. Vytvoření jednotlivých položek rozpočtu s jejich potřebným množství 3. Doplnění cen k jednotlivým položkám rozpočtu

39 3.2 Proces zpracování poptávky zákazníka Diagramy procesu zpracování poptávky Obr. 22: Stavový diagram - zpracování poptávky zákazníků

40 3.2 Proces zpracování poptávky zákazníka 40 Obr. 23: Procesní diagram - zpracování poptávky zákazníků

41 3.2 Proces zpracování poptávky zákazníka 41 Obr. 24: Sekvenční diagram - zpracování poptávky zákazníků

42 3.3 Proces zpracování objednávky Proces zpracování objednávky V tomto procesu jsou zpracovávány objednávky na zakázky od zákazníků až po jejich předání a navazuje na předchozí proces zpracování poptávky zákazníků. Na základě vypracované nabídky se zákazník rozhoduje, zda si zhotovení díla u firmy objedná, či nikoliv. Pokud nabídka zákazníkovi vyhovuje, odešle firmě závaznou objednávku. Objednávka je přijímána výhradně v elektronické podobě. Další možností je osobní předání objednávky. Objednávku přijme zaměstnankyně sekretariátu a předá ji řediteli. Ten zkontroluje, zda se objednávka shoduje se zaslanou nabídkou zákazníkovi, pokud ano, objednávku schválí, podepíše a předá ji obchodnímu a marketingovému manažerovi, který založí složku pro novou zakázku a vytvoří návrh Smlouvy o dílo. Smlouva o dílo by měla obsahovat číslo smlouvy, údaje o smluvních stranách, předmět smlouvy, termíny plnění, cenu díla, platební podmínky, dodací podmínky, záruční podmínky a smluvní sankce. Takto vytvořený návrh předá zpět řediteli ke schválení. Pokud je vše v pořádku, smlouva se vytiskne, ředitel ji podepíše a je zaslána zákazníkovi k podpisu. Pokud zákazník nemá žádné připomínky, předá podepsanou smlouvu řediteli a smlouva je platná. Pokud připomínky jsou, ředitel rozhodne, zda jsou akceptovatelné a zakomponují se do smlouvy nebo je smlouva zrušena. Poté dochází k plnění zakázky oddělením Realizace zakázek. Během tohoto plnění je veden stavební deník a informace o spotřebovaném materiálu ze skladu. Na základě těchto údajů jsou po skončení díla vytvářeny faktury. Tyto podklady jsou předány do ekonomického úseku, kde jsou dále zpracovávány specializovaným software a zaneseny do účetnictví firmy. Poté jsou vytvořeny a předány faktury investorovi zakázky. U větších zakázek dochází k průběžné fakturaci podle Smlouvy o dílo Scénář Hlavní scénář zpracování objednávky zákazníka Ředitel společnosti: 1. Přijme objednávku od zákazníka a) Jestliže se objednávka shoduje s nabídkou, pokračuje se bodem 2 b) Pokud se objednávka neshoduje s nabídkou, Use Case je ukončen 2. Vytvoření smlouvy o dílo - viz scénář Smlouva o dílo 3. Schválí smlouvu o dílo 4. Odeslání smlouvy o dílo zákazníkovi k podpisu

43 3.3 Proces zpracování objednávky 43 a) Pokud zákazník se smlouvou souhlasí bez připomínek a podepíše ji, pokračuje se scénářem Realizace zakázky b) Pokud zákazník nesouhlasí a má připomínky, zašle smlouvu zpět i s připomínkami Pokud ředitel rozhodne, že jsou připomínky akceptovatelné, dá pokyn k jejich zapracování do smlouvy a pokračuje se bodem 4 Pokud jsou připomínky pro firmu nepřijatelné, ředitel rozhodne o odstoupení zhotovení díla a Use Case končí Hlavní scénář Smlouva o dílo Obchodní a marketingový manažer: 1. Založí složku pro novou zakázku 2. Sepíše novou smlouvu o dílo 3. Spojí se se zákazníkem pro upřesnění podmínek a údajů Hlavní scénář Realizace zakázky úsekem Realizace zakázek Stavbyvedoucí: 1. Provede realizaci zakázky 2. Rozhodne o fakturaci podle smlouvy 3. Předá příslušné účetní doklady a stavební deník a) pokud je zakázka kompletní Use Case končí b) pokud jde o průběžnou fakturaci, pokračuje se bodem 1

44 3.3 Proces zpracování objednávky Diagramy procesu zpracování objednávky Obr. 25: Stavový diagram - zpracování objednávek zákazníků

45 3.3 Proces zpracování objednávky 45 Obr. 26: Procesní diagram - zpracování objednávek zákazníků

46 3.4 Proces zpracování faktur 46 Obr. 27: Sekvenční diagram - zpracování objednávek zákazníků 3.4 Proces zpracování faktur Proces zpracovaní faktur se dále dělí na dvě části. Buď se jedná o fakturu přijatou od dodavatele společnosti nebo fakturu vystavenou. Zpracování těchto faktur ve společnosti Rekstan, spol. s.r.o. se řídí podobnými pravidly jako v ostatních podnicích. Faktury jsou zpracovávány specializovaným účetním software SB Komplet. Nejprve bude popsán proces zpracování faktury vystavené. Po skončení realizace zakázky nebo po skončení realizace určité části zakázky a předání investorovi jsou veškeré podklady pro fakturaci vzniklé během realizace předány účetní podniku, která je dále zpracovává. Jedná se zejména o stavební deník, kde jsou zaznamenány

47 3.4 Proces zpracování faktur 47 provedené pracovní úkony včetně víceprací a spotřebovaný materiál. Zpracované podklady jsou dále předány sekretářce. Sekretářka na základě pokynu od ředitele společnosti a přijatých podkladů o zakázce může vystavit fakturu. Vystavená faktura obsahuje veškeré standardní položky jako je číslo faktury, datum vystavení, splatnosti, způsob úhrady, informace o dodavateli, o odběrateli. Dále faktura obsahuje jednotlivé řádky s popisem fakturovaných položek, u kterých je uvedena sazba uplatňované DPH a cena bez DPH a s DPH. Po vystavení je faktura předána řediteli ke schválení. Po odsouhlasení ředitelem společnosti je faktura odeslána odběrateli. Tímto proces vystavené faktury zcela nekončí. U každé odeslané faktury musí sekretářka hlídat její úhradu. Pokud nedojde k úhradě faktury do požadovaného data splatnosti, je odběratel upozorněn a je dodatečně prodloužené datum splatnosti faktury. Když ani po tomto upozornění nedojde k úhradě, je urgování úhrady faktury předáno právnímu zástupci společnosti, který částku vymáhá. Veškeré fakturace zakázek se řídí Smlouvou o dílo a podmínkami v ní přijatými a odsouhlasenými oběma stranami. Faktury přijaté zpracovává také sekretářka firmy. Po přijetí faktury ji zaeviduje do systému a předá dále k ověření. Pokud se jedná o fakturu za materiál, konzultuje fakturu s vedoucím skladu, pokud se jedná o jiný typ faktury, je konzultována s příslušnou kompetentní osobou a odsouhlasena ředitelem firmy. Jsou - li ve faktuře jakékoliv nesrovnalosti, kontaktuje se dodavatel pro upřesnění položek. Pokud je faktura v pořádku a odsouhlasená, dojde k její úhradě pomocí bankovního převodu Scénář faktury vystavené Hlavní scénář zpracování faktury vystavené Sekretářka společnosti: 1. Dostane příkaz k fakturaci 2. Vyžádání veškerých podkladů k fakturaci od účetní firmy 3. Vytvoření nové faktury s rozepsanými položkami 4. Předání ke schválení faktury ředitelem firmy a) Jestliže ředitel fakturu schválí, pokračuje se bodem 5 b) Pokud ředitel fakturu neschválí, předá jí i s připomínkami na přepracování, pokračuje se bodem 3 5. Odeslání faktury zákazníkovi 6. Kontrola úhrady faktury a) Pokud zákazník fakturu uhradí v termínu splatnosti faktury, Use Case končí b) Pokud zákazník fakturu neuhradí v termínu splatnosti, je upozorněn a dodatečně se splatnost faktury prodlouží

48 3.4 Proces zpracování faktur 48 Pokud dojde v k úhradě faktury v nové době splatnosti, platba se zaznamená a Use Case končí Pokud ani v nové době splatnosti nedojde k úhradě faktury, je pohledávka předána právnímu zástupci k řešení a Use Case končí Diagramy - faktura vystavená Obr. 28: Stavový diagram - zpracování faktury vystavené

49 3.4 Proces zpracování faktur 49 Obr. 29: Procesní diagram - zpracování faktury vystavené

50 3.4 Proces zpracování faktur 50 Obr. 30: Sekvenční diagram - zpracování faktury vystavené Scénář faktury přijaté Hlavní scénář zpracování faktury přijaté Sekretářka společnosti: 1. Přijme fakturu od dodavatele 2. Zaeviduje fakturu 3. Předá fakturu k odsouhlasení a) Pokud se jedná o fakturu za materiál, odsouhlasí ji vedoucí skladu, viz. Odsouhlasení faktury přijaté vedoucím skladu b) Pokud se jedná o jiný typ faktury, je předána ke schválení řediteli společnosti, viz Odsouhlasení faktury přijaté ředitelem společnosti 4. Pokud je faktura odsouhlasená, je provedena její úhrada, Use Case končí 5. Jestliže není faktura odsouhlasena, kontaktuje se dodavatel a předloží se mu připomínky a) Pokud se s dodavatelem domluví na nových podmínkách, vystaví se nová faktura a uhradí, Use Case končí

51 3.4 Proces zpracování faktur 51 b) Pokud dodavatel s připomínkami nesouhlasí, úhrada faktury neproběhne a celá věc se předá právnímu zástupci firmy, Use Case končí Hlavní scénář Odsouhlasení faktury přijaté vedoucím skladu Vedoucí skladu: 1. Přijme fakturu od sekretářky 2. Zkontroluje položky na faktuře s příslušným dodacím listem a) Pokud se položky shodují, fakturu odsouhlasí a předá zpět sekretářce b) Pokud se položky neshodují, oznámí skutečnost sekretářce Hlavní scénář Odsouhlasení faktury přijaté ředitelem společnosti Ředitel splečnosti: 1. Přijme fakturu od sekretářky 2. Zkontroluje položky na faktuře a) Pokud je faktura v pořádku, fakturu odsouhlasí a pokračuje se bodem 4 scénáře Zpracování faktury přijaté b) Pokud faktura není v pořádku, oznámí skutečnost sekretářce, pokračuje se bodem 5 scénáře Zpracování faktury přijaté

52 3.4 Proces zpracování faktur Diagramy - faktura přijatá Obr. 31: Stavový diagram - zpracování faktury přijaté

53 3.4 Proces zpracování faktur 53 Obr. 32: Procesní diagram - zpracování faktury přijaté

54 3.5 Zásobování 54 Obr. 33: Sekvenční diagram - zpracování faktury přijaté 3.5 Zásobování Posledním z obchodních procesů, kterým se práce zabývá je zásobování. Zásobování je důležitou součástí podniku, zejména je velmi blízce spojen s výrobním úsekem, který pro svoji činnost a stavební práce potřebuje materiál. Sklad materiálu firmy má na starosti vedoucí zásobování. Tento zaměstnanec má v popisu práce vedení veškeré skladové agendy a sledování stavu zásob. Na skladě se udržují převážně zásoby nejobvyklejšího materiálu, který je pro většinu zakázek společnosti používaný. Dále jsou zde ukládány chemické látky potřebné k montážním a stavebním pracím a vysokotlaké nádoby naplněny plynem pro svařování. Tyto nebezpečné látky jsou uloženy ve speciálních boxech k tomu určených a patřičně zabezpečeny. Vedoucí má přehled o zakázkách podniku. Před započetím prací na zakázkách jsou mu předány položkové rozpočty, na základě kterých zjistí, jaký materiál je třeba objednat. Pokud dojde k nečekaným změnám v množství nebo druhu materiálu v průběhu plnění zakázek, je o tomto informován od vedoucího referenta realizace zakázek a na základě společné konzultace se materiál objedná. Vedoucí skladu má tedy na starost vedení záznamů o stavu materiálu na skladě a objednávání nového, potřebného materiálu. Po objednání materiálu od dodavatele se čeká na jeho doručení na sklad. Vedoucí zásobování na základě objednávky a dodacího listu zkontroluje, zda je fyzicky zboží v pořádku, pokud ano, zboží přijme a je

55 3.5 Zásobování 55 nachystané k naskladnění. Ke každému zboží se vypisuje příjemka na sklad a zapíše se do skladové karty společně s dodacím listem. Poté se zboží uloží na připravené místo a čeká se na jeho vyskladnění na zakázku. Při vyskladnění materiálu se vypíše výdejka a vyskladněný materiál se odepíše ve skladové kartě. Poté je předán přejímající osobě. Pokud se při vyskladňování zjistí, že je materiálu nedostatek, objedná se u dodavatele. Na základě předchozího popisu dochází k nakupování a vyskladňování materiálu ze skladu. Dále bude vedle naskladnění a vyskladnění materiálu rozveden jeho nákup a výběr dodavatelů. Každý nákup materiálu je nějakým způsobem iniciován. Iniciován může být více faktory, může se jednat například o: plnění smluv se zákazníkem - realizace zakázky pořízení a udržování (opravy) technického vybavení ostatní interní potřeby Pokud dojde k některému z výše jmenovaných faktorů k iniciování nákupu, je podán návrh na objednání zboží. Návrh na objednání zboží podává nejčastěji stavbyvedoucí, pokud se jedná o materiál na zakázky. V případě, že se jedná o jiný materiál nebo kancelářské vybavení, podává návrh libovolný zaměstnanec firmy. Tento návrh je dále schválen ředitelem firmy, který jej předá vedoucímu zásobování. Ještě před samotnou objednávkou je třeba provést výběr vhodného dodavatele. Dodavatel se vybere buď podle adresáře dodavatelů, se kterými firma již spolupracovala, pokud se jedná o zboží, pro které nemá firma svého dodavatele, je uplatněno poptávkové řízení - odeslání poptávky dodavateli, který firmě pošle svoji nabídku. Na základě předchozích výsledků může vedoucí zásobování vystavit objednávku dodavateli Scénáře Hlavní scénář Nákup materiálu Ředitel firmy: 1. Přijme od zaměstnance návrh na objednání zboží 2. Schválení návrhu na objednání a) Ředitel návrh schválí b) Ředitel návrh neschválí, Use Case končí 3. Výběr vhodného dodavatele materiálu a objednávka podle scénáře Výběr dodavatele 4. Naskladnění objednaného materiálu podle scénáře Naskladnění materiálu

56 3.5 Zásobování 56 Hlavní scénář Výběr dodavatele Vedoucí zásobování: 1. Přijme od ředitele schválený návrh na objednání zboží nebo materiálu 2. Zjistí dodavatele daného zboží 3. Podle adresáře dodavatelů zjistí, zda firma s dodavatelem již spolupracovala a) Pokud spolupracovala, kontaktuje firmu a předá jí objednávku zboží, Use Case končí b) Jestli firma s dodavatelem nespolupracovala, odešle dodavateli poptávku na zboží 4. Vyhodnocení nabídky firem a) Jestliže je nabídka přijatelná, kontaktuje dodavatele a předá mu objednávku, Use Case končí b) Jestli je nabídka nepřijatelná, zjistí jiného dodavatele a pokračuje se bodem 3 Hlavní scénář Naskladnění materiálu Vedoucí zásobování: 1. Přijme od dodavatele materiál s dodacím listem 2. Kontrola dodaného materiálu a porovnání s dodacím listem a objednávkou a) Pokud se materiál shoduje s položkami na dodacím listu, přijme jej k naskladnění b) Pokud se položky neshodují s dodávkou, materiál nepřijme a Use Case končí 3. Vypsání příjemky materiálu na sklad 4. Zapsání materiálu do skladové karty a jeho uložení na sklad Hlavní scénář Výdej materiálu ze skladu Vedoucí zásobování: 1. Přijme od zaměstnance firmy požadavek na výdej materiálu 2. Pokud není materiál na skladě, pokračuje se scénářem Nákup materiálu 3. vytvoří výdejku materiálu a předá materiál zaměstnanci 4. zapíše vydaný materiál do skladové evidence, Use Case končí

57 3.5 Zásobování Diagramy procesu objednání zboží Obr. 34: Stavový diagram - Objednání zboží a jeho naskladnění

58 3.5 Zásobování 58 Obr. 35: Procesní diagram - proces objednání zboží na sklad

59 3.5 Zásobování 59 Obr. 36: Sekvenční diagram - proces objednání zboží na sklad Diagramy procesu naskladnění zboží Obr. 37: Sekvenční diagram - naskladnění zboží

60 3.5 Zásobování 60 Obr. 38: Procesní diagram - naskladnění zboží

61 3.6 Diagramy tříd Diagramy tříd Diagram tříd představuje statickou část systému. Na následujících obrázcích je vyobrazen celkový pohled na třídy v systému a poté je celek rozdělen na jednotlivé části, u kterých jsou zobrazeny atributy a operace jednotlivých tříd a také jejich vzájemné vztahy. Následující obrázek zachycuje pohled na diagram tříd v jeho celkovém zobrazení. Obr. 39: Diagram tříd - celkový pohled

62 3.6 Diagramy tříd Třídy v procesu zpracování poptávky Následující diagram zobrazuje třídy v procesu zpracování poptávky od zákazníků. Každá třída má své atributy a operace. Operace jsou si u většiny tříd podobné. Veškeré důležité údaje lze vyčíst z následujícího obrázku. Obr. 40: Diagram tříd - poptávka a nabídka

63 3.6 Diagramy tříd Třídy v procesu objednávka Diagram tříd v procesu objednávka zachycuje třídy, jejich atributy a operace v procesu přijetí objednávky od zákazníka až po sepsání smlouvy o dílo. Obr. 41: Diagram tříd - objednávka Třídy v procesu fakturace Obr. 42: Diagram tříd - fakturace Třída faktura vyjadřuje hlavičku faktury se všemi nezbytnými údaji a operace, které se s touto třídou provádí. Tato třída se dále rozděluje na fakturu přijatou a fakturu vydanou. Podle toho a jaký typ dokladu se jedná se použijí vhodné atributy. Třída Položka faktury znamená každou jednotlivou položku na faktuře.

64 3.6 Diagramy tříd Třídy v procesu zásobování Následující obrázek ukazuje diagram tříd pro zásobování. Třída Skladová evidence zachycuje údaje o celkovém stavu materiálu na skladě. Její součástí jsou třídy Skladová karta a Skladový doklad. Třídu Skladový doklad lze dále rozdělit na třídy Příjemka a Výdejka, což je zobrazeno podřízenými třídami. Třída skladová karta zaznamenává údaje o množství materiálu na skladě a pohyb s ním. Položka skladový doklad zobrazuje jednotlivé položky materiálu na skladovém dokladu, jejich množství a další podrobné informace. Následující obrázek vše zachycuje v grafické podobě. Obr. 43: Diagram tříd - Zásobování Na předchozích diagramech jsou zachyceny jen nejdůležitější třídy procesů, kterými se práce zabývá. Další detaily tříd jako například třída Zaměstnanec nebo třída Obchodní partner jsou zobrazeny v přílohách práce.

65 4 REENGINEERING VYBRANÝCH PROCESŮ 65 4 Reengineering vybraných procesů V práci byly namodelovány obchodí procesy ve firmě Rekstan, spol. s.r.o. Vybrané namodelované procesy byly analyzovány, aby došlo k zjištění jejich nedostatků a v případě jejich zjištění byly navrhnuty patřičné úpravy. Prvními analyzovanými celky bylo vyřizování poptávek a objednávek zákazníků. Tyto procesy nejsou nijak automatizovány a jsou prováděny ručně. V současné podobě a při současném množství poptávek a objednávek je není třeba nijak upravovat. Problém by mohl nastat, pokud by došlo k navýšení poptávek od zákazníků. Větší množství by nemusely zaměstnanci plnit v požadovaných termínech. Zde je prostor pro reengineering procesu. Proces by mohl být upraven následujícím způsobem. Na webových stránkách firmy se vytvoří poptávkový formulář, do kterého by zákazník po registraci napsal svoje požadavky a měl možnost vložit soubory včetně projektové dokumentace, která je při vyřizování poptávky nezbytná. Takto zvolená data by se nahrála do IS firmy, kde by ji přijal rovnou vedoucí úseku zpracování zakázek, který by vykonal potřebné zákroky a poptávka by byla automaticky předána dále ke zpracování. Po přihlášení zaměstnance k systému by se zjistily jeho oprávnění a poptávka by se zobrazila spolu s potřebnými kroky, které na ní musí vykonat. Vedoucí úseku by měl možnost kontrolovat stav, ve kterém se poptávka nachází. Po vykonání veškerých potřebných operací by nabídku vedoucí schválil a odeslal zákazníkovi. V tomto případě by informační systém urychlil příjem poptávky, ale také její následné zpracování. Dále by celé vytváření nabídky bylo lépe kontrolovatelné, byla by ulehčena komunikace mezi zaměstnanci, a tím by se také zvýšila kvalita a rychlost jejich práce. Toto řešení má ale také své nevýhody, kterými jsou náklady, které je třeba vynaložit na pořízení a zprovoznění informačního systému ve firmě a dále náklady potřebné pro jeho provoz a pravidelnou údržbu. Upravený proces zpracování poptávek zákazníků je zobrazen na následujícím obrázku.

66 4 REENGINEERING VYBRANÝCH PROCESŮ 66 Obr. 44: Sekvenční diagram - Reengineering procesu zpracování poptávky Dalším procesem je zpracování faktur. Jedná se o faktury vydané a faktury přijaté. K tomuto účelu je ve firmě používaný specializovaný software SB Komplet, pomocí kterého se faktury vytváří a evidují. Tato oblast zcela vyhovuje požadavkům společnosti a není třeba ji nijak upravovat. Při analýze procesu zásobování bylo zjištěno, že nedochází k důkladné kontrole kvality přijímaného materiálu od dodavatelů, která je v případě zavedeného managementu jakosti nezbytná. Nabízí se zde tedy prostor, pro mírnou úpravu procesu. Společnost by se měla více zaměřit na vstupní kontrolu materiálu. Kontrolu by měl provádět vedoucí zásobování u materiálu přijímaného na sklad. Pokud se jedná o rozměrnější materiál, který je dodáván přímo na místo realizace zakázky, kontroluje kvalitu stavbyvedoucí. Kontrola kvality spočívá v náhodné kontrole jednotek materiálu u každé přijaté dodávky. Kontrola jakosti probíhá podle interních směrnic firmy Rekstan, spol. s.r.o. pro kontrolu jakosti zboží. Budou se kontrolovat například rozměry materiálu, značení, složení, bezpečnostní listy, prohlášení o shodě nebo atesty. Pokud dodaný materiál projde vstupní kontrolou, je možné jej přijmout na sklad a uložit. Procesní diagram inovovaného procesu je k nahlédnutí v příloze na obrázku č. 48. Další mírnou inovací v procesu objednávky zboží bude schvalování návrhu objednávek. V současné době schvaluje veškeré objednávky ředitel společnosti. Tento proces by bylo možné mírně upravit. Ředitel by stále mohl schvalovat veškeré objednávky, ale jeho schválení by bylo nezbytně nutné pouze u objednávek nad Kč. Objednávky, které by nepřesáhly tuto sumu by měl v kompetenci schvalo-

67 4 REENGINEERING VYBRANÝCH PROCESŮ 67 vat Vedoucí referent realizace zakázek. Tímto krokem by došlo k odlehčení činností ředitele a předání pravomocí by také zrychlilo proces objednávání zboží. Následující obrázek zachycuje procesní diagram, na kterém je zobrazen inovovaný proces zpracování objednávek materiálu. Obr. 45: Procesní diagram - Upravený proces schvalování objednávek

68 5 DISKUZE 68 5 Diskuze Firma Rekstan, spol. s.r.o. si za dobu svého působení na trhu upevnila svoje postavení mezi zákazníky i dodavateli a stále rozšiřuje pole svého působení. Společnost prošla dlouhým vývojem a díky usilovné práci svých zaměstnanců má dnes pevné postavení na trhu a mnoho spokojených zákazníků. Jedním z důležitých milníků v historii společnosti bylo, když firma v roce 2000 zavedla management jakosti a v současné době vlastní certifikát jakosti ČSN EN ISO 9001:2008. Firma má veškeré své oddělení v jedné budově. Budova je připojena na internet prostřednictví poskytovatele O2, který je dále distribuován z datového rozvaděče mezi klienty pomocí sítě LAN. Ve firmě není doposud zaveden žádný automatizovaný informační systém, který by umožňoval automatizaci procesů. Jen některá oddělení využívají specializovaný software. V současné době vedení společnosti neuvažuje o pořízení specializovaného informačního systému a to zejména z finančních důvodů. Ovšem do budoucna je jedním z dlouhodobých cílů firmy rozšířit pole své působnosti a současně s rozšířením působnosti by bylo vhodné zavést IS, který by zjednodušil a urychlil administrativní činnosti. Při procesní analýze nebyly zaznamenány žádné vážné nedostatky. Dá se říct, že současná podoba vykonávání jednotlivých obchodních činností v podniku funguje, proto navrhované úpravy nejsou nijak zásadní. První navrženou změnou je reengineering procesu zpracování poptávek od zákazníků. Tato změna procesu není v současné době nezbytně nutná. Zaměstnanci vyřizování poptávek zvládají v požadovaných termínech a vše vyhovuje. Ovšem v budoucnu by se tato situace mohla změnit a firma by se již nyní měla zajímat o navrhovanou úpravu procesu, protože v případě zvýšení poptávek by nemusela být kapacita pro jejich zpracování dostatečná. Jak jsem zjistil z konzultací s Ing. Pavlem Skočovským, ředitelem společnosti, tak právě s tímto stavem je možné, že se bude společnost potýkat, neboť v dlouhodobých cílech a vizích společnosti je mimo jiné rozšíření oblasti a předmětů jejího podnikání. V tomto případě by již zaměstnanci nemuseli zvládat zpracovávat poptávky zákazníků. Aby se předešlo tomuto případu, bylo by vhodné zavést informační systém, který by proces zautomatizoval a ulehčil práci zaměstnancům, co nejdříve. Implementace informačního systému je pro malou firmu velmi nákladná a významná investice, ale její přínos může mít značný význam pro budoucí vývoj společnosti. Přínosnost této investice by spočívala zejména v rychlejším vyřizování poptávek zákazníků a v možnosti zvýšit kapacitu pro jejich zpracování. Tím by došlo k uspokojení většího množství zákazníků a ke zkrácení potřebné doby pro zpracování poptávek. Dalším očekávaným efektem při vyřízení poptávek pro větší množství zákazníků se předpokládá zvýšení zisku společnosti. U příjmu materiálu na sklad je nezbytné firmě doporučit, aby v rámci procesu byl kladen větší důraz na kontrolu kvality přebíraného materiálu. Bylo zjištěno, že kontrola je v současnosti zanedbávána. Tato kontrola by v případě držení certifikátu jakosti ČSN EN ISO 9001:2008 měla být samozřejmostí. Bylo by tedy vhodné, aby

69 5 DISKUZE 69 se zaměstnanci na tuto kontrolu více soustředily. Došlo by tím zejména ke snížení reklamací, protože případné nedostatky u materiálu by mohly být zjištěny již při jeho přebírání od dodavatele a firma by jej nemusela vůbec přijmout. Dále je možnost zefektivnit proces nákupu materiálu a tím zjednodušit řediteli schvalování návrhů na objednání zboží. Nyní ředitel schvaluje veškeré objednávky, v případě zefektivnění procesu by ředitel společnosti schvaloval jen objednávky, které by přesáhly hranici Kč. Tento krok by měl umožnit zrychlit schvalování objednávek a současně by se ředitel mohl věnovat jiným řídícím činnostem. Všechny navržené inovace povedou k zefektivnění a ke zkvalitnění obchodních procesů ve firmě Resktan, spol. s.r.o., ovšem jejich skutečný finanční přínos nelze v současnosti vyčíslit z důvodu nedostatku potřebných informací.

70 6 ZÁVĚR 70 6 Závěr Cílem mé práce bylo vytvoření procesního modelu vybraných obchodních procesů společnosti Rekstan spol. s.r.o. pomocí standardního profilu jazyka UML pro procesní modelování. Na základě vytvořeného modelu zhodnotit současný stav obchodních procesů ve firmě a navrhnout změny pro zvýšení efektivity těchto procesů. U navrhovaných úprav poté zhodnotit jejich přínos pro firmu. Část práce je věnována analýze současného stavu podnikových obchodních procesů a tvorbě jejich modelů s využitím CASE nástroje Enterprise Architect podle standardního profilu UML pro procesní modelování. Byly namodelovány procesy zpracování poptávek a objednávek od zákazníků, dále proces zpracování faktur a zásobování. Pro každý proces byl namodelován stavový diagram, procesní diagram a sekvenční diagram. Dále byl pro každý celek vytvořen diagram tříd. Pro nejlepší pochopení podnikových obchodních procesů ve firmě Rekstan, spol. s.r.o. se jeví jako nejvhodnější právě procesní diagramy, které jsou založeny na diagramu aktivit, a sekvenční diagramy. Tyto diagramy nám dávají jasný pohled na proces, na jeho dílčí aktivity a zobrazují spolupráci mezi jednotlivými objekty v rámci procesu. Na základě procesní analýzy byl ve čtvrté kapitole zhodnocen současný stav obchodních procesů ve společnosti a v případě potřeby byly u vybraných procesů navrhnuty změny pro zvýšení jejich efektivity. Přínosy těchto navrhovaných úprav procesů jsou zhodnoceny v páté kapitole práce. Všechny vymezené cíle práce byly tedy splněny. Celou práci jsem předal řediteli společnosti panu Ing. Pavlu Skočovskému a je jen na jeho uvážení, zda navrhované úpravy podnikových procesů budou realizovány v praxi.

71 7 LITERATURA 71 7 Literatura Řepa, V. Podnikové procesy: Procesní řízení a modelování. 2. aktualizované a rozšířené vydání. Praha: Grada, s. ISBN Kanisová, H., Müller, M. UML srozumitelně. 2. aktualizované vydání. Brno: Computer Press, s. ISBN Arlow, J., Neustadt, I. UML 2 and the unified process: practical object-oriented analysis and design. 2nd ed. Upper Saddle River: Pearson Education, s. ISBN Fowler, M. Destilované UML. Praha: Grada, s. ISBN Page-Jones, M. Základy objektově orientovaného návrhu v UML. Praha: Grada, s. ISBN X. Rábová, I. a kol. Podniková architektura - strategický nástroj v rukou manažera. Brno: Tribun EU, s. ISBN Eriksson, H., Penker, M. Business Modeling with UML: Business Patterns at Work. New York: John Wiley & Sons, s. ISBN Perry, S. Process modelling comparison. [online]. [cit ]. Dostupné z:

72 Přílohy

73 A DIAGRAMY TŘíD 73 A Diagramy tříd Obr. 46: Diagram tříd - Zaměstnanec

74 A DIAGRAMY TŘíD 74 Obr. 47: Diagram tříd - Obchodní partner

75 B NÁVRH INOVACE 75 B Návrh inovace Obr. 48: Procesní diagram - Upravený proces naskladnění materiálu