Návrh projektového řízení ve firmě Juli Motorenwerk s.r.o

Mendelova univerzita v Brně Provozně ekonomická fakulta

Návrh projektového řízení ve firmě Juli Motorenwerk s.r.o. Diplomová práce

Vedoucí práce:

Autor:

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

Ing. Karel Paulík

Brno 2013

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í diplomové práce.

Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. V Brně dne 15. května 2013

__________________

Abstract Paulík, K. Project management suggestion in company Juli Motorenwerk s.r.o. Graduation thesis. Brno: MUAF, 2013. In the document is analysed the current status of project management in company Juli Motorenwerk s.r.o. Next is performed proposal of specific project management implementation focused on the need of the company including transform conditions of proposed solution into other company as well. 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 projektového řízení ve firmě Juli Motorenwerk s.r.o. Diplomová práce. Brno: MZLU v Brně, 2013. V textu je analyzován současný stav projektového řízení ve firmě Juli Motorenwerk s.r.o. Dále je proveden návrh specifické implementace projektového řízení zaměřené na potřeby firmy včetně identifikace podmínek převoditelnosti navrženého řešení i do jiných firem. 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 ......................................................................................................... 12

1.2

Cíl práce ................................................................................................... 12

1.3

Metodika .................................................................................................. 12

Teoretická východiska práce 2.1

14

Organizování v podniku........................................................................... 14

2.1.1

Organizační struktury podniku vhodné pro projektové řízení ....... 15

2.2

Obecná metodika projektového řízení ....................................................18

2.3

Databáze .................................................................................................. 22

2.3.1

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

2.3.2

Normalizace databáze ..................................................................... 24

2.4

3

12

Microsoft Access 2010 ............................................................................ 25

2.4.1

Tabulky ............................................................................................ 25

2.4.2

Dotazy.............................................................................................. 25

2.4.3

Formuláře........................................................................................ 26

2.4.4

Sestavy ............................................................................................. 26

2.4.5

Makra .............................................................................................. 26

2.4.6

Programové moduly ........................................................................ 26

Analýza současného stavu projektového řízení

27

3.1

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

3.2

Prostředí firmy ........................................................................................ 27

3.2.1

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

3.2.2

Vnitřní prostředí ............................................................................. 29

3.2.3

SWOT analýza ................................................................................. 30

3.3

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

3.4

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

3.5

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

3.6

Zhodnocení provedené analýzy .............................................................. 38

6

Obsah

3.6.1

Z ekonomického hlediska ............................................................... 38

3.6.2

Z technického hlediska ................................................................... 40

3.7 4

5

6

Doporučení plynoucí z provedené analýzy ............................................ 40

Návrh specifické implementace projektového řízení

41

4.1

Požadavky kladené na nové řešení .......................................................... 41

4.2

Vývojová stádia projektu ......................................................................... 41

4.3

Návrh jednotného plánu projektu ...........................................................42

4.3.1

Hierarchický rozpad činností – WBS ..............................................42

4.3.2

Plán projektu .................................................................................. 46

4.4

Organizační struktura podniku podle dělby pravomoci mezi organizačními jednotkami...................................................................... 49

4.5

Návrh implementační fáze projektu....................................................... 49

4.6

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

Návrh softwaru projektového řízení

54

5.1

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

5.2

Tvorba systému řízení báze dat ............................................................... 56

5.3

Kompletní softwarové řešení...................................................................56

Popis navrženého řešení

58

6.1

Zakládání položek .................................................................................... 59

6.2

Správa položek ......................................................................................... 59

6.3

Přehledy .................................................................................................. 64

7

Převoditelnost navrženého řešení do jiných firem

65

8

Zhodnocení navrženého řešení

67

9

8.1

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

8.2

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

Diskuze 9.1

70

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

10 Závěr

72

10.1 Rekapitulace řešení ................................................................................. 72 10.2 Praktický přínos práce ............................................................................. 72

Obsah

7

11

Literatura

74

A

Vzorový plán projektu

77

B

Relační model databáze

83

C

Použitý software

92

D

Výběr použitých formulářů

93

E

Výběr použitých tiskových sestav

95

8

Seznam obrázků

Seznam obrázků Obr. 1

Projektová řídící struktura

16

Obr. 2

Maticová řídící struktura

17

Obr. 3

Pseudomaticová řídící struktura

18

Obr. 4

Organizační struktura podniku

29

Obr. 5

Juli Projekt Manager

35

Obr. 6

Správa odpracovaných hodin na projektech

36

Obr. 7

AS/400 Iseries

37

Obr. 8

Teamcenter

38

Obr. 9

Začátek plánu projektu

47

Obr. 10

Konec plánu projektu

48

Obr. 11

Pseudomaticová řídící struktura ve firmě Juli Motorenwerk s.r.o.

49

Obr. 12

Entitně-relační model

52

Obr. 13

Typy vazeb v relačním modelu

53

Obr. 14

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

55

Obr. 15

Kompletní softwarové řešení

57

Obr. 16

Hlavní formulář

58

Obr. 17

Správa plánu projektu

60

Obr. 18

Formulář zápisů porad

62

Obr. 19

Formulář správy osob

63

Obr. 20

Formulář úkolů konkrétního oddělení

64

Obr. 21

Moduly databázového systému Juli Projek Manager

66

Seznam obrázků

9

Obr. 22

Plán projektu, první část

77

Obr. 23

Plán projektu, druhá část

77

Obr. 24

Plán projektu, třetí část

78

Obr. 25

Plán projektu, čtvrtá část

78

Obr. 26

Plán projektu, pátá část

79

Obr. 27

Plán projektu, šestá část

79

Obr. 28

Plán projektu, sedmá část

80

Obr. 29

Plán projektu, osmá část

80

Obr. 30

Plán projektu, devátá část

81

Obr. 31

Plán projektu, desátá část

81

Obr. 32

Plán projektu, jedenáctá část

82

Obr. 33

Plán projektu, dvanáctá část

82

Obr. 34

Relační model základní kostry

83

Obr. 35

Relační model vztahující se k projektové skupině

84

Obr. 36

Relační model vztahující se k projektu, první část

85

Obr. 37

Relační model vztahující se k projektu, druhá část

86

Obr. 38

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

87

Obr. 39

Relační model vztahující se k výpočtovému listu

88

Obr. 40

Relační model vztahující se k parametrům motoru

89

Obr. 41

Relační model vztahující se k bodům porad

90

Obr. 42

Relační model vztahující se k nářadí

91

Obr. 43

Microsoft Access 2010

92

Obr. 44

Microsoft Visual Basic for Applications

92

Obr. 45

Formulář správy vozíků

93

10

Seznam obrázků

Obr. 46

Formulář správy motorů

93

Obr. 47

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

94

Obr. 48

Formulář správy nářadí

94

Obr. 49

První tiskové sestavy informací k projektu

95

Obr. 50

Druhá strana tiskové sestavy informací k projektu

96

Obr. 51

První strana tiskové sestavy informací k motoru

97

Obr. 52

Druhá strana tiskové sestavy informací k motoru

98

Obr. 53

Tisková sestava zápisu z porady

99

Obr. 54

Tisková sestava nastavení zkušebny

100

Seznam tabulek

11

Seznam tabulek Tab. 1

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

28

Tab. 2

Matice SWOT

30

Tab. 3

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

33

Tab. 4

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

33

Tab. 5

Náklady na vývoj první části Juli Projekt Manager

39

Tab. 6

Předpokládané úspory spojené s vytvořením první fáze Juli Projekt Manageru. 39

Tab. 7

Náklady na vývoj nového řešení

67

Tab. 8

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

68

12

Úvod a cíl práce

1 Úvod a cíl práce 1.1

Úvod

Projektové řízení je způsob realizování jedinečných, jednorázových akcí, s jasně stanoveným cílem, který musí být dosažen v předem stanoveném čase, nákladech a kvalitě (Dolanský, 1996). Projektového řízení využívá v současné době velké množství firem a jednou z těchto mnoha firem je i firma JULI Motorenwerk s.r.o. Firma 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í. Projektové řízení se ve firmě používá pro vývoj nových produktů, kdy vývoj nového produktu je vedený jako samostatný projekt, za který je odpovědný projektový manažer. Nutno podotknout, že jeden projektový manažer odpovídá za několik projektů současně. I když pro projektové řízení existuje obecně doporučená metodika, znamená každá jeho konkrétní implementace návrh jedinečného řešení, které se vytváří jako úprava obecně doporučeného postupu projektového řízení podle potřeb konkrétní firmy. Použití projektového řízení však vyžaduje i konsekvence z opačného pohledu. Vedle přizpůsobení projektového řízení požadavkům konkrétní firmy je nutno přizpůsobit i organizaci firmy danému projektovému řízení, protože bez ní nebudou zajištěny podmínky pro úspěšnou realizaci projektů.

1.2 Cíl práce Cílem této práce je návrh specifické metodiky projektového řízení, která nahradí současný stav, kdy ve firmě neexistuje žádná jednotná metodika vedení projektu, takže každý vedoucí řeší projekt ad hoc. Důsledkem této nesystematičnosti vedení projektů jsou pak problémy související se špatnou informovaností zaměstnanců, vedoucí většinou k nedodržování cílů, které byly pro dané projekty stanoveny.

1.3 Metodika Výchozím bodem práce je charakteristika firmy, analýzy jejího vnitřního i vnějšího prostředí, které jsou použity pro následující SWOT analýzu. Dále je podrobně analyzován současný stav projektového řízení ve firmě včetně současného řešení správy dat. Závěry z provedených analýz doporučují vypracování nového způsobu projektového řízení založeného na jednotné metodice vedení projektů. Návrh rozdělení vzorového projektu do pracovních úkolů a činností je proveden metodou WBS (work breakdown structure), tzv. hierarchický rozpad činností. Na základě WBS je proveden návrh jednotného plánu projektu, který je

Úvod a cíl práce

13

