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

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

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.

Zadání

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 2010

…………………………………..

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, 2010. 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

Obsah 1

2

Úvod a cíl práce ........................................................................................................ 8 1.1

Úvod do problematiky....................................................................................... 8

1.2

Cíl práce ............................................................................................................. 8

Literární přehled .................................................................................................... 10 2.1

Procesní řízení ................................................................................................. 10

2.2

Procesní modelování ........................................................................................12

2.3

Jazyk UML .......................................................................................................13

2.3.1

Metodika Unified Process .........................................................................14

2.3.2

Struktura jazyka UML ...............................................................................16

2.4

Diagramy jazyka UML ..................................................................................... 17

2.4.1

Business Process model ........................................................................... 18

2.4.2

Modelování případů užití (Use Case Diagram) ....................................... 20

2.4.3

Modelování tříd a objektů ........................................................................ 22

2.4.4

Diagram aktivity ....................................................................................... 23

2.4.5

Sekvenční diagram ................................................................................... 24

2.4.6

Stavové digramy ....................................................................................... 24

2.4.7

Entitně-relační diagram (ERD) ............................................................... 26

3

Metodika Práce ...................................................................................................... 28

4

Analyzovaná společnost UNIKOL s.r.o. ................................................................ 29

5

4.1

Charakteristika společnosti............................................................................. 29

4.2

Struktura společnosti ...................................................................................... 29

4.3

Současný stav informačního systému ..............................................................31

Vlastní práce .......................................................................................................... 33 5.1

Procesní model ................................................................................................ 33

5.1.1

Řízení obchodu ......................................................................................... 35

5.1.2

Řízení skladu ............................................................................................ 36

5.1.3

Finanční řízení.......................................................................................... 37

5.2

Současná softwarová podpora firemní procesů ............................................. 38

5.3

Možnosti inovace informačního systému společnosti .................................... 39

5.3.1

Inovace stávajících modulů informačního systému ................................ 39

5.3.2

Dokoupení a integrace dalších programových modulů ........................... 40

7

5.3.3 5.4

6

Kompletní integrace nového informačního systému................................41

Návrh inovace IS řízení skladové evidence (MTZ) ......................................... 43

5.4.1

Případy užití a aktéři systému MTZ ......................................................... 43

5.4.2

Diagram tříd systému MTZ ....................................................................... 51

5.4.3

Diagram aktivit - příjem skladové položky .............................................. 52

5.4.4

Sekvenční diagram ................................................................................... 54

5.4.5

Stavový diagram ....................................................................................... 55

Realizace inovace systému řízení skladové evidence ............................................ 56 6.1

Datová struktura ............................................................................................. 56

6.2

Aplikační logika ............................................................................................... 57

6.2.1

Řízení a správa skladové evidence (package MTZ) ................................. 57

6.2.2

Správa uživatelů (package Uživatel) ........................................................ 58

6.2.3

Správa firem (package Firma) ................................................................. 59

6.3

Export dat a spojovací soubor......................................................................... 59

6.4

Grafické uživatelské rozhraní ......................................................................... 60

7

Diskuse a závěr....................................................................................................... 62

8

Literatura ............................................................................................................... 63

9

Seznam obrázků a tabulek ..................................................................................... 64 9.1

Seznam obrázků .............................................................................................. 64

9.2

Seznam tabulek ............................................................................................... 64

Přílohy ........................................................................................................................... 65 A. Diagram případů užití MTZ – celkový pohled ................................................... 66

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.

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

•

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

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

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

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)

2.3.1 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

• • •

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

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

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

2.4.1 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

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í <> — 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 <> — 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í <> — 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

2.4.2 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

•

<> — 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

2.4.3 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

2.4.4 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

2.4.5 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í (<>, <<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) 2.4.6 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

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

2.4.7 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

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

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

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í

30

Obrázek 5: Organizační struktura společnosti UNIKOL s.r.o.

hlavní sklad celé společnosti (převažuje však zboží právě pro Zubří – největší objem zakázek). Zbylé tři pobočky mají tedy za úkol pouze obchodování. Díky vysokým odběrům zboží a nutnosti být neustále předzásoben především ložisky kvůli haváriím strojů, byly zřízeny dva konsignační sklady společnosti UNIKOL u dvou největších odběratelů – Vítkovice Mechanika a.s. a TOS Kuřim. Tyto konsignační sklady se tedy nacházejí přímo v areálech těchto dvou společností, jsou v nich zaměstnáni zaměstnanci těchto firem, nicméně zboží zde uskladněné je stále majetkem firmy UNIKOL. Jsou s ním tedy spojeny všechny procesy, které vznikají při prodeji a skladování zboží, jako na ostatních pobočkách.

31

Společnost také v roce 2005 zavedla systém managementu jakosti podle normy ISO 9001:2000, který slouží jako prostředek pro posouzení schopnosti společnosti plnit požadavky zákazníka a zvyšovat jeho spokojenost a současně jako prostředek k naplňování příslušných požadavků zákonů a předpisů. Certifikát získaný z tohoto auditu je nutné každý rok obhájit podle příslušné normy (certifikát požaduje většina významných zákazníků v ČR i v zahraničí). Tento systém řízení jakosti zasahuje, či ovlivňuje většinu vnitropodnikových procesů.

4.3

Současný stav informačního systému

Informační systém společnosti UNIKOL s.r.o. je v dnešní době tvořen několika moduly, které byly integrovány během posledních 10 let. Některé z nich již byly během doby používání inovovány, některé však stále zůstaly původní od počáteční doby nasazení do firmy. Základem celého podnikového IS je modul zpracovávající účetnictví a saldokonto. Tato část je provozována pouze na pobočce v Zubří, jelikož se zde nachází účetní oddělení společnosti. Modul zpracovává podvojné účetnictví, správu mezd, pokladnu a banku. Pracují s ním pracovníci účtárny a finanční ředitelka. Jednotlivá účetní data jsou zpracovávány pro každou pobočku zvlášť, účetní modul je tedy rozdělen na několik částí podle poboček, nelze tedy získávat jednotlivé informace o účetnictví pro všechny pobočky souhrnně. Na tuto část systému navazuje modul saldokonto, kterým jsou zpracovávány přijaté a vydané faktury. Tento modul se nachází na každé pobočce, pracují s ním jednotliví fakturanti. Informace ze saldokonta na jednotlivých pobočkách opět nejsou mezi sebou propojeny, lze je tedy získávat pouze ze softwarových částí na jednotlivých pobočkách. Původní software zpracovávající tuto agendu od roku 1993 byl inovován v roce 2008 společně s účetním modulem. Další důležitou částí IS je MTZ (materiálně technické zabezpečení), tedy modul pro řízení skladové evidence. Tato programová část systému je nejstarší, od svého nasazení nebyla dosud inovována. Opět zde není propojení mezi jednotlivými softwarovými částmi, které jsou užívány na jednotlivých pobočkách. Pracovníci využívající tuto část proto mají přehled pouze o zboží skladované na své pobočce, popř. pokud chtějí zjistit stav skladových zásob zboží z ostatních poboček, musí být daná část softwaru nainstalována zvlášť. Celkové přehledy o stavu zboží na skladě pro všechny pobočky tedy zatím nemají pracovníci jednotlivých poboček k dispozici. Data z tohoto modulu jsou využívána jak v saldokontu, tak v účetnictví. Tyto tři programové části podnikového informačního systému jsou spolu provázány pomocí spojovacích souborů, díky kterým dochází k elektronické výměně dat mezi těmito softwarovými moduly. Tyto spojovací soubory jsou vytvářeny jednou denně a obsahují jednotlivé změny a nové údaje týkající se MTZ, saldokonta a

32

účetních dat. Všechny tyto moduly vytvořila a do IS integrovala společnost RAVEN-SOFTWARE Choryně. V roce 2007 byl také zprovozněn internetový systém objednávek, který doplnil stávající webovou prezentaci společnosti, aby nabídl zákazníkům novou alternativu pro naplňování jejich potřeb. Tento podsystém však nevyužívá společnou datovou základnu se systémem řízení skladové evidence, což do značné míry omezuje jeho funkcionalitu (jednotlivé skladové položky jsou vkládány duplicitně do objednávkového systému a do MTZ, navíc nabídky položek k objednání nekopíruje aktuální stav skladových položek). Hlavním problémem stávajícího podnikového informačního systému je tedy nejednotná datová základna, z čehož vyplývá duplicita dat a problémy s jejich sběrem a hodnocením informací, které lze z těchto podnikových dat získat. Zcela také chybí softwarová podpora manažerského rozhodování a software zajišťující data potřebná v systému řízení jakosti.

