Modelování podnikových procesů a návrh informačního systému ve firmě UNIKOL s.r.o.

Transkript

1 Mendelova univerzita v Brně Provozně ekonomická fakulta Modelování podnikových procesů a návrh informačního systému ve firmě UNIKOL s.r.o. Diplomová práce Vedoucí práce: doc. Ing. Ivana Rábová, Ph.D. Bc. Ludvík Mikulenka BRNO 2010

2 Na tomto místě bych rád poděkoval vedoucí mé diplomové práce doc. Ing. Ivaně Rábové, Ph.D. za její cenné rady a připomínky v průběhu tvorby této práce. Dále bych také rád poděkoval všem zaměstnancům společnosti UNIKOL s.r.o., za jejich náměty a pomoc zvláště při tvorbě realizace aplikace.

3 Zadání

4 Prohlašuji, že jsem tuto diplomovou práci řešil a zpracoval samostatně, na základě metodických pokynů vedoucí mé diplomové práce a za použití literatury, kterou uvádím v seznamu na konci práce. V Brně 20. května

5 5 Abstract Mikulenka, L. Business process modeling and design of information system in the company UNIKOL s.r.o. Diploma thesis. Brno, 2010 This diploma thesis deals with the process analysis in the company UNIKOL s.r.o. and its main aim is the design innovations of the current information system, based on object-oriented analysis of business processes. Based on this analysis are proposed options for the innovation of corporate information systems, including their financial value. Subsequently, one selected innovations for which they are created by the most important UML diagrams, and is also implemented in the form of software applications. Abstrakt Mikulenka, L. Modelování podnikových procesů a návrh informačního systému ve firmě UNIKOL s.r.o. Diplomová práce. Brno, Diplomová práce se zabývá procesní analýzou ve společnosti UNIKOL s.r.o. a jejím hlavním cílem je návrh inovací současného informačního systému, který vychází z objektové analýzy podnikových procesů. Na základě této analýzy jsou navrženy možnosti pro inovace podnikového informačního systému, včetně jejich finančního zhodnocení. Následně je vybrána jedna inovace, pro kterou jsou vytvořeny nejdůležitější UML diagramy, a je také realizována ve formě softwarové aplikace.

6 6 Obsah 1 Úvod a cíl práce Úvod do problematiky Cíl práce Literární přehled Procesní řízení Procesní modelování Jazyk UML Metodika Unified Process Struktura jazyka UML Diagramy jazyka UML Business Process model Modelování případů užití (Use Case Diagram) Modelování tříd a objektů Diagram aktivity Sekvenční diagram Stavové digramy Entitně-relační diagram (ERD) Metodika Práce Analyzovaná společnost UNIKOL s.r.o Charakteristika společnosti Struktura společnosti Současný stav informačního systému Vlastní práce Procesní model Řízení obchodu Řízení skladu Finanční řízení Současná softwarová podpora firemní procesů Možnosti inovace informačního systému společnosti Inovace stávajících modulů informačního systému Dokoupení a integrace dalších programových modulů... 40

7 Kompletní integrace nového informačního systému Návrh inovace IS řízení skladové evidence (MTZ) Případy užití a aktéři systému MTZ Diagram tříd systému MTZ Diagram aktivit - příjem skladové položky Sekvenční diagram Stavový diagram Realizace inovace systému řízení skladové evidence Datová struktura Aplikační logika Řízení a správa skladové evidence (package MTZ) Správa uživatelů (package Uživatel) Správa firem (package Firma) Export dat a spojovací soubor Grafické uživatelské rozhraní Diskuse a závěr Literatura Seznam obrázků a tabulek Seznam obrázků Seznam tabulek Přílohy A. Diagram případů užití MTZ celkový pohled... 66

8 8 1 Úvod a cíl práce 1.1 Úvod do problematiky Informační systémy jsou v dnešní době již nedílnou součástí většiny společností bez ohledu na to, v jakém oboru, či odvětví tyto společnosti působí. Navíc díky neustále se zvětšujícímu konkurenčnímu boji má dnes zákazník mnohem větší možnost volby a přechod ke konkurenci je pro něj jednodušší než kdykoliv dříve. Právě proto je dnes velice důležité zaměřit se na potřeby zákazníka a vhodně navržený a realizovaný informační systém může být v tomto směru klíčovým zdrojem všech informací spojených nejen se všemi procesy, se kterými se zákazník při svém styku se společností setkává, ale také všech ostatních procesů, spojených s fungováním jakékoliv firmy. Moderní informační systém by tak měl nejen zajišťovat podporu všech těchto procesů, ale především poskytnout dostatek informací pro usnadnění jejich optimalizace a také nástroje pro podporu manažerského rozhodování nebo usnadnění komunikace se všemi externími subjekty, které si s organizací vyměňují jakékoliv informační toky. Před samotným nasazením informačního systému do společnosti je nutné strukturu procesů a informačních toků s nimi spojených analyzovat, navíc je vždy nutné promítnout do těchto procesů požadavky jak zaměstnanců společnosti, tak externích subjektů. Nicméně je nutné počítat také se změnami, které mohou být spojeny s fungováním a vývojem společnosti, a proto jsou následné inovace informačního systému stejně důležité, jako jeho prvotní návrh a realizace. Díky moderním CASE (Computer-aided software engineering) nástrojům má analýza a následné modelování těchto procesů a informačních toků velice dobrou softwarovou podporu a to umožňuje ještě efektivnější a kvalitnější vývoj informačních systémů ve všech fázích jeho životního cyklu. 1.2 Cíl práce Cílem této diplomové práce je vytvoření procesního modelu ve firmě UNIKOL s.r.o. pomocí notace UML a prostřednictvím CASE nástroje Enterprise Architect od společnosti Sparx Systems. Tato analýza bude sloužit jako podklad pro zhodnocení stávajícího stavu informačního systému ve společnosti a aktuální softwarovou podporu procesů nalezených při analýze. Z tohoto zhodnocení budou vycházet případné návrhy inovací jednotlivých částí systému, popř. návrh částí nových, které ještě stávající informační systém neobsahuje (podpora dalších důležitých firemních procesů). Toto zhodnocení by mělo také obsahovat ekonomickou úvahu nad investiční zátěží, kterou by musela firma UNIKOL s.r.o. vynaložit na tyto inovace. Ekonomická

9 úvaha by měla obsahovat několik variant pro srovnání, náklady spojené s případnými inovacemi jsou totiž pro společnost stěžejní. Z těchto inovací pak bude vybrána jedna konkrétní pro realizaci. Před samotnou realizací bude provedena analýza opět pomocí notace UML a jejích diagramů. Samotná realizace bude vytvořena v programovacím jazyku JAVA (grafické uživatelské rozhraní SWING) s využitím relační databáze MySQL. Tuto aplikaci by mělo být možno integrovat do stávajícího systému. 9

