Návrh databázového systému pro podporu řízení projektů ve firmě Juli Motorenwerk s.r.o

Mendelova univerzita v Brně Provozně ekonomická fakulta

Návrh databázového systému pro podporu řízení projektů ve firmě Juli Motorenwerk s.r.o. Bakalářská práce

Vedoucí práce:

Autor:

Ing. Mgr. Jana Dannhoferová, Ph.D.

Ing. Karel Paulík

Brno 2010

Na tomto místě bych chtěl poděkovat zejména vedoucí této práce paní Ing. Mgr. Dannhoferové Ph.D. za cenné rady a pomoc při vypracování bakalářské práce.

Prohlašuji, ţe jsem svou bakalářskou práci vypracoval samostatně a pouţil jsem pouze podklady uvedené v přiloţeném seznamu. V Brně dne 11. dubna 2011

__________________

Abstract Paulík, K. Database system suggestion for support of project management in company Juli Motorenwerk s.r.o. Bachelor thesis. Brno: MUAF, 2011. In the document is described current state analysis of project management, proposal and creation of new database system to provide the support of current project management in company Juli Motorenwerk s.r.o. An abstract is in (British) English. Keywords Project management, database system, Microsoft Access. Here are key words in (British) English.

Abstrakt Paulík, K. Návrh databázového systému pro podporu řízení projektů ve firmě Juli Motorenwerk s.r.o. Bakalářská práce. Brno: MZLU v Brně, 2011. V textu je popsána analýza současného stavu projektového řízení, návrh a tvorba nového databázového systému, který má slouţit jako podpora současného projektového řízení ve firmě Juli Motorenwerk s.r.o. Klíčová slova Projektové řízení, databázový systém, Microsoft Access.

Obsah

5

Obsah 1

2

Úvod a cíl práce 1.1

Úvod .........................................................................................................10

1.2

Cíl práce ...................................................................................................10

1.3

Metodika ..................................................................................................10

Analýza problému 2.1

3

12

Charakteristika firmy JULI Motorenwerk s.r.o. ..................................... 12

2.1.1

Vnější prostředí ................................................................................ 12

2.1.2

Vnitřní prostředí .............................................................................. 13

2.1.3

SWOT analýza .................................................................................. 15

2.2

Popis současného projektového řízení ve firmě ...................................... 15

2.3

Základní údaje vztahující se k projektovému řízení ................................ 17

2.4

Popis současného stavu správy dat projektového řízení ......................... 17

2.5

Poţadavky kladené na nové řešení .......................................................... 19

2.6

Analýza softwarových nástrojů ............................................................... 20

Teoretická východiska práce

22

3.1

Projektové řízení ..................................................................................... 22

3.2

Databáze.................................................................................................. 25

3.2.1

Entitně-relační model dat ............................................................... 27

3.2.2

Normalizace databáze ..................................................................... 27

3.3

4

10

Microsoft Access 2010 ............................................................................ 28

3.3.1

Tabulky ............................................................................................ 28

3.3.2

Dotazy.............................................................................................. 28

3.3.3

Formuláře........................................................................................ 29

3.3.4

Sestavy ............................................................................................. 29

3.3.5

Makra .............................................................................................. 29

3.3.6

Programové moduly ........................................................................ 29

Návrh řešení

30

6

5

6

7

Obsah

4.1

Výběr řešení ............................................................................................ 30

4.2

Výběr konkrétního databázového softwaru ........................................... 30

4.3

Návrh entitně-relačního modelu .............................................................32

Realizace databázového systému 5.1

Tvorba relačního modelu ........................................................................34

5.2

Tvorba dotazů .......................................................................................... 41

5.3

Tvorba formulářů ....................................................................................42

5.4

Tvorba tiskových sestav ...........................................................................43

5.5

Tvorba programových modulů ............................................................... 44

Popis a zhodnocení daného řešení

45

6.1

Popis řešení.............................................................................................. 45

6.2

Ekonomické zhodnocení řešení .............................................................. 47

6.3

Technické zhodnocení řešení ................................................................. 49

Diskuze 7.1

8

34

50

Moţné rozšíření databázového systému ................................................ 50

Závěr

51

8.1

Rekapitulace řešení ................................................................................. 51

8.2

Praktický přínos práce ............................................................................. 51

9

Literatura

52

A

Použitý software

54

B

Formuláře správy záznamů

55

C

Tisková sestava

57

Seznam obrázků

7

Seznam obrázků Obr. 1

Organizační struktura podniku

14

Obr. 2

Entitně-relační model

32

Obr. 3

Typy vazeb v relačním modelu

33

Obr. 4

Relační model základní kostry databáze

35

Obr. 5

Relační model vztahující se k Tab_projektova_skupina

36

Obr. 6

První část rel. modelu vztahující se k Tab_projekty

37

Obr. 7

Druhá část rel. modelu vztahující se k Tab_projekty

38

Obr. 8

Relační model databáze vztahující se k tab dbo_INP35

39

Obr. 9

Relační model databáze vztahující se k Tab_vyp_list

39

Obr. 10

Relační model vztahující se k Tab_parametry_motoru

40

Obr. 11

Vytváření dotazu v návrhovém zobrazení

41

Obr. 12

Formulář databáze

43

Obr. 13

Hlavní přepínací panel

45

Obr. 14

Zakládání projektů

46

Obr. 15

Přehled osob příslušných k projektům pro koncerny

47

Obr. 16

Microsoft Access 2010

54

Obr. 17

Microsoft Visual Basic for Applications

54

Obr. 18

Formulář správy vozíků

55

Obr. 19

Formulář správy projektů

55

Obr. 20

Formulář správy motorů

56

Obr. 21

Formulář správy výpočtových listů

56

Obr. 22

První strana tiskové sestavy

57

8

Obr. 23

Seznam obrázků

Druhá strana tiskové sestavy

58

Seznam tabulek

9

Seznam tabulek Tab. 1

Geografické rozdělení zákazníků

13

Tab. 2

Matice SWOT

15

Tab. 3

Základní údaje o počtech produktů

17

Tab. 4

Základní údaje o zaměstnancích podílejících se na projektovém řízení

17

Tab. 5

Náklady na vývoj databázového systému.

48

Tab. 6

Předpokládané úspory spojené s novým řešením.

48

10

Úvod a cíl práce

1 Úvod a cíl práce 1.1

Úvod

Společnost JULI Motorenwerk s.r.o. je předním světovým výrobcem motorů a pohonů pro manipulační techniku. Je vlastněna výrobci manipulační techniky, koncerny JUNGHEINRICH a KION, pro které motory a pohony vyvíjí a vyrábí. Pro vývoj nových produktů se ve firmě pouţívá projektové řízení, kdy vývoj nového produktu je vedený jako samostatný projekt, za který je odpovědný projektový manager. Nutno podotknout, ţe jeden projektový manager odpovídá za několik projektů současně. Ke kaţdému projektu se vztahuje spousta informací, které je potřeba vhodně evidovat a zpracovávat. (Taylor, 2007) uvádí, ţe průměrný projektový manager stráví přibliţně 90 procent svého času komunikací s projektovým teamem, vedením společnosti, zákazníkem a dalšími zainteresovanými osobami. Většinu tohoto času stráví shromaţďováním, zpracováním nebo předáváním údajů. S těmito informacemi nepracuje tedy pouze projektový manager, ale spousta ostatních lidí a je tedy jen otázkou konkrétního řešení ve firmě, zdali k těmto informacím budou přistupovat přes projektového managera, nebo k nim budou mít přímý přístup. Aby byla práce s informacemi co nejefektivnější, je nutné tyto informace systematicky zpracovávat. Toto zpracování informací je tedy jednou z nejpodstatnějších částí informačního systému ve firmě.

1.2 Cíl práce Cílem této práce je navrhnout nové řešení, které bude pouţito pro podporu projektového řízení ve firmě JULI Motorenwerk s.r.o. a nahradí v současné době nevyhovující stav, kdy jsou informace k jednotlivým projektům uloţeny v souborech na počítačích jednotlivých uţivatelů.

1.3 Metodika Výchozím bodem práce je charakteristika firmy, jejíţ součástí je i SWOT analýza. Strategie vyplývající ze SWOT analýzy potvrzují nutnost zavedení nového způsobu správy dat projektového řízení. Dále je provedena analýza současného projektového řízení a analýza současného stavu správy dat projektového řízení. Nezbytným krokem je dále stanovení poţadavků, které budou kladeny na nové řešení. Dalším nezbytným krokem je analýza a výběr softwarového nástroje. Pro tvorbu nového řešení je vybrán databázový systém Access 2010. Následuje návrh a tvorba nového databázového systému. Návrh databázového systému je proveden jako ER diagram.