33

5 Vlastní práce Objektová procesní analýza společnosti UNIKOL s.r.o. a následný návrh inovace části tohoto systému vychází z metodiky Unified Process, nicméně je tato použitá metodika do jisté míry zredukována, především s ohledem na rozsah této diplomové práce. Pro tvorbu všech diagramů obsažených v této části byl použit modelovací CASE nástroj Enterprise Architect 7.5.

5.1

Procesní model

Prvním krokem analýzy podnikového informačního systému je procesní model. Tento model slouží k popisu hlavních interních procesů v organizaci s jejich vstupy a výstupy. Jak je možné vidět na obrázku 6, stěžejní firemní činnost je vzhledem k hlavnímu cíli společnosti, kterým je samozřejmě tvorba zisku, proces řízení obchodu, který je tím pádem hlavním procesem ve společnosti. Tento proces vytváří produkt pro zákazníka a proto je jediným možným firemním procesem vedoucím ke splnění podnikových cílů. Událostí, která inicializuje tento proces, je objednávka podaná od zákazníka společnosti. Výstupem tohoto procesu je tedy prodané zboží, které uspokojuje jeho potřeby. Aby byly tyto potřeba zákazníka uspokojeny, je třeba dbát především na tyto aspekty: • splnění požadavků z hlediska kvality a ceny prodávaného zboží, • dodržení termínů smluvených při objednání zboží, • poradenská činnost spojená s prodejem zboží i po jeho prodeji zákazníkům, • servis spojený se zárukou na zboží. Proces řízení obchodu je tvořen dalšími procesy, které popisují činnosti v jednotlivých fázích zpracování přijaté objednávky (přijetí objednávky, její zpracování a vyřízení). Končí tedy předáním, nebo odesláním prodaného zboží. Podpůrným procesem tohoto hlavním procesu je řízení skladu. Jeho cílem je uspokojení materiálních potřeb společnosti, tedy zabezpečit dostupnost objednaného zboží v rámci dohodnutých termínů. Skládá se z dalších procesů, kterými jsou zjištění stavu zboží na skladu, při jeho nedostupnosti je nutné ho objednat a posléze naskladnit. Poslední částí tohoto podpůrného procesu je výdej zboží podle přijatých objednávek. Poslední částí tohoto modelu je proces finanční řízení podniku. To zajišťuje zákonem povinné vedení účetnictví, saldokonta a tvorbu sestav popisujících všechny hlavní informace o stavu podniku (výsledovky) za jednotlivé měsíce, či jinak zvolená období. Tyto hlavní činnosti se tedy neustále opakují a na jejich jednotlivých částech se podílejí všichni zaměstnanci společnosti. V následující části budou jednotlivé bloky popsány detailněji.

34

Obrázek 6: Business Process Model - celkový pohled

35

5.1.1 Řízení obchodu Jak již bylo řečeno výše, řízení obchodní činnosti je hlavním podnikovým procesem ve společnosti UNIKOL s.r.o., jelikož vytváří hodnoty pro zákazníky a tím pádem tak naplňuje jejich potřeby. Tento blok je vyvolán objednávkou zboží, tuto událost vyvolá zákazník společnosti. Ten má možnost objednávku odeslat elektronickou formou (e-mail nebo internetový systém objednávek), telefonicky nebo faxem. Prvním procesem, aktivovaným nově vzniklou objednávkou, je přijetí objednávky. Vlastníky tohoto procesu jsou obchodníci, kteří mají na starost prodej zboží a komunikaci se zákazníky. Cílem tohoto procesu je přijetí a založení nové objednávky zboží. Jeho výstupem je vznik nového zákazníka a přijaté objednávky. Dalším navazujícím procesem je zpracování a vyřízení objednávky, jehož vlastníkem jsou také obchodníci společně s fakturanty. Vstupem do tohoto procesu je přijatá objednávka, ze které vychází požadavek na zajištění potřebného zboží ve formě výstupu, který je potřebný pro podpůrný proces řízení skladu. Po zajištění zboží v podpůrném procesu vstupuje zpracovaná objednávka zpět do tohoto procesu a je vyřízena. Tato vyřízená objednávka je konečným výstupem tohoto procesu společně s vystavenou fakturou na to zboží, kterou vystaví fakturant. Poslední činností je zabalení a odeslání zboží (případně převzetí). Vlastníkem tohoto procesu je skladník (logistik), jehož úkolem je v tomto případě připravit zboží na převzetí zákazníkem. Zboží může být odesláno přepravní službou, poštovním balíkem, nebo vyzvednuto osobně na pobočce. Skladník musí k tomuto zboží také vystavit dodací list, který je také výstupem tohoto procesu. Předání zboží zákazníkovi (v diagramu výstupní událost) je tedy výstupem tohoto procesu a celého bloku řízení obchodu.

Obrázek 7: BPM - řízení obchodní činnosti

36

5.1.2 Řízení skladu Řízení skladu se skupina podpůrných procesů pro obchodní činnost společnosti, která má za úkol především uspokojení materiálních potřeb společnosti. Tento blok je tvořen čtyřmi procesy, kterými jsou zjištění stavu zboží na skladu, objednávka zboží, naskladnění zboží a jeho následné vyskladnění. První z nich, tzn. zjištění stavu zboží na skladu, je aktivován při objednávce zboží. Vstupem je nová objednávka a stav skladu. Vlastníkem tohoto procesu je obchodník. Pokud je požadované množství zboží fyzicky na skladě, je výstupem výdejka pro toto zboží. V opačném případě je výstupem seznam zboží pro objednání. To zajišťuje opět obchodník v procesu objednávka zboží. Je zde tedy u dodavatelů zajišťováno zboží, které je zákazníky objednáno, ale firma jím aktuálně nedisponuje. Výstupem je realizovaná objednávka zboží u dodavatele společnosti. Proces naskladnění zboží je realizován po dodání zboží od dodavatele. Vstupem je dodací list na toto zboží a příjemka na sklad. Vlastníkem tohoto procesu je skladník (naskladní zboží) a fakturant. Fakturant následně vytvoří výdejku na zboží pro zákazníka. Je také aktualizován stav skladové evidence.

Obrázek 8: BPM - řízení skladu

37

Po vytvoření skladové výdejky skladník zboží vydá ze skladu v procesu vyskladnění zboží. Je také znovu na základě výdejky fakturantem upraven stav skladové evidence a dalším výstupem je zpracovaná objednávka od zákazníka. 5.1.3 Finanční řízení Posledním blokem procesů je finanční řízení. To je složeno z vedení saldokonta, vedení účetnictví a tvorby výsledovek společnosti. Vstupy do vedení saldokonta tvoří přijaté faktury od dodavatelů a vydané faktury pro zákazníky na zboží. Evidenci těchto faktur má ve společnosti na starost fakturant (jak přijaté tak vydané). Výstupem tohoto procesu je tedy jak samotné saldokonto, tak přehled tržeb odvozený z jednotlivých faktur. Dalším procesem je vedení účetnictví, vlastníkem toho procesu jsou již účetní. Jednotlivé vstupy tvoří bankovní výpisy, stavy pokladny, různé účetní doklady a také pracovní výkazy od zaměstnanců. Zde je vytvořen výstup v podobě vypočtených mezd a jednotlivých účetních záznamů. Ty jsou následně i s přehledem tržeb využity v posledním procesu, kterým je tvorba výsledovky. Tyto výsledovky jsou vytvářeny jako přehledy o fungování společnosti za jednotlivé měsíce, či jinak zvolená období, které následně využívá vedení firmy pro svá rozhodnutí. Do tohoto procesu zasahuje jako aktér opět účetní.

Obrázek 9: BPM - finanční řízení

38

5.2

Současná softwarová podpora firemních procesů