10 10 2 Literární přehled 2.1 Procesní řízení Před samotným popisem procesního řízení je nutné definovat podnikový proces. Podle (Řepa, 2007) je podnikový proces souhrn činností, které transformují určitou skupinu vstupů na jinou skupinu výstupů (zboží nebo služeb) pro jiné lidi, či procesy. K této transformaci jsou využíváni lidé nebo jiné nástroje a je pro ni podstatná především tvorba přidané hodnoty pro zákazníky podniku. Tyto podnikové procesy mohou být rozděleny do tří kategorií (Sodomka, 2006): Řídící procesy (strategické plánování, řízení kvality) jejich úkolem je zajištění rozvoje a řízení výkonnosti společnosti a vytváření podmínek pro správné fungování ostatních podnikových procesů. Hlavní procesy (výroba, logistika, řízení vztahů se zákazníkem) vytvářejí hodnoty v podobě výrobků a služeb pro zákazníky společnosti, jsou nedílnou součástí hodnotového řetězce celé organizace. Podpůrné procesy (ekonomika, personalistika, IT) zajišťují podmínky pro správné fungování ostatních procesů v organizaci dodáním hmotných, či nehmotných výstupů, tyto procesy však nejsou součástí hodnotového řetězce. Cílem procesního řízení je tedy rozvíjet a optimalizovat fungování celé organizace. Jedná se tedy o soubor činností týkajících se plánování a sledování výkonnosti především realizačních firemních procesů s využitím znalostí, zkušeností, dovedností, nástrojů, technik a systémů k definování, vizualizaci, měření, kontrole, informování a zlepšování procesů, s cílem splnit požadavky zákazníka za současné optimální rentability svých aktivit. Přechod na procesní řízení by tak mohl být pro každou organizaci klíčovým rozhodnutím. Důvodem pro tento přechod může být: Zjednodušení zaměření na zjednodušení, zrychlení a zefektivnění stávajících procesů v organizaci. To je dosahováno především průběžným nahrazováním papírových agend počítačovými procesními modely, u kterých lze dynamicky simulovat, kvantifikovat a ověřovat, zda se dosáhne projektované výkonnosti a zlepšení. Efektivita procesní řízení automatizuje pořadí činností a s nimi spojená pravidla, přičemž nutí pracovníky a příslušné systémy k dodržování těchto pravidel a sleduje také dokončování prací v daných termínech. Výsledkem je významná redukce časových cyklů (větší objem práce bez nárůstu počtu pracovníků). Soulad a kontrola převzetím kontroly nad procesy a vynucováním pravidel, zajišťuje procesní řízení soulad nejen s politikami a regulačními požadavky organizace, ale i s nejnovějšími poznatky zaměřenými na výkonnostní cíle. Podporuje tak opakované použití procesních fragmentů po celé firmě, přičemž dovoluje obměny tam, kde je to zapotřebí.

11 11 Agilita s využitím architektury orientované na služby (SOA) odhaluje možnosti opakovaného využití a propojení nových i existujících IT prostředků jako komponent IT služeb a tím snižuje náklady a pracnost integrace aplikačních systémů standardizací rozhraní mezi komponentami. Nabízí také modifikaci těchto služeb na základě měnících se potřeb zákazníků. Průběžné zlepšování hlavním úkolem procesního řízení je celková optimalizace jednotlivých procesů v organizaci. Díky tomu také dochází k průběžnému zlepšování jednotlivých procesů se záměrem lepšího plnění stanovených strategických cílů v organizaci. (ITIL, 2007) Procesní řízení každé organizace začíná na strategické úrovni stanovením strategických cílů a postupů, pomocí kterých lze těchto stanovených cílů dosáhnout. Definice hlavních podnikových procesů následně vychází z tohoto základu. Tyto procesní aktivity jsou založeny na procesních modelech a jsou poté implementovány uvnitř i napříč organizacemi. Hlavní a podpůrné procesy jsou poté řízeny a integrovány prostřednictvím podnikových informačních systémů (Enterprise Resource Planning, Customer relationship management a jiné). Obrázek 1: Procesní model tříúrovňové architektury (Sodomka, 2006) Především díky měření a kontrole vnitropodnikových procesů je kladen největší důraz na průběžné zlepšování procesů v celé organizaci. To je započato v době, pokud jsou zjištěny rozdíly mezi klíčovými výkonnostními indikátory (Key

12 12 Performence Indicators) stanovenými na strategické úrovni a skutečnými hodnotami KPI (pokud nedošlo k zásadním proměnám okolních či vnitřních podmínek v organizaci, v tom případě je nutné provést změny na strategické úrovni). Tímto způsobem se organizace dokáže rychle adaptovat na okolní změny. Díky tomu, že management může všechny tyto procesy plně ovládat, se mohou v rámci procesního řízení podnikové procesy dále dělit na: Interní procesy tyto má vedení podniku pod svou kontrolou a může jim přidělit osobu odpovědnou za jejich chod a inovace. Externí procesy vedení nemá plnou kontrolu, jedná se o procesy spadající do řízení vztahů se zákazníky nebo řízení dodavatelského řetězce. (Sodomka, 2006) 2.2 Procesní modelování Jak uvádí (Řepa, 2007) podnikový proces je vždy modelován jako struktura vzájemně na sebe navazujících činností. Z toho tedy vyplývá, že jakákoliv činnost, která vyplývá z běžného fungování organizace, může být samostatně popsána jako proces (tzv. princip sémantické relativity hlavním typem hierarchické abstrakce v procesní struktuře je agregace). Mezi základní prvky každého modelu jakéhokoliv podnikového procesu patří: Proces Činnost Podnět Vazba návaznost Jakákoliv činnost v organizaci vzniká na základě předem daných podnětů. Z hlediska jednotlivých procesů, mohou být tyto podněty vnější, nebo vnitřní. Tyto vnější podněty, které vznikají v okolí procesů, jsou nazývány událostmi. Naopak vnitřní podněty, které jsou na rozdíl od vnějších subjektivní, jsou nazývány stavem procesu. Činnosti jednotlivých procesů jsou řazeny do jednotlivých návazností, které tvoří definovanou strukturu. Tyto návaznosti jsou poté popsány pomocí vazeb, kterými jsou definována typová uspořádání činností v procesu. Procesní modelování lze podle (Rábová a kolektiv, 2008) rozdělit na tři základní typy. Jsou to: Procesní nebo funkční modelování procesů to se zaměřuje na nejvyšší úroveň pohledu na aktivity dané organizace, dále také na faktory řídící tyto aktivity a v poslední řadě na výsledky těchto aktivit. Modelování procesních toků toto je známé také jako workflow modelování, či modelování aktivit (soustřeďuje se na jednotlivé procedury a na rozhodování, které je obsaženo ve vykonávání jednotlivých aktivit, a tok informací mezi jednotlivými procesy). Modelování datových toků zaměření na aktivity zpracovávající data.