vytvořen v softwaru Microsoft Project jako Ganttův diagram. Jako konkrétní metoda plánování je zvolena metoda CPM (critical path method). Dále je proveden návrh databázového systému jako ERD diagram, který názorně zobrazuje vztahy mezi jednotlivými entitami pomocí vzájemných relací. Dalším krokem je pak návrh softwaru projektového řízení, který je proveden jako doplnění již existujícího databázového systému určeného pro správu dat projektů a produktů. K tomuto návrhu řešení jsou dále identifikovány podmínky a způsoby převoditelnosti i do jiných firem, které také projektové řízení využívají. Nové řešení je zhodnoceno z ekonomického hlediska. Jsou vyčísleny náklady na jeho tvorbu, časová a finanční úspora vyplývající z řešení a návratnost nového řešení. Dále je nové řešení zhodnoceno z technického hlediska, kde jsou stanoveny jeho přínosy.

14

Teoretická východiska práce

2 Teoretická východiska práce 2.1 Organizování v podniku Jedním ze základních atributů projektového managementu je organizování a koordinování projektů chápané jako cílený proces, který musí respektovat následující předpoklady utváření řídících struktur (Dolanský, 1996):  vytváření vhodného organizačního prostředí pro dosahování projektových cílů a realizaci projektových plánů,  racionální delegování pravomocí a zodpovědností pro jednotlivé pozice organizační struktury,  respektování okolí, ve kterém se organizační struktura nachází,  respektování a rozvíjení organizační kultury,  vyvíjení organizačního prostředí v souladu s celosvětovými trendy tak, aby vytvářelo vhodné sociální klima pro projektové pracovníky. Organizační struktura by měla umožnit efektivně realizovat projektové procesy. Běžné funkcionální liniové organizační struktury, kde každý vrcholový liniový manažer řídí pouze práce v jemu podřízeném úseku, bývají pro efektivní dosahování projektových cílů nevhodné. Proto je nutné vytvářet takové organizační struktury, jejichž pomocí bude možné efektivně zabezpečovat realizaci projektů. Tento požadavek bývá zabezpečován různým stupněm integrace projektových struktur do stávajícího formálního organizačního uspořádání. Všechny organizace mají určitou formální organizační strukturu vytvářející manažerskou hierarchii. Ve většině organizací jsou vytvářeny pracovní skupiny podle druhu práce, kterou vykonávají. Tímto způsobem vznikají jednotlivá oddělení, která zabezpečují realizaci určitých druhů vymezených činností. Velice často může dojít k situaci, kdy je jeden pracovník podřízen několika manažerům. Jednomu manažerovi (liniovému vedoucímu) odpovídá za plnění pravidelně se opakujících činností a druhému (vedoucímu projektu) je zodpovědný za plnění úkolů v rámci projektu. Tak dochází k prolínání vertikálních a horizontálních organizačních vztahů a organizace je nucena zahrnout do svého funkčního managementu také management projektový. Zapojení pracovníků do různých činností může vést k vytváření konfliktních situací, které mohou vzniknout neustálým přechodem od plnění úkolů spojených s rutinní činností na daném oddělení k plnění úkolů spojených s realizací projektu. Liniový vedoucí si přeje, aby pracovník plnil běžné úkoly na svém pracovišti, a projektové činnosti až po splnění těchto úkolů. Projektový manažer si přeje přesný opak. Nevyjasněnost organizačních vztahů a podobné konflikty mohou vést k narušování mezilidských vztahů, k ohrožení dosažení cílů nejen projektových, ale i celé organizace.


15

Malé projekty obvykle nevyžadují rozsáhlé změny ve stávající organizační struktuře. Se vzrůstajícím rozsahem a komplexností projektů nastávají potíže při jejich koordinaci a jen těžko se dají zvládnout ve stávající organizační struktuře. V této situaci je zcela nezbytné, aby vrcholové vedení přikročilo k reorganizaci a zavedení určitého modelu projektového managementu. U organizací, které již mají projektový management zavedený, je velice důležité získávat a systematicky uplatňovat zkušenosti pracovníků, kteří se na projektových činnostech podílejí. Jsou-li k dispozici organizační zásady, pak se jimi bezvýhradně řídit. Definování a dodržování zásad projektového managementu je dobrým vodítkem pro stanovení celkových organizačních zásad. Vrcholoví manažeři by měli mít k dispozici statistická data o realizovaných projektech. Měli by mít taky trvalou možnost kontroly průběhu realizace projektů a přehled o tom, kteří pracovníci se na jednotlivých projektech podílejí. Jedině tak je možné eliminovat duplicitní a jiné nežádoucí práce. 2.1.1

Organizační struktury podniku vhodné pro projektové řízení

Aby byla organizace projektového managementu úspěšná, je nutné aplikovat takový organizační model, který odpovídá komplexnosti a rozsahu realizovaných projektů. V rámci zvoleného modelu organizační struktury projektového managementu je nutné především delegovat pravomoci a odpovídající zodpovědnosti. Existuje mnoho rozdílných klasifikací formálních organizačních struktur. Organizační struktury je možno dělit (Vágner, 2004. Rosenau, 2007. Veber, 2009): 1. Podle sdružování činností vytvářejících obsahovou náplň dílčích jednotek rozlišujeme struktury funkcionální, výrobkové a ostatní.  funkcionální – jsou založeny na specializaci dílčích strukturálních jednotek (útvarů) podle jejich funkcí. Do jednoho organizačního celku se kumulují stejné funkční činnosti např. vývoj, nákup, ekonomika, sledování kvality adt.  výrobkové – do jednotlivých jednotek se sdružují stejné či podobné výrobky, služby.  ostatní – podle specifických potřeb může jít především o sdružování podle zákazníků, geografického umístění, technologické uzavřenosti obslužných procesů a zařízení atd. 2. Podle uplatňování rozhodovací pravomoci mezi dílčími jednotkami rozlišujeme struktury liniové, štábní a kombinované.  liniové – kde je uplatňována přímá rozhodovací pravomoc.  štábní – plní především poradní funkce k zabezpečení kvalifikovaného rozhodování jednotek s liniovou pravomocí.  kombinované

16


3.

Podle dělby pravomoci mezi organizačními jednotkami rozlišujeme struktury liniové, funkcionální, liniově štábní a další tzv. pružné struktury, mezi které patří struktura projektová, maticová, pseudomaticová.  liniové – pro tuto strukturu je typické respektování principu jediného odpovědného vedoucího a dodržování jednoznačných vazeb mezi nadřízenými a podřízenými.  funkcionální – pro tuto strukturu jsou charakteristické mnohostranné funkčně specializované vazby. Každý podřízený pracovník má dva přímé nadřízené. V této struktuře neplatí princip jediného odpovědného vedoucího.  liniově štábní – v této struktuře jsou odděleny rozhodovací pravomoci od odborných kompetencí. Manažer patří k liniové složce a je nadřízeným všem pracovníkům, tedy i pracovníkům štábu. Štábní složka se podílí na managementu pouze zprostředkovaně, připravuje podklady pro rozhodování liniového manažera.  projektové – vytváří se přesunem mnoha lidí, kteří na projektu pracují, z jejich profesních skupin k manažerovi projektu (obr. 1). Pro projekt je jasně vymezena pravomoc a vytvoří se tak jediné řídící centrum projektu. Pracovníci pracují pouze na jednom projektu, je zajištěna kontinuita a odborná úroveň. Hlavním problémem je nejistota, kterou lidé pociťují, pokud jde o jejich uplatnění po skončení projektu. Strach z konce projektu může nepříznivě ovlivnit jeho úspěšné dokončení.

Obr. 1

Projektová řídící struktura

Zdroj: Rosenau, 2007

 maticové – je kombinací funkční a projektové struktury a snaží se získat to nejlepší z obou forem, protože si uvědomuje výhody existence odborných


17

(funkčních) skupin, ale uvědomuje si také potřebu ústředního článku pro každý projekt (obr. 2).

Obr. 2

Maticová řídící struktura


 pseudomaticové (útvarový projektový management) - vedoucí projektu zůstává v této organizační struktuře i nadále součástí funkční skupiny pro práce prováděné v této skupině, což je stejné jako ve funkční organizaci. Avšak pokud jde o práci na řízení projektu je přímo podřízen vrcholovému managementu (obr. 3).

18


Obr. 3

Pseudomaticová řídící struktura


Projektová, maticová a pseudomaticová struktura patří do tzv. pružných struktur, které jsou vhodné pro projektové řízení. Projektová organizační struktura je vhodná pro rozsáhlé a dlouhodobé projekty. Maticová organizační struktura je zřejmě nejlepší volbou pro střední a velké firmy, pokud firmy zpracovávají velké množství projektů. Naproti tomu pseudomaticová organizační struktura je vhodná buď pro menší firmy, které si projektový management nemůžou dovolit, nebo je vhodná pro menší projekty.

2.2 Obecná metodika projektového ří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)


19

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

2.

Plánování projektu Plánovací činnosti jsou pro řízení projektu rozhodující. Plánování je odpovědí na otázku co musí být uděláno, jaký je rozsah práce? Častým důvodem neúspěšného projektu bývá zapomenutí důležité části práce. 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í porada 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ů:  Pochopení požadavků zákazníka. Tedy vyhodnotit, zda opravdu víme, co od nás zákazník žádá.

20


 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í).  Definování rozhodujících faktorů úspěchu. s určením nejdůležitějších komponent projektu.

Spojeno

většinou

 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ů:  Rozložení projektu do jednotlivých úkolů. Používá se Hierarchický rozklad činností, tzv. WBS (Work breakdown structure). V této části se identifikují základní úkoly nutné pro splnění projektu, které se následně rozpadají na dílčí úkoly. Tyto dílčí úkoly se můžou dále rozpadat na dílčí podúkoly.  Určení doby trvání úkolu a vzájemné závislosti úkolů. Nejčastěji se používá metoda CPM a metoda PERT (Program Evaluation and Review Technique), která stanovuje termíny ukončení projektu s jistou pravděpodobností. Metoda CPM slouží k určení plánování činností v rámci projektu a ve své podobě byla navržena v 50. letech 20. století. Metoda umožnuje určit jednak kritické a nekritické činnosti v rámci projektu a u nekritických činností jejich časové rezervy. Metoda PERT je nedeterministickým rozšířením metody CPM. U metody CPM se předpokládá, že každá činnost v rámci projektu má pevně danou dobu trvání, která musí být dodržena. U metody PERT je doba trvání náhodná veličina, mající specifické rozdělení, realizovaném na pevně daném intervalu. Pro každou činnost se definují 3 časové charakteristiky: nejkratší předpokládaná doba trvání činnosti (optimistický odhad), nejpravděpodobnější doba trvání činnosti (modální odhad) a nejdelší předpokládaná doba trvání činnosti (pesimistický odhad). Doba trvání jednotlivých činností je tedy spojitá náhodná veličina s nespecifikovaným rozdělením, které lze vhodně aproximovat βrozdělením, realizovaným na intervalu: optimistický odhad vs. pesimistický odhad.  Vypracování časového plánu projektu. Nejčastěji se používá síťový graf zobrazený jako Ganttův diagram.  Odhad nákladů na úkol a vypracování rozpočtu projektu. Slouží jako podrobnější doplnění WBS.