V současné době jsou všechny tři skupiny procesů ve společnosti UNIKOL s.r.o., které byly popsány v procesní analýze, do určité míry podporovány softwarovými moduly stávajícího podnikového informačního systému společnosti RAVEN-SOFTWARE. Hlavní firemní proces, kterým je řízení obchodu, je podporován pouze systémem internetových objednávek. Základním problémem tohoto procesu je ukládání přijatých objednávek v papírové podobě ať už jsou přijaty jakýmkoliv způsobem (telefon, fax, e-mail, dokonce i objednávky přijaté internetovým systémem jsou následně tisknuty), tím pádem je papírová agenda v tomto případě opravdu rozsáhlá. Z tohoto důvodu společnosti vznikají jak problémy časové (přepisy objednávek, jejich zakládání), problémy se zpětným dohledáním objednávky (v jakémkoliv stavu) a v neposlední řadě problémy s vymezením prostoru pro uložení těchto objednávek v papírové podobě (šanonů neustále přibývá). Chybí také jakákoliv softwarová podpora řízení vztahu se zákazníkem. Systém internetových objednávek také nevyužívá společné datové základny s ostatními moduly informačního systému, proto také vzniká duplicita dat a jeho nabídka produktů nekopíruje aktuální stav skladu a nabídku zboží. Řízením skladové evidence se zabývá modul informačního systému MTZ. Jeho hlavním nedostatkem je však skutečnost, že pro jeden fyzický sklad na jednotlivých pobočkách je vytvořen samostatný program, čili informace o stavu skladu na jednotlivých pobočkách nelze zpracovávat a získávat hromadně, nýbrž odděleně pro každou pobočku. Tato skutečnost komplikuje práci především obchodníkům. Import dat z MTZ do účetnictví je realizován pomocí spojovacích souborů, ten však neprobíhá automaticky, ale každodenně až po zvolení příslušné akce v účetním programu. Modul MTZ umožňuje také tisk sestav potřebných např. při inventurách. Asi nejlepší softwarovou podporu má proces finanční řízení. Programové moduly, které zpracovávají tuto agendu, obsahují všechny důležité části pro vedení saldokonta, účetnictví a mezd (faktury přijaté a vydané, banka, pokladna, mzdy, majetek, podvojné účetnictví). Určité nedostatky má správa personalistiky (hlavně evidence docházky). Účetní modul také zajišťuje tvorbu výsledovek, ten je ale jako programový nástroj pro podporu manažerského rozhodování již nedostačující. Všechny tyto moduly informačního systému společnosti RAVEN-SOFTWARE (MTZ, saldokonto, účetnictví, mzdy, fakturace) mají společnou datovou základnu založenou na databázovém systému MySQL. Pro potřeby společnosti tak nejvýrazněji chybí softwarová podpora řízení vztahů se zákazníkem, zlepšená podpora manažerského rozhodování (analýza a plánování) a jelikož je v této firmě zavedeno řízení kvality jakosti (nutné pro získání certifikátu ISO 9001:2008), chybí zde také podpora těchto procesů (vedení řízené dokumentace pro tyto ISO normy).

39

5.3

Možnosti inovace informačního systému společnosti

Z procesní analýzy a ze zhodnocení současné softwarové podpory se nabízí několik možností inovace současného podnikového informačního systému. Tyto možnosti inovací se mezi sebou liší především náklady na jejich vývoj a implementaci a délkou období, které by bylo potřebné na jejich integraci do stávajícího systému. Mezi takovéto možnosti patří především: • Inovace stávajících modulů informačního systému podle aktuálních potřeb společnosti od stejného dodavatele. • Dokoupení a integrace dalších modulů podporující procesy, které nejsou prozatím zpracovány žádnou částí podnikového informačního systému. • Kompletní integrace nového informačního systému od jiného dodavatele se všemi potřebnými moduly, které by pokryly veškeré procesy ve společnosti. 5.3.1 Inovace stávajících modulů informačního systému První možností inovace podnikového informačního systému je úprava stávajících modulů podle nových potřeb společnosti. Tyto úpravy by se týkaly především části IS MTZ a účetnictví, za účelem rozšíření, nebo zefektivnění jejich funkcionality. U modulu MTZ by to bylo především sloučení všech programových částí pro jednotlivé pobočky do jediné aplikace, což by umožňovalo získávání všech potřebných informací o celkovém stavu skladu ve společnosti v rámci jednoho programu. Dále by bylo nutné sjednotit datovou základnu MTZ se systémem internetových objednávek. Tuto inovaci značně zjednodušuje fakt, že pro správu a uložení dat obou těchto částí IS je použit stejný databázový systém (MySQL). S objednávkami by byla také spojena inovace evidence objednávek, která by mohla rozšířit část systému zpracovávající agendu fakturací. Účetní modul by měl být v tomto případě obohacen zvláště o možnost tvorby lepšího výstupu pro manažerské rozhodování (kromě výsledkových sestav také hodnocení finančních výsledků a zdraví firmy, které je možno sestavit na základě účetních údajů). Tyto inovace částí IS by byly implementovány stávajícím dodavatelem, kterým je společnost RAVEN-SOFTWARE. Vzhledem k tomu, že by se jednalo pouze o vylepšení stávajících modulů, byla by tato možnost nejméně finančně náročná. Jak je možné vidět v tabulce níže, hrubé odhadované náklady (vypočtené na základě obvyklé sazby účtované společností RAVEN-SOFTWARE) potřebné k realizaci těchto inovací IS by se pohybovaly kolem 300 000 Kč. Otázkou však zůstává, zda-li by byla tato varianta, vzhledem k úplné absenci některých ucelených funkcionalit (podpora řízení kvality jakosti, nástroje pro podporu řízení vztahů se zákazníky, pokročilé nástroje pro podporu manažerského rozhodování), pro společnost UNIKOL s.r.o. vhodná.

40

Tabulka 1: Odhadované náklady na inovací stávajících modulů IS

Činnost Úprava modulu MTZ Úprava modulu účetnictví Elektronická evidence objednávek Úprava internetového systému Celkem

Člověkodny 25 7 10 5 42

Cena celkem v Kč 150 000,42 000,60 000,30 000,282 000,-

5.3.2 Dokoupení a integrace dalších programových modulů Kromě výše popsané inovace stávajících modulů podnikového informačního systému se také nabízí možnost dokoupení programových modulů, které by pokryly i části procesů, kterým doposud výrazná softwarová podpora chybí. Došlo by tím také ke značnému omezení papírových agend, kterých vzniká při činnostech firmy velké množství. Jednalo by se především o programové moduly v těchto oblastech: • Personalistika, • MIS (manažerský informační systém), • řízení dokumentace. Tyto nové části informačního systému by byly dodány a integrovány také firmou RAVEN-SOFTWARE, která by tak pouze rozšířila své stávající nasazené řešení. Následující tabulka popisuje navrhovanou finanční náročnost a počty potřebných licencí pro rozšíření informačního systému. Tabulka 2: Cena licencí nových modulů stávajícího IS

Modul Personalistika MIS Řízení dokumentace Celkem

Počet uživatelů 5 5 5 15

Cena 45 000,10 000,25 000,80 000,-

Pokud by tedy chtěla společnost UNIKOL s.r.o. investovat jak do inovace stávajících částí informačního systému, tak do nákupu částí nových (připočteme-li 55 000 Kč jako odhadované náklady na implementaci a školení zaměstnanců), potřebná částka by neměla přesáhnout 420 000 Kč. Pokud by upřednostnila pouze nákup nových modulů, bylo by potřeba investovat přibližně 135 000 Kč. Výhodou by byla dobrá návaznost na již implementované části IS, využití stejných technologií (databázový systém MySQL) a stejného uživatelského rozhraní.

41