13 13 Použití těchto typů modelování závisí pouze na organizaci vykonávající procesní modelování. Modelování procesů může například odhalit některé procesy, které nevytvářejí žádné výsledky. Díky modelování procesních toků mohou být také označeny duplicitní nebo opakované úlohy. Datové modelování má za úkol zjistit, zda nejsou informace uloženy na více místech, nebo zda různé procesy nepřepisují stejná data. 2.3 Jazyk UML Tento unifikovaný modelovací jazyk (Unified Modelling Language) slouží jako univerzální jazyk pro modelování informačních systémů a je navržen takovým způsobem, aby mohl být implementován jakýmkoliv CASE (computer-aided software engineering) nástrojem. Nabízí proto vizuální syntaxi, která je využívána při sestavování modelů. Jazyk samotný však nepředstavuje metodiku jako takovou, UML je využíváno především metodikou Unified Process právě jako standardní notace vizuálního modelování. UML se snaží o unifikaci především těchto domén: Vývojový cyklus jazyk poskytuje prostředky vizuální syntaxe, kterou je možno aplikovat ve všech vývojových cyklech softwarového projektu. Aplikační domény byl vytvořen jako nástroj pro modelování jakéhokoliv systému (systémy pracující v reálném čase i podpůrné systémy). Implementační jazyky a platformy UML je nezávislý na jakékoliv platformě či programovacím jazyku. Nabízí však vynikající podporu především pro objektově orientované programovací jazyky, jakými jsou např. Java nebo C#. Vývojové procesy jazyk podporuje velké množství metodik používaných při vývoji softwarového vybavení (asi nejvíce upřednostňovanou metodikou je výše zmíněná metodika UP). Vlastní interní pojmy vnitřní jednota a konzistence je zajišťována prostřednictvím množiny interních pojmů. (Arlow, Neustadt, 2007) Jak uvádí (Řepa, 2007), UML je založen na principu vícevrstvé architektury, která zajišťuje jeho potřebnou otevřenost. Je totiž specifikován tak zvaným meta-modelem. Ten lze chápat jako model modelů, ve smyslu modelu modelovacího jazyka. Díky této koncepci poté vznikl jazyk MOF (Meta Object Family). V tomto pojetí je tedy v dnešní době architektura UML čtyřúrovňová. V nejnižší vrstvě této architektury se nachází exempláře. Ty mohou být chápány jako jednotlivé instance modelu, čili uživatelské objekty implementované v cílovém prostředí. Nad vrstvou exemplářů se nachází vrstva modelů. Ten představuje abstrakci uživatelských objektů. Lze si pod ním představit např. logický nebo konceptuální model databáze.

14 14 Další vrstvou této architektury je vrstva meta-modelů, pomocí kterých jsou definovány základní elementy se vztahy mezi nimi a principy vytváření modelů daného druhu. Meta-model UML definuje soustavu modelů (ty se dělí na tzv. balíčky), vztahy mezi nimi, ostatní pomocné definice a různé pohledy na modely. Poslední částí architektury UML Meta-meta-model vymezující základní výrazové prostředky meta-modelu. Třída meta-modelu je tedy instancí meta-třídy z meta-meta-modelu. Meta-třídy, meta-operace, či meta-atributy jsou proto nedílnou součástí této nejvyšší části architektury jazyka UML. Obrázek 2: Čtyřúrovňová architektura UML (Řepa, 2007) Metodika Unified Process Metodika Unified Software Development Process (USDP) je průmyslovým standardem metodiky tvorby softwarového vybavení a pochází od autorů UML. Tato metodika se tedy snaží odpovědět na základní otázky co, kdo, kdy a jak při tvorbě jakéhokoliv softwarového díla. Jedná se o proces, který realizuje požadavky uživatelů pomocí softwarového vybavení. Tato metodika je ale pouze obecnou metodou tvorby softwaru, proto je nutné pro každou organizaci a jednotlivé projekty vytvořit novou instanci této metodiky. Je tedy zřejmé, že by se měl každý takovýto softwarový projekt od ostatních alespoň v některých aspektech lišit. Při procesu tvorby jednotlivých metodik v organizacích je proto třeba definovat a začlenit tyto struktury: Vnitropodnikové standardy Šablony dokumentů

15 15 Nástrojů překladače, nástroje pro správu konfigurace, atd. Databáze sledování projektu. Úpravy životnosti např. zlepšení měřítek pro kontrolu kvality, která jsou používána v bezpečnostních systémech. Důležitým aspektem UP je, že vychází z iterativního a přírůstkového procesu. Celkový softwarový projekt je tak vždy rozložen na větší počet menších projektů, kdy každá z těchto menších částí je považována za jednu iteraci. Samotná iterace pak obsahuje všechny obvyklé prvky softwarového projektu, kterými jsou: Zjištění požadavků zaměření na to, co by vlastně měl systém dělat. Analýza z požadavků je vytvořena jednotná struktura. Návrh realizace jednotlivých požadavků na systém. Implementace tvorba softwarového díla. Testování ověření správné funkčnosti implementace Díky tomuto rozložení na jednotlivé iterace je možné mnohem lépe rozvrhnout plánování celého projektu a zajistit nejlepší možnou časovou posloupnost takovýchto iterací. (Arlow, Neustadt, 2007) Obrázek 3: Pracovní postupy jednotlivých iterací (Arlow, Neustadt, 2007) Celá metodika UP se skládá ze čtyř na sebe navazujících fází. Jedná se o fázi zahájení, rozpracování, konstrukce a zavedení. Každá je také ukončena milníkem, který představuje cíle v jednotlivých fázích, kterých by mělo být na jejich konci dosaženo. Jak již z názvu vyplývá, cílem fáze zahájení je odstartování celého projektu. Zaměřuje se především na tvorbu podmínek proveditelnosti (návrh technických prototypů), srovnání podobných podnikatelských případů, na kterých lze dokázat kvantitativní obchodní přínos nového softwarového systému. Je také potřeba definovat základní požadavky, aby bylo možné nastavit rozsah nového systému. Je