Úvod a cíl práce

11

Nové řešení je zhodnoceno z ekonomického hlediska, které určuje náklady vynaloţené na jeho tvorbu. Současně jsou odhadnuty úspory, které nové řešení generuje. Na základě nákladů a úspor je vypočítána návratnost nového řešení. Dále je uvedeno zhodnocení technického stavu nového řešení a stanovení dalších moţných rozšíření.

12

Analýza problému

2 Analýza problému 2.1 Charakteristika firmy JULI Motorenwerk s.r.o. Společnost JULI Motorenwerk s.r.o. se zabývá výrobou elektrických motorů a pohonů pro manipulační techniku. Se svým nynějším objemem výroby cca 300.000 motorů ročně a výrobní kapacitou cca 400.000 motorů ročně patří mezi největší výrobce motorů a pohonů ve svém oboru. Společnost vznikla v první polovině roku 1993. Je vlastněna dvěma velkými výrobci manipulační techniky, společností JUNGHEINRICH AG a společností KION (dřívější název LINDE AG). Společnost zaměstnává v současnosti přibliţně 300 zaměstnanců, má vlastní vývojové centrum a je tedy schopna svým zákazníkům nabídnout pohony, které svým designem i elektrickými parametry odpovídají zákazníkovým poţadavkům. Postavení vůči zákazníkům je velmi specifické tím, ţe společnost nemůţe dodávat pohony na volný trh, ale zákazníky jsou pouze firma JUNGHEINRICH a KION, tedy její vlastníci. Původní výrobní sortiment byl zaměřen na výrobu stejnosměrných motorů, které se v manipulační technice téměř výhradně pouţívaly. S rozvojem elektroniky se v manipulační technice začal pouţívat stále více asynchronní motor. Přibliţně od roku 2000 zavedla tedy i naše firma do výrobního spektra výrobu a vývoj asynchronních motorů. V současnosti převaţuje a stále vzrůstá produkce asynchronních motorů a produkce stejnosměrných motorů neustále klesá. V následujících letech budou stejnosměrné motory vyráběny zejména pro potřebu náhradních dílů ve stávajících vysokozdviţných vozících. V dalších odstavcích je provedena analýza vnitřního a vnějšího prostředí firmy, které poskytují vstupní informace pro následnou SWOT analýzu. 2.1.1 1.

Vnější prostředí

Trhy Firma dodává na celosvětový trh, většina produktů je určena pro evropský trh.

2.

Identifikace zákazníků Firma nedodává produkty na volný trh, produkty jsou výhradně určeny pro koncernové zákazníky.

3.

Geografické rozdělení zákazníků Pro evropský trh je určeno přibliţně 98% výrobků. V následující tabulce je uvedeno procentuální rozdělení zákazníků podle jejich geografického rozdělení.

Analýza problému Tab. 1

13

Geografické rozdělení zákazníků

Země Podíl na obratu [%]

ČR 28

Německo 59

Francie 7

Itálie 4

Zdroj: Hába, 2004.

4.

Dodavatelé Dodavatele je moţno rozdělit do dvou skupin:  Dodavatelé normovaných dílců Zde se jedná zejména o spojovací materiál a loţiska. Podíl těchto dílců ve společnosti tvoří přibliţně 3%.  Dodavatelé dílců, které jsou vyráběny podle přání firmy JULI Jedná se zejména o odlitky, obrobky, statorové a rotorové svazky. Podíl těchto dílců tvoří přibliţně 97% nakupovaných dílců.

5.

Konkurence Za konkurenci se povaţují všichni výrobci motorů a pohonů v celém světě. Největší bariérou vstupu konkurentů do odvětví je fakt, ţe naše společnost dodává pro koncerny 80-90% motorů nebo pohonů. Největšími konkurenty jsou firmy:  Lerroy Sommer  ABM  ELMO

6.

Situační analýza vnějšího prostředí 6.1. Příleţitosti  Dostupnost levných dodavatelů z východu  Moţnost státní dotace na výzkum a vývoj 6.2. Hrozby  Nepříznivý pohyb cen základních komodit  Nepříznivý pohyb zahraničních kurzů  Konkurence ostatních výrobců

2.1.2

Vnitřní prostředí

1. Finanční situace Během posledních let do roku 2009 dosahovala firma ročního zisku 50-100 mil. Kč, který býval vyuţit zejména na modernizaci výroby. V první polovině roku 2009 se firma pohybovala ve ztrátě, která byla způsobena finanční krizí, na kte-

14

Analýza problému

rou firma reagovala propouštěním zaměstnanců a s ním spojeným vyplácením odstupného. V druhé polovině roku 2009 se firmě podařilo tuto ztrátu postupně sniţovat a na konci roku 2009 jiţ hospodařila s vyrovnaným rozpočtem. V roce 2010 dosáhla firma zisku přibliţně 50 mil. Kč. Roční obrat se pohybuje přibliţně okolo 2-2,5 miliardy Kč. 2. Organizační struktura podniku

Ředitelství

Služby

Výroba

Vývoj

Odbyt / disponenti

Tech. podpora výroby

Konstrukce

Výroba

Odbyt / disponenti

Základní vývoj

Nákup

Nákup

Výroba, linka 7

Informatika, organizace.

Výroba, linka 5

Obr. 1 Organizační struktura podniku Zdroj: JULI Motorenwerk, 2009.

3.

Finanční účtárna Personální a mzdy

Expedice, příjem zboží

Výroba, linka 1

Ekonomika

Situační analýza vnitřního prostředí 3.1. Silné stránky  Silní a stabilní zahraniční vlastníci  Vlastní výzkum a vývoj  Dobré jméno firmy  Dobré vztahy se zákazníky  Moderní výrobní technologie  Kvalifikovaný personál 3.2. Slabé stránky  Nemoţnost dodávat na volný trh

Výroba, linka 6

Sledování kvality

Analýza problému

15

 Úvěrové zatíţení firmy  Omezení rozhodovacích práv  Nejednotný způsob správy dat projektového řízení  Malá spolupráce s vysokými školami 2.1.3

SWOT analýza

Na základě vzájemného porovnání příleţitostí a hrozeb vnějšího prostředí a silných a slabých stránek vnitřního prostředí se nabízí několik strategií. Tab. 2

Matice SWOT

Vnitřní prostředí Vnější prostředí

Silné stránky (Strengths)

Slabé stránky (Weaknesses)

Vytvoření pobočky Vytvoření pobočky v asijských zemích. v asijských zemích Příleţitosti (Opportunities) Zaţádání o státní dotaci na vývoj.

Vývoj nových pohonů ve spolupráci s vysokými školami.

Přesunutí části výroby do asijských zemí.

Svolení od majitelů dodávat na volný trh.

Zajišťovací obchody pro nákup komodit.

Zavedení nového způsobu jednotné správy dat projektového řízení.

Hrozby (Threats)

Zdroj: Vlastní tvorba

Jedna z moţných WT strategií je zavedení nového způsobu jednotné správy dat projektového řízení. Tato strategie byla zvolena jako předmět této práce.

2.2 Popis současného projektového řízení ve firmě Vývoj nového produktu je vţdy v JULI evidován jako samotný projekt. Kaţdý projekt začíná v oddělení základního vývoje, které provádí elektrické výpočty.

16

Analýza problému

Pokud jsou základní elektrické parametry zákazníkem odsouhlaseny, přechází projekt na projektový team, skládající se ze tří osob: 1. Konstruktér Je odpovědný za konstrukci motoru, kusovníky a různé kontrolní výpočty. 2. Technolog Je odpovědný za přípravu výroby, výrobní postupy, výrobní a zkušební přípravky. Konstrukce přípravků zadává technolog konstruktérovi přípravků, který pak zajišťuje také samotnou výrobu přípravků. 3.