5.3.3 Kompletní integrace nového informačního systému Posledním způsobem inovace by mohl být nákup nového informačního systému od jiného dodavatele. Tento krok je výhodný především vzhledem k integraci všech modulů IS najednou, možností zvolit jiný databázový systém pokrývající datovou základnu a především dobrou vzájemnou komunikaci a výměnu dat mezi jednotlivými moduly. Takovýmto informačním systémem by mohl být např. Dialog 3000S, který je vyvíjen a nasazován společností Control, spol. s r.o., která sídlí v Šenově u Nového Jičína (což by mohlo být výhodné vzhledem k blízkosti do Zubří, kde by bylo potřeba integrovat největší část systému – hlavně díky přítomnosti účetního úseku a finančního vedení společnosti na této pobočce). Z procesní analýzy a potřeb společnosti vyplývá vhodnost nasazení následujících nabízených modulů informačního systému Dialog 3000S: • Správa systému – slouží k definici uživatelů a přístupových práv, archivaci dat, konfigurace replikace, správa systému, správa číselníků. • Finanční komplex – účetní modul, který slouží ke zpracování účetních zápisů z informačního systému (finanční agenda – pokladna, bankovní účty, finanční účetnictví, správa majetku, agenda spojená s DPH, statistické výkazy). Umožňuje nastavení účetních pravidel, daní a zpracování účetních závěrek. Tento modul také zajišťuje správu saldokonta dodavatelských a odběratelských dokladů. • Finanční kancelář – modul pro zpracování manažerských výstupů (finanční analýza a plánování, hodnocení finančního zdraví firmy, ROLAP). • Nákup a prodej – skladové hospodářství, kontakty, zboží, zakázky, objednávky, nabídky, fakturace, péče o zákazníky, zásobování s vazbou na sklady, podporuje více skladů na různých pobočkách. • Mzdy – modul pro vedení mzdové agendy v souladu s platnou legislativou. Obsahuje vazbu na docházku, personalistiku a řízení výroby. • Personalistika – modul pro personální řízení a přípravu podkladů pro výpočet mezd. • Řízení dokumentace – modul pro vedení řízené dokumentace dle potřeb pro ISO normy. V oblasti firemního managementu dokumentů je využíván pro distribuci zápisů z porad a přidělování úkolů včetně sledování jejich plnění. V následující tabulce jsou uvedeny počty potřebných licencí jednotlivých modulů (odvozené od počtu používaného hardwaru) a náklady na jejich pořízení:

42

Tabulka 3: Cena licencí jednotlivých modulů IS Dialog 3000S

Modul Správa systému Nákup a prodej Finanční komplex Finanční kancelář Personalistika Řízení dokumentace Mzdy Cena licencí

Počet uživatelů 1 20 5 5 5 5 5 -

Cena celkem v Kč 10 000,300 000,60 000,18 000,63 000,40 000,55 000,546 000,-

S integrací nového informačního systému jsou spojeny samozřejmě také náklady na jeho implementaci a školení uživatelů (seznámení s funkcionalitami jednotlivých modulů), které jsou závislé na počtu uživatelů systému a počtu integrovaných modulů. Náklady spojené s těmito činnostmi vyjadřuje další tabulka: Tabulka 4: Náklady na implementaci a školení zaměstnanců

Činnost Instalace HW (servery a PC) Správa systému Nákup a prodej Finanční komplex Finanční kancelář Personalistika Řízení dokumentace Mzdy Celkem

Člověkodny 2 3 15 8 6 2 2 7 45

Cena celkem v Kč 16 000,24 000,120 000,64 000,48 000,16 000,16 000,56 000,360 000,-

Pro ukládání a správu dat využívá informační systém Dialog 3000S databázi Adaptive Server Enterprise 15.03 od společnosti Sybase. Tato technologie je při jejích nasazení výhodná především v těchto ohledech: • veškerá data do systému vstupují pouze jednou, • všechna data jsou bez jakéhokoliv zásahu distribuována na místo určení pouze nastavením systému, • zvýšená bezpečnost zpracování dat, • data při distribuci neopustí systém, • dochází k automatické kontrole integrity dat na úrovni serveru a minimalizuje se možnost chyb způsobených lidským faktorem. Použitý databázový systém Sybase by byl konfigurován na jeden server a 40 instalovaných pracovních stanic. Náklady na takovéto nasazení by dosáhly výše 205 000 Kč.

43

Pokud jsou tedy všechny náklady na pořízení nového informačního systému Dialog 3000S sečteny (viz. Tabulka 5), musela by společnost UNIKOL s.r.o. investovat 1 151 000 Kč do integrace systému a dalších 81 900 Kč ročně za služby spojené s provozem IS, což je vzhledem k ostatním možnostem inovace IS zdaleka nejvyšší částkou. Toto řešení by však společnosti zřejmě přineslo největší pozitiva, vzhledem k větším možnostem modulů ve srovnání s těmi, co jsou ve firmě nasazeny v dnešní době (především se to týká částí IS, které prozatím nejsou integrovány). Tabulka 5: Celková cena řešení IS Dialog 3000S

Položka Licence IS DIALOG 3000S Vstupní analýza Implementační práce a školení Cena databáze Sybase Cena řešení celkem HotLine – 5% ročně z ceny licence Update – 10% ročně z ceny licence Služby roční celkem (Hot-line, aktualizace)

5.4

Celkem v Kč bez DPH 546 000,40 000,360 000,205 000,1 151 000,27 300,54 600,81 900,-

Návrh inovace IS řízení skladové evidence (MTZ)

Jak vyplývá z části zhodnocení softwarové podpory podnikových procesů, jedním z modulů systému vhodných pro inovaci je modul MTZ, který zajišťuje řízení skladové evidence. Jedním z hlavních důvodů pro návrh inovace této části IS je rozdělení této systémové aplikace na několik programových částí, kdy každá takováto část zahrnuje skladovou agendu pouze na jedné pobočce společnosti. Bylo by proto vhodné, kdyby inovovaný software zahrnoval především možnost prohlížení stavu skladu na různých pobočkách v rámci jednoho programu. 5.4.1 Případy užití a aktéři systému MTZ Use Case analýza bude vycházet z již navrženého procesního modelu, kde byly definovány základní požadavky na tuto část podnikového informačního systému. Nejprve je potřeba nalézt jednotlivé aktéry, kteří budou systém MTZ využívat. Jedná se o zaměstnance společnosti, kteří byli rozděleni podle svých pracovních pozic a dále podle možností, které mají při používání MTZ. Jsou to tyto typy uživatele: • Administrátor • Obchodník • Fakturant • Skladník Administrátor má přístup k veškeré funkcionalitě programu, má také na starost správu uživatelů (jejich přidání, či odebrání). Takovýto uživatel je vždy

44

pouze jeden na každé pobočce a jedná se o vedoucího pobočky pro obchod (má také možnost v systému upravit údaje o své pobočce). Skladník pracuje ve skladu s fyzickými skladovými položkami. V systému MTZ může pouze prohlížet stav skladových položek na jednotlivých pobočkách a vyhledávat skladové položky (tento výstup je možné tisknout). Má přístup také k seznamu společností a může měnit své uživatelské údaje. Stejné možnosti práce se systémem jako skladník má také řadový obchodník. Výjimku mezi obchodníky tvoří vedoucí pobočky pro obchod s právy administrátora. Posledním aktérem je fakturant. Ten má přístup k příjmu a výdeji zboží, zakládání nových skladových karet, úpravě údajů o skladových položkách, vytváření a editaci údajů o firmách (jak dodavatelských, tak odběratelských). Zvláštním případem aktéra je čas, ten je spojen především s exportem dat. Po nalezení aktérů systému následuje zobrazení jednotlivých případů užití (tedy jednotlivých funkcionalit) v Use Case diagramu. Díky složitosti celkového diagramu případů užití byly tyto funkcionality rozděleny do čtyř oblastní podle svého využití (celkový diagram případů užití je uveden v příloze): • Uživatelská část, • evidence skladové položky, • stav skladu, • evidence firem. Díky tomuto rozdělení vznikly čtyři diagramy případů užití, které budou popsány v následující části. Ty budou poskytovat ucelený pohled na funkcionalitu celé aplikace. Ke každému diagramu bude také vytvořen jeden scénář případu užití (pokud bude potřeba, tak i s jeho alternativními scénáři). Ostatní případy užití budou popsány pouze slovně. a) Uživatelská část: Jak již bylo uvedeno výše, systém rozlišuje několik druhů uživatelů, podle jejich pracovní pozice. Jelikož mají při používání této části různá práva a povinnosti, je nutné pro jejich evidenci využít těchto funkcionalit: • Přidání nového uživatele — vytvoření nového záznamu o uživateli v databázi a uložení všech potřebných údajů o tomto uživateli. Kontroluje se korektnost všech zadaných vstupů, jinak nové údaje nelze uložit. • Odebrání uživatele — vymazaní zvoleného uživatele a všech údajů o něm z databáze. Tento uživatel se již nemůže přihlásit do systému. • Změna osobních údajů uživatele — každý uživatel má možnost změnit své osobní údaje, jako je jméno, příjmení, přihlašovací jméno a heslo. Po kontrole korektnosti vstupů jsou nové údaje uloženy do databáze. • Odhlášení uživatele — uživatel se po potvrzení dialogu odhlásí ze systému.