16 16 také vhodná doba na označení kritických rizik projektu. Milníkem této fáze je tedy předmět životního cyklu a stanovení rozsahu systému. Hlavním úkolem ve fázi rozpracování je vytvoření částečné funkční verze systému (spustitelné). Z toho také vyplývá zachycení případů užití pro přibližně 80% funkčních požadavků na vznikající systém. Dále dochází k vylepšování odhadu všech rizik spojených s projektem, tvorba plánu konstrukční fáze a formulace nabídky zahrnující prostředky, čas, lidské zdroje nebo vybavení, které jsou potřebné k dokončení projektu. Milníkem je vytvoření architektury. Programový základ, který byl vytvořen ve fázi rozpracování, je v konstrukční fázi postupně nahrazován kompletním a plně funkčním systémem. Jsou tedy plněny všechny požadavky vznesené během analýzy a návrhu (je dokončen analytický model a model návrhu), také může ještě dojít k odhalení požadavků, které byly v předchozích fázích opomenuty. Po zajištění začínajícího provozu následuje testování jednotlivých funkcí nového softwaru. Milníkem této fáze je počáteční provozní způsobilost systému a jeho testování. Poslední fází, která začíná po dokončení testování systému, se nazývá fází zavedení. Ta spočívá v opravě všech nalezených chyb, přípravě pracovišť na převzetí nového programového vybavení a jeho přizpůsobení pro bezproblémovou funkčnost. Tato fáze je také spojená s tiskem manuálů a dokumentace, nebo konzultacemi s uživateli systému. Milníkem je tedy konečné nasazení nového systému do ostrého provozu v organizaci. (Arlow, Neustadt, 2007) Struktura jazyka UML Struktura jazyka UML je tvořena ze třech částí, kterými jsou stavební bloky, společné mechanismy a architektura. Stavební bloky jsou tvořeny artefakty, což jsou jednotlivé prvky modelu, dále pak relacemi představujícími významový vztah mezi jednotlivými artefakty, a diagramy. Ty jsou v kontextu jazyka UML chápány jako pohledy na modely UML, čili je to vizualizace toho, co a jak bude systém dělat. Mechanismy popisují celkem čtyři možnosti modelování objektů, které jsou používány v celém jazyku UML. Tyto čtyři pohledy tvoří (Arlow, Neustadt, 2007): Specifikace jedná se o textový popis sémantiky jednotlivých prvků modelu. Vytváří tedy sémantický podklad, který tvoří jádro modelu a dává mu smysl. Ornamenty mohou doplnit jednotlivé prvky, pokud je třeba zdůraznit jeho určité detaily nebo zobrazit více informací (např. jednotlivé třídy jsou doplněny o atributy a operace). Podskupiny umožňují popis různých způsobů vidění světa. Jazyk UML rozlišuje dvě podskupiny. Nejprve je to skupina klasifikátorů a instancí, dále pak skupina rozhraní a implementací. Klasifikátor je abstraktním vyjádřením určitého předmětu (např. auto), naopak instance představuje konkrétní výskyt

17 17 abstraktní představy (např. moje auto). Rozhraní umožňuje vykonávání určité činnosti (grafické uživatelské rozhraní programu), kdežto implementace vyjadřuje způsob, jakým se tato činnost vykonává (jednotlivé metody tříd). Mechanismy rozšiřitelnosti vzhledem k uspokojení potřeb všech uživatelů jazyka UML, poskytli jeho autoři jednoduché mechanismy, které umožňují jeho rozšiřitelnost. Tyto mechanismy tvoří omezení (tvorba nových pravidel), stereotypy (definice nových prvků modelu založených na existujících prvcích), označené hodnoty (rozšíření prvků modelu o jejich vlastní hodnoty) a profily UML (množina stereotypů, značek a omezení, které jazyk UML přizpůsobí konkrétnímu účelu). Aby popsal všechny podstatné aspekty architektury, definuje jazyk UML čtyři různé pohledy, které jsou poté integrovány do pohledu pátého (tzv. pohled 4+1). Jedná se o pohled logický, procesů, implementace, nasazení a případů užití. Logický pohled se snaží zachytit slovník oblasti problému jako množinu tříd a objektů. Zaměřuje se především na způsob implementace svého chování jednotlivými třídami a objekty. Pohled procesů obsahuje stejné artefakty jako pohled logický, nicméně se zaměřuje na procesy, které modeluje jako aktivní třídy. Prostřednictvím implementačního pohledu se modelují komponenty, které utvářejí finální kód systému (kódový základ). Je využíván především ke znázornění jednotlivých propojení a návazností mezi programovými moduly, umožňuje tak definici celého systému. Pohled nasazení se zabývá fyzickým nasazením softwarových komponent na výpočetní uzly v organizaci (počítače nebo periferní zařízení). Umožňuje tak modelování distribuce komponent na tyto příslušné uzly. Všechny již zmíněné pohledy jsou odvozeny od pohledu případů užití, který definuje základní požadavky kladené na nově vznikající, či inovovaný systém. Tento pohled tak tvoří základ pro tvorbu všech ostatních pohledů a architekturu. (Arlow, Neustadt, 2007) 2.4 Diagramy jazyka UML Diagramy reprezentují grafický pohled na obsah modelu, který zachycuje prvky a vztahy mezi nimi. Tyto diagramy však nejsou modelem samotným. Množinu jednotlivých diagramů pak tvoří diagramy modelující statickou strukturu a diagramy modelující dynamickou strukturu systému. Statický model popisuje předměty a strukturní asociace mezi těmito předměty, dynamický model naopak představuje vzájemnou interakci mezi jednotlivými předměty, která způsobuje požadované chování celého softwarového systému. Pro modelování systému v této práci byl použit Business Process Model, Use Case diagram, diagram tříd, diagram aktivit, stavový diagram, sekvenční diagram a entitně-relační diagram.

18 Business Process model Řepa uvádí jako jeden z hlavních profilů pro modelování podnikových procesů profil H. Erikssona. Tento profil vychází ze čtyř pohledů na organizaci: Pohled strategický tento pohled zahrnuje vize organizace, její hodnoty a strategické cíle. Procesní pohled zaměřuje se na podnikové procesy, činnosti a hodnoty, které tyto aktivity zahrnují. Popisuje také vzájemnou interakci mezi těmito procesy a využívání zdrojů v organizaci. Strukturní pohled přibližuje strukturu celé organizace, její produkty, jednotky, dokumenty, znalosti nebo informace. Chování organizace popisuje jak vnitřní chování, tak interakci mezi prvky v organizaci (Řepa 2007) Tyto pohledy jsou zobrazovány pomocí diagramů UML, které mohou být doplněny o textový dokument, který využívá rozšiřující mechanizmy pro oblast podnikového modelování. (Rábová a kolektiv, 2008) Model podnikových procesů tedy popisuje hlavní interní procesy v organizaci a jejich vstupy a výstupy. Hlavními prvky BPM jsou tedy procesy samotné. Dalšími prvky toho modelu jsou aktéři, informace, zdroje, události, cíle a výstupy. a) Aktéři: Podle (Arlow, Neustadt, 2007) aktér reprezentuje roli, kterou přijímá jakákoliv externí entita v okamžiku užívání systému. Tato entita může být buďto uživatel (popř. čas), nebo jiný systém, který sdílí hranice systému organizace (v UML2 to mohou být i jiné subjekty). Při hledání aktérů je proto třeba se ptát, kdo, nebo co systém používá a komunikuje s ním. b) Informace a zdroje (Resource): Jakýkoliv podnikový proces využívá informace, které jsou přizpůsobeny jeho aktivitám. Tyto informace však nejsou na rozdíl od zdrojů během procesu spotřebovávány, nýbrž jsou použity později jako součást transformovaného procesu. Zdroje se tedy během podnikového procesu spotřebovávají. c) Události (Events): Za událost je možné považovat přijetí nějakého objektu, dosažení určitého data, nebo jiná akce, která je iniciátorem podnikového procesu. Událost může být v procesu spotřebována i transformována (např. objednávka), nebo je iniciátorem procesu.