Nákupčí Nákupčí na základě dokumentace zajišťuje činnosti spojené s nákupem nových dílů. Rozsah jeho činností závisí na tom, jestli se jedná o sériové, nebo prototypové dílce. V případě dodávky prototypových dílců zajišťuje všechny činnosti spojené s dodávkou dílů do firmy, tj.:  poptání dílů (v případě prototypových dílů se často oslovuje jen jeden dodavatel, se kterým má firma dobré dlouholeté zkušenosti)  výběr dodavatele  objednání dílů  případně také transport. V případě dílců pro sériové dodávky zajišťuje veškeré činnosti spojené s výběrem dodavatele a dohodnutí nákupních podmínek, tedy připravení podmínek pro sériový nákup dílů. Tj.:  poptání dílců  po konzultaci s vedoucím projektu a vedoucím nákupu výběr dodavatele  dohodnutí nákupních podmínek (cena, min. odebírané mnoţství, platební podmínky, dodací podmínky, atd.)

 zajištění kontrolních vzorků Po zajištění dílce pro sériovou výrobu (tzv. uvolnění dílce) přechází odpovědnost za dílec (zejména objednávání a hlídání dodávek dílce) na oddělení dispozice. Vedoucí projektu je jedna z těchto tří osob. Aţ na několik málo výjimek jím bývá vţdy konstruktér. Hlavními úkoly vedoucího projektu je:  Koordinace projektového teamu spojená s předáváním informací o projektu, svoláváním porad a tvorbou zápisů z porad.  Vedení vývojové sloţky, kde jsou umístěny důleţité informace o projektu.  Řešení projektu se zákazníkem.

Analýza problému

17

2.3 Základní údaje vztahující se k projektovému řízení Pro lepší představu o firmě nyní uvádím základní přehled údajů o firmě vztahující se k projektovému řízeni. V tab. 3 je uveden seznam evidovaných produktů ve firmě, kde jsou dále rozvedeny produkty podle současného stavu jejich aktivity. Většina těchto produktů byla ve firmě vyvinuta v projektovém řízení. Tab. 3

Základní údaje o počtech produktů

Produkty Produkty celkem Aktivní produkty Prototypové produkty Produkty evidované jako náhradní díly Neaktivní produkty

Počet 1070 206 164 209 491


V tab. 4 je uveden základní přehled o zaměstnancích, jejichţ činnosti se týkají projektového řízení. Celkem pracuje ve firmě cca 300 zaměstnanců. Tab. 4

Základní údaje o zaměstnancích podílejících se na projektovém řízení

Zaměstnanci Konstruktéři Základní vývoj Nákup Technologie + Konstrukce přípravků Sledování kvality

Počet 10 3 9 6 6


2.4 Popis současného stavu správy dat projektového řízení Ve firmě je pouţit různý software. Jako podpora projektového řízení slouţí zejména tyto software:  AS/400 ISeries – software kategorie SCM

18

Analýza problému

Hlavní databázový systém vyuţívaný prakticky všemi zaměstnanci naší společnosti. V tomto systému jsou evidovány všechny jednotlivé dílce, objednávky, stavy skladů a mnoho dalších informací. Pro vývoj nových výrobků má tento systém zejména ten význam, ţe jsou v něm vytvářeny kusovníky a pracovní postupy. Na základě kusovníku a objednávek motorů jsou pak systémem automaticky generovány objednávky jednotlivých nakupovaných dílů.  TeamCenter – software kategorie PDM Tento software je pouţíván pro správu dokumentace. Je to databázový systém, který je spuštěn na síťovém serveru. To umoţňuje, ţe kaţdý uţivatel má přístup do kompletní dokumentace. Teamcenter samozřejmě vyuţívá propracovaného systému přidělení příslušných oprávnění tak, aby kaţdý pracovník mohl provádět jen jemu přidělené činnosti. TeamCenter je vyuţíván několika odděleními. Nejvíce jej pouţívá oddělení konstrukce, které do něj ukládá a dále spravuje dokumentaci. Dále je pouţíván oddělením nákupu, které tyto díly zajišťuje, oddělením kvality, které po dodání díly kontroluje, oddělením technologie, které pro výrobu sestav musí vyrobit potřebné přípravky. Do databáze má přístup i vedení firmy. Teamcenter vyuţívá propracovaného systému správy verzí jednotlivých dílců a systému zavádění výrobků do výroby. Při zavádění výrobků do výroby je nad kaţdým dílcem spuštěn zaváděcí proces, který musí všechny zainteresované osoby do projektu elektronicky podepsat. Kaţdý z těchto dvou software je pouţíván k běţným činnostem výrobní firmy, které se částí týkají i projektového řízení. Ţádný z nich ale není specializovaný na projektové řízení, a spoustu nezbytných informací do nich tedy nelze vloţit. Oddělení základního vývoje vytvoří vţdy k produktu výpočtový list, ve kterém jsou uvedeny hlavní elektrické parametry. Tento výpočtový list je uloţen na počítači vedoucího tohoto oddělení v excelovském souboru. Všechny projekty eviduje vedoucí konstrukce v jednom excelovském souboru, do kterého mají přístup všichni zaměstnanci. V tomto souboru jsou uvedeny tyto velice stručné informace k projektům:  název projektu  členové projektového teamu  výhled klíčových termínů projektu V současné době tedy neexistuje ţádný společný systém správy dat důleţitých pro projektové řízení. Za správu dat je odpověděný vedoucí projektu a je pouze na něm, jakým způsobem data uchovává. Z tohoto řešení správy projektů vyplývá několik důleţitých nevýhod:  Pokud někdo potřebuje informace o projektu, je jedinou moţností obrátit se na vedoucího projektu.

Analýza problému

19

 Protoţe vedoucí projektu odpovídá za několik projektů současně, musí dané informace sám pracně vyhledat.  Pokud není vedoucí projektu ve firmě, jsou informace většinou nedohledatelné.  Nejednotný systém správy dat k projektům.  V případě vytváření různých přehledů projektů se musí pracně procházet jeden projekt za druhým, coţ je časově velice náročné.

2.5 Požadavky kladené na nové řešení V průběhu roku 2009 byl ve firmě vyměněn vedoucí konstrukce. Nový vedoucí konstrukce dostal od managementu za úkol navrhnout nový způsob evidence projektů, protoţe ten současný byl zcela nevyhovující. Autor této bakalářské práce nabídl, ţe by se na tvorbě nového řešení rád podílel, vedoucí konstrukce souhlasil. Prvním krokem, který bylo nutné provést, bylo stanovení základních poţadavků, které by nové řešení mělo splňovat. Základní poţadavky stanovil vedoucí konstrukce, po konzultacích s vedením podniku. Bylo stanoveno, ţe nové řešení by mělo splňovat tyto základní poţadavky:  sdílení dat  nastavení přístupových práv  přehledné a logické uspořádání dat  moţnost úpravy struktury dat  moţnost třídění a vyhledávání dat  moţnost tvorby statistických přehledů Po stanovení základních poţadavků bylo nutno stanovit základní okruhy dat, které je nutno spravovat. Tyto okruhy dat stanovil autor této práce ve spolupráci s vedoucím konstrukce a vedením podniku. Základní okruhy dat:  návaznost projektů  projektový team  zákazníci projektu  nabídky projektu  historie projektu  produkty příslušné k projektu  předběţný plán projektu  parametry produktu

20

Analýza problému

Z podrobnějšího rozboru vyplývá, ţe je nutno u kaţdého projektu spravovat více neţ 220 atributů.

2.6 Analýza softwarových nástrojů V úvahu přichází několik moţných řešení. Kaţdé z těchto řešení má svoje výhody a nevýhody, je tedy nutno zvolit z těchto řešení to nejvýhodnější. Moţná řešení jsou: 1.

Podrobná excelovská tabulka 1.1. Výhody  Nejlevnější moţné řešení, protoţe MS Excel je součástí standartního Office balíčku.  Znalost Excelu všemi uţivateli. 1.2. Nevýhody

2.

 Toto řešení by se stanovených poţadavků nejvíce odlišovalo. Řešení by se dalo pouţít v případě správy jednodušší struktury dat. Úprava PDM systému TeamCentrum 2.1. Výhody  Jde o systém, který se jiţ ve firmě pouţívá. 2.2. Nevýhody  Nejdraţší řešení. Toto řešení se u firmy Siemens (dodavatel PDM systému TeamCentrum) poptalo. Jen pouhá licence, která by umoţnila vytvářet v TeamCentru vlastní datovou strukturu byla nabídnuta za cca 6 tis. Euro.

3.

 Další vícenáklady nezbytné při eventuální podpoře od firmy Siemens. Zkušenosti jasně ukazují, ţe TeamCentrum je vytvořeno pro standartní správu dokumentace. Je moţná i úprava tohoto systému dle přání zákazníka, ta se ale neobejde bez podpory firmy Siemens. Denní podpora firmy Siemens stojí naši firmu 470 Euro/den. Tvorba vlastního databázového systému 3.1. Výhody  Moţnost vytváření vlastní struktury dat bez omezení.  Vyhovuje stanoveným poţadavkům ve všech bodech. 3.2. Nevýhody  Nutná znalost vhodného systému.

4.

Koupě hotového softwaru 4.1. Výhody