21

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

22


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ů: 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.

2.3 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í.


23

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

24


Je to báze dat ve spojení se systémem řízení báze dat. 2.3.1

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. 2.3.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é.


25

 BCNF – Boyce Coddova normální forma 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.

2.4 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: 2.4.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 2.4.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í:

26


 Výběrové dotazy  Křížové dotazy  Akční dotazy  Dotazy SQL 2.4.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. 2.4.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ů. 2.4.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í. 2.4.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í.


27

3 Analýza současného stavu projektového řízení 3.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ě 350 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.

3.2 Prostředí firmy 3.2.1

Vnější prostředí

1.

Trhy

2.

Firma dodává na celosvětový trh, většina produktů je určena pro evropský trh. Identifikace zákazníků Firma nedodává produkty na volný trh, produkty jsou výhradně určeny pro koncernové zákazníky.

3.


28


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


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

5.

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


3.2.2

29

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 kterou 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č. Vlivem následného pozitivního stavu na trhu manipulační techniky roste i stav hospodaření firmy. V roce 2012 dosáhla firma zisku přibližně 150 mil. Kč. Roční obrat firmy se pohybuje přibližně okolo 2-2,5 miliardy Kč. 2.

Organizační struktura podniku (obr. 4)

Ředitelství

Služby

Výroba

Vývoj

Odbyt / disponenti

Technologie

Konstrukce

Výroba

Odbyt / disponenti

Základní vývoj

Nákup

Nákup

Obr. 4

Výroba, linka 7

Informatika, organizace.

Výroba, linka 5

Organizační struktura podniku

Zdroj: JULI Motorenwerk, 2013.

3.

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

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

Expedice, příjem zboží

Výroba, linka 1

Ekonomika

Výroba, linka 6

Sledování kvality

30


 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ěrové zatížení firmy  Omezení rozhodovacích práv  Nejednotný způsob projektového řízení  Malá spolupráce s vysokými školami 3.2.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). 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 projektového řízení.

Hrozby (Threats)

Zdroj: Vlastní tvorba


31

3.3 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. 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. Konstrukci přípravků zadává technolog konstruktérovi přípravků, který pak zajišťuje také samotnou výrobu přípravků. 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.:

3.

 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í záležitosti spojené se zajišťováním dílců (zejména objednávání a hlídání dodávek dílců) 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.

32


 Řešení projektu se zákazníkem. Vedení samotného projektu je v současné době nejednotné a je tedy na každém vedoucím projektu, jakým způsobem jej provádí. U většiny projektů jsou důležitá data uložena na počítačích vedoucích projektů, u některých projektů jsou již uloženy v novém databázovém systému Juli Projekt Manager. Zatím zde nejsou data od všech projektů a to z toho důvodu, že na některých počítačích není dostupný software Access 2010, nebo jeho Runtime modul, nezbytný ke spuštění databázového systému Juli Projekt Manager. Orientační termínový plán projektu se provádí většinou na začátku projektu (jsou projekty, u kterých se ani základní plánování neprovádí). Jeho evidence je ale nejednotná, týká se jen základních časových milníků a bývá většinou v některém MS Office souboru. V průběhu vývoje projektu, kdy dochází ke změnám tohoto časového plánu, se tyto změny systematicky neevidují, tudíž pak je aktuální časový plán znám jen vedoucímu projektu, který ho často navíc musí dohledávat např. v elektronické poště. Zápisy z porad vývojových teamů provádí většinou vedoucí projektu. Ty bývají prováděny v MS Excel, po jejich zapsání bývají posílány elektronickou poštou účastníkům porad. Kontrola úkolů přidělených na poradách se většinou neprovádí. Důležité je ještě rozlišit, která data je možno do současného softwaru Juli Projekt Manager uložit. Tento databázový systém umožňuje uložit data vztahující se k samotnému produktu, jako jsou zejména technické parametry. Ohledně dat vztahujících se k projektu umožňuje Juli Projekt Manager uložit pouze základní data, jako jsou např. členové projektového teamu, zákazníci atd. Neumožňuje ale pokročilejší funkce, jako je např. evidence úkolů stanovených na poradách.

3.4 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 řízení. 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í.

Analýza současného stavu projektového řízení Tab. 3

33

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 1335 240 303 250 542


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 13 3 9 8 7


3.5 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:  Juli Projekt Manager (obr. 5) Jedná se o databázový systém, který umožňuje ukládat základní informace týkající se ukončených a aktuálně probíhajících projektů. Tyto informace spravuje a dále za ně odpovídá oddělení konstrukce. Dále by zde měli být uvedeny všechny podstatné parametry týkající se produktů. Tyto informace zakládá oddělení základního vývoje a dále je také spravuje. Tento software je uložený na síťovém serveru a je tedy dostupný všem uživatelům, pro které byl vytvořen účet pro přístup do něj. Mezi základní okruhy dat, které tento software umožňuje uchovávat, patří:

34


 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 Z podrobnějšího rozboru vyplývá, že je v tomto softwaru možné spravovat více než 220 atributů ke každému projektu. Tento software umožňuje:  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ů Jedná se o databázový systém navrhnutý a vytvořený autorem této diplomové práce. Tento databázový systém byl také předmětem bakalářské práce autora (Paulík, 2011). Databázový systém byl vytvořen v softwaru Microsoft Access (příloha C). Jedná se o 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). Základní důvody pro volbu tohoto softwaru:  Cena (cca 3500 Kč za licenci).  Software je již ve firmě dostupný.  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.


Obr. 5

35

Juli Projekt Manager


 Správa odpracovaných hodin na projektech (obr. 6) Jedná se pouze o pomocný software, který umožňuje evidovat odpracované hodiny na jednotlivých projektech. Pomocí této evidence mají vedoucí jednotlivých oddělení představu o vytížení pracovníků. Dále je software důležitý z ekonomického hlediska, protože v případě, že se projekt nerealizuje, je možné vyčíslit náklady na vývoj projektu, na kterých se pak podílí zákazník. Tento software je ve firmě již déle než pět let.

36


Obr. 6

Správa odpracovaných hodin na projektech


 Microsoft Project Jedná se o profesionální software určený pro řízení projektů. Tento software má firma zakoupený již několik let, ale pro řízení projektů se používá zřídka. Software byl firmou sice zakoupen za účelem podpory řízení projektů, ale zaměstnanci nebyli zaškoleni na jeho používání, tudíž ho po pár prvních, nezdařených pokusech práce s ním přestali používat. Mezi další důležitý software používaný pro vývoj nových produktů a úzce související s projektovým řízením ve firmě patří:  AS/400 ISeries (obr. 7) – software kategorie ERP Hlavní podnikový informační 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ů.


Obr. 7

37

AS/400 Iseries


 Teamcenter (obr. 8) – 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.

38


Obr. 8

Teamcenter


3.6 Zhodnocení provedené analýzy 3.6.1

Z ekonomického hlediska

Jako podpora projektového řízení slouží zejména databázový systém Juli Projekt Manager. Protože se jedná o vlastní vytvořený 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 byly 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ěstnance v době vypracování tohoto softwaru byla 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. V tab. 5 jsou uvedeny náklady na vývoj první fáze softwaru Juli Projekt Manager.

Analýza současného stavu projektového řízení Tab. 5

39

Náklady na vývoj první části Juli Projekt Manager

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

Částka[Kč] 03500 00750 93800 98050


Celkové náklady vynaložené s tvorbou softwaru pro správu dat tedy činí přibližně 98050Kč. Vytvořený databázový systém pro jednotnou správu dat 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ý. Následující tab. 6 zobrazuje časovou úsporu při mzdách a stavu zaměstnanců v době vytvoření první fáze Juli Projekt Manageru. Tab. 6

Předpokládané úspory spojené s vytvořením první fáze Juli Projekt Manageru.

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

Předpokládaná návratnost zavedení první fáze Juli Projekt Manageru je přibližně 64 dnů.

40

3.6.2


Z technického hlediska

Současný stav projektového řízení ukazuje, že vedení projektů není jednotné a je závislé zejména na vedoucím projektu. Do plánu se uvádějí pouze základní časové milníky. V průběhu projekty, kdy dochází ke změnám plánu, se tyto změny systematicky neevidují, takže aktuální plán je pak znám pouze vedoucímu projektu. Stejný stav je i se zápisy z porad, jejichž evidence je nejednotná, kontrola úkolů stanovených na poradách se většinou neprovádí a předpokládá se jejich splnění, ke kterému ovšem ne vždy dochází. Během posledních dvou let se podařilo vyřešit správu základních informací k projektu a správu všech podstatných informací k produktu, kdy byl do firmy zaveden nový databázový software Juli Projekt Manager, který toto umožňuje. Tento software ale neumožňuje v současnosti pokročilejší funkce projektového řízení, jako jsou například zápisy z porad, přehledná kontrola splněných úkolů, atd. Jedná se o software, který byl vyvinut přímo ve firmě Juli Motorenwerk s.r.o., tudíž v případě potřeby je možné ho modifikovat a doplňovat. Současným problémem je také zatím nedostupnost tohoto softwaru na počítačích všech uživatelů.

3.7 Doporučení plynoucí z provedené analýzy Na základě provedené analýzy firmy se ukazuje jako největší současný problém nejednotné vedení projektů jednotlivými vedoucími. Závěry plynoucí ze SWOT analýzy doporučují jako jednu z možností zavedení nového způsobu projektového řízení. Jako nové řešení se tedy naskytuje sloučení těchto dvou aspektů, kdy návrh nového řešení projektového řízení bude proveden jako vypracování jednotné metodiky vedení jednotlivých projektů. Tímto návrhem se bude zabývat zbývající část této práce.