19 19 d) Výstupy (Outputs): Všechny podnikové procesy vytvářejí nějaký výstup (či výstupy), který jsou využity buďto pro další interní použití, nebo pro uspokojení vnějších požadavků. Výstupy mohou být fyzické objekty (faktury, doklady, sestavy), transformované interní záznamy (denní plány, přehledy) nebo výsledné podnikové komplety (vyřízená objednávka). Výstup může také být spouštěcí událost (tzv. trigger), který vyvolá nové aktivity. e) Cíle (Goals): Jednotlivé podnikové procesy mohou mít také definovány své cíle, aby byl jednoznačně určen důvod, proč je daný proces organizace dělá. Většinou je definován v rámci uspokojování potřeb podniku. f) Relace: Model podnikových procesů definuje několik druhů relací: Spojení <<supply>> souvisí s využitím informací nebo jiných objektů v podnikovém procesu. Udává, že tyto objekty nejsou v rámci jednotlivých fází procesu spotřebovány (např. šablona objednávky může být používána opakovaně stále znovu). Spojení <<input>> týká se také vstupů (zdrojů), nicméně takto připojený objekt je v procesu spotřebován (konkrétní objednávka, která je zpracována a vyřízena je ve většině případů použita pouze jednou). Vazba <<output>> označuje nově vzniklý objekt, který je výstupem podnikového procesu. Navenek je většinou reprezentován nějakou viditelnou hodnotou, nebo také může být ve formě interního produktu (který je využíván jinými procesy). Spojení <<goal>> definuje připojení objektu k podnikovému procesu s popisem cíle tohoto procesu. Jedná se o zdůvodnění vykonávané aktivity. Obrázek 4: Notace BPM v UML (Enterprise Architect)

20 Modelování případů užití (Use Case Diagram) Řepa popisuje model případů užití (v kontextu procesního modelování a zobrazení pomocí Use Case Diagramu), který byl v UML původně určený k popisu uživatelských požadavků a rozhraní systému, jako model popisující podnikové procesy a jejich interakce s aktéry systému. Model Use Case je označován jako Externí model, jehož cílem je popis vztahů organizace s jejím okolím. (Řepa, 2007) Jak uvádí (Arlow, Neustadt, 2007), výstupem těchto aktivit je zachycení požadavků na systém, které reprezentuje model obsahující: Hranice systému (system boundary) jedná se o ohraničení zobrazené kolem jednotlivých případů užití, které představuje vyznačení hranic systému. Aktéři (actors) role přidělené osobám nebo předmětům používajícím systém. Případy užití (use cases) činnosti, jež jsou vykonávány prostřednictvím aktérů. Relace (relationship) jednotlivé vazby mezi aktéry a případy užití a) Hranice systému: Díky vymezení hranic systému je možné systém oddělit od zbytku světa. Jedná se tedy o zjišťování, co je součástí systému (nachází se uvnitř jeho hranic) a co již součástí systému není (nachází se za hranicemi). Tyto hranice jako celek jsou nazývány subjektem a ten je definován uživateli systému (aktéry) a případy užití. Subjekt je v Use Case diagramu označen jako rámeček (s popisem a názvem systému), který ve svém nitru obsahuje případy užití, naopak aktéři se nacházejí mimo tento rámec. b) Případy užití: Případ užití může být definován jako něco, co aktér od systému očekává. Popisuje tedy funkce, které jsou aktérovi poskytovány k jeho užitku. Je třeba si uvědomit, že případy užití jsou vždy iniciovány aktérem a napsány vždy z pohledu aktéra. V jazyku UML se případ užití značí jako elipsa s názvem činnosti, která je aktérovi systémem poskytována. (Arlow, Neustadt, 2007) c) Vztahy (asociace): Jednotlivé případy užití mohou být v relaci s aktérem tím, že se systémem komunikuje a využívá ho. Tato vazba je v diagramu případů užití také doplněna o sloveso vyjadřující činnost systému iniciovanou aktérem. Jednotliví aktéři mohou být v relaci také mezi sebou, pokud je nutné takovýto vztah vyjádřit (generalizace, nebo specializace). Dále mohou být vazby mezi jednotlivými případy užití, jelikož ty mohou mezi sebou spolupracovat. Jedná se o tyto dva druhy vazeb:

21 21 <<include>> o tento vztah se jedná tehdy, pokud jeden případ užití zahrnuje druhý. Jedná se o povinný vztah, oba takto spojené případy užití se tedy musí provést. <<extends>> vazba je použita, pokud případ užití za určitých podmínek rozšiřuje chování jiného (je zde ale možnost volby). O tomto rozšířeném chování rozhoduje aktér. Generalizace (zobecnění) vytvoření případu užití s chováním společným pro několik dalších případů užití. (Wikipedie, 2009) d) Slovník pojmů (Project Glossary): Tento artefakt tvoří velmi důležitou část celého projektu. Jeho úkolem je popsat různé specifické názvosloví pro určitá odvětví, zaměřuje se také na žargon a terminologii používanou v organizaci, poskytuje tedy lexikon klíčových obchodních termínů a definicí. Zabývá se také problematikou synonym a homonym. e) Scénáře případu užití: Před samotným popisem jednotlivých scénářů vztažených k případům užití je nutné nadefinovat vstupní podmínky. Ty omezují stav systému předtím, než je možné případ užití spustit. Aktéři mohou tedy využívat funkcionalitu systému až po splnění těchto podmínek. Po splnění těchto vstupních podmínek následuje sousledný tok událostí neboli scénáře, které v sobě obsahují jednotlivé kroky případu užití. Hlavní scénář obsahuje kroky, které po sobě následují v ideálním případě, tedy v situaci, kdy během funkcionality spuštěné aktérem nedochází k žádným chybám, rozvětvením, nebo přerušením. V případě mírných odchylek od hlavního scénáře je možné modelovat větvení tohoto toku událostí. V případě složitých odchylek je pak nutné vytvořit scénář alternativní. Alternativní scénáře je možné dokumentovat samostatně nebo také mohou být připojeny na konec případu užití. Většinou jsou tyto scénáře rozpoznávány průzkumem hlavního scénáře. Na každém kroku hlavního toku událostí je nutné sledovat zda: Existují možné alternativy hlavního scénáře. Mohou se vyskytnout chyby způsobené hlavním scénářem. V určitém místě hlavního scénáře může dojít k přerušení. K přerušení může dojít také na libovolném místě v hlavním scénáři. (Arlow, Neustadt, 2007)