Analýza problému

21

 Není nutná znalost programovacího softwaru, ve kterém by byl program správy projektů vytvořen. 4.2. Nevýhody  Software připravený na míru naším poţadavkům neexistuje.  Nutnost vytvoření softwaru externí firmou.  Vysoké náklady.  Jakákoli úprava softwaru by byla spojena s dalšími vícenáklady.

22


3 Teoretická východiska práce 3.1 Projektové řízení Projektové řízení je způsob řízení jednorázových neopakovatelných akcí pomocí projektů (Dolanský, 1996. Taylor, 2007). Je to řízení takových úloh, které:  Sledují přesně vymezený cíl  Musí být splněny v určitém termínu  Musí být splněny s určitými náklady Kaţdý projekt má tedy tři základní parametry (Rosenau, 2007. Lewis, 2007):  Provedení  Čas  Náklady (hmotné, lidské a finanční zdroje) Tyto tři základní parametry bývají spolu navzájem v určitém vztahu a úzce spolu souvisí. Pokud například budeme klást větší důraz na kvalitu provedení, budou se zvyšovat nároky na peníze a čas. Projektem se rozumí soubor činností, které je potřeba naplánovat a provést, aby bylo dosaţeno jednotlivých cílů. Projektové řízení se skládá ze 4 základních etap (Heerkens, 2002): 1.

Zahájení (iniciace) projektu V této fáze se určují základní charakteristiky projektu. Jsou to zejména:

2.

1.1. Výběr projektového managera, který je prvním velice důleţitým krokem. Dále je velice důleţité předat této osobě co nejvíce informací o projektu. 1.2. Volba projektového teamu. Tomuto kroku někdy předchází volba tzv. základního projektového teamu – skupiny odborníků, kteří budou blíţe definovat projekt a budou volit lidi do projektového teamu. 1.3. Definice rizik a přínosů projektu, které je nutno mít při řešení projektu neustále na zřeteli. Tímto se dá předejít mnoha nepříjemnostem v průběhu celého projektu. Plánování projektu Skládá se opět z několika dílčích úkolů: 2.1. Nastartování projektu Kaţdý projekt musí mít zahajovací poradu všech členů teamu. Velice důleţité je tuto poradu správně načasovat. Pokud by se zahajovací po-


23

rada konala příliš brzo, mohlo by se stát, ţe vedoucí projektu nebude mít dostatek informací, které by projektový team potřeboval. Pokud by se zahajovací porada konala příliš pozdě, mohlo by se stát, ţe dojde ke zbytečné ztrátě času při samotném řešení projektu. 2.2. Analyzování poţadavků projektu Rozdíl oproti zahajovací fázi je ten, ţe v zahajovací fázi se manager projektu zajímá o projekt ze široka. V této druhé fázi se projektový manager a projektový team zajímají o definování specifických prvků projektu. S tímto bodem je spojeno několik specifických kroků: 2.2.1. Pochopení poţadavků zákazníka. Tedy vyhodnotit, zda opravdu víme, co od nás zákazník ţádá. 2.2.2. Definování cílů projektu (technický přístup k řešení projektu). Zde je nutné zhodnotit skutečné potřeby zákazníka tak, abychom se snaţili splnit zákazníkovy poţadavky, ale současně aby tyto potřeby náš výrobek zbytečně nepřevyšoval (například dosáhnutí vyšší neţ poţadované ţivotnosti by zřejmě vedlo ke zdraţení). 2.2.3. Definování rozhodujících faktorů úspěchu. Spojeno většinou s určením nejdůleţitějších komponent projektu. 2.2.4. Rozhodnutí, které části projektu se budou vyrábět a které se budou nakupovat. 2.3. Plán projektu Podrobný plán projektu se skládá z pěti kroků: 2.3.1. Rozloţení projektu do úkolů a dílčích úkolů. Pouţívá se Hierarchický rozklad činností, tzv. WBS (Work breakdown structure). 2.3.2. Určení doby trvání úkolu a vzájemné závislosti úkolů. Nejčastěji se pouţívá metoda PERT (Program Evaluation and Review Technique), která stanovuje termíny ukončení projektu s jistou pravděpodobností. 2.3.3. Vypracování časového plánu projektu. Nejčastěji se pouţívá síťový graf zobrazený jako Ganttův diagram. 2.3.4. Odhad nákladů na úkol a vypracování rozpočtu projektu. Slouţí jako podrobnější doplnění WBS. 2.3.5. Určení koncových poţadavků na zdroje. Slouţí taktéţ jako podrobnější doplnění WBS. Zdroje zahrnují veškerý personál, zařízení, příslušenství a materiál potřebný pro realizaci projektu. 2.4. Identifikace různých rizik

24


Důvodem je fakt, ţe pokud se rizika předem naplánují a při průběhu projektu se s nimi počítá, pak pokud k nim dojde, předchází se nepříjemným překvapením a časovým posunům v časovém plánu projektu. 2.5. Probrání projektového plánu se zákazníkem. Je velice důleţité projektový plán se zákazníkem zkonzultovat. Zákazník, který zná projektový plán si dokáţe lépe představit, jak můţou případné změny v zadání (ke kterým dochází téměř u kaţdého projektu) ovlivnit průběh (čas, náklady, kvalitu) projektu. 3.

Implementační fáze (řízení realizace projektu) Je to fáze provádění jednotlivých úkolů, které jsou nutné k úspěšnému splnění obsahu projektu. V této fázi je prováděna hlavní práce na projektu a projektový plán se stává realitou. Nejdůleţitějším bodem této fáze je sledování projektu, které se skládá z několika kroků: 3.1. Shromaţďování informací (mapování stavu) projektu Jde o získávání informací o aktuálním stavu realizace projektu. Informace se získávají z porad, telefonních hovorů, emailů, schůzek vedoucích pracovníků apod. Některé informace mohou být shromáţděny formálně schváleným způsobem (dopředu připravené a schválené formuláře), většina informací je ale shromáţděna neformálním způsobem. 3.2. Analýza údajů (kontrola realizace projektu) V tomto bodě se jedná o kontrolování, zda realizace projektu probíhá podle plánu, nebo zda má tendenci se od něj odchýlit. Nejčastěji se kontroluje rozpočet, časový plán a kvalita. 3.3. Informační hlášení (vykazování stavu realizace) Výsledky analyzovaných informací se předávají buď pomocí formálně schválených dokumentů, nebo pomocí informačních setkání. Stěţejním cílem řídícího procesu je zabezpečit plynulý průběh činností tak, aby byly splněny stanovené projektové cíle v poţadovaném mnoţství a provedení, kvalitě a termínech. Vlastní řídící procedury by měly být prováděny ihned poté, co byl kontrolním procesem zjištěn nesoulad průběhu projektu s jeho plánováním.

4.

Ukončení projektu Jednou z charakteristik projektu je to, ţe má dočasné trvání. Kaţdý projekt má tedy koncový bod. Tento koncový bod existuje pouze tehdy, pokud existuje formálně schválené ukončení projektu. Jinak by se mohly projekty prodluţovat i o celé roky. Fáze ukončení projektu se skládá z několika kroků:


25

4.1. Poskytnutí výrobku nebo sluţby O jaký výrobek nebo sluţbu se jedná, závisí na konkrétním projektu. V případě firmy JULI Motorenwerk tento bod znamená vytvoření kompletní dokumentace (konstrukční dokumentace, technologická dokumentace, stanovení podmínek nákupu komponent), podle které je firma schopna vyrábět motory bez řešení jakýchkoli výraznějších problémů. 4.2. Závěrečná zpráva obsahující souhrnný přehled Závěrečnou zprávu sestavuje manager projektu a předává ji zástupci vedení organizace. Závěrečná zpráva zahrnuje informace o průběhu, plánování a realizaci projektu. Obsahuje informace o časovém průběhu realizace projektu, porovnání skutečných a plánovaných nákladů, vzniklé problémy a odchylky od plánu, důsledky realizace projektu a závěrečná doporučení. Závěrečná zpráva by měla obsahovat souhrnný přehled výsledků, který poskytuje informace o celém projektu. Pro zpracování souhrnného přehledu je vhodné mít zpracovaný formulář, zajišťující jednotnou strukturu poţadovaných projektových informací. To pak zajišťuje dobrou moţnost následného zpracování informací. Cílem závěrečné zprávy je poskytnout managementu projektu a celé organizaci údaje o průběhu předchozích projektů. Tyto zprávy pak představují cenné informace pro plánování a realizaci dalších projektů. 4.3. Formální ukončení projektu Pro ukončení projektu by měl existovat formálně schválený formulář, kde podpisem kaţdý člen projektového teamu potvrzuje splnění všech očekávaných úkolů. 4.4. Vyhodnocení projektu Podle různých hledisek se hodnotí přínos (popř. také ztráta), který podniku vznikl realizací projektu.