41

4 Návrh specifické implementace projektového řízení 4.1 Požadavky kladené na nové řešení Na tvorbu nového řešení jsou kladeny základní dva požadavky: 1.

2.

Respektování metodiky projektového řízení. Důvodem tohoto požadavku je, aby se nevynalézalo nějaké nové řešení, když již existuje osvědčená metodika projektového řízení. Pokud možno používání dostupného softwaru ve firmě. Tento požadavek je zejména z ekonomického důvodu, aby se nemusel pořizovat nový, zejména finančně náročný software, který by mimo pořizovacích nákladů byl spojený i se zaškolením zaměstnanců na nový software.

4.2 Vývojová stádia projektu Před vlastním návrhem specifické metodiky je nutno definovat možná výrobní stádia, ve kterých se může projekt nalézat. 1.

Funkční vzorek Konstrukce produktu v tomto stádiu nemusí a většinou ani neodpovídá žádanému sériovému stavu. Důvod je většinou ten, že sériový tvar není ještě znám. U funkčního vzorku je důležité, aby byl použit elektromagnetický obvod, zamýšlený pro sériovou produkci. Produkty v tomto výrobním stádiu používá zákazník pro účely, kdy produkt testuje v laboratoři, jestli jsou jeho výkonové parametry odpovídající. Druhým důvodem je pak zástavba do vozíku, kdy sám zákazník si konstrukci produktu upravuje pro první zástavbu do vozíku.

2.

Prototyp

3.

Konstrukce produktu v tomto výrobním stádiu by již měla odpovídat sériovému stavu. Základním rysem tohoto výrobního stádia je to, že komponenty, které jsou použity pro výrobu produktu, odpovídají zamýšlenému konečnému stavu, nejsou ale vyrobeny sériovou technologií, nýbrž technologií tzv. rapid prototyping. Tato technologie se vyznačuje tím, že komponenta může být vyrobena ve velice krátké době, je ale deseti i vícenásobně dražší. Produkt je následně vyroben nejčastěji v prototypové dílně, nikoli na sériové lince. Pilotní série Produkty, které jsou ve stádiu pilotní série, se vyznačují tím, že odpovídají zamýšlenému sériovému stavu konstrukce. Komponenty, nutné pro výrobu

42


4.

takového produktu, jsou vyrobeny také sériovou technologií, ale vlastní výroba produktu ještě neprobíhá na sériové lince, nýbrž v prototypové dílně. Nultá série

5.

Produkt v tomto výrobním stavu plně odpovídá zamýšlené sériové konstrukci, komponenty pro tento produkt jsou vyrobeny sériovou technologií a i vlastní výroba produktu probíhá již na sériové lince. Takto vyrobený produkt je určen pro poslední testování produktu před jeho uvedením do série. Koordinace výroby takového produktu je pro toto výrobní stádium a pro všechna předchozí výrobní stádia v režii projektového teamu. Série Konstrukce produktu i komponenty pro jeho výrobu mají finální podobu a výroba produktu probíhá na sériové lince. O výrobu produktu v sériovém stádiu se již nestará projektový team, ale výroba je již plně zprocesovaná. Nákup komponent zajišťuje oddělení dispozice, které od oddělení nákupu dostalo kompletní nákupní podmínky. Výrobu produktu zajišťuje oddělení výroby, které má k dispozici kompletní uvolněnou dokumentaci vypracovanou oddělením konstrukce a dále kompletní technologické postupy, vypracované oddělením technologie. Sériová výroba tedy musí probíhat bez jakýchkoli problémů. Jejím cílem je rychlá a levná výroba.

4.3 Návrh jednotného plánu projektu Projekt vývoje produktu je možno rozdělit na čtyři základní stádia. Prvním je zahájení projektu, ve kterém přichází první impuls od zákazníka na vývoj nového produktu, tvoří se projektový team a firma se seznamuje s projektem. Ve druhém stádiu se provádí stanovení základních parametrů projektu oddělením základního vývoje, které se u většiny produktů v průběhu projektu dále nemění. Ve třetím stádiu dochází k vlastnímu vývoji a ověření produktu a to jak ve firmě, tak u zákazníka. Čtvrtým stádiem je pak ukončení projektu, kdy je vývoj projektu ukončen a výroba produktů přechází plně na oddělení výroby, které dostává od projektového teamu kompletní podklady nutné pro hladkou, sériovou výrobu produktů. Časově nejnáročnější je třetí stádium, kdy dochází k vlastnímu vývoji produktu. Projekt zde může procházet čtyřmi na sebe navazujícími stádii (funkční vzorek, prototyp, nultá série, pilotní série), která si jsou navzájem podobná. 4.3.1

Hierarchický rozpad činností – WBS

V současnosti neexistuje ve firmě jednotný, vzorový plán projektu, který by obsahoval všechny podstatné činnosti nutné k úspěšnému zvládnutí projektu.


43

Každý vedoucí projektu si projekty řídí ad-hoc, a často a opakovaně se pak zapomíná na důležité činnosti, které musí být při vedení projektu provedeny. V textu níže je rozepsán návrh jednotného, hierarchického rozpadu činností. Za dílčími činnostmi je vždy v závorce uvedený průměrný čas trvání konkrétní činnosti. V případě konstrukčně ověřovací fáze je hierarchický rozpad činností proveden odděleně. Důvodem tohoto odděleného WBS je stejná struktura dílčích činností, které se ale pro jednotlivá stádia liší délkou trvání. Návrh hierarchického rozpadu činností pak vypadá následovně: 1.

2.

3.

4.

zahájení projektu 1.1. požadavek zákazníka na vývoj projektu (0) 1.2. seznámení vedení firmy s projektem (4) 1.3. volba projektového teamu (1) 1.4. seznámení projektového teamu s projektem (3) 1.5. definice rizik projektu (2) stanovení základních parametrů produktu 2.1. definice potřeb zákazníka (2) 2.2. návrh elektrických parametrů produktu (3) 2.3. zaslání základních parametrů zákazníkovi (1) 2.4. nalezení shody se zákazníkem (2) konstrukčně ověřovací fáze 3.1. funkční vzorky 3.2. prototypy 3.3. pilotní série 3.4. nultá série ukončení projektu

4.1. uvolnění dílců (5) 4.2. zavedení produktu do kalkulací (5) 4.3. ukončení projektu (0) Jednotlivé konstrukčně ověřovací fáze se vyznačují tím, že jsou jejich hierarchické rozpady činností stejné a liší se pouze dobou trvání jednotlivých úkolů. Doby trvání jednotlivých činností jsou uvedeny za každým dílčím úkolem. Postupně je vždy v závorce nejprve uvedena doba trvání funkčního vzorku, prototypu, pilotní série a nulté série. Hierarchický rozpad činností pro jednotlivá stádia konstrukčně ověřovací fáze: 1.

definice zástavby a připojovacích rozměrů od zákazníka (5, 10,20,5)

2.

zahájení procesu vývoje a dodávky produktů 2.1. porada vývojového teamu (1, 1, 1, 1)

44

3.

4.


vyhotovení 3d konstrukce 3.1. vyhotovení konstrukce (10, 15, 15, 5) 3.2. nalezení shody ve firmě – velký vývojový pohovor (1, 1, 1, 1) 3.3. úprava řešení (5, 5, 5, 1) nalezení konstrukční shody se zákazníkem 4.1. zaslání konstrukce zákazníkovi (1, 1, 1, 1) 4.2. nalezení shody se zákazníkem (5, 5, 5, 5)

5.

mechanické výpočty navrhnutého řešení 5.1. stanovení okrajových podmínek a zatížení kontrolovaných dílců konzultace se zákazníkem (0, 2, 2, 1) 5.2. volba dílců nutných pro podrobení kontrolním výpočtům mech. návrhu (0, 1, 1, 1) 5.3. provedení kontrolních výpočtů (0, 8, 8, 1)

6.

nalezení shody kontrolních výpočtů se zákazníkem 6.1. zaslání vypočtených výsledků zákazníkovi (0, 1, 1, 1) 6.2. nalezení shody se zákazníkem (0, 5, 5, 1)

7. 8. 9.

vyhotovení 2d konstrukční dokumentace (15, 15, 15, 5) tvorba kusovníků (2, 2, 2, 1) balení 9.1. návrh balení 9.1.1. navrhnout balení (0, 0, 5, 0) 9.1.2. odsouhlasení balení ve firmě (0, 0, 1, 0) 9.2. nalezení shody balení se zákazníkem 9.2.1. zaslání balení zákazníkovi (0, 0, 1, 0)

10. 11.

12.

9.2.2. nalezení shody se zákazníkem (0, 0, 3, 0) 9.3. dodání balení 9.3.1. zaslání objednávky na balení od zákazníka (0, 0, 5, 0) 9.3.2. objednání balení u dodavatele (0, 0, 1, 0) 9.3.3. dodání balení do Juli (0, 0, 20, 0) odstranění neaktuálních existujících dílců ze skladů (0, 2, 2, 2) tvorba technologických postupů montáže 11.1. vytvoření technologických postupů montáže (1, 2, 6, 2) 11.2. nalezení shody v Juli (0, 1, 1, 1) FMEA analýza 12.1. FMEA analýza (0, 5, 0, 0)


13.

14.

15.

16.

45

12.2. úprava dokumentace dle FMEA analýzy (0, 2, 0, 0) nacenění komponent řešení 13.1. předání dokumentace na poptání (1, 1, 1, 0) 13.2. poptání dílců (5, 10, 15, 0) 13.3. uzavření nabídek (1, 1, 1, 0) 13.4. vyhodnocení nabídek a výběr dodavatele (1, 1, 5, 0) kalkulace řečení 14.1. příprava kalkulace oddělením konstrukce (1, 2, 3, 2) 14.2. doplnění oddělením nákupu (1, 2, 5, 2) 14.3. doplnění oddělením technologie (1, 2, 5, 2) 14.4. uzavření kalkulace (1, 1, 1, 1) nalezení cenové shody produktu se zákazníkem 15.1. zaslání cenové nabídky produktu a modelového zařízení zákazníkovi (1, 1, 1, 1) 15.2. nalezení shody se zákazníkem (1, 1, 5, 5) dodání modelového zařízení a komponent 16.1. zaslání objednávky produktů a modelového zařízení od zákazníka (5, 5, 5, 0) 16.2. objednání modelového zařízení a vzorků (2, 2, 2, 0) 16.3. dodání modelového zařízení a vzorků (25, 25, 60, 0) 16.4. kontrola vzorků (5, 5, 5, 0) 16.5. úprava modelového zařízení a dodání nových vzorků (0, 0, 20, 0) 16.6. kontrola vzorků (0, 0, 5, 0) 16.7. objednání komponent (0, 0, 1, 0)