22 Modelování tříd a objektů Pokud je model případů užití považován za externí model, tak objektový model (Object model), který je postavený na diagramu tříd, je nazýván modelem interním. Diagram tříd, který je jedním ze základních diagramů UML, tedy znázorňuje základní třídy modelu a vztahy mezi těmito třídami, čili představuje statickou stránku systému. Název interního modelu vychází z předpokladu, že diagram tříd popisuje vnitřní struktury organizace tím způsobem, že jednotlivé třídy vyjadřují samostatné entity organizace a relace popisující vztahy mezi těmito třídami. (Řepa, 2007) Třídu samotnou lze popsat jako abstrakci objektů, které mají společné atributy, metody, operace, či chování. Všechny instance jedné třídy mají tedy stejné operace, atributy a relace. Liší se pouze v hodnotách svých atributů. Jakýkoliv objekt je tedy instancí nějaké třídy. Analytické třídy, které modelují důležité aspekty problémové domény (např. zákazník nebo produkt), by v diagramu tříd notace UML měly zobrazovat vždy alespoň tyto informace: Název třídy Atributy třídy Operace třídy Název třídy by měl jednoznačně odrážet její účel v systému. Atributy třídy přestavují informace a hodnoty, které mají být u dané třídě uchovány. Tyto atributy by měly být atomické a dále nedělitelné. Atribut je reprezentován hodnotou, datovým typem (množina přípustných hodnot a operací s těmito hodnotami) a viditelností. Operace třídy definují její chování, nebo také představují zprávy, kterým může třída porozumět. Zdrojem pro hledání takovýchto operací jsou obvykle scénáře případů užití. V notaci UML jsou operace identifikovány svým názvem, množinou vstupních parametrů (argumentů) a návratovým typem. (Arlow, Neustadt, 2007) Co se týká různých druhů relací v diagramu tříd, rozlišují se tyto druhy vztahů: Asociace jedná se o tzv. slabou vazbu mezi třídami, která pouze říká, že dvě třídy mají mezi sebou určitý vztah. Může být definováno jméno relace, role, či násobnost (množství instancí vytvořených v jiné třídě). Agregace je to silnější forma asociace, kdy danou třídu tvoří skupina komponentních tříd. Dědičnost třída může od mateřské třídy zdědit operace a atributy (pouze s viditelností chráněnou a veřejnou, soukromé atributy se nedědí). Mateřská třída je tedy definována obecněji než potomek, který může mít kromě zděděných atributů a operací i své vlastní. V diagramu tříd se mohou vyskytovat i tzv. asociativní třídy, a to v případě, že vztah mezi třídami samotnými obsahuje informace, které nejsou atributy ani jedné ze tříd v asociaci M:N (např. třídy osoba a firma mají asociační třídu zaměstnání). (Wikipedie, 2009)

23 Diagram aktivity Tento diagram je jeden z UML diagramů, kterým je možné popsat chování systému a zaměřuje se na modelování procedurální logiky a procesů (tedy dynamickou část modelu). Jak popisuje (Arlow, Neustadt, 2007), jedná se o objektově orientované vývojové diagramy, díky kterým je možné procesy modelovat jako aktivitu, která se skládá z kolekce uzlů spojených hranami. Tento diagram prošel určitým vývojem, v UML 1 byl pouze zvláštní případ stavových automatů, ale v UML 2 vychází nová sémantika diagramů aktivit především z Petriho sítí (hlavně kvůli lepší přizpůsobivosti při modelování různých typů cest a oddělitelnosti od stavových automatů). Diagram aktivity lze připojit k libovolnému modelovanému prvku (případy užití, třídy, operace, obchodní procesy, rozhraní, atd.) a umožňuje tak popis jeho chování. Samotná aktivita se skládá z množiny uzlů (nodes), které jsou navzájem propojeny uzly (edges). Uzly můžeme rozdělit na: Akční nelze je v rámci aktivity rozdělit, jsou spuštěny, pokud token projde souběžně všemi jejich hranami a splní všechny místní vstupní podmínky akčního uzlu. Nejčastěji jsou to akční uzel volání a akční uzel přijetí časové události. Řídící řídí cestu uvnitř aktivity (počáteční uzel, konečný uzel aktivity, konečný uzel cesty, uzel rozhodnutí, sloučit uzel, rozvětvit uzel, spojit uzel). Objektové představují objekty využité během dané aktivity. Hrany, představující cestu v rámci aktivity, se dělí na: Řídící vyjadřují postup řízení v rámci aktivity, signalizují dostupnost instancí klasifikátoru (třídy). Objektové zastupují cestu objektu v rámci aktivity. (Arlow, Neustadt, 2007) Aktivita začíná v bodě inicializace a končí v bodě ukončení aktivity. Jednotlivé kroky, které jsou vykonávány sekvenčně, se v notaci UML značí jako šipky. Tyto šipky reprezentují řídící tok. Je možné také využívat symbolů pro rozhodování (tok lze podmínit vstupními nebo výstupními podmínkami, např. není-li splněna vstupní podmínka kroku, není spuštěn), rozvětvení (jeden vstup na několik výstupů), spojení (více vstupů na jeden výstup), nebo tzv. plaveckých drah (swimmlanes popis objektů a tříd zodpovědných za aktivitu). (Wikipedie, 2010) Jelikož jednotlivé aktivity mohou obsahovat mnoho vnitřních cest a větvení, umožňuje UML využít tzv. sponek (pins), které slouží k lepší orientaci a zpřehlednění diagramu. V diagramech aktivit je také možné využít vstupních, nebo výstupních parametrů aktivit. Jedná se uzly objektového typu, které zajišťují vstup, či výstup z aktivity. (Arlow, Neustadt, 2007)