3.2 Databáze Obecně můţeme za databázi označit vše, co obsahuje určitým způsobem uloţené a utříděné informace. Podrobnější definicí bychom za databázi mohli označit (Kruczek, 2010. Hernandez, 2006):  Utříděný souhrn souvisejících informací.  Sbírku informací uloţenou systematicky v počítačovém systému tak, aby počítačový systém byl následně schopen zodpovědět dotazy kladené na databázi.

26


 Soubor dat, v jehoţ rámci se sledují, shromaţďují a systematicky zpracovávají informace určitého typu a obsahu. Aby databáze pracovala spolehlivě, jsou na ni kladeny určité poţadavky. Mezi základní poţadavky kladené na databázi patří:  Zabránění redundance dat. Tzn., aby jedna informace nebyla uloţena na více místech.  Zabránění nekonzistence dat. Nekonzistence často bývá důsledkem redundance. Pokud je jedna informace uloţena na více místech a jestliţe bychom informaci na jednom místě změnily, pak ostatní zůstanou nezměněné, protoţe mezi nimi neexistuje ţádná vazba.  Kontrola vstupních dat. Kontrolou dat se zabraňuje porušení datové integrity. Smyslem můţe být například zabránit tomu, aby se na místo, kde má být uloţeno datum, neuloţilo například jméno.  Sdílení dat. Pokud tedy s databází začne pracovat jeden uţivatel, je nutné, aby s ní mohli pracovat i ostatní uţivatelé.  Zabezpečení dat. Tedy definování určitých pravidel, která stanoví, který z uţivatelů má přístup do určité části databáze. Dále je moţné také stanovit typ přístupu pro konkrétního uţivatele (čtení, zápis).  Správa dat. Záloha, obnova a přeuspořádání informací patří mezi klíčové poţadavky, které musí databáze splňovat. Z hlediska způsobu ukládání dat a vazeb mezi daty rozlišujeme některé základní typy databáze:  Hierarchická databáze  Síťová databáze  Relační databáze V současnosti je nejpouţívanější relační databáze, a také databáze popisovaná v této práci je relační. Ohledně terminologie ve vztahu k databázím je nutno rozlišovat tři základní termíny:  Báze dat Je uspořádaná mnoţina vzájemně propojených dat.  Systém řízení báze dat Programové vybavení, které umoţňuje přístup k bázi dat a manipulaci s daty.  Databázový systém neboli databáze Je to báze dat ve spojení se systémem řízení báze dat.


3.2.1

27

Entitně-relační model dat

Prvním krokem při návrhu databázového systému je vytvoření datového modelu. Tento model poskytuje jistý abstraktní a logický pohled na data celého systému bez ohledu na jejich fyzické uloţení v počítači. K tomuto účelu slouţí entitně relační model organizace dat (Konečný, 1996). Diagramy znázorňující tento model se nazývají entitně-relační diagramy, nejčastěji se pouţívá označení ER diagram. ER diagram se skládá z entit a relačních vazeb. Entity jsou zobrazovány pravoúhelníkem se jménem entity. V modelu popisují určitý typ objektů. Kaţdý objekt je nějaká existující realita (věc, osoba) a typ objektu je tedy její logická reprezentace. Entity odpovídají tedy skutečným objektům, o kterých jsou shromaţďovány určité charakteristické údaje (atributy). Názvy entit bývají reprezentovány podstatným jménem. V případě, ţe by entita měla variantní strukturu, tedy ţe by jedna entita byla rozdělena podle charakteru jednotlivých atributů, rozdělujeme ji na supertyp (pro společné atributy) a subtypy (atributy vlastní jednotlivým skupinám). Relační vazby představují v ER diagramech logické vztahy mezi jednou nebo několika entitami. Názvy relačních vazeb bývají reprezentovány slovesy. 3.2.2

Normalizace databáze

Při transformaci ER modelu na strukturu fyzického uspořádání tabulek a relací je nutno se vyhnout dvěma hlavním problémům, kterými jsou redundance dat a opakující se skupiny dat. Redundancí dat rozumíme opakující se záznamy, coţ značně komplikuje editaci dat. Místo jednoho údaje je pak nutno editovat celou řadu stejných údajů. Dalším problémem jsou opakujíce se skupiny dat. V tomto případě dochází k problému, ţe u některých záznamů zůstanou některé atributy prázdné a u jiného záznamu existuje naopak nedostatek atributů. Úprava modelu dat na takový, kde jsou výše uvedené nedostatky odstraněny, se nazývá normalizace. Normalizace pak znamená splnění několika následujících, tzv. normálních forem (Conolly, 2009):  1NF – První normální forma Kaţdý atribut obsahuje pouze atomické hodnoty, tedy z pohledu databáze jiţ dále nedělitelné.  2NF – Druhá normální forma Kaţdý neklíčový atribut je plně závislý na primárním klíči.  3NF – Třetí normální forma Všechny neklíčové atributy musí být vzájemně nezávislé.  BCNF – Boyce Coddova normální forma

28


Atributy, které jsou součástí primárního klíče, musí být vzájemně nezávislé.  4NF – Čtvrtá normální forma Relace popisuje pouze příčinnou závislost mezi klíčem a atributy.  5NF – Pátá normální forma Relaci není moţno bezztrátově rozloţit.

3.3 Microsoft Access 2010 Microsoft Access 2010 je další verzí (po předchozích verzích 2007, 2003, aj.) databázového systému od firmy Microsoft. Je součástí kancelářského balíku Office 2010 (Kruczek, 2010). Základní kameny databázového systému Microsoft Access: 3.3.1

Tabulky

Kaţdá tabulka se skládá z jednotlivých sloupců, kterým se říká pole. Pole je jeden sloupec v tabulce, je to jedna z vlastností, která popisuje dané věci v tabulce, např. jméno, datum, počet, atd. V kaţdé tabulce existuje několik řádků, kterým se říká záznamy. Záznam, tedy jeden konkrétní řádek popisuje jednu konkrétní věc, např. údaje o zaměstnanci (jeho jméno, příjmení, rodné číslo, atd.). Položka je jeden konkrétní údaj v daném sloupci a řádku, je to tedy konkrétní hodnota pole pro daný záznam, např. rodné číslo konkrétního zaměstnance. Tabulky jsou mezi sebou propojeny prostřednictvím relací. Relace definují spojení mezi primárním klíčem jedné tabulky a cizím klíčem druhé tabulky. Relace mohou být tří typů:  1:1  1:N  M:N 3.3.2

Dotazy

V tabulkách jsou uloţena samotná data. Aby měla ale databáze smysl, je potřeba se na tato data dívat z více pohledů. Někdy je potřeba zobrazit jen některé záznamy, vybrané podle určitého kritéria. Jindy je potřeba získat data z několika tabulek současně. Dotazy mohou dále provádět v daných tabulkách výpočty, mohou zpracovávat data z tabulek. Dále mohou také tabulky modifikovat, vytvářet, nebo do tabulek mohou data přidávat. Dotazy můţeme rozdělit do čtyř hlavních kategorií:  Výběrové dotazy


29

 Kříţové dotazy  Akční dotazy  Dotazy SQL 3.3.3

Formuláře

Formuláře usnadňují zadávání a prohlíţení dat v databázi. Data není nutné zadávat přímo do tabulek, ale vyuţijí se k tomu formuláře. Můţeme tak zajistit, ţe budou data z více tabulek zobrazena v jednom formuláři. Formulář můţe také zajistit kontrolu zadávaných údajů, můţe provádět automatické přepočty, či předvyplňovat zadávané údaje. 3.3.4

Sestavy

Sestavy jsou určené k tvorbě výstupů z databáze. Data bývají většinou graficky upravena, mohou být přepočítána či shrnuta a je z nich vytvořena sestava. Tato sestava je pak většinou určena k tisku, tzn., ţe obsahuje také informace o velikosti papíru, na který se bude tisknout a další informace k tisku. Samozřejmostí je libovolná grafická úprava včetně obrázků. Sestavou můţe být např. faktura vybraných výrobků. 3.3.5

Makra