45

•

Přihlášení uživatele — uživatel musí pro přístup do systému zadat své uživatelské jméno a heslo. Tabulka 6: Hlavní scénář - Přihlášení do systému

Případ užití: PřihlášeníDoSystému ID: 1 Stručný popis: Uživatel se přihlásí do systému MTZ. Aktér: Uživatel Vstupní podmínky: 1. Uživatel spustí program MTZ.

Hlavní scénář: 1. Případ užití startuje zobrazením přihlašovacího dialogu. 2. Uživatel zde zadává své přihlašovací jméno a heslo. 3. Uživatel vyplní dialog a zvolí tlačítko „Přihlásit se“. 4. DOKUD nejsou vyplněny oba dva údaje v dialogu. 4.1 Systém zobrazí informaci o chybném vyplnění dialogu. 4.2 Uživatel potvrdí zvolením „OK“. 5. Systém ověří existenci uživatele se zadaným loginem a heslem. 6. Uživatel je přihlášen do systému. 7. Je zobrazeno základní uživatelské prostředí programu. Výstupní podmínky: Uživatel je přihlášen a může pracovat se systémem. Alternativní scénáře: NeplatnéPřihlašovacíJméno NeplatnéHeslo Tabulka 7: Alternativní scénář - Neplatné přihlašovací jméno

Případ užití: PřihlášeníDoSystému:NeplatnéPřihlašovacíJméno ID: 1.1 Stručný popis: Upozornění uživatele při zadaní neplatného uživatelského jména Aktér: Uživatel Vstupní podmínky: 1. Uživatel zadal neplatné uživatelské jméno.

Alternativní scénář: 1. Alternativní scénář startuje v kroku 5 hlavního scénáře. 2. Uživatel zde zadává neplatné přihlašovací jméno. 3. Systém zobrazí dialog „Neplatné přihlašovací jméno“. 4. Je znovu zobrazen přihlašovací dialog. Výstupní podmínky: Žádné.

46

Druhý alternativní scénář NeplatnéHeslo se liší pouze vstupní podmínkou, kterou je zadání neplatného uživatelského hesla, a výpisem chybové hlášky.

Obrázek 10: Diagram případů užití uživatelské části

b) Evidence skladové položky: Základ celého systému řízení skladové evidence tvoří skladové položky. Data o jednotlivých skladových položkách zpracovává převážně fakturant. Tato část aplikace má tedy za úkol ukládat a následně zobrazovat informace o jednotlivých položkách na skladu. Jednotlivé případy užití jsou tyto: • Zobrazení skladovací karty a pohybu položky — každý uživatel systému má možnost nahlédnout do skladovací karty položky na jakékoliv pobočce. Karta se skládá z listu se souhrnnými údaji o skladové položce (např. počet kusů na skladě, průměrná skladová cena, atd.), dále obsahuje listy s údaji o všech příjmech a výdejích položky. • Výdej skladové položky — na základě výdejky fakturant zaeviduje výdej položky i v MTZ. Počet kusů vydané položky musí být menší nebo roven počtu kusů zaevidovaných na skladu, jinak není možné výdej uložit. Probíhá také kontrola vstupních dat a odběratele.

47

•

•

Založení skladové karty — v případě, že se skladová položka v evidenci nevyskytuje, je nutné založit novou skladovou kartu. Po vyplnění potřebných údajů a jejich kontrole je nová skladová karta uložena. Příjem skladové položky — evidence příjmu položky na sklad. Tabulka 8: Hlavní scénář - Příjem skladové položky

Případ užití: PříjemSkladovéPoložky ID:2 Stručný popis: Evidence příjmu skladové položky na sklad. Aktéři: Fakturant, administrátor Vstupní podmínky: 1. Fakturant vybere z nabídky menu aplikace „Příjem na sklad“. Hlavní scénář: 1. Případ užití startuje zobrazením dialogu pro vložení názvu položky. 2. KDYŽ zadaný název položky neexistuje, 2.1 je spuštěna funkce Založení skladové karty. 3. KDYŽ bylo podle názvu nalezeno více skladových položek, 3.1 je zobrazen dialog pro výběr hledané položky pro příjem. 4. Aktér musí vložit do zobrazeného formuláře potřebné údaje. 5. DOKUD není formulář korektně vyplněn, 5.1 je zobrazen dialog s chybovou hláškou, 5.2 Aktér potvrdí zvolením „OK“, je znovu zobrazen formulář pro příjem. 6. KDYŽ je počet kusů položky pro příjem >0, 6.1 proběhne přepočet všech údajů a nová data se uloží do databáze. 7. KDYŽ je počet kusů položky pro příjem <= 0, 7.1 proběhne kontrola počtu kusů skladovém položky, 7.2 minusový příjem je přepočten a nová data jsou uložena do databáze. Výstupní podmínky: Žádné. Alternativní scénáře: ZaloženíSkladovacíKarty NeplatnýMínusovýPříjem Hlavní scénář případu užití má dva alternativní scénáře. Jedním z nich je ZaloženíSkladovacíKarty, které odpovídá běžné funkcionalitě uvedené v evidenci skladových položek. Dalším alternativním scénářem je NeplatnýMinusovýPříjem. Ten je spuštěn v případě, že fakturant při minusovém příjmu zadá větší počet kusů, než je aktuálně k dispozici na skladě podle skladové evidence. V takovémto případě je zobrazen dialog s chybovou hláškou a fakturant má po jeho potvrzení možnost minusový příjem zadat znovu. Toto je opakováno neustále až do provedení platného minusového příjmu nebo do ukončení formuláře pro příjem.

48

Obrázek 11:Diagram případu užití evidence skladové položky

c) Stav skladu: Smyslem těchto případů užití je zobrazení stavu skladové evidence ve formě, kterou po aplikaci žádá uživatel. Navíc také umožňuje tisk výstupu a export změn na materiálových účtech. Tato část programu nabízí tyto funkce. • Výběr zobrazené pobočky — uživatelé mají možnost vybrat, se kterou skladovou evidencí dané pobočky se bude pracovat. Po přihlášení je nastavena pobočka, jejímž zaměstnancem je přihlášený uživatel. • Tisk — uživatelé mohou vytisknout buďto kompletní seznam skladové evidence, nebo pouze výsledky vyhledávání, či filtrování výpisu. • Export — Aktuální změny na materiálových účtech jsou každý den exportovány v nastavenou hodinu do spojovacího souboru. Fakturant a administrátor má také možnost zvolit ruční export a vytvoření tohoto souboru. • Filtrovaný výstup — zobrazený stav skladové evidence může být uživatelem přizpůsoben podle jeho potřeb. Tento případ užití umožňuje především omezení počtu zobrazených informací a omezení položek podle názvu. • Hledání skladových položek — vyhledávání nad množinou skladových položek napříč všemi pobočkami.

49

Tabulka 9: Hlavní scénář - Hledání skladových položek

Případ užití: HledáníSkladovýchPoložek ID:3 Stručný popis: Vyhledávání nad množinou skladových položek Aktéři: Uživatel Vstupní podmínky: 1. Uživatel vybere z nabídky aplikace „Najít“.