24 Sekvenční diagram Jak uvádí (Arlow, Neustadt, 2007), sekvenční diagramy patří (společně s komunikačními diagramy, diagramy zjednodušené interakce a diagramy časování) do skupiny diagramů interakce. Tyto diagramy se UML v používají k modelování jakéhokoliv typu interakce mezi jednotlivými instancemi tříd. Samotné sekvenční diagramy pak slouží k zobrazení interakce mezi čárami života jako uspořádanou posloupnost událostí. Hlavními prvky digramu jsou objekty, mohou obsahovat i aktéry. (Arlow, Neustadt, 2007) V notaci UML jsou v sekvenčním diagramu instance jednotlivých tříd zobrazeny jako obdélníky (na horní straně diagramu), které si mezi sebou vyměňují zprávy. Z každého takového objektu vedou šipky znázorňující jeho život v průběhu chování případu užití. Aktéři jsou zobrazeni z důvodu označení iniciátora případu užití. Každá zpráva reprezentuje operaci příslušného objektu, která je jiným objektem volána, a je označena jménem popř. vstupními parametry. Může také dojít k tomu, že objekt volá svou operaci (tzv. self-call), v tom případě šipka začíná a končí na čáře života stejného objektu. Diagram může také obsahovat vrácení aktivity volajícímu objektu (returns), které je znázorněno přerušovanou šipkou. V neposlední řadě umožňují sekvenční diagramy modelování vazeb mezi případy užití (<<include>>, <<extend>>) s využitím speciálního symbolu sondy. Sonda umožňuje značné zpřehlednění sekvenčního diagramu, jelikož představuje odkaz na jiný případ užití (ten může být zobrazen jiným sekvenčním diagramem). (Kanisová, Müller, 2004) Stavové diagramy Stavové diagramy popisují všechny možné stavy, které může nabývat konkrétní objekt systému, čili modelují chování objektu napříč všemi případy užití. Znázorňují také změnu stavu objektu v čase. (Kanisová, Müller, 2004) (Arlow, Neustadt, 2007) také uvádí, že stavové automaty představují životní cyklus instancí tříd, a to prostřednictvím konečného počtu stavů těchto instancí. Automat tedy prochází těmito stavy striktně definovaným způsobem. Klíčovými prvky těchto automatů jsou: Stavy představují podmínku nebo situaci, která vzniká během životního cyklu instance klasifikátoru. V tomto stavu objekt vykonává nějakou aktivitu, nebo čeká na vznik nějaké události. Událost specifikace něčeho významného, co se stane v určitém čase a prostoru, tento stimul však nemá žádné trvání (Wikipedie, 2010). Přechod posun mezi stavy v důsledku události. (Arlow, Neustadt, 2007)

25 25 Arlow popisuje, že stav je určen v daném konkrétním okamžiku těmito faktory: Hodnotami atributů daného objektu, relacemi s dalšími objekty, aktuálně vykonávanou aktivitou. (Arlow, Neustadt, 2007) Notace UML udává dva základní symboly stavu instance, kterými jsou počáteční a koncový stav. Počáteční stav (symbol Start) představuje bod zahájení životního cyklu a každý stavový diagram musí obsahovat právě jeden takovýto symbol. Stav Stop reprezentuje ukončovací stav objektu v jeho životním cyklu. Jednotlivé stavy pak mohou obsahovat akci, nebo aktivitu. Akce v tomto případě znamená nepřerušitelný, rychle probíhající proces (interní přechod nastávající v důsledku nějaké události). Každý stav obsahuje dvě implicitní akce, kterými jsou vstup a výstup (entry a exit). Naopak aktivita přerušitelný, po určitou dobu probíhající proces. Popisuje probíhající chování objektu v rámci jeho stavu, dokud není přerušeno událostí, nebo neskončí. (Kanisová, Müller, 2004) Přechody ukazující posun mezi jednotlivými stavy, jsou v syntaxi UML znázorněny šipkou. Tuto syntaxi lze použít jak pro interní, tak pro externí přechody. Nepovinné prvky přechodu tvoří události (zahajující přechod), podmínky (jejich splnění může podmiňovat přechod) a akce (připojená k přechodu, dochází k ní při jeho zahájení). Spojování takovýchto přechodů vzniká tzv. přechodový pseudostav. Jak je možné odvodit z názvu, nejedná se o stavy, ale o elementy, ve kterých stavový element nezůstává, ale pouze jimi prochází (Wikipedie, 2010). V těchto místech se přechody spojují nebo větví. Mohou obsahovat jeden nebo několik vstupních přechodů a také jeden nebo více výstupních přechodů. Výstupní přechody by měly být jednoznačně rozlišeny podmínkami, aby mohlo dojít vždy pouze k jednomu z nich. (Arlow, Neustadt, 2007) Ve stavovém diagramu je také podle notace UML možné rozlišit čtyři druhy událostí: Událost volání jedná se o požadavek metody dané třídy na spuštění události, spouští sérii akcí. Signální událost zajišťuje předání asynchronní zprávy mezi objekty. Většinou se jednotlivé signály modelují jako samostatné třídy (stereotyp <<signal>>), jejichž atributy obsahují přenášené informace. Událost změny obsahuje klíčové slovo when, podmínku a akci. Je aktivována po splnění podmínky. Časové události mohou být aktivovány po uplynutí určité doby (využití klíčového slova after). (Kanisová, Müller, 2004)

26 Entitně-relační diagram (ERD) Z důvodu, že v dnešní době je stále ještě v naprosté většině systémů využíváno relačních databází (objektové databáze jsou teprve ve vývoji), je nutné využít technik datového modelování, které se řadí do strukturovaného přístupu. Právě z tohoto důvodu bude v této práci využito k vytvoření pohledu na datový model entitně-relačního diagramu. Celkový pohled na datovou strukturu je podle (Kanisová, Müller, 2004) možné rozdělit na dva pohledy, kterými jsou logický a fyzický datový model. Logický model je nezávislý na implementaci a obsahuje tyto základní prvky: Entity jedná se o událost nebo fyzický objekt, který je schopen samostatné existence a lze ho jednoznačně identifikovat. Entita je popsána podstatným jménem. Atributy reprezentují položky jednotlivých entit, definují tak jejich charakteristiky. Označují se jménem, datovým typem a rozsahem. Vazby entity jsou mezi sebou propojeny pomocí vazeb, které se označují slovesem. U vazeb je rozlišována jejich kardinalita (násobnost) a parcialita (povinnost). Z pohledu násobnosti se vazby rozdělují na 1:1, 1:N a M:N. Klíče některé atributy entity mohou mít větší význam než ostatní. Tyto atributy jsou nazývány klíčem. Klíč může být primární (musí být jednoznačný a jeho výskyt musí být jedinečný), alternativní (jeho výskyt je také jedinečný, ale nebyl vybrán jako primární klíč) a cizí (typ toho klíče je atribut, který se v jiné entitě vyskytuje jako primární klíč). Fyzický datový model již zohledňuje relační databázi, která byla použita v systému pro uchovávání a zpracování dat. Databáze samotná je tedy organizovaná struktura uspořádaná do tabulek, jejichž řádky představují informaci o jednom výskytu entity uložené v databázi a sloupce reprezentují jednotlivé atributy těchto entit. Entitně-relační diagram představuje statickou část systému, z tohoto důvodu je nutné mapování diagramu tříd do modelu objektů uložení. a) Mapování tříd na tabulky: Mapování tříd na tabulky probíhá tím způsobem, že jednotlivé atributy třídy se stávají sloupci tabulky, a jejich instance odpovídají řádkům tabulky. b) Mapování asociací: V případě asociací je situace poněkud složitější, v případě asociace 1:1 většinou vedou na jedinou tabulku, proto se atributy těchto tříd slučují. Vztahy 1:N znamenají definici cizího klíče v jedné z tabulek, který odkazuje na primární klíč druhé tabulky. Asociace M:N vedou ke tvorbě asociačních tabulek (obsahuje svůj primární klíč, cizí klíče s odkazem do obou tabulek a atributy asociační tabulky).