Makra slouţí k usnadnění a automatizaci často se opakujících úkolů. Tyto úkoly jsou shrnuty a zapsány do makra, které pak provede vše, aniţ by byl nutný zásah uţivatele. Makro lze přiřadit tlačítku na formuláři, lze ho spustit při otevření databáze, nebo ho lze spustit při vzniku spousty jiných událostí. Na rozdíl od většiny ostatních aplikací balíku Office však nelze vytvořit makro pouhým zaznamenáním prováděných akcí. 3.3.6

Programové moduly

Programové moduly jsou moduly jazyka Visual Basic for Application. Programové moduly se vytvářejí buď psaním programového kódu v tomto jazyce, nebo se často vytvářejí tak, ţe se vytvořené makro převede na programový modul automaticky pomocí nástroje aplikace Microsoft Access. Vyuţití této druhé moţnosti bývá pak často spojeno s nějakou úpravou programového kódu a samotné převedení makra se pak pouţívá jako ulehčení části programování.

30

Návrh řešení

4 Návrh řešení 4.1 Výběr řešení Z moţných řešení, která byla stručně popsána v kapitole 2.6, byla ve firmě zvolena varianta č. 3, tj. tvorba vlastního databázového systému. Důvodem této volby je skutečnost, ţe pouze tato moţnost jako jediná splňuje všechny poţadavky, které byly na počátku stanoveny. Zmiňovaná nevýhoda tohoto řešení (nutná znalost programovacího nástroje) je z velké části vyřešena tím, ţe ve firmě jsou zaměstnanci (mezi nimi i autor této práce), kteří o tvorbě databázového systému jiţ nějaké znalosti mají. Samozřejmou podmínkou je volba takového databázového softwaru, ke kterému existuje literatura usnadňující v budoucnosti řešení případných problémů.

4.2 Výběr konkrétního databázového softwaru V současnosti existuje řada kvalitních databázových softwaru, které je moţné pouţít. V úvahu byly vzaty tyto:  Microsoft Access Je relační databázový systém vyvinutý společností Microsoft. Je vhodný pro malé aţ střední podniky. Často se také pouţívá pouze pro správu relačních databází, kdy funguje pouze jako systém pro řízení a správu dat a jako samotná báze dat je pouţit jiný software (Kruczek, 2010).  Microsoft SQL Server Je relační databázový systém vyvinutý společností Microsoft. Je vhodný pro spravování velkého objemu dat, bývá často pouţíván jako hlavní datový sklad firem. Uţivatelé mají přístup k datům buď prostřednictvím speciálně vyvinutých aplikací, nebo pomocí nástrojů jako jsou aplikace Microsoft Office (Hotek, 2009).  MySQL Je relační databázový systém vytvořený firmou MySQL AB, nyní vlastněný společností Sun Microsystems. Jedná se o výkonný software, poměrně snadno implementovatelný. Je distribuován pod hlavičkou Open Source, jedná se tedy o volně šiřitelný software, který je zdarma (Kofler, 2007). Z uvedených softwaru byl vybrán Microsoft Access. Důvody výběru tohoto software jsou následující:  Cena (cca 3500 Kč za licenci).  Software je jiţ ve firmě dostupný.

Návrh řešení

31

 Pokud by databáze v budoucnu narůstala, celkem snadná moţnost přechodu ke kvalitnějšímu řešení báze dat tj. Microsoft SQL server.  Existence modulu Access Runtime.

32

Návrh řešení

4.3 Návrh entitně-relačního modelu

Obr. 2 Entitně-relační model Zdroj: Vlastní tvorba

Návrh řešení

33

Entitně-relační model byl vytvořen podle poţadavků firmy na vzájemnou provázanost dat. Představuje logický pohled na databázový systém. Je zde přehledně znázorněna kostra databázového systému, kterou tvoří entity (na obrázku znázorněné tučně):  Projektová skupina  Projekt  Motor  Výpočtový list Z entitně-relačního modelu je také zřejmé, jakým typem vazby jsou spolu dvě konkrétní entity spojeny. Znázornění typů pouţitých vazeb je uvedeno na obr. 3.

Obr. 3 Typy vazeb v relačním modelu Zdroj: Konečný, 1996

Motory, které firma vyrábí, se nyní dodávají pouze do vysokozdviţných vozíků. Protoţe se ve firmě začíná rýsovat moţnost dodávat motory i pro jiné průmyslové pouţití, je relační model navrhnut tak, aby bylo moţné v budoucnu snadno upravit databázi i pro evidování tohoto nového pouţití. Tato moţnost je v modelu znázorněná entitami projektová skupina a vozík. Pokud by se nepočítalo s rozšířením pro jiné pouţití, neţ jsou vozíky, pak by v modelu byla pouze entita vozík, entita projektová skupina by chyběla. Nyní pokud by přibyla moţnost jiného pouţití, znamenalo by to v modelu navázání nové entity na relaci být typu. V tomto případě entita projektová skupina představuje supertyp a entita vozík představuje subtyp. Část modelu s těmito dvěma entitami a spojující relací představuje tedy variantní část struktury modelu, neboť entita projektová skupina můţe představovat nejen vozík, ale v budoucnu i jiné průmyslové pouţití.

34

Realizace databázového systému

5 Realizace databázového systému Realizaci databáze je moţno rozdělit do dvou základních kroků.  Tvorba báze dat, neboli tvorba relačního modelu.  Tvorba systému řízení báze dat. Prvním a nejdůleţitějším krokem tvorby databáze je tvorba relačního modelu. Relační model musí být vytvořen tak, aby byl schopen spravovat všechna data, potřebná pro projektové řízení. Současně musí splňovat všechny podmínky normalizace. Velký důraz na relační model spočívá ve skutečnosti, ţe jeho případná změna by byla velmi obtíţná. Po vytvoření databáze se mohou vyskytnout dva typy poţadavků na změnu relačního modelu:  Doplnění relačního modelu o nové tabulky, případně o nové atributy do tabulek. Tyto změny jsou realizovatelné bez větších obtíţí, protoţe většinou nemají vliv na současný systém řízení báze dat.  Úprava současného relačního modelu. Tyto úpravy jsou pak velice pracné, většinou znamenají velké zásahy do současného systému řízení báze dat. Druhým krokem tvorby databáze je systém řízení báze dat, který zahrnuje tvorbu formulářů, dotazů, tiskových sestav. Velice často se zde pouţívají makra, nebo programové moduly Visual Basicu.

5.1

Tvorba relačního modelu

Relační model jsem vytvářel ve spolupráci s vedoucím konstrukce (můj přímý nadřízený), který je z pohledu řízení projektů jedna z osob tvořící organizační strukturu řízení projektů. Relační model se skládá z 55 tabulek, ve kterých je přibliţně 220 atributů. Protoţe celkový relační model je velice rozsáhlý, je nutno jeho zobrazení vhodně rozdělit. Celkový model jsem rozdělil do 6 částí. První část zobrazuje hlavní kostru modelu, kterou tvoří tabulky:  Tab_projektova_skupina  Tab_projekty  dbo_INP35  Tab_vyp_list  Tab_parametry_motoru Další části pak popisují relační model, který se vztahuje k těmto pěti tabulkám. Tabulky jsou propojeny vhodnými relacemi. Relace M:N jsou vytvořeny pomocí propojovacích tabulek, např. pomocí Tab_propoj_projekt_motor. U většiny relací je nastavena referenční integrita.


35

Některá data potřebná pro databázi jsou součástí podnikového informačního systému. Aby nedocházelo k duplicitě dat mezi tímto databázovým systémem a podnikovým informačním systémem, pouţívá databáze několik tabulek přímo z podnikového informačního systému propojených přes ODBC rozhraní. Skutečnost propojení tabulek z vnější báze dat s sebou přináší tu nepříjemnost, ţe v tomto případě nelze nastavit referenční integritu. V databázi jsou pouţity čtyři takto propojené tabulky. Tabulky propojené z podnikového informačního systému se snadno poznají podle názvu. Začátek názvu tvoří vţdy označení dbo_.

Obr. 4 Relační model základní kostry databáze Zdroj: Vlastní tvorba

Na obrázku je znázorněná základní kostra relačního modelu. V levém sloupci jsou zobrazeny tři propojovací tabulky, které pomáhají tvořit relace typu M:N. Zbývajících pět tabulek tvoří nejdůleţitější tabulky relačního modelu.

36


Obr. 5 Relační model vztahující se k Tab_projektova_skupina Zdroj: Vlastní tvorba

Obrázek představuje část relačního modelu vztahující se k tabulce Tab_projektova_skupina. Tato část relačního modelu zahrnuje informace o vzájemných vztazích projektů a dále obecné informace o vozících, pro které jsou motory určeny.


37

Obr. 6 První část rel. modelu vztahující se k Tab_projekty Zdroj: Vlastní tvorba