Hlavní scénář: 1. Případ užití startuje zobrazením dialogu pro hledání položky podle názvu. 2. KDYŽ hledaný název položky neexistuje, 2.1 Je zobrazen dialog pro uživatele s chybovou hláškou. 2.2 Uživatel potvrdí zvolením „OK“. 3. KDYŽ hledaný název odpovídá alespoň jedné položce, 4. je zobrazeno okno obsahující údaje u těchto položkách. 5. KDYŽ uživatel použije tlačítko tisk, 5.1 je spuštěna funkce Tisk (pro aktuální výsledek hledání). Výstupní podmínky: Žádné. Alternativní scénáře: Žádné.

Obrázek 12: Diagram případů užití stav skladu

50

d) Evidence firem: Poslední skupina případů užití slouží k evidenci a správě informací o firmách dodavatelských i odběratelských. Administrátorovi umožňuje také upravit informace o své pobočce. Jedná se tedy o tyto případy užití: • Najít firmu — každý uživatel může vyhledat údaje, které jsou uloženy v systému o dané společnosti. Hledaná firma je identifikována podle názvu vloženého od uživatele. Po zvolení hledané společnosti je zobrazeno okno s jejími údaji. • Přidat firmu — Fakturant (popř. administrátor) má možnost přidat novou firmu do evidence společností. Po vyplnění formuláře s údaji o této společnosti jsou data uložena do databáze. • Upravit údaje o pobočce — každý administrátor může upravit základní údaje o své pobočce, které jsou uloženy v systému. • Upravit údaje o firmě — upravení údajů v systému o vybrané společnosti. Tabulka 10: Hlavní scénář - Upravit údaje o firmě

Případ užití: UpravitÚdajeOFirmě ID:4 Stručný popis: Fakturant změní údaje o vybrané společnosti. Aktéři: Fakturant, administrátor Vstupní podmínky:

1. V nabídce aplikace je zvolena možnost „Upravit údaje o společnosti“.

Hlavní scénář: 1. Případ užití startuje zobrazením dialogu pro hledání firmy podle názvu. 2. KDYŽ hledaný název firmy neexistuje, 2.1 je zobrazen dialog pro uživatele s chybovou hláškou. 2.2 Aktér potvrdí zvolením „OK“. 3. KDYŽ bylo podle názvu nalezeno více firem, 3.1 je zobrazen dialog pro výběr hledané firmy. 3.1 Aktér musí vybrat hledanou firmu. 4. Je zobrazeno okno obsahující údaje o vybrané společnosti. 5. Aktér zvolí tlačítko uložit pro úpravu údajů o firmě. 6. DOKUD není formulář se změnou údajů o firmě korektně vyplněn, 6.1 je zobrazen dialog s chybovou hláškou. 6.2 Aktér potvrdí zvolením „OK“, je znovu zobrazen formulář pro příjem. 7. Změněné údaje o firmě jsou uloženy do databáze. Výstupní podmínky: Žádné. Alternativní scénáře: Žádné

51

Obrázek 13: Diagram případu užití evidence firem

5.4.2 Diagram tříd systému MTZ Na základě vytvořeného procesního modelu a definice případů užití pro systém MTZ je možné vytvořit diagram návrhových tříd, který popisuje strukturu systému. Pro usnadnění následné realizace byly nejprve jednotlivé třídy rozděleny do tzv. balíčků (package), které slučují významově související třídy do stejné skupiny.

Obrázek 14: Diagram tříd – balíčky

52

Tímto sloučením pak vznikly v tomto diagramu čtyři balíčky – Firma (třídy Firma, Adresa a Pobočka), Uživatel, Rozhraní (třída s grafickým uživatelským rozhraním aplikace a třída obsahující metody pro práci s databází) a Mtz (třídy Položka, Zboží, Skladovka, Pohyb a Výrobce). Diagram návrhových tříd již obsahuje všechny třídy a implementační podrobnosti, které jsou reprezentovány atributy a operacemi. Operace tříd vycházejí především z již definovaných případů užití.

Obrázek 15: Diagram tříd systému MTZ

5.4.3 Diagram aktivit - příjem skladové položky Diagram, kterým se zabývá tato kapitola, popisuje realizaci případu užití příjem skladové položky. Jedná se tedy o zobrazení posloupnosti aktivit, jejichž cílem je evidence příjmu nově naskladněné položky. Tento případ užití je realizován fakturantem (popř. administrátorem).

53

Tato aktivita může být ukončena čtyřmi událostmi, kterými jsou: • Vytvoření nové skladové karty, • zrušení příjmu, • evidence příjmu, • evidence mínusového příjmu. Nová skladová karta může být vytvořena v případě, že hledaná skladová položka pro příjem není nalezena. V takovémto případě je také možné příjem zrušit. Při nalezení potřebné položky (pokud je položek nalezeno více, tak po výběru konkrétní položky) jsou zadány údaje potřebné k příjmu. Tento příjem může být buďto „klasický“ (kladný počet kusů položky), nebo záporný (je realizován např. při chybném zadání počtu kusů dané položky při jejím příjmu, tímto se dosáhne skutečnému počtu přijaté skladové položky).

Obrázek 16: Diagram aktivit - příjem skladové položky

54

5.4.4 Sekvenční diagram Pro lepší pochopení aktivit spojených s příjmem položky může posloužit sekvenční diagram na obrázku č. 17. Tento digram ukazuje, v jakém sledu jsou volány metody jednotlivých tříd při příjmu položky na sklad (vychází z hlavního scénáře případu užití Evidence příjmu skladové položky). Jelikož je při nenalezení hledané položky použit jiný případ užití, je v diagramu zobrazena pouze zpráva aktivující tento případ užití.

Obrázek 17: Sekvenční diagram - příjem skladové položky

55

5.4.5 Stavový diagram Pro stavový diagram byla vybrána třída Položka. Ta je klíčová vzhledem k tomu, že systém řeší problematiku skladové evidence. Během stavů, kterými tato třída prochází, se mění její dostupnost, která odpovídá počtu kusů dané skladové položky na skladu. Z tohoto vyplývá, že se rozlišují dva základní stavy: • Dostupná položka — počet kusů na skladu je větší než nula, • Nedostupná položka — počet kusů na skladu je roven nule. Jak popisuje stavový diagram uvedený níže, stavy skladové položky se mění na základě jejího příjmu a výdeje. Položka vystupuje v systému jako nedostupná pouze při vytvoření nové skladové karty a při vyskladnění všech jejich kusů (to je možné i prostřednictvím minusového příjmu). Na stavovém diagramu lze vidět jednotlivé přechody mezi stavy třídy při příjmu a výdeji společně s pravidly, po jejichž splnění se do tohoto stavu přejde.

Obrázek 18: Stavový diagram - pro třídu Položka

56

6 Realizace inovace systému řízení skladové evidence Pro realizaci byla tedy vybrána část informačního systému, které zpracovává agendu související s řízením skladové evidence na jednotlivých pobočkách společnosti UNIKOL. Jedná se o inovaci stávajícího softwarového vybavení z důvodu implementace nových funkcí. Mezi tyto funkce patří především využití databázového systému společného se systémem internetových objednávek a možnost získání informací o skladových položkách na ostatních pobočkách v rámci jednoho programu (nyní je potřeba mít spuštěnou pro MTZ každé pobočky jednu aplikaci).

6.1

Datová struktura

Datová základna bude pro uložení a zpracování dat využívat databázového systému MySQL (databázi tvoří 8 tabulek, které jsou popsány v entitně-relačním diagramu). V samotné aplikaci pro MTZ datovou logiku zpracovává třída Databáze. Ta zajišťuje spojení s databází, získávání jednotlivých dat a jejich následné zpracování pro využití v ostatních třídách programu, či úpravu jednotlivých tabulek.

Obrázek 19: Entitně-relační diagram systému MTZ

57

6.2

Aplikační logika