27 27 c) Mapování agregací: Z pohledu datového modelování představuje agregace stejnou vazbu jako asociace, mapování se tedy řídí stejnými pravidly, jako v předchozím případě. d) Mapování dědičnosti: Mapování dědičnosti tříd nabízí celkem tři způsoby realizace: Mapování dědičnosti 1:1 tento způsob mapování je sice, co se týká modelování, nejjednodušší, nicméně může značně snižovat výkon aplikace. Spočívá totiž v tom, že se každá třída mapuje do samostatné tabulky, které obsahují stejný primární klíč. Každá nová instance je ale datově rozdělena do několika tabulek. Mapování dědičnosti zahrnutím do nadtřídy všechny atributy podtříd jsou zahrnuty do mateřské třídy, z toho také vyplývá, že všechny sloupce z podtříd budou volitelné (vhodné při malém počtu podtříd s malým počtem atributů). Mapování dědičnosti rozpuštěním do podtříd všechny atributy mateřské třídy jsou přeneseny do tabulek vzniklých z neabstraktních tříd (vhodné v případě, že nadtřída má málo atributů, ale zároveň existuje mnoho odvozených tříd).

28 28 3 Metodika Práce Cílům, které byly stanoveny na počátku této diplomové práce, se bude věnovat část představující analyzovanou společnost a část s názvem Vlastní práce. V první z těchto dvou částí budou popsány základní charakteristiky analyzované společnosti UNIKOL s.r.o., které budou doplněny o podrobný popis firemní struktury. Poslední, ale velice důležitou součástí, bude zhodnocení současného stavu informačního systému, který je nyní ve společnosti nasazen a používán. Stěžejní část této diplomové práce, vzhledem ke splnění stanovených cílů, tvoří část Vlastní práce, která také bude těžit ze získaných teoretických poznatků z literárního přehledu. Jelikož půjde především o modelování a tvorbu diagramů UML, bude pro tuto činnost zvolen CASE nástroj společnosti Sparx Systems Enterprise Architect. Pomocí toho softwarového nástroje bude v první řadě vytvořen Business Process Model, který popisuje hlavní interní procesy organizace a jejich vstupy a výstupy. Vzhledem k přehlednosti pak bude tento celkový model rozdělen na procesní bloky, které budou detailněji popisovat jak vstupy a výstupy, tak vztahy mezi jednotlivými procesy. Díky tomuto zvolenému postupu vznikne ucelený pohled na chování a strukturu podnikových procesů ve společnosti. Z tohoto pohledu budou vycházet návrhy na jednotlivé inovace systému společně s ekonomickým zhodnocením jednotlivých variant těchto inovací, z nichž jedna bude vybrána pro následnou analýzu a realizaci. U této inovované části systému budou nalezeny všechny případy užití (neboli funkční požadavky na tuto část IS) společně s jejich aktéry. Tohoto bude dosaženo pomocí vytvořeného Use Case modelu. Analytická část bude pokračovat vytvořením modelu analytických tříd, které zprostředkují první náhled na třídy systému. Pro popis dynamické části systému bude také využito jiných diagramů jazyka UML, mezi které patří diagram aktivit, sekvenční diagram a stavový diagram. Z důvodů použití relačního databázového systému MySQL, bude z modelu analytických tříd v části realizace inovace vytvořen entitně-relační diagram. V poslední části vlastní práce pak bude vybraná inovace realizována prostřednictvím programovacího jazyka Java platformy SE 6 a databázového systému MySQL. Grafické uživatelské rozhraní aplikace bude vytvořeno pomocí knihovny uživatelských prvků Swing.

29 29 4 Analyzovaná společnost UNIKOL s.r.o. 4.1 Charakteristika společnosti Firma byla založena 17. června v roce 1993 jako obchodní společnost za účelem koupě zboží a následného prodeje tohoto zboží a další zprostředkovatelská činnost. Společnost se od svého vzniku specializuje na distribuci a prodej ložisek všech druhů (kuličková, válečková, jehlová a jiná) a jejich příslušenství. Tyto ložiska jsou využívána ve strojích a menších přístrojích ve většině průmyslových odvětví (hutnictví, strojírenství, automobilový průmysl, atd.). Dále také firma nabízí široký sortiment klínových řemenů, gufer, technických lepidel, či různého druhu nářadí. Mezi hlavní dodavatele patří mezinárodní společnosti jako Schaffler Group (FAG, INA), TIMKENnebo HELKEL. První pobočka firmy UNIKOL s.r.o. byla založena v Zubří (okres Vsetín), zaměřila se tedy především na klienty v moravském regionu. Nicméně díky stále rostoucímu počtu zákazníků v Čechách byla v roce 1998 otevřena další pobočka konkrétně v Nymburku. Nyní má společnost celkem pět poboček (Zubří, Nymburk, Kolín, Plzeň a Brno), její působnost tedy pokrývá celou Českou republiku a částečně i některé regiony na Slovensku. V současné době tak dosahuje ročního obratu přibližně 150 miliónů korun. Mezi hlavní zákazníky společnosti UNIKOL s.r.o. patří především Sigma Hranice, SIEMENS, Vítkovice Mechanika, Sokolovská Uhelná, Škoda Holding či Škoda Auto, TOS Kuřim, TOS Čelákovice, TOS Hulín. 4.2 Struktura společnosti Jak již bylo řečeno výše, společnost nyní provozuje pět poboček po celé České republice. Vedení společnosti nyní působí v Nymburku (s výjimkou finanční ředitelky), odtud jsou řízeny všechny zbývající pobočky. Nicméně pobočka v Zubří je poměrně autonomní část s vlastním obchodním ředitelem. Mateřská společnost byla totiž rozdělena na dva samostatné subjekty, kterými jsou UNIKOL s.r.o. (Zubří) a UNIKOL CZ s.r.o. (Nymburk, Kolín, Plzeň a Brno). Obě tyto obchodní společnosti však působí jako celek, mají jednoho majitele a jsou propojeny ve většině procesů spojených s běžným provozem. Jednotlivé kompetence a pole působnosti všech poboček jsou jasně nastaveny. Vedení společnosti společně s majitelem sídlí v Nymburku, většina rozhodnutí o vývoji firmy, nebo taktické a strategické plánování tedy probíhá na této pobočce. Samozřejmě je zde také realizována obchodní činnost a v Nymburku je také hlavní sklad se zbožím pro region Čechy. Finanční ředitelka společně s celým finančním úsekem však pracuje v Zubří. Veškeré účetnictví (všech poboček) se tedy zpracovává na této pobočce. Působí zde také obchodní ředitel se zaměřením na moravskou klientelu. V Zubří se nachází