Část relačního modelu vztahující se k projektům je nejvýznamnější částí databáze. Protoţe je tato část celkem rozsáhlá, je rozdělena na dvě další části. První zahrnuje informace o osobách, které mají vztah k projektům. Toto jsou buď zaměstnanci, nebo zákazníci.

38


Obr. 7 Druhá část rel. modelu vztahující se k Tab_projekty Zdroj: Vlastní tvorba

Druhá část relačního modelu související s projekty zahrnuje všechny ostatní informace, které se k projektům vztahují, např. zaslané cenové nabídky, historii stavu projektu, výhled výroby, poznámky k projektu atd. Část relačního modelu vztahující se k tabulce dbo_INP35 zahrnuje informace k motorům. Protoţe čísla motorů jsou v podnikovém informačním systému, jsou tyto data z informačního systému propojena. Všechny relace, které spojují tuto tabulku s ostatními tabulkami, nemají nastaveny referenční integritu, protoţe ji u propojených tabulek nastavit nelze.


Obr. 8 Relační model databáze vztahující se k tab dbo_INP35 Zdroj: Vlastní tvorba

Obr. 9 Relační model databáze vztahující se k Tab_vyp_list Zdroj: Vlastní tvorba

39

40


Další část relačního modelu zahrnuje data výpočtových listů motoru. Tato část představuje nejrozsáhlejší část databáze.

Obr. 10

Relační model vztahující se k Tab_parametry_motoru


Část modelu vztahující se k tabulce Tab_paramtry_motoru patří k datům výpočtového listu. To je zřejmé také z relační vazby mezi Tab_vyp_list a Tab_parametry_motoru, která je typu 1:1. Z důvodu velkého rozsahu této části modelu musela být tato část rozdělena. Vytvořením takového relačního modelu je hotova báze dat, která bude pouţita ve všech dalších částech databázového systému.


41

5.2 Tvorba dotazů Pro tvorbu databáze byly pouţity tři typy dotazů.  Výběrový dotaz V databázi jsou vytvořeny čtyři výběrové dotazy. Jeden je pouţit jako vstupní data pro tiskovou sestavu a tři dotazy jsou pouţity jako vstupní data pro formuláře. Dotazy je moţno vytvářet pomocí průvodce, nebo se dají vytvářet v návrhovém zobrazení, které je podrobnější. Všechny dotazy byly vytvořeny v návrhovém zobrazení.

Obr. 11

Vytváření dotazu v návrhovém zobrazení


 Kříţový dotaz V databázi jsou pouţity dva kříţové dotazy, které se pouţívají pro přehledné zobrazení souhrnů dat.  Akční dotaz V samotné databázi není akční dotaz pouţit. Akční dotaz je pouţit v pomocné bázi dat, která nahrazuje podnikový informační systém. Tento dotaz slouţí k vytvoření kopie tabulek z informačního systému, aby bylo moţné s databází pracovat nejen v podnikové síti.

42


5.3 Tvorba formulářů Formuláře jsou z pohledu uţivatele nejpouţívanější nástroj databáze. V této databázi je pouţito 51 formulářů. Většina z nich je pouţita jako podformuláře některého jiného formuláře. Nejčastěji se formuláře vytvářejí v návrhovém zobrazení. Jeden z formulářů slouţí jako hlavní přepínací panel. Ten se automaticky spustí po spuštění databáze. Z tohoto formuláře lze spouštět všechny ostatní. Formuláře mohou obsahovat data pro čtení, nebo umoţňují zápis dat. Na obr. 12 je znázorněný jeden z vytvořených formulářů.


Obr. 12

43

Formulář databáze


5.4 Tvorba tiskových sestav V databázi je v současnosti jedna tisková sestava zobrazující základní parametry motoru příslušejícího ke konkrétnímu projektu. Z důvodu rozsahu sestavy (2 stránky) je tato vloţena v přílohách na konci knihy. Tato tisková sestava byla vytvořena v návrhovém zobrazení. Protoţe jsou data pro tiskovou sestavu uloţena ve více tabulkách, jsou nejdříve předpřipravena výběrovým dotazem. Tisková sestava se spouští z formuláře spravujícího motory příkazovým tlačítkem. Po spuštění tlačítka generujícího tiskovou sestavu jsou tedy nejdříve data výběrovým dotazem z různých

44


tabulek sesbírána. Následně je pouţit filtr, který vyfiltruje data pro konkrétní motor. Z těchto dat je pak vytvořena tisková sestava.

5.5 Tvorba programových modulů Ovládání formulářů je moţné provést vyuţitím maker, nebo programových modulů. Vytváření maker je sice jednodušší a intuitivní v porovnání s programovými moduly, na druhé straně makra mají omezený rozsah činností, pro které jsou připravena. Pro ovládání databáze jsou vytvořeny programové moduly, protoţe moţnosti maker nepokrývaly poţadavky na ovládání. Programovými moduly je řešeno:  Otevírání formulářů  Vzájemné přepínání mezi formuláři  Otevírání tiskových sestav  Výběr záznamů Programové moduly většinou obsahují různou kombinaci předchozích činností. Části některých programových modulů byly vytvořeny převedením makra do jazyka Visual Basic (Jerke, 2005).


45

6 Popis a zhodnocení daného řešení 6.1 Popis řešení Po spuštění databázového systému se automaticky spustí hlavní přepínací panel, ze kterého je moţné spouštět ovládací formuláře.

Obr. 13

Hlavní přepínací panel


Z hlavního přepínacího panelu je moţné spouštět tři základní druhy formulářů:  Formuláře slouţící pro zakládání záznamů a správu základních atributů Pro správu záznamů je nutné jednotlivé záznamy nejdříve vytvořit. Pro zakládání různých záznamů existuje osm formulářů podle příslušného typu záznamu. Tyto formuláře se spouští z hlavního ovládacího panelu na horní

46


straně. Na následujícím obrázku je zobrazen formulář slouţící pro zakládání projektů. Ostatní formuláře z této skupiny, např. formlář pro zakládání projektové skupiny, vozíku, výpočtového listu apod., vypadají podobně, proto zde nejsou jejich obrázky zobrazeny.

Obr. 14

Zakládání projektů


 Formuláře slouţící pro správu záznamů Tyto formuláře tvoří nejvýznamnější část databázového systému. Jejich prostřednictvím se evidují všechny podstatné informace k projektům. Aby


47

bylo jejich ovládání uţivatelsky příjemné a také co moţná nejrychlejší, je moţné se mezi nimi přepínat dvojklikem na konkrétní záznam. Protoţe jsou tyto formuláře pro práci stěţejní, jsou zde uvedeny všechny čtyři formuláře. Z důvodu svého rozsahu jsou uvedeny v příloze.  Formuláře pro zobrazení statistických přehledů Zde je moţno prozatím spustit dva přehledy. První zobrazuje počet projektů vyvíjených pro konkrétní koncern, na jehoţ vývoje se podílí konkrétní osoba. Druhý přehled zobrazuje počet projektů v daném roce, které byly pro konkrétní koncern zaloţeny. Tyto přehledy jsou vytvořeny jako kříţové dotazy. Pro ukázku uvádím první z nich.

Obr. 15

Přehled osob příslušných k projektům pro koncerny


6.2 Ekonomické zhodnocení řešení Vytvořením vlastního software nevznikly firmě náklady spojené s nákupem speciálního softwaru. Přesto firmě vznikly náklady spojené se samotným vývojem řešení. Náklady na vývoj databázového systému jsou tvořeny těmito poloţkami:  Software Microsoft Access  Literatura k danému tématu  Personální náklady, spojené s časem stráveným vývojem řešení. Vývoj databázového systému trval přibliţně 350 hodin. Hodinová sazba zaměstnan-

48


ce je 200Kč/hod. Personální náklady firmy jsou tvořeny hrubou mzdou zaměstnance navýšenou o sociální a zdravotní pojištění 34%, které je firma povinna za zaměstnance odvést. Tab. 5

Náklady na vývoj databázového systému.

Náklady Microsoft Access Literatura Personální náklady Celkové náklady

Částka[Kč] 03500 00750 93800 98050


Vytvořený databázový systém znamená pro firmu úsporu, která se projeví jako kratší čas strávený na projektovém řízení. Průměrný čas spojený s projektovým řízením je pro kaţdé oddělení jiný. Tab. 6

Předpokládané úspory spojené s novým řešením.

Oddělení

Konstrukce Zákl. vývoj Nákup Technologie Kvalita

Průměrný čas zaměstnance Počet spojený s čistě pracovníků projektovým řízením [h/den] 10 3 3 1 9 2 6 2 6 0,25