Pro zpracování aplikační logiky byly vytvořeny 3 třídy (na základě navržených balíčků v diagramu tříd) – Mtz, Uživatel a Firma. Mtz zpracovává všechny funkce spojené s řízením skladové evidence a evidence jednotlivých skladových položek. Třída Uživatel má za úkol správu uživatelů v systému a třída Firma správu dodavatelů, odběratelů a jiných externích subjektů spolupracujících se společností UNIKOL (navíc ještě správu údajů o jednotlivých pobočkách). 6.2.1 Řízení a správa skladové evidence (package MTZ) Třída zpracovává příjem (výdej) zboží na sklad. Uživatel systému (fakturant) zadává příjem (výdej) zboží na sklad po jednotlivých položkách. Ke každé položce je nutné vyplnit všechny nutné informace (název položky, výrobce, počet ks, nákupní cena, dodavatel a číslo faktury – příjem zboží, u výdeje pak název, výrobce, počet ks, prodejní cena, odběratel a číslo faktury). Po zadání vstupů následuje kontrola korektnosti vstupů (vstupy byly vyplněny a mají správné datové typy – kontrola vstupních polí) a kontrola existence skladové položky (u příjmu vytvoření nové, pokud položka neexistuje). Při nesprávném vložení vstupů je uživatel vyzván k jejich opětovnému vyplnění. Poté dochází k přepočtení počtu ks dané položky na skladě (při výdeji kontrola, zda je požadovaný počet ks na skladě). Výstupem funkce je zanesení nových hodnot do databáze a vytvoření nového datového modelu pro tvorbu výpisu. Tato třída také zajišťuje vytvoření modelu pro výpis celkového stavu skladu, tzn. všechny skladové položky (pokud není nastaveno filtrem výpisu jinak – výpis položek, jejichž počet na skladě je větší než 0, nebo rovno 0). Vstupem jsou atributy jednotlivých položek získané z databáze. Získaná data jsou uloženy do modelu (ke každému datovému modelu jsou získána příslušná meta data – záhlaví výpisu, počet prvků) aby mohla být prezentována uživateli formou tabulky (základní výpis obsahuje název položky, výrobce, popis položky, počet ks na skladě, aktuální souhrnná hodnota skladové položky a pobočka, na níž se skladová položka nachází). Další důležitou funkcí této třídy je editace již existující položky (pouze informace o položce, nikoli počty ks) ve skladové evidenci. Vstupy zadává uživatel systému (fakturant), jedná se o název skladové položky pro editaci a hodnoty, které mají být editovány. Tyto data jsou zpracována tak, že je nejprve zkontrolována jejich korektnost (opět při nesprávném vyplnění musí uživatel tyto data vložit znovu), poté aplikace provede kontrolu, zda se hledaná položka nachází ve skladové evidenci. Pokud ano, upravené informace jsou uloženy do databáze, v opačném případě je uživateli ohlášena chyba. Výstupem této funkce je aktualizovaný model pro výpis skladové evidence (upravuje se název, popis a výrobce položky). Funkce také umožňuje upravit informace o konkrétním pohybu dané skladové položky (je možno upravit datum, odběratele, či dodavatele nebo číslo faktury).

58

Dále je také nutné umožnit uživateli zobrazit stav jednotlivých skladových položek podle jeho požadavků, což zajišťuje vytváření datového modelu podle nastaveného filtrování výpisu. Vstupem tohoto filtrování jsou atributy nastavené uživatelem (počet sloupců pro vypsání, pouze položky co jsou reálně na skladě, konkrétní položka nebo skupina položek, jejichž název odpovídá určitému zadanému řetězci). U vyhledávání je to název skladové položky zadané uživatelem v textovém poli. Tyto požadavky jsou zpracovány tak, že se nastaví dotaz na databázi podle potřeby výpisu. Výstupem je pokaždé nový datový model potřebný pro výpis skladové evidence (je vytvořen nový datový model reprezentující uživatelem požadovaný filtr nebo hledanou položku). Důležitou součástí této třídy je také podpora tisku aktuálního stavu skladové evidence, buďto celkové, nebo v rozsahu definovaném uživatelem (pomocí filtru nebo po vyhledávání). Vstupem je datový model tabulky (nelze tisknout prázdný datový model – výpis po filtrování nebo vyhledávání nezobrazuje žádnou skladovou položku), která tvoří soupis stavu zboží na skladu. Tento model pak tvoří výstup pro tisk. Možnosti tisku jsou poté definovány uživatelem (volba tiskárny, počet kopií, nastavení tisku). Evidence pohybu jednotlivých skladových položek reprezentuje soupis všech příjmů a výdajů dané položky v čase. Vstupem je název položky vložený uživatelem přes textové pole. Nejprve je opět nutná kontrola korektního vyplnění tohoto textového pole (datový typ musí být řetězec, nesmí být prázdný). Pokud je nalezeno více položek shodujících se s daným řetězcem, je pak nutné ještě vybrat konkrétní položku ze všech nalezených. Tato informace je zpracována tak, že jsou získána všechna data o dané položce z databáze. Výstupem jsou 3 druhy informací. Nejprve lze vidět detailní informace o daném produktu (název, popis, výrobce, počet zboží na skladě, jeho aktuální hodnota na skladě, průměrná skladová cena a pobočka, na které se daná položka nachází), dále pak již pohyb skladové položky (příjem nebo výdej, počet ks, nákupní /prodejní cena, dodavatel/odběratel, číslo faktury, datum). 6.2.2 Správa uživatelů (package Uživatel) Tato třída zpracovává řízení přístupu jednotlivých uživatelů do programu. Každý uživatel se musí před použitím systému přihlásit. To mohou udělat pouze uživatelé vedení v databázi (pracovníci poboček – obchodníci, fakturanti, skladníci a administrátoři). Vstupem při přihlášení uživatele je jeho přihlašovací jméno a heslo. Po kontrole korektnosti vstupů (datový typ řetězec, nesmí být prázdný) jsou údaje porovnány s údaji v databázi. Pokud takový uživatel není v databázi, nebo zadal špatné heslo, nemůže být přihlášen (je upozorněn na chybu). Uživatelská hesla jsou v databázi uložena jako zašifrované hodnoty pomocí algoritmu SHA-1, aby se předešlo jejich případnému zneužití.

59

Po přihlášení má každý uživatel přidělena svá práva (obchodník nesmí dělat příjem a výdej zboží, upravovat údaje o firmách, přidávat nové uživatele atd.). Každý uživatel může upravit své údaje (jméno, příjmení, přihlašovací jméno, heslo, pobočku, pozici). Po přihlášení do systému bude moci zobrazit nabídku s těmito údaji, po jejich změně a kontrole korektnosti vstupů jsou informace o uživateli uloženy do databáze. Administrátoři na jednotlivých pobočkách mohou přidat/odebrat uživatele. Po jejich přihlášení budou moci zobrazit nabídku s těmito možnostmi. Pro přidání nového uživatele musí zadat jeho údaje do textových polí, nastavit práva (obchodník, fakturant, skladník, administrátor). Po kontrole korektnosti vstupu je nový uživatel přidán do databáze. Pro odebrání je nutné vybrat z nabídky uživatelů systému, poté je uživatel vymazán z databáze. 6.2.3 Správa firem (package Firma) Hlavní funkcí této třídy je správa dodavatelů a odběratelů společnosti. Vybraní uživatelé (pracovní pozice administrátor a fakturant) mohou přidávat nové společnosti, nebo upravovat uložené údaje o těchto společnostech. Uživatel musí vždy do formulářů vložit korektní údaje a po jejich kontrole (prázdné hodnoty, regulární výrazy) jsou nové nebo změněné údaje o společnostech ukládány do databáze. Všichni uživatelé systému mají možnost vyhledávat v seznamu firem, které jsou uloženy v databázi. Musí nejprve zadat název firmy, pokud existuje více se stejným názvem, je potřeba vybrat konkrétní společnost. Pokud hledaná firma není v databázi uložena, je vypsána chybová hláška. Pokud je společnost nalezena, jsou uživateli vypsány konkrétní informace, jako je název společnosti, adresa, IČO, DIČ, kontakt a také objem obchodů a počet uskutečněných obchodů. Administrátor má také možnost změnit údaje o své pobočce, které jsou vedeny v databázi.

6.3

Export dat a spojovací soubor

Kromě již zmíněné možnosti tisku je nutné jednotlivé změny skladových položek promítnout také do účetnictví (především účty materiál na skladě a spotřeba materiálu). Pro přenos těchto dat do účetnictví je potřeba vytvořit tzv. spojovací soubor (tímto způsobem je přenos dat do účetnictví řešen i ve stávajícím softwaru). Ten obsahuje změny na jednotlivých účtech v účetnictví vzniklých po posledním vytvoření tohoto spojovacího souboru. Data jsou zde uložena ve standardním formátu CSV (Comma-separated values). Celkový stav skladové evidence je také možné exportovat ve formátu CSV, nebo ve formátu Office Open XML (XLS - formát pro Microsoft Excel).