18.

16.8. dodávka komponent do Juli (0, 0, 20, 0) 16.9. kontrola dodaných komponent (0, 0, 5, 0) výroba a dodání produktů 17.1. vystavení výrobní dokumentace pro výrobu produktů v Juli (2, 2, 2, 2) 17.2. výroba produktů v Juli (5, 10, 10, 10) 17.3. zkoušení produktů v Juli (1, 3, 3, 1) 17.4. balení a expedice produktů z Juli (1, 1, 1, 1) zhodnocení daného řešení v Juli

19.

18.1. porada vývojového teamu (1, 1, 1, 1) zhodnocení daného řešení zákazníkem

17.

46


19.1. zpráva od zákazníka o dodaném řešení, souhlas s řešením resp. návrh úprav (5, 5, 5, 5)

4.3.2

Plán projektu

Pro vlastní naplánování projektu byl zvolen software Microsoft Project. Je to software, který je ve firmě dostupný, doposud však nepoužívaný. Jako konkrétní metoda plánování je zvolena metoda CPM (critical path method). Tato metoda dostala přednost před dokonalejší metodou PERT. Důvodem volby metody CPM je její jednoduchost oproti metodě PERT a z ní vyplývající rychlejší naplánování projektu. Metoda PERT je vhodnější spíše pro složitější projekty většího rozsahu. Ve firmě Juli Motorenwerk s.r.o. se jedná spíše o projekty menšího rozsahu, kdy navíc jeden vedoucí projektu je zodpovědný za více projektů. Při průběhu zpracování projektů dochází velmi často ke změnám plánu. V takovém to případě by přeplánování projektů bylo časově náročnější, což by při plném vytížení zaměstnanců bylo nežádoucí. Dalším důvodem nepoužití metody PERT je fakt, že při stanovení vzorového plánu projektu by se odhad pesimistického a optimistického času zřejmě prováděl vzhledem k času nejpravděpodobnějšímu předpokládanému. Protože i tento čas je časem předpokládaným, tedy odhadnutým, pak stanovení optimistického a pesimistického času by prakticky znamenalo odhad z již provedeného odhadu. Tedy přesnost optimistického a pesimistického času by nebyla příliš vysoká. Na následujících dvou obrázcích je zobrazen průběh začátku (obr. 9) a konce (obr. 10) projektu v softwaru Microsoft Project. Průběh celého projektu je z důvodu velkého rozsahu projektu uveden v příloze A této diplomové práce.


Obr. 9

Začátek plánu projektu


47

48


Obr. 10

Konec plánu projektu


Jednotlivé fáze projektu jsou vždy v Microsoft Project ohraničeny milníky zahájení fáze projektu a ukončení fáze projektu. Milníkem se v projektovém řízení označuje činnost, která trvá nulovou dobu. Na těchto milnících vždy jednotlivá fáze projektu začíná, respektive končí. Použití těchto milníků má velký význam při případné úpravě plánu projektu. Pokud například zákazník vyžaduje zkrácení projektu, které by bylo spojeno s vynecháním některé z fází projektu, znamená to smazání dané fáze z projektového plánu. Milníky zde pak hrají důležitou roli při zadávání závislostí mezi úkoly. Na ukončení fáze projektu vždy totiž navazuje zahájení následující fáze projektu. Tedy při odstranění některé fáze projektu se uživatel nemusí zabývat složitými závislostmi jednotlivých činností, ale závislosti volí podle předem dané systematiky tvorby jednotného výchozího plánu. Z vypracovaného návrhu jednotného plánu vyplívají následující časy trvání projektu: 1. projekt: 619 dnů 1.1. zahájení projektu: 10 dnů 1.2. stanovení základních parametrů produktu: 8 dnů 1.3. konstrukčně ověřovací fáze: 591 dnů 1.3.1. funkční vzorky: 108 dnů 1.3.2. prototypy: 157 dnů


49

1.3.3. pilotní série: 267 dnů 1.3.4. nultá série: 59 dnů 1.4. ukončení projektu: 10 dnů Uvedené časy znamenají průměrné časy trvání jednotlivých částí projektu pro případ, že se realizují všechny výrobní fáze.

4.4 Organizační struktura podniku podle dělby pravomoci mezi organizačními jednotkami Z hlediska dělby pravomoci je ve firmě Juli Motorenwerk s.r.o. použita pseudomaticová řídící struktura. Její schéma je znázorněno na následujícím obr. 11.

Obr. 11

Pseudomaticová řídící struktura ve firmě Juli Motorenwerk s.r.o.

Vzhledem k menšímu rozsahu projektů ve firmě je to vhodně zvolená řídící struktura.

4.5 Návrh implementační fáze projektu Po naplánování projektu následuje vlastní implementace projektu, která je spojená s kontrolou stanoveného plánu. Správně prováděná kontrola je nezbytná pro úspěšný průběh projektu. Proces kontroly průběhu projektu by měl být nastaven tak, aby řešil současné problémy související s nastavením řídící struktury ve firmě, tedy problémy vyplývající zejména z pseudomaticové řídící struktury. Největším problémem pseudomaticové řídící struktury je to, že jeden zaměstnanec oddělení podílejícího se na projektu je podřízený dvěma vedoucím.

50


První je liniový vedoucí oddělení a druhý je vedoucí projektu. Liniový vedoucí oddělení v Juli je osoba, která má skutečné pravomoci vedoucího, tedy zadává podřízeným úkoly, kontroluje jejich průběh a rozhoduje o platu podřízených. Naproti tomu vedoucí projektu zadává úkoly související s projektem, kontroluje jejich plnění, ale žádným způsobem se nepodílí na hodnocení člena teamu, protože projektové prémie určuje ředitel firmy, který zohledňuje náročnost projektu, ale nezohledňuje plnění úkolů jednotlivých zaměstnanců podílejících se na projektech. Každý zaměstnanec účastnící se projektu dostává tedy dva rozdílné typy úkolů. Jedna část úkolů souvisí s chodem oddělení na kterém pracuje, a druhá část úkolů souvisí s projekty, na nichž se podílí. Problémy tedy nastávají, když má zaměstnanec současně plnit úkoly týkající se oddělení i projektů. Protože úkoly na projektech, ani úkoly související s chodem jednotlivých oddělení nejsou nikde přehledně evidovány, dochází k takovým situacím velice často. V těchto případech zaměstnanec většinou plní přednostně úkoly související s oddělením, protože jak již bylo dříve řečeno vedoucí oddělení je ten, kdo rozhoduje o platu zaměstnance a teprve pak se věnuje úkolům spojených s projekty. Takto tedy dochází velice často ke zpoždění průběhu projektu, způsobeném nesplněním některého z dílčích úkolů. Vedoucí projektů o problémech samozřejmě vědí, ale z kolegiálních důvodů většinou tyto problémy s vedoucími oddělení neřeší, takže informace o tom, že dochází k problémům s plněním časového plánu projektu, se k vedoucím oddělení dostává až v případech stížností zákazníků u vedoucích. Dalším problémem je účast jednoho zaměstnance na více projektech současně. Běžně zaměstnanec pracuje na deseti projektech současně. V takovém případě je i pro samotného zaměstnance velice obtížné, aby neztratil přehled o současných úkolech, které má splnit a také o tom, aby si dokázal sám jednotlivé úkoly správně naplánovat. Z výše uvedeného tedy vyplývají následující požadavky na návrh řešení kontrolní fáze projektu:  přehledná evidence úkolů jednotlivých pracovníků k jednotlivým projektům  přehledná evidence úkolů jednotlivých pracovníků ke všem současně řešeným projektům  přehledná evidence úkolů všech úkolů vztahující se k jednotlivým projektům  přehledná evidence všech úkolů, které mají být řešeny pracovníky na daném oddělení, sloužící jako podklad pro liniové vedoucí Tyto všechny požadavky musí být současně splněny s podmínkou jednoduché, časově nenáročné evidence úkolů. Pro sledování jednotlivých úkolů z několika různých hledisek je nutné využití výpočetní techniky. Jednotný plán projektu je provedený software Microsoft Project. Přestože tento software umožňuje i kontrolu stanoveného plánu, tzv. směrného plánu, tak s ohledem na výše uvedené požadavky není dostatečný pro


51

kontrolu plánů všech projektů. Pro splnění výše uvedených požadavků nestačí ani využití tabulkových procesorů, ale je nutné vytvoření vhodného databázového softwaru. Pro realizaci řešení je vhodné použít doplnění stávajícího databázového softwaru Juli Projekt Manager. Tímto způsobem se dosáhne toho, že správa dat k produktům i správa dat k projektům bude v jednom programu.

52


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

Obr. 12

Entitně-relační model



53

Entitně-relační model (obr. 12) 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  Body porad  Nářadí 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. 13.

Obr. 13

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

54


5 Návrh softwaru projektového řízení Následující řešení bylo vytvořeno na platformě Windows 7. Základní předpoklady na hardware jsou: CPU Intel I3, 1GB operační paměti. Tvorba databázového systému se skládá z dvou základních kroků:  Tvorba báze dat, neboli tvorba relačního modelu.  Tvorba systému řízení báze dat. První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. Druhým krokem tvorby databáze je systém řízení báze dat, který zahrnuje tvorbu formulářů, dotazů, tiskových sestav a maker. Pro uživatelsky příjemné ovládání databázového systému jsou použity programové moduly Visual Basic.

5.1

Tvorba relačního modelu