Předpokl. úspora nového řešení [%]

Předpokl. úspora nového řešení [h/den]

10 10 10 5 5

3 0,3 1,8 0,6 0,075


Celková předpokládaná časová úspora firmy je 5,775h/den. Úspora firmy při sazbě 200Kč/hod a při povinných odvodech 34% na zdravotní a sociální pojištění je tedy 1547,7Kč/den. Návratnost nového řešení je dána podílem celkových nákladů vzniklých při tvorbě nového řešení a předpokládanou úsporou nového řešení.

návratnost 

náklady 98050   63,4dne úspora 1547,7

Náklady na nové řešení by se měli firmě vrátit za 64 dnů.


49

6.3 Technické zhodnocení řešení Z pohledu správy dat je současné řešení jiţ hotové a v současnosti je v testovací fázi. Pro plné nasazení ve firmě je potřeba provést:  Vytvoření uţivatelských práv.  Rozdělit databázi na front-end a back-end část.  Stanovení pravidel pro zálohování databáze.

50

Diskuze

7 Diskuze Vytvoření nového databázového systému bylo ze čtyř uvaţovaných řešení časově nejnáročnější. V porovnání s ostatními řešeními ale jako jediné splňuje všechny stanovené poţadavky. První uvaţovaná moţnost řešení (podrobná excelovská tabulka) by většinu stanovených poţadavků vůbec nesplnila a i kdyţ by tato moţnost byla časově i finančně nejvýhodnější, byla by pro firmu naprosto nedostačující. Druhé uvaţované řešení (úprava PDM systému) by znamenala poměrně velké finanční náklady a velkou závislost na dodavateli PDM. Přesto by vlastní řešení musela firma JULI sama vytvořit. Poslední uvaţované řešení (nákup hotového softwaru) by znamenal omezení stanovených poţadavků. Neexistuje totiţ ţádný komerční software, který by umoţnoval spravovat firmou stanovená data, takový software by musela externí firma dle potřeb firmy JULI vytvořit. Náklady na toto řešení by byly vyšší, neţ na vývoj současného databázového systému a navíc by se firma JULI stala na dodavateli softwaru závislou. Zvolené řešení je i managementem firmy hodnoceno velmi pozitivně.

7.1

Možné rozšíření databázového systému

Jak jiţ bylo řečeno dříve, komplexní projektové řízení se skládá z několika etap. S těmito etapami souvisejí činnosti jako např. plánování, koordinace projektu, kontrola průběhu projektu aj. Toto jsou činnosti, které jsou nyní nejednotně řešeny v rámci projektů, a organizace těchto činností je plně v kompetenci vedoucích projektů. Současný databázový systém je připraven pro uchování nejpodstatnějších informací o jednotlivých projektech, ale činnosti související s jednotlivými etapami projektového řízení nezahrnuje. Databázový systém je tedy nyní vytvořen jako podpora projektového řízení. Doplnění databázového systému o tyto činnosti by mohlo být jeho dalším rozšířením.

Závěr

51

8 Závěr Cílem této bakalářské práce bylo vytvořit návrh databázového systému pro podporu řízení projektů pro firmu JULI Motorenwerk. Tohoto cíle bylo v zadaném rozsahu dosaţeno. Tvorba řešení byla ve firmě několikrát konzultována. Na podnět firmy bylo řešení několikrát upraveno tak, aby opravdu odpovídalo jejím poţadavkům. Konečné řešení bylo ve firmě převedeno a firma s ním souhlasí. Zahrnutím správy dalších činností projektového řízení my mohlo být další rozšíření tohoto databázového systému. Protoţe zamýšlím ve škole pokračovat v rámci magisterského studia, rád bych se tímto problémem zabýval v diplomové práci.

8.1 Rekapitulace řešení Při řešení tohoto úkolu byla nejdříve provedena analýza současného projektového řízení. Tato analýza ukázala, ţe současné řešení správy dat projektového řízení je opravdu nepostačující a ţe současné řešení můţe sniţovat konkurenceschopnost firmy při vývoji nových produktů. Byla provedena analýza různých řešení, v úvahu byla vzata čtyři moţná řešení. Tato analýza ukázala, ţe nejvhodnějším řešením pro firmu bude tvorba vlastního databázového řešení, protoţe pouze takto budou splněny všechny podmínky, které byly zpočátku stanoveny jako důleţitá kritéria. Pro tvorbu databázového systému byl ze tří moţných softwaru vybrán Microsoft Access. Dalším krokem bylo vytvoření návrhu databáze. Ten byl vytvořen jako ER diagram odpovídající poţadavkům firmy. Realizace databázového systému zahrnovala vytvoření relačního modelu, ovládacích formulářů, tiskové sestavy a dotazů. Pro ovládání databáze byly vytvořeny programové moduly ve Visual Basic for Application.

8.2 Praktický přínos práce Nově vytvořený databázový systém je pro firmu přínosný z několika důvodů. Data jsou nyní veřejně přístupná, jestliţe tedy někdo potřebuje informace o projektu, nemusí je vyţadovat od vedoucího projektu, ale můţe si je vyhledat sám. Data jsou uloţena v jednotné formě, coţ umoţní přehlednější a rychlejší vyhledávání. Data je moţné analyzovat prostřednictvím sql dotazů, které v případě většího objemu dat nesrovnatelně urychlují práci. Sql dotazy jsou v databázi pouţity a současně není problém, nové sql dotazy v případě potřeby vytvořit. Protoţe je databázový systém vyvinut přímo ve firmě, není problém ho libovolně rozšiřovat bez dalších vícenákladů, které by v případě koupeného softwaru nepochybně vznikly.

52

Literatura

9 Literatura CONOLLY, T. Databáze: Profesionální průvodce tvorbou efektivních databází. Brno: Computer Press, 2009. 584 s. ISBN 978-80-251-2328-7. DOLANSKÝ, V., MĚKOTA, V.,NĚMEC, V. Projektový management. 1. vydání. Praha: Grada, 1996. 372 s. ISBN 80-7169-287-5. HÁBA, J, ŠVANCAROVÁ, Š, JANKŮ, Z. Znalecký posudek č. ZU 616-051/2004. Brno: Znalci a odhadci, 2004. 78 s. HEERKENS, G.R. Project Management. New-York: McGraw-Hill, 2002. ISBN 007-137952-5. HERNANDEZ, M. Návrh databází. Praha: Grada, 2006. 408 s. ISBN 80-2470900-7. HOTEK, M. Microsoft SQL Server 2008: krok za krokem. 1. vydání. Brno: Computer Press, 2009. 488 s. ISBN 978-80-251-2466-6. JERKE, N. Microsof Access 2003 pro pokročilé. 1. vydání. Brno: CP Books, 2005. 351 s. ISBN 80-251-0723-x. JULI MOTORENWERK. Moravany. Výroční zpráva 2009. 2009. 33 s. KOFLER, M., OGGL, B. PHP 5 a MySQL: Průvodce webového programátora. 1. vydání. Brno: Computer Press, 2007. 607 s. ISBN 978-80-251-1813-9. KONEČNÝ, V. Projektování informačních systémů. 1. vydání. Brno: Mendelova zemědělská a lesnická univerzita v Brně, 1996. 97 s. ISBN 80-7157-241-1. KRUCZEK,A. Microsoft Access 2010: Podrobná uživatelská příručka. 1. vydání. Brno: Computer Press, 2010. 392 s. ISBN 978-80-251-3289-0. LEWIS, J. P. Fundamentals of Project Management. New-York: Amacom Books, 2007. ISBN 0-8144-0879-6. ROSENAU, M. Řízení projektů. Brno: Computer Press, 2007. 344 s. ISBN 978-80251-1506-0. TAYLOR, J. Začínáme řídit projekty. Brno: Computer Press, 2007. 215 s. ISBN 978-80-251-1759-0.

Přílohy

53

Přílohy

54

Pouţitý software

A Použitý software

Obr. 16

Microsoft Access 2010


Obr. 17

Microsoft Visual Basic for Applications



B Formuláře správy záznamů

Obr. 18

Formulář správy vozíků


Obr. 19

Formulář správy projektů


55

56


Obr. 20

Formulář správy motorů


Obr. 21

Formulář správy výpočtových listů


Tisková sestava

57

C Tisková sestava

Obr. 22

První strana tiskové sestavy


58

Tisková sestava

Obr. 23

Druhá strana tiskové sestavy


Návrh databázového systému pro podporu řízení projektů ve firmě Juli Motorenwerk s.r.o

Recommend Documents