60

6.4

Grafické uživatelské rozhraní

Pro zpracování GUI byla vytvořena třída MztGUI, která využívá komponent třídy javax.swing. Po spuštění programu je nejprve zobrazeno okno pro přihlášení uživatele. Po jeho přihlášení se již pracuje s hlavním oknem aplikace, které zaručuje kompletní ovládání programu (jak je možné vidět na jednotlivých snímcích GUI). Pro spuštění jednotlivých funkcí aplikace může uživatel vybrat tuto funkci v menu, nebo využít u nejdůležitějších částí systému klávesové zkratky (správa jednotlivých skladových položek, vyhledávání, tisk atd.). Menu je rozděleno na šest částí podle funkcionality: • Soubor – tisk, export dat, spojovací soubor, odhlášení, ukončení programu • Položka – správa skladových položek • Najít – vyhledávání a filtrování • Firmy – správa externích firem • Uživatel – správa uživatelů • Pobočka – Volby týkající se jednotlivých poboček

Obrázek 20: GUI - základní obrazovka

61

Obrázek 21: GUI - filtrované vyhledávání

Obrázek 22: GUI - Skladovací karta, příjem

62

7 Diskuse a závěr Cíle, které byly popsány na začátku této diplomové práce, se podařilo splnit. Nejdříve byl vytvořen ucelený procesní model celé společnosti, který byl následně dekomponován na menší celky, kvůli zobrazení všech detailů procesního modelu. Z této procesní analýzy následně vycházely návrhy pro inovace stávajícího informačního systému (ty vycházely z předešlého zhodnocení stavu a softwarovém podpory podnikových procesů), které byly doplněny o přehled jejich finanční náročnosti. Tento přehled předkládá vedení společnosti různé alternativy, mezi kterými mohou při inovaci současného podnikového informačního systému volit. Mezi popsanými možnostmi jsou jak inovace současného IS, tak nákup chybějících modulů. Jako poslední možnost bylo zvoleno řešení integrace kompletně nového informačního systému Dialog 3000S. Tato varianta je však finančně nejnáročnější. Společnost má ale možnost získat cenovou nabídku i od jiných dodavatelů IS, která by se mohla od variant představených v této práci poněkud lišit, to již ale záleží na konkrétním jednání mezi dodavateli a vedením společnosti. Pro další část práce byla vybrána inovace systému řízení skladové evidence. Jeho jednotlivé funkcionality a struktura byly popsány pomocí diagramů UML. Tyto diagramy pak vytvořily výstupní bod pro realizaci této části systému. Realizace, která byla vytvořena, splňuje základní funkční požadavky stanovené během analýzy. Tato nová aplikace představuje další alternativu pro zlepšení stávajícího stavu podnikového IS, a pokud bude vedením společnosti schválena (popř. bude ještě doplněna o některé nové doplňkové funkce), bude nasazena do testovacího provozu. Samozřejmě, že pro inovaci mohla být zvolena část systému, která zpracovává proces s doposud chybějící softwarovou podporou (např. systém pro podporu manažerského rozhodování, systém pro správu objednávek, atd.), nicméně vybraná inovace se zaměřuje na jeden ze závažných nedostatků současného řešení IS (oddělené řízení skladové evidence podle poboček). Pokud by však vedení společnosti nebylo spokojeno s realizací, která byla vytvořena v rámci této diplomové práce, jsou zde nastíněny i jiné alternativy nákupu, či inovace této části. Volba o směru, kterým se bude podnikový informační systém ve společnosti UNIKOL s.r.o. vyvíjet, je tedy plně v kompetenci jejího vedení. Tato diplomová práce však může být cenným zdrojem informací, který by mohl toto rozhodování značně usnadnit.

63

8 Literatura ARLOW, J., NEUSTADT, I. UML2 a unifikovaný proces vývoje aplikací 2. vydání Brno: Computer Press, a.s., 2007, 567 s. ISBN 978-80-251-1503-9 KANISOVÁ, H., MÜLLER, M. UML srozumitelně 1. Vydání Brno: Computer Press, a.s., 2004, 158 s. ISBN 80-251-0231-9 SODOMKA, P. Informační systémy v podnikové praxi 1. Vydání Brno: Computer Press, a.s., 2006, 351 s. ISBN 80-251-1200-4 RÁBOVÁ, I A KOLEKTIV Podniková architektura – strategický nástroj v rukou manažera 1.vydání, Brno: Tribun EU s.r.o., 2008, 131 s. ISBN 978-80-7399-568-3 ŘEPA, V. Podnikové procesy – procesní řízení a modelování 2. Vydání Praha: Grada Publishing, a.s., 2007, 281 s. ISBN 978-80-247-2252-8 ITIL – procesní řízení [online], 2007, [cit. 30.3.2010]. Dostupný z WWW: Wikipedie – otevřená encyklopedie [online], [cit. 6.4.2010]. Dostupná z WWW:

64

9 Seznam obrázků a tabulek 9.1

Seznam obrázků

Obrázek 1: Procesní model tříúrovňové architektury (Sodomka, 2006)...................... 11 Obrázek 2: Čtyřúrovňová architektura UML (Řepa, 2007) ..........................................14 Obrázek 3: Pracovní postupy jednotlivých iterací (Arlow, Neustadt, 2007) ................ 15 Obrázek 4: Notace BPM v UML (Enterprise Architect)................................................19 Obrázek 5: Organizační struktura společnosti UNIKOL s.r.o. .................................... 30 Obrázek 6: Business Process Model - celkový pohled ................................................. 34 Obrázek 7: BPM - řízení obchodní činnosti ................................................................. 35 Obrázek 8: BPM - řízení skladu.................................................................................... 36 Obrázek 9: BPM - finanční řízení ................................................................................. 37 Obrázek 10: Diagram případů užití uživatelské části................................................... 46 Obrázek 11:Diagram případu užití evidence skladové položky .................................... 48 Obrázek 12: Diagram případů užití stav skladu ........................................................... 49 Obrázek 13: Diagram případu užití evidence firem ...................................................... 51 Obrázek 14: Diagram tříd – balíčky .............................................................................. 51 Obrázek 15: Diagram tříd systému MTZ ...................................................................... 52 Obrázek 16: Diagram aktivit - příjem skladové položky .............................................. 53 Obrázek 17: Sekvenční diagram - příjem skladové položky ......................................... 54 Obrázek 18: Stavový diagram - pro třídu Položka ....................................................... 55 Obrázek 19: Entitně-relační diagram systému MTZ .................................................... 56 Obrázek 20: GUI - základní obrazovka ........................................................................ 60 Obrázek 21: GUI - filtrované vyhledávání .....................................................................61 Obrázek 22: GUI - Skladovací karta, příjem .................................................................61 Obrázek 23: Diagram případů užití MTZ - celkový pohled ......................................... 66

9.2

Seznam tabulek

Tabulka 1: Odhadované náklady na inovací stávajících modulů IS............................. 40 Tabulka 2: Cena licencí nových modulů stávajícího IS ................................................ 40 Tabulka 3: Cena licencí jednotlivých modulů IS Dialog 3000S .................................. 42 Tabulka 4: Náklady na implementaci a školení zaměstnanců ..................................... 42 Tabulka 5: Celková cena řešení IS Dialog 3000S ........................................................ 43 Tabulka 6: Hlavní scénář - Přihlášení do systému....................................................... 45 Tabulka 7: Alternativní scénář - Neplatné přihlašovací jméno ................................... 45 Tabulka 8: Hlavní scénář - Příjem skladové položky ................................................... 47 Tabulka 9: Hlavní scénář - Hledání skladových položek ............................................. 49 Tabulka 10: Hlavní scénář - Upravit údaje o firmě ...................................................... 50

65

Přílohy

66

A. Diagram případů užití MTZ – celkový pohled

Obrázek 23: Diagram případů užití MTZ - celkový pohled

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

Recommend Documents