Každý relační model sestávající se z tabulek vzájemně propojených relacemi je základ každého databázového systému. Relační model tohoto databázového systému jsem vytvářel ve spolupráci s liniovými vedoucími jednotlivých oddělení, nejčastěji s vedoucím konstrukce. Jejich úloha spočívala v definování potřebných atributů, které je pro projektové řízení nutno spravovat. Relační model se skládá z 69 tabulek, ve kterých je přibližně 310 atributů. Z důvodu velkého rozsahu relačního modelu je níže uveden pouze relační model základní kostry databáze. Celý relační model je po jednotlivých logických blocích uveden v příloze B této diplomové práce. Protože relační model vychází z entitně relačního modelu, tvoří i jeho kostru následujících 6 tabulek (obr. 14):  Tab_projektova_skupina  Tab_projekty  dbo_INP35  Tab_vyp_list  Tab_body  Tab_wz


Obr. 14

55

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


Tabulky jsou mezi sebou propojeny vhodnými relacemi, u všech relací je nastavena referenční integrita. Relace M:N jsou vytvořeny pomocí propojovacích tabulek, např. pomocí Tab_propoj_projekt_juli_nr. Některá data potřebná pro databázi jsou již součástí podnikového informačního systému. Aby se zabránilo duplicitě těchto dat, jsou tyto data importována z podnikového informačního systému. V bázi dat jsou čtyři takové tabulky. Název těchto tabulek vždy začíná dbo. Tato syntaxe je zvolena z důvodu stejného názvu tabulky v podnikovém informačním systému. Vytvořením relačního modelu je hotova báze dat, která je použita v ostatních částech databázového systému.

56


5.2 Tvorba systému řízení báze dat Systém řízení báze dat je programové vybavení, které umožňuje uživateli práci s uloženými daty. Současný systém řízení báze dat tvoří:  14 dotazů V databázovém systému jsou použity výběrové a křížové dotazy. V pomocném databázovém systému, který zajišťuje synchronizaci dat s podnikovým informačním systémem, jsou použity vytvářecí, přidávací a aktualizační dotazy.  105 formulářů Formuláře jsou nejpoužívanější nástroj databáze. Existuje jeden hlavní formulář, který slouží jako hlavní přepínací panel. Tento se spouští automaticky po spuštění databáze. Z tohoto formuláře se spouštějí ostatní formuláře. Výběr formulářů je uveden v příloze D diplomové práce. Některé formuláře jsou použity jako podformuláře v jiných formulářích, nebo v tiskových sestavách.  6 tiskových sestav Tiskové sestavy slouží jako hlavní tisknutelný výstup z databáze. Data jsou před spuštěním tiskové sestavy nejdříve předpřipravena výběrovým dotazem. Následně je použit filtr, který filtruje data pro konkrétní položky. Z těchto dat je pak vytvořeny tiskové sestavy. Výběr tiskových sestav je uveden v příloze E diplomové práce.  1 makro Jedná se o automaticky spouštěné makro při startu databázového systému sloužící k evidenci logování do databázového systému.  1 programový modul V programovém modulu jsou vytvořeny funkce identifikace uživatele a jemu příslušnému oddělení.  105 ovládacích funkcí Tyto funkce jsou součástí formulářů a řídí chod programu např. při stisknutí tlačítka na formuláři, při zavedení formuláře atd. Pro práci s daty v tabulkách je použita metoda DAO umožňující přístup k datům.

5.3 Kompletní softwarové řešení Kompletní softwarové řešení není tvořeno pouze databázovým systémem, ale je tvořeno z více částí (obr. 15). Jak již bylo řečeno, část datového modelu využívá


57

data z podnikového informačního systému, tedy bylo potřeba připravit napojení na tento informační systém. Dále je řešení potřeba upravit tak, aby je mohli využívat i zaměstnanci na služebních cestách. Potřebná data jsou nejdříve z podnikového informačního systému přes ODBC rozhraní vyexportována do samostatného souboru. Dále jsou nová data naimportována do databázového systému a následně je provedena aktualizace stávajících dat. Tímto se dosáhne synchronizace dat s podnikovým informačním systémem. Pro spuštění databázového systému je vytvořen spouštěcí dávkový soubor, jehož hlavním úkolem je rozlišit, zda se databázový systém spouští na firemní síti, nebo jestli ho uživatel spouští pouze na lokálním počítači, např. na notebooku na služební cestě. V tomto případě databázový systém slouží pouze pro čtení. Pro databázový systém je dále vytvořen soubor pracovní skupiny, který umožňuje řízení uživatelských účtů, tedy nastavení přístupových práv uživatelů. Pro nastavení konkrétních přístupových práv jsou v tomto souboru vytvořeny skupiny odpovídající jednotlivým oddělením. Každý uživatel má právo čtení všech dat, ale právo zápisu a změn dat závisí na příslušnosti ke konkrétní skupině. Pro spuštění databázového systému je vytvořen zástupce spouštěcí dávky, který si uživatelé nakopírují na jejich počítač a z něj databázový systém spouštějí.

Obr. 15

Kompletní softwarové řešení


58


6 Popis navrženého řešení Po spuštění databázového systému a přihlášení uživatele se zobrazí hlavní formulář softwaru (obr. 16). Hlavní formulář navrženého softwaru je rozdělen do tří základních bloků:  Zakládání položek  Správa položek  Přehledy

Obr. 16

Hlavní formulář


V současnosti jsou přepínací tlačítka všech tří základních bloků umístěna na jednom formuláři. To umožňuje uživateli bez dalšího „proklikávání“ dostat se


59

okamžitě do cílové oblasti. Pokud by časem přibývali další položky na hlavním formuláři, bylo by nutné z důvodu přehlednosti umístit jednotlivé bloky do samostatných formulářů.

6.1 Zakládání položek Jak z názvu vyplývá, slouží tento blok pro zakládání nejrůznějších typů položek, přičemž je nutno říci, že ne všechny položky, které se v databázi vyskytují, jsou v tomto bloku uvedeny. Zde jsou uvedeny pouze položky, které se zakládají často a které mohou být zakládány různými uživateli. V databázi existuje mnoho dalších položek, které zakládá administrátor, a ty se zakládají z jiného umístění z důvodu větší přehlednosti. Přístup a údržba jednotlivých položek jsou ošetřeny přístupovými právy. Všechny položky jsou přístupny všem uživatelům pro čtení, ne však zakládání a údržba položek. Zakládání nových vozíků a projektů může provádět pouze vedoucí konstrukce, zakládání výpočtových listů může provádět pouze vedoucí předvývoje, zakládání nářadí může provádět pouze nákupčí atd. Přístupová práva jsou omezena z toho důvodu, že zakládání a základní informace k položkám jsou strategické záležitosti ve firmě, které provádí pouze určité osoby a není tedy důvod k tomu, aby měla kterákoliv jiná osoba možnost tyto data zakládat nebo je měnit.

6.2 Správa položek Blok správy položek je těžištěm projektového řízení. Jak uvádí literatura (Taylor, 2007), 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 jiný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 tedy nepracuje pouze projektový manager, ale spousta dalších zaměstnanců, kterými jsou např. členové projektového teamu, vedení firmy. Tento blok tedy umožňuje zprůhlednit projektové řízení všem zainteresovaným zaměstnancům. Z důvodu velkého počtu formulářů, které jsou v databázovém systému použity, zde uvedu pouze ty nejdůležitější, týkající se plánování a implementace projektového řízení. Na formuláři správa projektů (obr. 17) jsou přehledně uvedeny všechny informace týkající se konkrétních projektů, a dále jsou zde vytvořeny odkazy na jiné položky, které se k projektu vztahují (tedy po poklepání např. na číslo motoru se otevře formulář správy motorů, ve kterém jsou informace o motorech a dále odkazy na jiné položky vztahující se k motoru). Data zobrazená v tomto formuláři jsou buď data, která byla tímto formulářem vložena, nebo data, která byla vložena jiným formulářem, která jsou pro-

60


střednictvím datového modelu svázána s projektem. Takto můžou být vloženy například úkoly k projektu. Naplánování průběhu projektu, jak bylo uvedeno dříve, se provádí v softwaru Microsoft Project. Jednotlivé body plánu se pak zapisují do formuláře správy projektů na položce Plán projektu.

Obr. 17

Správa plánu projektu


Cílem není po naplánování projektu do této položky přepsat kompletní plán projektu, ale pouze hlavní milníky plánu. Jednotlivé body plánu se budou doplňovat postupně, v závislosti na blížícím se termínu bodu plánu. Přepsat na toto místo celý plán se všemi jednotlivými body nemá žádný význam, protože v průběhu každého projektu dochází k úpravě plánu. Změna jednoho bodu plánu znamená změnu celého zbytku plánu, který na tento bod navazuje. Pokud se tedy změní jeden bod plánu, provede Microsoft Project automaticky úpravu plánu, ale databázový systém Juli Projekt Manager tuto úpravu automaticky provést neumí a ani to není jeho cílem. Při změně plánu by vedoucí projektu vždy provedl jeho aktualizaci v MS Project. Dále v pravidelných intervalech, předpo-


61

kládám jednou za týden, by provedl aktualizaci plánu v Juli Projekt Manager. Tímto způsobem se zajistí na jedné straně prostor pro rychlou, časově nenáročnou změnu plánu, na druhé straně bude plán projektu uvedený v Juli Projekt Manager neustále aktuální a dostupný všem zaměstnancům. Úkoly, přiřazené jednotlivým členům projektového teamu v průběhu projektu, mohou vzniknout dvěma způsoby: 1.

Ad hoc úkoly Jsou to úkoly, které vznikají běžně v průběhu projektu ať již při osobním setkáním vedoucího projektu se členem teamu, telefonicky, nebo emailem. K požadavku vedoucího projektu by se měl člen teamu vždy vyjádřit, měl by se vždy vyjádřit také k požadovanému termínu. Po nalezení shody mezi vedoucím projektu a členem teamu vzniká úkol (může jít i o úkol, který stanoví vedoucí projektu sám sobě), který je bez řádné evidence nekontrolovatelný. Tento úkol se zapíše na formuláři správy projektů v záložce úkol. Na tomto formuláři nejsou viditelné všechny atributy, které se k danému úkolu vztahují, protože se by se sem nevešly. Při poklepání na identifikační číslo úkolu se otevře formulář, kde jsou již uvedeny všechny atributy.

2.

Úkoly přiřazené na poradách Zde se jedná zásadně o úkoly, které jsou přiřazeny na poradách projektového teamu. Stejně jako v prvním případě je nutno nejdříve nalézt shodu mezi vedoucím projektu a členem projektového teamu a teprve pak tento úkol řádně zaevidovat. Úkoly stanovené na poradě projektového teamu se zapisují ve formuláři zápis porady (obr. 18).

62


Obr. 18

Formulář zápisů porad


Ze zápisu porady je možné vygenerovat přehlednou tiskovou sestavu, jejíž podoba je uvedena v přílohách E diplomové práce. Ať již jsou úkoly zapsány prvním nebo druhým způsobem, jsou viditelné na formuláři správy projektu, seřazené chronologicky podle termínu splnění. Tímto je zajištěna přehledná evidence úkolů k danému projektu. Jak již bylo uvedeno dříve, každý vedoucí projektu a každý člen projektového teamu pracuje na několika projektech současně. V takovém případě je velice obtížné udržovat přehled úkolů, které mají být splněny. Pro účely zpřehlednění úkolů jednotlivých osob byl vytvořen formulář správy osob (obr. 19). Na tomto formuláři je jednak uvedeno, na kterých projektech se daná osoba podílí, dále za které úkoly a ve kterém termínu je odpovědná, a dále úkoly, které osoba sama zapsala, aby mohla jejich plnění přehledně kontrolovat. Obsah tohoto formuláře samozřejmě žádná osoba v tomto formuláři nevytváří, ale vzniká automaticky na základě relace mezi osobou a projekty, resp. úkoly.


Obr. 19

63

Formulář správy osob


Dalším významným faktorem řízení projektů, který vyplývá z pseudomaticové řídící struktury, je to, že každý člen teamu má dva vedoucí. Vedoucího oddělení a vedoucího projektu. Pokud neexistuje přehledná evidence úkolů osoby, dochází často ke konfliktům, kdy má jedna osoba plnit současně dva úkoly, jeden úkoly zadaný od vedoucího oddělení a druhý od vedoucího projektu. Dalším faktorem řízení projektů, který vyplývá z pseudomaticové řídící struktury bývá přetížení lidských zdrojů. Jedná se o příklad, kdy má osoba současně plnit dva úkoly. Jeden úkol zadaný vedoucím oddělení a druhý úkol vedoucím projektu. Řešením se opět naskýtá ve větší přehlednosti úkolů, které má plnit v tomto případě konkrétní oddělení. Z tohoto důvodu je vytvořený formulář spravující úkoly vztahující se k celému oddělení (obr. 20). Zde jsou zobrazeny všechny úkoly, za které je odpovědné konkrétní oddělení. Vytvoření takového formuláře umožňuje existence relace mezi osobou a oddělením. Tento formulář tedy umožňuje dvě důležité věci: 1.

Přehledná kontrola úkolů oddělení

64


Vedoucí oddělení může přehledně kontrolovat plnění úkolů, za které je zodpovědné jeho oddělení. Úkoly jsou opět řazeny chronologicky, tudíž vedoucí oddělení přesně ví, které úkoly mají být kdy splněny. 2.

Efektivní rozdělování úkolů souvisejících s chodem oddělení Vedoucí oddělení může efektivně rozdělovat úkoly související s chodem oddělení, protože zde vidí, jak je která osoba v danou dobu vytížena.

Obr. 20 Formulář úkolů konkrétního oddělení Zdroj: Vlastní tvorba

6.3 Přehledy Tento blok správy dat slouží pro zobrazení nejrůznějších přehledů, týkajících se jak projektů tak i produktů. Přehledy související s produkty jsou určeny jak pro běžné zaměstnance, tak i pro vedení podniku. Přehledy slouží pro přehledné třídění produktů podle nejrůznějších hledisek. Tyto přehledy jsou vytvořeny výběrovými dotazy. Přehledy související s projekty jsou spíše strategického charakteru a jsou určeny pro vedení firmy. První přehled zobrazuje počet projektů vyvíjených pro konkrétní koncern, na jehož vývoji 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ými dotazy.


65

7 Převoditelnost navrženého řešení do jiných firem Představený návrh řešení byl vytvořen pro firmu Juli Motorenwerk s.r.o. V této části textu se budu zabývat možnou převoditelností řešení i do jiných firem, jejichž předmětem podnikání nemusí být výroba motorů. Z analýzy entitně relačního diagramu vyplývá, že navržené řešení se dá rozdělit na dvě základní části. 1.

Část zabývající se čistě projektovým řízením Jedná se o část řešení vycházející z obecné metodiky projektového řízení. Je to tedy část, která je univerzální pro všechny firmy, které využívají projektového řízení. Tato část řešení je tedy použitelná i v jiných firmách.

2.

Část řešení odpovídající konkrétním potřebám firmy Toto je část řešení, která byla vytvořena čistě podle potřeb firmy Juli Motorenwerk s.r.o. Tato část by mohla být využita firmami, jejichž předmětem podnikání je výroba motorů, ale pro jiné firmy je nepoužitelná.

Tyto dvě části jsou spolu vzájemně propojeny relacemi. Druhou část řešení je možno dále rozdělit na část databázového systému zabývající se vozíky, dále část zabývající se motory a část zabývající se výpočtovými listy. Části řešení tedy tvoří jednotlivé moduly databázového systému (obr. 21). Tyto moduly je možno přehledně zobrazit v entitně relačním diagramu, viz obrázek níže. Odstranění modulu vozíku, modulu motoru a modulu výpočtového listu vede k databázovému sytému, které využívá pouze obecnou metodiku projektového řízení. Toto řešení by bylo možné použít i v jiných firmách, které projektové řízení používají. V případě potřeby jiných firem na správu specifických atributů podle předmětu jejich podnikání, by bylo nutné tyto moduly nově vytvořit. Praktickou realizaci převodu současného řešení i do jiných firem by bylo ale jistě výhodnější řešit jiným a to jednodušším způsobem. Odstranění modulu vozíku, modulu motoru a modulu výpočtového listu by na jedné straně bylo časově náročné, na druhé straně by se mohlo stát, že některý z modulů, nebo jeho část by mohla využít i jiná firma. Pokud by se nejdříve některý modul odstranil a teprve později by firma tento modul požadovala, bylo by obtížné tento modul z řešení jedné firmy přenést do řešení druhé firmy. Mnohem jednodušší a současně efektivnější způsob je žádné moduly neodstraňovat, ale nové moduly pouze přidávat. Pro daný databázový systém by to pak znamenalo následující opatření: 1. V případě back-end části databáze by zůstaly všechny tabulky a relace. Některé tabulky by se pouze neplnily daty. 2. V případě front-end části databáze by zůstaly všechny formuláře, dotazy, atd. pouze by jejich část byla nepřístupná.

66


Obr. 21

Moduly databázového systému Juli Projek Manager



67

8 Zhodnocení navrženého řešení 8.1 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 Project.  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ě 450 hodin. Hodinová sazba zaměstnance je 250Kč/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. V tab. 7 jsou uvedeny náklady na vývoj druhé softwaru Juli Projekt Manager. Tab. 7

Náklady na vývoj nového řešení

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

Částka[Kč] 014500 001100 150750 166350


Celkové náklady spojené s tvorbou nového řešení tedy činí 166350Kč. 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ý. Následující tab. 8 zobrazuje časovou úsporu při mzdách a stavu zaměstnanců v době vytvoření druhé fáze Juli Projekt Manageru.

68 Tab. 8

Zhodnocení navrženého řešení 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] 13 3 3 1 9 2 8 2 7 0,25

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

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

10 5 5 5 5

3,9 0,15 0,9 0,8 0,0875


Celková předpokládaná časová úspora firmy je tedy přibližně 5,84h/den. Úspora firmy při sazbě 250Kč/hod a při povinných odvodech 34% na zdravotní a sociální pojištění je tedy 1956,4Kč/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 166350   85dnů úspora 1956,4

Předpokládaná spojená se zavedením nového řešení je tedy 85 dnů.

8.2 Technické zhodnocení řešení Nejdříve je vypracován jednotný vzorový plán projektu v softwaru MS Projekt. Vypracování tohoto plánu umožňuje sladit požadavky firmy na vývoj projektu s požadavky zákazníka na termín dodání projektu. V případě kdy zákazník požaduje zkrácení doby projektu, umožňuje vzorový plán projektu úpravu tohoto plánu, respektive vynechání některých částí projektu, přímo zákazníkem. Vynechání jednotlivých částí projektu vždy zvyšuje pravděpodobnost, že se kvalita vyvíjeného produktu na úkor zkrácení času může zhoršovat. Čas na zpracování projektu a následná kvalita produktu jsou vždy dva protichůdné aspekty, tedy pokud se zkrátí čas na vývoj projektu, dá se očekávat zhoršení kvality vyvíjeného produktu, nebo je kladen vysoký důraz na kvalitu a pak je potřeba dostatek času na vývoj produktu, tedy na zpracování projektu. Pokud tedy zkrátí plán sám zákazník, přebírá takto na sebe části rizika za zhoršení kvality. Na základě vypracovaného vzorového plánu projektu vyplývá, že délka trvání „průměrného“ projektu je 619 pracovních dnů, což je přibližně 2,5 roku. Tato doba opravdu odpovídá délce trvání projektů ve firmě Juli Motorenwerk s.r.o.


69

Kontrola vlastního plánu projektu není prováděna v MS Projekt, nýbrž v databázovém systému Juli Projekt Manager sloužícího pro správu projektů. Tímto je zajištěno jednotné vedení projektů, přehledná evidence a kontrola plánu projektů, úkolů stanovených na projektech a nákladů souvisejících s projekty. Shrnutí přínosů, které přináší nové řešení:  Pružná tvorba plánu projektu vycházející z vypracovaného vzorového plánu projektu.  Přehledná evidence a kontrola plánu.  Snadná evidence úkolů.  Přehledná kontrola úkolů stanovených k projektům.  Přehledná kontrola úkolů stanovených konkrétním osobám.  Přehledná kontrola úkolů stanovených konkrétním oddělením.  Evidence nákladů spojených s projekty.

70

Diskuze

9 Diskuze Vlastní databázové řešení umožňující projektové řízení není ve firmách příliš obvyklé. Osobně spolupracuji s několika firmami, které patří do dvou velkých nadnárodních koncernů (Jungheinrich a Kion), a v obou firmách je správa projektů řešena pomocí kancelářských programů Excel a Word. V těchto případech většinou dojde časem k menší či větší nesystematičnosti vedení projektů, protože zde neexistuje společná báze dat, ve které jsou data uspořádána podle jasných pravidel, od kterých se nelze odchýlit. V těchto případech také vznikají problémy se systematickým tříděním dat, protože data jsou uložena v samostatných souborech a neexistuje tedy jednoduchá možnost jejich třídění. Další problém vzniká již jen se samotným dohledáváním dat, kdy jsou jednotlivé soubory uloženy v různých adresářových strukturách, které se dříve nebo později stanou nepřehledné. Pro správu projektů existují také komerčně prodávané programy, které ale nikdy nebudou pokrývat veškeré potřeby firem, protože jsou určeny širokému spektru firem. V těchto případech pak vždy musí firma řešit kompromis, co se zbývajícími daty. Řešením je pak většinou jejich ukládání opět do běžných kancelářských programů jako ve Word a Excel. Dalším řešením je možnost tvorby softwaru na míru od programátorských firem. Problémem v tomto případě jsou pak zaprvé vysoké náklady a za druhé to, že firma zabývající se projektovým řízením musí programátorské firmě přesně specifikovat vlastní požadavky na software. Tato specifikace je často největší problém, firma většinou není schopna počáteční požadavky specifikovat přesně a kompletně, tudíž dále následují různé úpravy softwaru. Tyto jsou opět finančně náročné a firma zabývající se projektovým řízením se pak na programátorské firmě stává závislá. Tvorba vlastního řešení se jeví z počátku možná obtížná z důvodu kladených požadavků na programovací znalosti pracovníků. Jak ale ukazuje tato diplomová práce je tento způsob realizovatelný a osobně bych jej doporučil i jiným firmám. Výhodou tohoto řešení je pak stoprocentní kontrola softwaru, možnost jeho libovolné úpravy a nepříliš vysoké náklady. Naopak největší nevýhodou je časová náročnost řešení, které je v porovnání s ostatními možnostmi časově nejnáročnější. Tento nedostatek se ale později vrátí právě s pružnou možností úpravy databázového systému.

9.1 Možné rozšíření databázového systému Současné řešení je po obsahové stránce velice rozsáhlé, přesto je možné identifikovat jeho další možná rozšíření. Mezi další možné rozšíření by mohlo patřit:

Diskuze

71

 Převedení back-end části databázového systému na Microsoft SQL Server. MS SQL Server je schopen snadněji obsloužit větší množství současně přihlášených uživatelů.  Synchronizace mezi databázovým systémem a softwarem MS Projekt.  Automatické zasílání informací o projektech zákazníkům, eventuálně přístup zákazníků přes internet do databázového systému.  Automatické vyhodnocování spolehlivosti člena teamu při ukončení projektu, které by sloužilo jako podklad pro jeho odměňování.

72

Závěr

10 Závěr Cílem této diplomové práce bylo navrhnout specifickou implementaci projektového řízení pro firmu JULI Motorenwerk s.r.o. Tohoto cíle bylo v zadaném rozsahu dosaženo. Navržené řešení odstraňuje nesystematičnost vedení projektů, zavádí vzorový, jednotný plán projektu a přehledným způsobem umožnuje jeho kontrolu tak, aby mohlo být splnění cíle projektu snáze dosaženo. Řešení bylo ve firmě několikrát konzultováno zejména s liniovým vedoucím konstrukce, který je hlavní osobou spravující projekty. Řešení bylo několikrát upraveno tak, aby odpovídalo požadavkům firmy. Autor vychází z bakalářské práce, ve které se zabýval správou dat vztahujících se zejména ke správě dat produktů, které se ve firmě vyrábějí.

10.1 Rekapitulace řešení Při vypracování této diplomové práce byla nejdříve provedena analýza současného stavu projektového řízení. Z analýzy vyplývá, že velkým problémem současného stavu je nejednotné vedení projektů jednotlivými vedoucími. Dále byla provedena SWOT analýza a její závěry doporučují, jako jednu z možností, zavedení nového způsobu projektového řízení. Za nové řešení tedy bylo zvoleno sloučení těchto dvou aspektů, kdy návrh nového řešení je proveden jako vypracování jednotné metodiky vedení jednotlivých projektů. Nové řešení se skládá ze dvou hlavních částí. První část se zabývá plánováním projektu. Nejprve je vypracován hierarchický rozpad činností, na jehož základě je vytvořen jednotný plán projektu. Jednotný plán projektu byl vytvořen v software MS Project, kde pro určení doby trvání činností a vzájemné závislosti projektu byla použita metoda CPM (critical path method). Druhá část řešení se zabývá implementací projektu. Tato část je řešena jako rozšíření dosavadního databázového systému Juli Projekt Manager. Tento software byl doposud využit pro správu dat k projektům, nově je tedy rozšířený o správu dat projektového řízení. Tento databázový systém byl vytvořen v softwaru Microsoft Access 2010, jeho základem je tedy relační databáze. Toto řešení umožňuje spravovat data k projektům, přehledně evidovat a kontrolovat plán projektu, úkoly spojené s projekty a náklady související s projekty. Dále byla provedena identifikace podmínek převoditelnosti navrženého řešení i do jiných firem využívajících projektové řízení.

10.2 Praktický přínos práce Nově navržené řešení je pro firmu přínosné z několika důvodů. Přehledný vzorový plán projektu nyní umožňuje firmě ve spolupráci se zákazníkem najít vhodný kompromis mezi dobou vývoje projektu a kvalitou pro-

Závěr

73

jektu. Vzorový plán projektu dále pomáhá předejít tomu, aby se v průběhu projektu nezapomněly naplánovat některé důležité úkoly. Správa projektů je nyní v jednotné, všem zaměstnancům dostupné formě. Protože každý zaměstnanec podílející se na projektovém řízení pracuje současně na více projektech, umožňuje nová správa projektů lepší přehlednost o projektech, o úkolech souvisejících s projekty. Vložená data je možné analyzovat prostřednictvím sql dotazů, které v případě většího objemu dat výrazně urychlují práci. Dotazy použité v databázovém systému je možné bez větších problémů upravovat a doplňovat, eventuálně nové dotazy v případě potřeby vytvořit. Protože je celé řešení vytvořené přímo ve firmě Juli Motorenwerk, není problém ho upravit, nebo v případě potřeby dále rozšiřovat a to bez výrazných vícenákladů, které by v případě zakoupení nového softwaru, nebo vývoje nového softwaru externí firmou, nepochybně vznikly.

74

Literatura

11 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. HELD, B. Access VBA: velká kniha řešení. 1. vydání. Brno: Computer Press, 2006. 639 s. ISBN 80-251-1112-1. 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. 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: 2011. 58 s. ROSENAU, M. Řízení projektů. Brno: Computer Press, 2007. 344 s. ISBN 978-80251-1506-0. SODOMKA, P. Informační systémy v podnikové praxi. Brno: Computer Press, 2006. 351 s. ISBN 80-251-1200-4. TAYLOR, J. Začínáme řídit projekty. Brno: Computer Press, 2007. 215 s. ISBN 978-80-251-1759-0. VÁGNER, I. Management z pohledu všeobecného a celostního. Brno: Masarykova univerzita v Brně, 2004. 607 s. ISBN 80-210-3536-6. VEBER, J. Management: základy, moderní manažerské přístupy, výkonnost a prosperita. Praha: Management Press, 2009. 734 s. ISBN 978-80-7261200-0.

Literatura

75

VODÁČEK, L., VODÁČKOVÁ, O. Moderní management v teorii a praxi. Praha: Management Press, 2009. 324 s. ISBN 978-80-7261-197-3.

76

Přílohy

Přílohy


A Vzorový plán projektu

Obr. 22 Plán projektu, první část Zdroj (u všech obrázků plánu projektu): Vlastní tvorba

Obr. 23 Plán projektu, druhá část

77

78


Obr. 24 Plán projektu, třetí část

Obr. 25 Plán projektu, čtvrtá část


Obr. 26 Plán projektu, pátá část

Obr. 27 Plán projektu, šestá část

79

80


Obr. 28 Plán projektu, sedmá část

Obr. 29 Plán projektu, osmá část


Obr. 30 Plán projektu, devátá část

Obr. 31

Plán projektu, desátá část

81

82


Obr. 32 Plán projektu, jedenáctá část

Obr. 33 Plán projektu, dvanáctá část


B Relační model databáze

Obr. 34 Relační model základní kostry Zdroj (u všech obrázků relační databáze): Vlastní tvorba

83

84


Obr. 35 Relační model vztahující se k projektové skupině


Obr. 36 Relační model vztahující se k projektu, první část

85

86


Obr. 37 Relační model vztahující se k projektu, druhá část


Obr. 38 Relační model vztahující se k motoru

87

88


Obr. 39 Relační model vztahující se k výpočtovému listu


Obr. 40 Relační model vztahující se k parametrům motoru

89

90


Obr. 41

Relační model vztahující se k bodům porad


Obr. 42 Relační model vztahující se k nářadí

91

92

Použitý software

C Použitý software

Obr. 43 Microsoft Access 2010 Zdroj: Vlastní tvorba

Obr. 44

Microsoft Visual Basic for Applications



D Výběr použitých formulářů

Obr. 45 Formulář správy vozíků Zdroj: Vlastní tvorba

Obr. 46 Formulář správy motorů Zdroj: Vlastní tvorba

93

94


Obr. 47 Formulář správy výpočtových listů Zdroj: Vlastní tvorba

Obr. 48 Formulář správy nářadí Zdroj: Vlastní tvorba


E Výběr použitých tiskových sestav

Obr. 49 První tiskové sestavy informací k projektu Zdroj: Vlastní tvorba

95

96


Obr. 50 Druhá strana tiskové sestavy informací k projektu Zdroj: Vlastní tvorba


Obr. 51

První strana tiskové sestavy informací k motoru


97

98


Obr. 52 Druhá strana tiskové sestavy informací k motoru Zdroj: Vlastní tvorba


Obr. 53 Tisková sestava zápisu z porady Zdroj: Vlastní tvorba

99

100


Obr. 54 Tisková sestava nastavení zkušebny Zdroj: Vlastní tvorba

Návrh projektového řízení ve firmě Juli Motorenwerk s.r.o

Recommend Documents