Řízení IT projektu podle metodiky PRINCE2

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

Řízení IT projektu podle metodiky PRINCE2 diplomová práce

Autor:

František Klimeš Informační technologie a management

Vedoucí práce:

Praha

Ing. Bc. Jiří Rezler

duben, 2014

Prohlášení: Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze, dne 30. 4. 2014

František Klimeš

Poděkování Děkuji mému vedoucímu práce panu Ing. Bc. Jiřímu Rezlerovi za odborné konzultace, pomoc, vstřícnost, čas a za další cenné rady při zpracování mé diplomové práce.

Anotace Diplomová práce má za úkol přiblíţit problematiku řízení IT projektů a vysvětlit širší veřejnosti fungování řízení projektů v praxi. Diplomová práce je rozdělena do čtyř větších tematických celků a kaţdá část blíţe vysvětluje danou problematiku. První část obecné problematiky řízení IT projektů má za úkol uvést problematiku. Druhá část má seznámit čtenáře s metodikou PRINCE2 a vysvětlit její podstatu a základní principy. Třetí část popisuje zadávací dokumentaci skutečného projektu, který byl řízen podle firemních zvyklostí. Poslední závěrečná kapitola popisuje reálný IT projekt tak, jak by vypadalo projektové řízení podle metodiky PRINCE2. Jinými slovy řečeno, kdyby se vyskytl další obdobný projekt, tak tato práce by mohla slouţit jako vzorový dokument.

Klíčová slova Metodika, IT projekt, PRINCE2, 3D měření.

Annotation This diploma thesis aims to approach the problem of managing IT projects and explain to the public the functioning of the management projects in practice. The thesis is divided into four major thematic groups and each section further clarifies the issue. The first part of the general problems of IT project management aims at providing the issue. The second part is to familiarize the reader with the PRINCE2 methodology and explain its essence and basic principles. The third section describes the specifications of the real project, which was controlled according to company practices. The conclusion part describes the real IT project as it would seem to project management methodology according to PRINCE2 methodology. In other words, if there were another similar project, this thesis could serve as a model document.

Key words Methodics, IT project, PRINCE2, 3D measuring.

Obsah Úvod ........................................................................................................................................... 8 1

Problematiky řízení IT projektů .......................................................................................... 9 1.1

Co je projekt................................................................................................................. 9

1.2

Historie....................................................................................................................... 11

1.3

Role na projektu ......................................................................................................... 12

1.3.1

Projektový manaţer ............................................................................................ 12

1.3.2

Zákazník ............................................................................................................. 13

1.3.3

Projektový tým ................................................................................................... 13

1.3.4

Investor ............................................................................................................... 14

1.3.5

Další účastníci .................................................................................................... 14

1.4

1.4.1

Zahájení projektu ................................................................................................ 16

1.4.2

Příprava............................................................................................................... 17

1.4.3

Konstrukce .......................................................................................................... 17

1.4.4

Předávání ............................................................................................................ 18

1.4.5

Vyřazení ............................................................................................................. 19

1.5

2

Ţivotní cyklus ............................................................................................................ 15

Vybrané techniky projektového řízení ....................................................................... 19

1.5.1

Ganttův diagram ................................................................................................. 19

1.5.2

Síťová analýza .................................................................................................... 20

Metodika PRINCE2 .......................................................................................................... 22 2.1

Seznámení .................................................................................................................. 22

2.2

Principy ...................................................................................................................... 23

2.2.1

Neustálé zdůvodňování opodstatnění ................................................................. 23

2.2.2

Učení z předchozích zkušeností ......................................................................... 24

2.2.3

Definování rolí a jejich odpovědností ................................................................ 24

2.2.4

Etapové řízení projektu....................................................................................... 24

2.2.5

Řízení na základě výjimek.................................................................................. 24

2.2.6

Produktové zaměření .......................................................................................... 25

2.2.7

Přizpůsobení řízení prostředí na projektu ........................................................... 25

2.3

Témata ....................................................................................................................... 25

2.3.1

Obchodní případ ................................................................................................. 25

2.3.2

Organizace .......................................................................................................... 26

5

2.3.3

Kvalita ................................................................................................................ 26

2.3.4

Plány ................................................................................................................... 27

2.3.5

Riziko ................................................................................................................. 27

2.3.6

Změna ................................................................................................................. 28

2.3.7

Progres ................................................................................................................ 29

2.4

2.4.1

Zahájení projektu ................................................................................................ 29

2.4.2

Směrování projektu............................................................................................. 30

2.4.3

Nastavení projektu .............................................................................................. 32

2.4.4

Kontrola etapy .................................................................................................... 33

2.4.5

Řízení dodávky produktů ................................................................................... 34

2.4.6

Přechod mezi etapami (Managing stage boundaries , SB) ................................. 35

2.4.7

Ukončení projektu .............................................................................................. 37

2.5

3

Procesy ....................................................................................................................... 29

Certifikace PRINCE2................................................................................................. 38

2.5.1

PRINCE2 Foundation ......................................................................................... 38

2.5.2

PRINCE2 Practitioner ........................................................................................ 38

2.5.3

PRINCE2 Professional ....................................................................................... 38

IT projekt pořízení měřícího softwaru .............................................................................. 39 3.1

Seznámení s firmou Pöttinger .................................................................................... 39

3.1.1

Historie s milníky ............................................................................................... 39

3.1.2

Současnost .......................................................................................................... 41

3.2

Organizace firmy ....................................................................................................... 41

3.3

Hlavní výrobní procesy .............................................................................................. 42

3.3.1

Pracovní postup dílu do stroje Lion 3002........................................................... 43

3.4

Začlenění kontroly kvality do výrobního procesu ..................................................... 44

3.5

Obchodní případ potřeby nového měřícího softwaru ................................................ 45

3.6

Vize návrhu hardwarové struktury............................................................................. 47

3.7

Poţadavky na nový měřící systém ............................................................................. 48

3.8

Časový plán zavedení softwaru ................................................................................. 50

3.9

Vhodní výrobci měřících sestav ................................................................................ 55

3.9.1

Výběrové řízení softwaru pro měření ................................................................. 55

3.9.2

Výběr měřící periferie ........................................................................................ 56

3.9.3

Výběr provozní stanice (notebooku) .................................................................. 58

3.10 Problémy zjištěné v provozu ...................................................................................... 58 6

3.10.1 Chybějící grafická karta...................................................................................... 58 3.10.2 Malý dosah měřícího ramene ............................................................................. 59 3.10.3 Špatná stabilita na stativu ................................................................................... 60 3.10.4 Špatné přesuny na delší vzdálenosti ................................................................... 61 3.11 Celkové náklady projektu .......................................................................................... 62 4

Pořízení měřícího software podle PRINCE2 .................................................................... 63 4.1

Získání představy ....................................................................................................... 64

4.1.1

Analýza současné situace ................................................................................... 65

4.1.2

Charta projektu ................................................................................................... 66

4.2

Plánování ................................................................................................................... 69

4.2.1

Návrh plánování etap .......................................................................................... 71

4.3

Realizace .................................................................................................................... 76

4.4

Revize a kontrola ....................................................................................................... 77

4.5

Předejití moţných problémů s PRINCE2 .................................................................. 79

Závěr ......................................................................................................................................... 80

7

Úvod Během mého studia oborů zabývajících se informačních technologií jsem se zúčastnil několika brigád, kde jsem aktivně pracoval při strojírenském zpracování, a tak měl moţnost seznámit se s jednotlivými výrobními procesy. Nejdříve jsem byl zasvěcen do samotného obrábění na CNC centrech, postupem času jsem přešel na druhou stranu výrobního procesu a to do pozice kontrolního pracovníka. Posléze jako zaměstnanec firmy Richmont-cz a.s. jsem zastával funkci programátora portálového měřícího přístroje, v současné době jsem zaměstnán ve společnosti Pöttinger, která má jednu ze svých poboček ve Vodňanech. Zde pracuji na pozici programátora a obsluhy manuálního trojrozměrného přístroje. Všechny obtíţnější díly a sestavy musí projít mým měřením a já je následně uvolňuji či zastavuji v postupu do další operace. Tato má záliba v měřících přístrojích a zajímavosti kolem řízení projektů mě přivedla na nápad vypracování diplomové práce procesu zavedení měřícího ramene a softwaru pro vyhodnocení výsledků do naší firmy. Ještě před mým nástupem do závodu Pöttinger proběhl zde interní projekt pro pořízení měřícího softwaru Power Inspect. Průběh projektu jsem nemohl ţádným způsobem nějak ovlivnit ani se nějak podílet na jeho řízení. V mé diplomové práci vám proto představím a popíšu průběh jiţ uzavřeného projektu a pokusím se odhadnout, jak by ten samý projekt byl řízen metodikou PRINCE2, měl–li by se znovu opakovat či by mělo dojít k případnému rozšíření. Zároveň se pokusím vysvětlit a přiblíţit, proč je nutné ve strojírenské výrobě nezapomínat na rychlý rozvoj informačních technologií a proč je nutnost implementovat do výrobního procesu nejnovější trendy v oblasti měřící techniky.

Obr. 1 - Portálový 3D měřící přístroj1

1

[2014-03-23], [online], Dostupné z WWW:

8

1 Problematiky řízení IT projektů 1.1 Co je projekt Pod pojmem projekt si kaţdý z nás v dnešní době dokáţe vybavit spoustu věcí. Většina lidí si ihned představí ohromné komerční projekty, které vídáme na televizních obrazovkách, věnuje se jim hodně pozornosti a všichni si dokáţou bez dlouhého rozmýšlení alespoň jeden vybavit. Ovšem pravý smysl projektu lze chápat úplně jednoduše. Význam slova projekt pochází původně z latinských slov "pro-jicio" nebo "pro-iectum" a nechá se přeloţit jako plán, rozvrh, návrh či záměr. Hlavní náplň projektu je efektivní zacházení se zdroji a umění se zdroji správně nakládat. Rozhodně se projekt nesmí chápat jako nějaká sloţka nebo dokumentace. Obecná podstata projektu se dá pochopit jako, cituji: "Jedinečná soustava činností směřujících k předem stanovenému a jasně definovanému cíli, která má určený začátek a konec, která vyžaduje spolupráci různých profesí, váže jejich kapacity a jejich úsilí a využívá (případně spotřebovává) pro vytvoření cílových výstupů informace, materiál, peníze, schopnosti a dovednosti zúčastněných lidí."2 RNDr. Zdenko Staníček Zjednodušeně lze projekt charakterizovat jako: řízený proces s daným začátkem a koncem, dočasné úsilí s cílem vytvořit jedinečný produkt nebo sluţbu, jednorázové přetvoření (transformace) vstupních zdrojů na výstupy za pouţití řídících, vývojových a koordinovaných činností. Zdroji máme na mysli lidské, materiální, časové, ... Snaha projektu je dosaţení určité změny, kde jsou prováděny činnosti, které změny vytváří a směrují k určitému cíli. Projekt jako jedinečné pořadí činností má určitá omezení a lze ho popsat pomocí tzv. "projektového trojimperativu". Konečného stavu musí být dosaţeno s předem stanovenými parametry a ty si lze představit jako tři základní pilíře projektu:

2

Staníček, Zdenko. Řízení projektů: Podstata řízení projektů [online]. 12/2012 [cit. 11.ledna 2014]. Dostupný na WWW:

9

ZDROJE - specifikace provedení produktu nebo sluţby, ČAS - má být co provedeno (plánování dílčích aktivit), NÁKLADY - bude celý projekt realizován.

Obr. 2 - Trojimperativ projektu3

Kaţdý projekt má nezbytné charakteristické rysy a pro splnění musí mít určité vlastnosti. Pro snadné vytyčení vlastností a stanovení cílů nám slouţí metoda SMART. Pomocí ní můţeme hodnotit kvalitu jednotlivých projektových cílů nebo cílů osobního rozvoje. Poprvé byl tento pojem pouţit v roce 1981 v listopadovém vydání Management review. SMART je zkratka prvních písmen anglických slov.

Písmeno

Anglické slovo

Překlad

Význam

S

Specific

Konkrétní

Dobře specifikovaný cíl

M

Measurable

Měřitelný

Metriky na dosaţení cílů

A

Achievable

Dosaţitelný

Cíl přidělen jedinému subjektu

R

Realistic

Realistický

Reálné a splnitelné zadání

T

Time bound

Časově ohraničený

Časové ohraničení cílů

Tab. 1 - Vysvětlení metody SMART

2


10

Můţeme se setkat s příbuznými metodami jako DUMB (proveditelný, pochopitelný, uřiditelný a prospěšný) nebo domácí alternativa KARAT (konkrétní, ambiciózní, reálný, akceptovatelný, termínovaný)

1.2 Historie Projektové řízení je staré jako lidstvo samo, kdy lidé začali vyuţívat dělbu práce. Dalo by se tedy říci, ţe management je od dávných časů jeden z nejdůleţitějších cílů lidstva. Začali se stavět ohromné stavby, které by jednotlivci vůbec bez důkladného řízení nemohli postavit. Samotný pojem projektové řízení se sice objevil aţ ve třicátých letech dvacátého století, ale daleko předtím lidstvo uţ řízení pouţívalo a můţeme o tomto faktu nalézt důkazy. Například velké pyramidy v Gíze v Egyptě by nikdy nemohli vzniknout bez toho, aniţ by si jejich stavitel dopředu nestanovil, jak budou pyramidy vypadat, kde bude brát základní stavební materiál, kolik bude potřeba dělníků a kolik to celé bude ve výsledku stát. Určité rysy projektového řízení můţeme nalézt i v Bibli, kde se ve Starém zákoně popisuje stavba Šalamounova chrámu v Jeruzalémě. V knize je uvedeno, který materiál byl na stavbu pouţit, kdo ho zajistil a kolik byla mzda za vynaloţenou práci. Další unikátní doloţení můţeme nalézt třeba v Číně při stavbě Velké čínské zdi, stavby amfiteátrů ve starověkém Řecku a nebo monumentální stavby akvaduktů v říši římské. Z trochu novější historie by se dalo poukázat na stavbu Nového města v Praze Karlem IV. nebo na stavbu dvou umělých mořských průplavů, Suezského a Panamského.

Obr. 3 - Pyramidy v Gíze4

4


11

Na přelomu dvacátého století se spolu s rozvojem průmyslové výroby realizovalo hodně známých projektů. Asi jako nejznámější z nich by se dal uvézt příklad stavby Eiffelovy věţe v Paříţi mezi roky 1887-1889. Samotné projektové řízení jako samostatná manaţerská disciplína se začala vytvářet aţ v období druhé světové války. V této době bylo uskutečněno mnoho projektů ohledně vývoje nových zbraní, kdy plánování času zde sehrálo velkou roli. Nejznámější projekt z této doby je bez pochyby vývoj atomové bomby americkými státy pod názvem Manhattan. Velký revoluční rozmach nastal aţ v posledních pár desetiletích, kdy se o projektovém řízení začalo mluvit jako o samostatné vědecké disciplíně. Jako moţná příčina by se dala uvést rozvoj obecné teorie řízení, kdy lidská společnost došla do bodu, kdy k dosaţení vyšších cílů uţ nelze pouţít metodu pokus omyl, ale bylo potřeba věnovat více pozornosti přípravě a teoretickým otázkám. Přidal tomu i fakt, ţe došlo k rozmachu vědy a techniky a výrazně se urychlily otázky řízení projektů v optimálním čase. Rozvoj telekomunikační techniky umoţnil daleko rychleji přesouvat informace a eliminovat omyly a tím došlo k dokonalejšímu sdílení informací. Podíl přinesl i vývoj informačních technologií, kdy vznikly přenosné personální počítače a informace o projektech a samotné plánování mohlo probíhat přímo v terénu. Projektové řízení do současné podoby pomohl dostat americký Project Management Institut (PMI), který definoval základní okruhy projektového managementu.

1.3 Role na projektu Projekt se jako celek skládá z řady několika subjektů, které mají zásadní vliv na správný průběh projektu. Mezi nejčastější z nich patří následujících pět subjektů.

1.3.1 Projektový manažer Osoba projektového manaţera má pověření vedením projektu a má za úkol dodrţovat milníky projektu a jeho dokončení. Zastřešuje celý projekt a je prostředníkem mezi zadavatelem projektu a sponzorem. Po celý průběh zastává více rolí a při rozsáhlejších projektech můţe některé své pravomoci delegovat. Mezi role, které zastává, můţeme zařadit následující:

12

"Zastupuje vedení, plánuje, předpovídá (vizionář), organizuje, hlídá změny a řídí rizika, rozpočtuje, kontroluje kvalitu, informuje členy týmu, atd." Měl by být příkladem ostatním členům týmu, být zdatný, rozhodný, umět komunikovat s lidmi a umět vést svůj tým. Projektový manaţer by měl mít znalosti v řízení a znalost v oblasti daného projektu, poznatky, měl by umět komunikovat a zvládat ovládání softwarových aplikací. Projektový manaţer musí zastupovat zájmy zákazníka a společnost, pro kterou pracuje.

Obr. 4 - Manaţer projektu musí komunikovat se všemi členy týmu5

1.3.2 Zákazník Zákazník hraje velkou úlohu, neboť on bude projekt pouţívat. Role zákazníka můţe mít několik podob. Můţe to být investor nebo vlastník projektu, který si nechá zhotovit projekt a sám ho financuje. Zákazníci mohou být sami uţivatelé nebo akcionáři a dokonce i samotní zaměstnanci zákazníka projektu.

1.3.3 Projektový tým Základem úspěchu projektu je dobře sestavený a sehraný tým. Důleţité je, ale tým měl společný cíl, kaţdý z členů pracoval pro tým, musí vědět, proč je třeba dosáhnout cíle, jakou mají roli v týmu a co se od nich očekává za přínos. Sestavit dobrý projektový tým vyţaduje mnoho úsilí. Pokud se to ale povede, pracuje tým daleko lépe neţ pracovní skupina. Dochází

5


13

k tzv. synergickému efektu, kdy se jednotliví členové týmu navzájem inspirují, povzbuzují a tým pracuje s větší efektivitou. Příklad rolí v projektovém týmu: organizátor - koordinuje a organizuje tahoun - svojí vytrvalostí motivuje tým k práci kontrolor - pozoruje a hodnotí předloţené návrhy vizionář - umění předvídat situaci a umění kreativně myslet komunikátor - přenášení informací mezi týmem a okolím

1.3.4 Investor Sponzor jako hlavní zásadní investor má rozhodující slovo a má největší pravomoc na projektu. Rozhoduje na úrovni finanční a investorské činnosti. Sponzorem mohou být dvě odlišné skupiny. První můţe být sám zadavatel projektu, který má zájem pouze o to, aby projekt byl úspěšně dokončen. Na druhou stranu můţe být sponzorem nějaká zájmová skupina, která investuje do projektu proto, aby na něm do budoucna vydělala. U této varianty se můţe stát, ţe se nemusí starat o správný průběh projektu. Hlavní body, o kterých sponzor rozhoduje, jsou předmět projektu, doba a celkový rozpočet. Řídí všechny přidělené finanční zdroje a sleduje jejich efektivní vyuţití. Zde se vyskytuje moţnost, ţe samotný projekt můţe být perfektně zpracován, ale bez investora nemá šanci na úspěch. Sponzor ručí za úspěch projektu jako celku. Měl by dopředu stanovit metriky, podle kterých bude prováděna kontrola správného hospodaření s financemi.

1.3.5 Další účastníci Tyto subjekty se přímo nepodílejí na tvorbě projektu, ale nějakým způsobem ho z vnějšího okolí zásadně ovlivňují. Můţe se například jednat o místní zastupitelské úřady, které nemusejí s podobou projektu souhlasit a mohou ho směrovat např. podle dopadu na ţivotní prostředí. Mezi dalšími to mohou být například Úřad vlády České republiky, který můţe být zainteresovaný a projekt nemusí vzniknout. Nesmíme opomenout také konkurenční prostředí a současný kurz měny a míru inflace, která by mohla projekt prodraţit. Určitý vliv mají na dopad projektu také veřejnost, sdělovací prostředky a také počasí.

14

Projektová kancelář jako taková není přímý účastník, ale bez ní by projekt nemohl vznikat. Musíme si uvědomit, ţe projektová kancelář (nebo-li PMO) samotný projekt neřídí, vedení má na starosti projektový manaţer. Projektová kancelář slouţí jako základna pro sběr, uchování a předávání informací o projektu. Má na starosti podporu řízení projektového portfolia, správu procesů, účetnictví, analýzy, monitoring (dohled), atd.

1.4 Životní cyklus Projekt je vymezen časem, ale to neznamená, ţe neprochází určitou postupnou realizací vývoje, kterou nazýváme ţivotní cyklus projektu. Počátkem všeho je specifikace projektu, následovaná jeho realizací aţ k fázi rozpuštění projektového týmu a uvedení projektu na trh. Podle metodiky Rational Unified Process6 je ţivotní cyklus rozdělen do čtyř základních fází. Mezi kaţdou hlavní etapou se vyskytují tzv. milníky, které nám uzavírají určitou část projektu a dochází k zhodnocení. Další část projektu můţe začít po splnění všech daných kritérií. Například milník u projektu řešení nové databáze můţe být dokončení konceptuálního návrhu.

Obr. 5 - Hlavní milníky projektu7

Časové náročnosti jednotlivých fází z hlediska hlavních zdrojů (času a financí) se liší podle typu projektu. Pokud se jedná o vývoj software, můţeme předpokládat, ţe dokončením první verze se ţivotní cyklus neuzavírá. Proběhne další ţivotní cyklus druhé verze programu o stejném počtu fází, ale s tím rozdílem, ţe u prvních dvou fází se zkrátí doba, protoţe byly ve větší míře provedeny u první verze. Kaţdá fáze by měla mít stanoveno, jaký typ práce má být

6

Metodika vývoje softwaru vytvořená společností Rational Software Corporation. Metodika RUP vychází z kolekce osvědčených praktik a postupů při vývoji softwaru. 7 [2014-01-12], [online], Dostupné z WWW:

15

vykonán, jaké konkrétní výstupy budou v jednotlivých fázích generovány, ověřovány a hodnoceny a kdo se jak bude zapojovat do aktivit projektu v dílčích fázích.

Obr. 6 - Časová náročnost dílčích kroků8

1.4.1 Zahájení projektu Základním poţadavkem fáze zahájení je vymezení poţadavků projektu, na kterém se musejí shodnout všechny zainteresované strany. Důleţité je vymezení rozsahu a klíčových bodů a dopředu stanovení přesné specifikace jejich řešení. Vstupy Kladen důraz na stanovení původní vize myšlenky projektu. Pokud se jedná o vývoj softwaru, můţe být za vstup povaţována minulá verze. Výstupy Odhad přibliţných zdrojů a nákladů projektu. Údaje nemusí být příliš přesné, neboť se v dalších fázích spočítají přesně. Potřeba stanovení základních otázek: Co, Kdo, Kdy, Jak, Za kolik? Jestliţe dokáţeme zodpovědět na všechny otázky, můţeme povaţovat proces zahájení za úspěšný.

8


16

Milník na konci fáze zahájení Na konci fáze se musí rozhodnout, zda projekt bude pokračovat, nebo se projekt přepracuje či se v krajním případě úplně zastaví. Zadavatelé se musejí dohodnout s dodavateli na míře rizik, nákladech a časovém plánu.

1.4.2 Příprava Fáze přípravy navazuje na část zahájení a měla by být k dispozici úvodní specifikace. Hlavní náplní druhé fáze je snaha o navrhnutí modelů projektu, kterou lze následně konstruovat. Modelování by mělo vycházet ze základních poţadavků na systém a ve fázi přípravy by se měl navrhnout jeden či více prototypů řešení. Prokázalo se, ţe vytvořením prototypů se správně identifikovaly a odhadly rizikové oblasti. Zadavatelé musí souhlasit s realizací vize projektu a s tím, ţe skutečná spotřeba zdrojů nepřevýší stanovený plán. Je zapotřebí připravit detailní plány pro realizaci. Stanovení cílů lze provézt pomocí techniky SMART. Vstupy Úvodní specifikace projektu. Výstupy Několik prototypů návrhu projektu. Mělo by být identifikováno alespoň 80% případů uţití spolu s identifikováním všech aktérů. Výstupní model návrhu by měl obsahovat alespoň 10% všech případů uţití. V tuto chvíli by měl být jiţ upravený a reálný ekonomický plán projektu a stanovena rizika. Milník na konci fáze přípravy Návrh projektu je jiţ víceméně neměnný s jasnou vizí realizace, kde nebude docházet k zásadním úpravám.

1.4.3 Konstrukce Hlavní náplní této fáze je dokončit návrh, vytvořit a v první řadě otestovat první verzi projektu. Hlavní důraz je kladen uţ na samotnou implementaci projektu, kde je největším problémem správné efektivně rozdělit zdroje. Nejsnadnější způsob je rozdělit projekt do

17

menších celků a ty pak přidělit více pracovním týmům. Poţadavky na projekt by měly být jiţ stabilní a upravovat pouze malé změny. Vstupy Ujasněná odsouhlasená vize projektu. Výstupy První funkční verze projektu a jeho následné testování. Porovnáme zadání projektu s testováním a výsledek by měl odpovídat prvotním poţadavkům projektu. Zároveň by měla vzniknout uţivatelská dokumentace spolu s první verzí manuálu. Milník na konci fáze konstrukce První funkční verze projektu, která je stabilní a projekt mohl být poskytnut uţivatelům. Při nesplnění některých podmínek je doporučeno odloţení předání projektu o další verzi.

1.4.4 Předávání Závěrečná fáze je určena pro předání celého projektu zadavatelům nebo koncovým uţivatelům projektu. Uţ by nemělo docházet k ţádným úpravám. Můţe dojít k nepatrným modifikacím ze strany uţivatelů, které uţ nezmění celkový vzhled projektu. Vstupy První funkční verze projektu připravená na předání. Výstupy Výsledná verze projektu, která splňuje všechny vstupní poţadavky zadání. Projekt by měl obsahovat dokumentaci k aktuální verzi. Milník na konci fáze předání Konečná fáze aktuální verze projektu tímto končí. Výsledný projekt je předán zadavateli a je zhodnocena úspěšnost podle spotřeby zdrojů a podle spokojenosti uţivatelů.

18

1.4.5 Vyřazení V poslední fázi projektu hodnotíme, jak byl projekt úspěšný, jakých výsledků jsme dosáhli a jak tyto zkušenosti můţeme pouţít při konstrukci dalšího projektu. Samozřejmostí je záznam všech získaných zkušeností. Vypracuje se závěrečná zpráva a dojde k vyúčtování projektu. Vhodné je zaznamenat i ostatní problémy, které v průběhu realizace vznikly. Hodnocení slouţí jako vstup pro další projektový cyklus.

1.5 Vybrané techniky projektového řízení 1.5.1 Ganttův diagram Ganttův diagram je druhem jednoho z mnoha pruhových diagramů pojmenovaný po autorovi Henrym Laurenci Ganttovi (1861-1919), který byl během první světové války nejznámějším průkopníkem. Graf byl poprvé představen v letech 1910-1915. Diagram pracuje na jednoduchém principu, kde horizontální osa obsahuje časové období trvání projektu rozdělené na stejně dlouhé časové intervaly, např. na dny, týdny, měsíce, roky. Na vertikální ose najdeme jednotlivé činnosti, kterými je projekt členěn. Kaţdý řádek přesně odpovídá jedné činnosti v projektu. Na vzniklé ploše vymezené dvěma osami umísťujeme obdélníky, nebo také pruhy. Levá strana obdélníku označuje plánovaný začátek činnosti, naopak pravá strana ukazuje na plánované ukončení činnosti. Šířka obdélníku udává délku trvání činnosti. Rozšířená verze diagramu nám můţe ukazovat vzájemné navázání činností formou šipek vedoucích od jedné činnosti k činnosti druhé. Tyto spojovací čáry neboli vztahy mohou nabývat čtyřech forem: a) začátek => začátek b) začátek => konec c) konec => začátek d) konec => konec

19

Velmi je pouţívaná svislá linka udávající aktuální datum v průběhu činností. Lze i vybarvovat plochu obdélníků pro přehlednost stavu činnosti. Hlavní výhoda Ganttových digramů je ta, ţe jsou na první pohled přehledné pro velké mnoţství lidí. Doporučuje se pro projekty do 30 činností. Pokud projekt obsahuje více činností, začíná být diagram nepřehledný a tudíţ nepouţitelný.

Obr. 7 - Příklad Ganttova diagramu9

1.5.2 Síťová analýza Síťová analýza je dnes nejpouţívanější nástroj při plánování projektu. Podporují ji v hojném počtu komerční softwarové nástroje. Síťová analýza je zaloţená na principu jednoduchých sousedských závislostí vytvořených mezi milníky a etapami, kdy nám vzniká tzv. síťový graf. Vytvořený síťový graf je obrazem ţivotního cyklu projektu. Problém nastává, kdyţ projekt obsahuje smyčky, protoţe do síťového grafu zakreslujeme po sobě jdoucí činnosti a ne smyčky. Tento fakt je jeden z nejslabších slabin síťové analýzy. Síťový graf nám ukazuje jednotlivé etapy projektu. Časové období ubíhá z levé strany (kde je zpravidla začátek projektu) ke straně pravé, kde projekt zpravidla končí. Kruhy znázorňujeme milníky, číslované vzestupně od začátku průběhu projektu. Spojovací čáry (tzv. hrany) udávají délku trvání činnosti (aktivity) mezi dvěma milníky. Plná čára ukazuje na nutný průběh aktivity. Přerušovaná čára udává orientační navázání činností. V celé struktuře síťového grafu vţdy musíme stanovit tzv. kritickou cestu, která ukazuje na nejdelší cestu moţného trvání projektu. Činnosti vázané na kritickou cestu je důleţité sledovat, protoţe jakékoliv nedodrţení bude mít zásadní dopad na zpomalení celého projektu.

9


20

Pokud některá aktivita skončí v jiném termínu, neţ byla naplánovaná, je důleţité síťový graf aktualizovat, protoţe se můţe stát, ţe dojde k přesunu kritické cesty na jiný síťový milník.

Obr. 8 - Struktura síťové analýzy10

10


21

2 Metodika PRINCE2 2.1 Seznámení V dnešní době při řízení projektů se můţeme spolehnout na své znalosti a zkušenosti, nebo zjistit průběh obdobného projektu a nebo se nechat inspirovat jednou z jiţ zavedených metodik. Na výběr máme z několika moţností světově uznávaných a osvědčených způsobů. Pokud budeme konkrétnější, lze pouţít metodiku PRINCE2 nebo konkurenční PMBOK 11 . Obě vznikly ve stejné době, ale kaţdá je trochu jinak orientovaná. Obě prošly revizemi, mají moţnost certifikace a celkový počet verzí se dnes odhaduje na stovky tisíc. Mohlo by se zdát, ţe oba standardy jsou si velice podobné, i kdyţ kaţdá pochází z jiného koutu světa, ale rozdílů můţeme najít více. Na přelomu století, kdy v roce 1989 dochází v Československu k revoluci, se začíná na britských ostrovech rodit metodika PRINCE2 (Projects in Controlled Environment). V českém jazyce lze přeloţit jako projektování v kontrolovaném prostředí. Za zrodem stojí organizace Office of Goverment Commerce, která je součástí britské vlády a mimo jiné stojí za zrodem další známé metodiky ITIL 12 . Standard byl vytvořen více jak sto padesáti společnostmi se spoustou zkušeností. Na vývoji mimo jiné také spolupracovali a sdíleli své poznatky generální ředitelé a členové jednotlivých týmů IS/ICT. Jádro vychází ze starší známé metodiky PROMPTII 13 , která byla vyvinuta v roce 1975 firmou Simpact Systems a výhradně popisovala metody pro oblast řízení IT. Metodika za celou dobu své existence prošla několika velkými změnami, převáţně v roce 1996, aţ do doby veliké a doposud poslední aktuální revize v roce 2009. V dnešní době je nejrozšířenější projektovou metodikou a území Evropy. Oproti tomu PMBOK vznikla jiţ o pár let dříve v roce 1986 ve Spojených státech amerických. Na rozdíl od PRINCE2 je tato metodika tzv. nejlepší praxí ("best practices") v řízení projektů a také vznikla za spoluúčasti autorů z mnoho organizací a firem. Poslední revize je datována na konec roku 2008, coţ je o pár měsíců dříve neţ současná revize PRINCE2. Celý standard je zaloţený na sedmi principech, které tvoří sedm procesů 11

PMBOK Guide (A Guide to the Project Management Body of Knowledge) je metodika a příručka pro projektové řízení vyvíjena neziskovou organizací zaměřující se na projektové řízení s základem shromaţďování nejlepší praxe z oboru 12 ITIL- Information Technology Infrastructure Library je soubor praxí prověřených konceptů a postupů, které umoţňují lépe plánovat, vyuţívat a zkvalitňovat vyuţití informačních technologií (IT), a to jak ze strany dodavatelů IT sluţeb, tak i z pohledu zákazníků. 13 PROMPTII vznikla přijetím CCTA v roce 1979 jako standard pro řízení vládních projektů informačních systémů

22

a detailně popisuje sedm témat. Abychom byli schopni porozumět podstatě metodiky a umět jí správně napasovat na aktuální projektové prostředí, je potřeba pochopit základní principy, které jsou pilířem PRINCE2. Metodika nabízí funkce při práci s dokumenty, jako je sdruţování, zjednodušování nebo případné nepouţití dokumentů. Samotné procesy lze také zjednodušovat a kaţdý lze uplatnit podle velikosti projektu. Základní principy nám zaručují, ţe se nadále jedná o projekt řízený metodikou PRINCE2. Moţnost přizpůsobení metodiky je přímo uvedeno v manuálu a je to velký přínos oproti PMBOK.

Obr. 9 - Struktura metodiky14

2.2 Principy Samotná metodika definuje sedm principů, které musejí být bezpodmínečně dodrţeny. Pokud se tak nestane, nelze projekt označit jako řízený podle PRINCE2 ale jenom jako takzvaný PINO projekt (PRINCE2 in name only), označení pouze ve významu pojmenování.

2.2.1 Neustálé zdůvodňování opodstatnění Po dobu ţivotního cyklu projektu, to je na jeho začátku, v průběhu i ve fázi ukončení, musí mít projekt jasně definovaný cíl, kvůli kterému vlastně vzniká. Problém můţe nastat, kdyţ například při vývoji informačního systému přejde zákazník ke konkurenci. 14


23

2.2.2 Učení z předchozích zkušeností Náš projekt byl uţ někdy v minulosti v podobném měřítku realizován a proč tedy si z něj nevzít příklad, i kdyţ skončil neúspěchem. Naší snahou je vzít si z těchto projektů ponaučení, předejít a vyvarovat se stejných omylů. Samozřejmě platí pravidlo, ţe člověk se nejlépe učí ze svých chyb. Tento přístup nám ušetří hodně starostí.

2.2.3 Definování rolí a jejich odpovědností V celém projektu musí být jasně definováno, kdo všemu velí. V řízení musí být vidět jasné uspořádání nadřazenosti a podřízenosti pracovníků, definovaná projektová struktura, nastavení komunikace a kaţdý účastník na projektu musí odsouhlasit a být si vědom svého místa v rámci týmu.

2.2.4 Etapové řízení projektu Jeden celek projektu se rozdělí a rozkouskuje na menší části. Tyto menší části se daleko lépe kontrolují a lze snadno uhlídat, zda dodrţují časový plán či nikoliv. Například kdyţ při vývoji informačního systému vytváříme jednotlivé moduly. Na jeden modul máme naplánován časový plán jeden měsíc a samotný vývoj trvá jen dva týdny. Mohli bychom si říci, ţe jsme uţ v předstihu. Ale co komunikace s ostatními moduly a celkový chod systému? Zde můţe nastat problém s časovou tísní.

2.2.5 Řízení na základě výjimek Výjimky můţeme také nazvat jako vymezení tolerancí. Tolerancí máme na mysli přidělení intervalů zdrojů jak finančních tak třeba i časových. Projektový manaţer nemůţe řídit projekt, pokud má přesně stanovené výdaje a přesně stanovený čas, kdy se má práce dokončit. Tento krok nám v podstatě říká, ţe nedochází k řízení projektu. Zdraţení projektu o 10000Kč kvůli zdraţení elektřiny neznamená, ţe se musí čekat na výjimku. Právě čekáním na výjimku se čas prodluţuje. To samé platí i o ukončení projektu v předtermínu. Pokud projekt vývoje skončí o týden dříve, nemůţeme rozhodně říci, ţe projekt nebyl úspěšný.

24

Pokud nebudou schváleny výjimky s intervaly, tak v podstatě projektový manaţer jen doručuje ţádosti nadřízeným a čeká na souhlas.

2.2.6 Produktové zaměření Hlavní úvahy při řízení projektu podle PRINCE2 je upřednostnění produktů (dodávkami projektu) před aktivitami. Při vývoji software nás bude nejdříve zajímat, k čemu vlastně bude určen a jaké bude mít výstupy a aţ posléze se budeme zajímat, na jaké architektuře bude software postavený.

2.2.7 Přizpůsobení řízení prostředí na projektu Z definice projektu o jeho jedinečnosti můţeme říci, ţe se kaţdý projekt liší velikostí, druhem, účelem, prostředím a tak dále. Projektový manaţer je povinen přizpůsobit řízení projektu tak, aby byl schopen ho spolehlivě řídit bez zbytečných administračních záleţitostí.

2.3 Témata Pod významem témata si můţeme představit jednotlivé aspekty projektu, na které je potřeba dohlíţet po celou dobu trvání projektu. Metodika PRINCE2 definuje sedm témat. Na kaţdé z nich je potřeba se neustále ptát otázkami, abychom dostali poţadované informace.

2.3.1 Obchodní případ V první řadě musíme být schopni popsat důvody vzniku projektu, tedy Business Case. Ptáme se na to, zda byly zváţeny různé alternativy? Je potřeba zapojit externího dodavatele? Existují určité zkušenosti a znalosti? Je známa předpokládaná cena prací? Jsme schopni si projekt dovolit? Je znám přínos? Je důleţité prokázat oprávněné vynaloţení prostředků. Pozornost si zaslouţí více nápadů, neţ se ve výsledku uskuteční a na kolik bude k dispozici finančních prostředků. V našich silách je vhodné se ujistit, ţe právě námi vybraný projekt je ten pravý pro realizaci. U výsledného projektu musí být lehce měřitelné přínosy oproti nákladům. Nemusí to ale znamenat přesné a náročné stanovení finanční analýzy pro náš budoucí projekt.

25

Ptáme se otázkou: Proč?

2.3.2 Organizace Je velice malá šance, ţe pro náš projekt bude potřeba obsáhlá organizační struktura. Základní myšlenka metodiky však ale doporučuje obsadit všechny role. Dále uţ jen záleţí čistě na poţadavcích a jak role kombinovat. V ţádném případě není potřeba mít pro kaţdou roli jednoho člena týmu, jak se někteří domnívají. Ani sama metodika to neupřesňuje. Po zváţení o obsazení rolí je potřeba se zamyslet, kdo se zaváţe za jednotlivé sloţky projektu. Zvolíme-li na jednoho člena týmu více rolí, je to v pořádku. Pokud se jedná o projekt, měla by existovat role odpovědná za poskytování finančních prostředků a zároveň být sladěn cíl projektu s cíli nadřízené organizace. Potřebujeme tedy sponzora projektu. Někdo ale musí zastupovat druhou stranu jako dodavatel. Hlavní dodavatel se na projektu podílí tak, ţe se zaváţe k zajišťování potřebných zdrojů k vyvíjení cílového produktu projektu. Ptáme se otázkou: Kdo?

2.3.3 Kvalita Obecně v projektu popisuje a definuje veškeré vlastnosti vytvářených produktů. Říká nám, kdo má co na starosti, aby produkt byl co nejkvalitněji dodán zákazníkovi. Aby kvality bylo moţné dosáhnout, musí všichni účastníci projektového týmu rozumět základním poţadavkům kvality. V našich silách je zaručit co nejmenší změny kvality produktu podle kvality poţadované. Projekt musí být kvalitní i po stránce standardů jako je smluvní kvalita, poţadovaná zákonem nebo poţadovaná zákazníkem. I kdyţ se náš projekt bude ubírat různými směry, hledisko kvality a rizik musíme vţdy zváţit. Větší snaha o plán kontrol bude vyţadovat většího počtu nezávislých kontrolních členů a je větší pravděpodobnost, ţe se náš zadaný úkol stane projektem. Popis produktu by měl uţ na začátku obsahovat zmínku o poţadované kvalitě, kterou je potřeba se zákazníkem pořádně prodiskutovat. Můţe nastat situace, kdy bezproblémový průběh projektu na konci ohrozí fakt, ţe jsme se neřídili standardem, jeţ nám zákazník neřekl. Nejlepší je si u kaţdého produktu naplánovat způsob

26

kontroly v průběhu vývoje. Nedoporučuje se nechávat kontrolu aţ na konec projektu, protoţe je prokázáno, ţe většina chyb je způsobena špatnou specifikací projektu. Ptáme se otázkou: Co? Revizi kvality je vhodné revidovat a uplatnit i při práci s dokumenty stejně jako se skutečnými projekty. Revizi neformálního charakteru můţeme uplatnit jednoduše i mezi dvěma pracovníky.

2.3.4 Plány Velikost projektu rozhodne o tom, do jakých detailů musíme při plánování zajít. Metodika PRINCE2 rozeznává 3 druhy plánů a to projektový plán, plány etapy a plány týmů. Etapy zahájení a nastavení projektu mohou být tak malé, ţe je můţeme opomenout a více se s plánováním nezdrţovat. U malého projektu se nevyskytnou ani ţádné týmové plány. Jediné plány, na kterých bude náš projekt stát, budou plány etap. Kolik se jich objeví uţ čistě záleţí na velikosti projektu. V menším projektu je třeba naplánovat hlavní etapu a na ni zpracovat buď síťovou analýzu nebo Ganntův Diagram. Snadnější cesta je rozkreslení tzv. produktového rozpadu, kde se hierarchicky dělí hlavní produkt na podmnoţiny menších produktů. Nad malým projektem je potřeba se řádně zamyslet, aby nedošlo k opomenutí klíčového produktu. Ať uţ vynecháme v plánování nějaký bod, je nutné ho sepsat v popisu produktu. Nesmíme ale vynechat plán pro celý projekt, čili projektový plán. Daleko přehlednější je nechat projekt rozpadnout do několika menších etap, kde realizace dílčích částí bude lépe řízena a bude zde lepší optimalizace řízení zdrojů. Pak mluvíme o skutečném projektu. Ptáme se otázkou: Jak? Kolik? Kde?

2.3.5 Riziko Rizika nám mohou velice zkomplikovat hladký průběh projektu. Je tedy nevyhnutelné věnovat větší pozornost řízení rizik. Pokud budeme rizika správně řídit, docílíme toho, ţe

27

zmírníme jejich dopad nebo je zcela eliminujeme. Touto snahou můţeme zvýšit pravděpodobnost úspěchu dokončení projektu. Ošetření rizik není vhodné pouţívat jako hlavní linii k rozhodnutí, ať uţ se bavíme o projektech nebo obyčejných úkolech. Někdy realizovaný projekt můţe být natolik jednoduchý, ţe si rizika ani vůbec nepřipustíme. Můţe nastat situace, kdy závaţné opomenutí rizika dovede projekt k neúspěchu. Kaţdé řízení projektu by mělo mít domluvenou metodu na efektivní posouzení a ošetření rizika. Je tedy nutnost provést celý postup řízení rizik klidně i v rychlém časovém sledu. Dokumentace řízení rizika můţe být sepsána jak formálně, tak můţe být vedena i neformálním způsobem. Je potřeba mít na paměti, ţe řízení rizik je vlastně projektový management. Ostatní záleţitosti je pouhá administrativa. Důsledná analýza rizik při vytváření projektového plánu by měla bez problémů pokrýt všechny potřeby v dané oblasti. Zásada projektového manaţera je, aby v pravidelných časových intervalech vyhodnocoval stav projektu. Ptáme se otázkou: Co kdyţ?

2.3.6 Změna Vznik projektu s sebou přináší změnu funkce projektu nebo programu. Proto je na denním pořádku potřeba změnových řízení. Při realizaci jakéhokoliv úkolu nebo projektu je zapotřebí mít k dispozici metodu, podle které bude probíhat proces řízení změn. Změny lze provést lehce bez zájmu na výslednou cenu, potřebný čas, celkový dojem a chování produktu. I přesto jsme pouţili proces řízení změn s tím rozdílem, ţe jsme jen poţadavek na změnu předali vyšším správním orgánům. Problém můţe nastat v okamţiku, kdyţ se liší naše obchodní případy. Proto proces řízení změn projektu v rámci projektu je nutný. V projektech malého rozsahu by se nemělo vyskytnout tolik potřeb na změny, ale musíme mít dopředu připravený scénář a formulář na poţadavky změn. Opět zde platí, ţe čím lépe je projekt definován a popsán, tím méně změnových řízení budeme po dobu projektu řešit. Projektový výbor musí být na začátku ujištěn, ţe jakákoliv změna na projektu bude vyţadovat navýšenou spotřebu zdrojů. Mělo by platit, ţe o průběh změnových řízení se stará pořád jedna osoba nebo skupina stejných osob. Ptáme se otázkou: Jaký je dopad?

28

2.3.7 Progres V rámci řízení projektu musí existovat způsob, jak zjistit současný stav průběhu našeho projektu. Musí být moţnost porovnání plánovaného bodu s bodem skutečným. Význam slova progres můţeme definovat jako míru dosáhnutí cílů plánu. Porovnání aplikujeme na úrovni projektu, etap a projektových týmů. Řídící prvky nám udávají, ţe kaţdá úroveň má svou nadřazenou úroveň, která je schopna sledovat aktuální stav projektu. Výjimky jsou situace, kdy dojde k překročení stanovených tolerancí na úrovni projektu nebo etapy. Tolerance udávají, o kolik se můţeme odchýlit od skutečné hodnoty. Nejčastěji se pouţívají u pouţitých zdrojů, jako jsou čas a náklady. Můţeme je vyuţít také při stanovení kvality, rozsahu, výhod nebo rizik. Ptáme se otázkou: Kde se nacházíme? Kam směřujeme?

2.4 Procesy 2.4.1 Zahájení projektu Při zahájení je potřeba si nejdříve promyslet, jak budeme metodiku přizpůsobovat na daný malý projekt. Není zapotřebí ihned navrhovat a kombinovat procesy zahájení a nastavení projektu. Tato úvaha je spjata se vznikem dokumentace o nastavení a charty projektu a celý projekt se posune ihned k fázi schválení. Celý pojem zahájení projektu pod sebou skrývá více významů, neţ jen samotnou chartu projektu. Samotné zahájení se zaměřuje hlavně na činnosti jako návrh a jmenování řídícího týmu projektu, který musí zůstat neměnný i po část slučování procesů. Organizační hledisko by mělo zodpovědět otázky jednotlivých rolí na projektu. Ostatní produkty mohou vznikat sjednocením procesů zahájení a nastavení na očekávání zákazníka na kvalitu, projektový přístup, registr rizik a také na hledisko projektové tolerance. Je moţno vynechání stanovení prvotního plánu na konci etapy zahájení, ale stále musíme naplánovat čas a potřebné zdroje pro sjednocení dvou procesů zahájení a nastavení. Při řízení malých projektů se jedná o zanedbatelné prostředky a předběţný časový rozvrh jsme schopni si stanovit v několika málo minutách. Měla by být zodpovězena otázka, kolik bude potřeba časových zdrojů k plánování prvních dvou sloučených procesů. Není nutno stanovení časové náročnosti samotné realizace procesů.

29

Hlavní body: a) Jmenování projektového manaţera a stanovení jeho práce. Projektový manaţer bude mít na starosti plánování a řízení projektu. Dále je potřeba stanovit správní výbor, který bude rozhodovat. Po jejich přijetí do projektu je potřeba jejich jmenování do rolí. b) Navrţení názvu projektového týmu, který bude reprezentovat všechny zájmy zainteresovaných stran včetně uţivatelů, dodavatelů a obchodních partnerů. c) Projektový tým musí znát své povinnosti a je potřeba se ujistit, zda členové týmu správně pochopili svou roli a vědí, co se od nich očekává a jaká je jejich odpovědnost. Je potřeba se předem domluvit na způsobu komunikace a zajištění včasných doručení zpráv, pokud jsou vyţadovány. Po jmenování týmu můţe nastat problém s rolemi, názvem skupiny a událostmi. Tento fakt můţe nastat, pokud projektový manaţer nebo jiní členové týmu zastávají roli v jiném projektu, který probíhá současně. Je potřeba domluvit a naplánovat schůzky předem. Je pravděpodobné, ţe moţná dojde i na dodatečné změny týmu. d) Vytvořením stručného popisu projektu zajistíme, aby řídící výbor mohl rozhodnout, zda se projekt vyplatí realizovat. Zákazník by měl definovat kritéria přijatelnosti projektu a měl by být sepsán seznam všech rizik, která mohou nastat. Je moţnost vytvoření plánu rizik. Je nezbytné do projektu vloţit a zakomponovat připravený obchodní případ. Stručný návrh projektu odsouhlasený řídícím výborem slouţí jako hrubý mustr pro vytvoření projektové dokumentace. e) Je vhodné stanovení produktů či sluţeb, jaké budou v rámci projektu vytvořeny. Projektový manaţer se bude o této úloze radit s dalšími odborníky. f) Celý proces směruje úsilí k vytvoření a definování projektové dokumentace a termínu zahájení projektu. Proces zahájení by měl být plánován jako krátká a levná fáze v rámci celého projektu. Při projektu trvajícím například 6 měsíců, by fáze zahájení měla být něco kolem dvou aţ tří týdnů. Pokud projekt trvá týden, postačí jedno dopoledne.

2.4.2 Směrování projektu Potřeba procesu schválení projektu záleţí čistě na individualitě projektu. Etapu je moţno spojit s dalším procesem nastavení projektu. V tomto případě zmizí úplně. Proces

30

schválení se nedoporučuje odstranit ani při malém rozsahu projektu. Samotný čas ke schválení nemusí být za kaţdou cenu natahován a zbytečně formalizován. Je ale nezbytné, aby došlo k zodpovědnému rozhodnutí podle projektového plánu a obchodního případu. Nutnost potřeby schválení plánů etap a schválení realizace výjimky je čistě závislá na počtu etap realizovaného projektu. Můţe se vyskytnout malý problém, který projekt dostane do problému a mohou se objevit výjimky a je potřeba schválení plánu realizace výjimek. Není potřeba mnoho administrativy, záleţí pouze na tom, aby schválení poslouţilo jako spolehlivý kontrolní nástroj. Jestli tento krok bude odsouhlasen neformálně či bude formalizován, záleţí pouze na dohodě projektového manaţera a projektového výboru. Pokud je projekt většího rozsahu, lze předpokládat, ţe zprávy o stavu etapy si bude chtít výbor přečíst. Výskyt výjimky a její potvrzení musí výbor schválit, i kdyţ bude nepatrná. V kaţdém případě musí dojít ke schválení o ukončení projektu. Ukončování projektů bývá velkým problémem. Na vině jsou tři základní aspekty: Nepřesné stanovení rozsahu projektu na začátku plánování takzvaný "scope" (rozsah projektu). Nedostatečně kontrolované změnové poţadavky a projekt se začne odklánět od původního záměru a vzniká z něj nekonečný sled se spoustou doplňků. Špatná kontrola rozpočtu a obchodního případu sponzorem či investorem projektu. Směrování projektu, jakoţto hlavní strategie řízení projektu, slouţí primárně pro projektový výbor, aby mohl udrţet strategické kontrolování projektu a mohl poskytnout směrování projektu, neboť projektový manaţer řídí projekt v jeho kaţdodenní fázi. Hlavní body: a) Poskytnutí schválení začátku projektu, která je uskutečněna realizací inicializace. Dochází ke schvalování dokumentů z předprojektové fáze, tím máme na mysli chartu projektu a plán etapy nastavení projektu. b) Mělo by se hlavně rozhodnout o schválení projektu. Schválením výstupů dokumentů strategie organizační struktury, kontrolních mechanismů, obchodního případu, plánu projektu a plánu další etapy. c) Řízení a směrování projektu by mělo být při jeho průběhu samozřejmostí, aby se zajistilo, zda projekt je schopen se dále rozvíjet. Dochází k jednotlivým schvalováním

31

plánů etapy. Projektový manaţer řídí vţdy pouze jednu etapu projektu a po jeho dokončení nemůţe dále v projektu bez souhlasu strategického řízení pokračovat. d) Tento proces slouţí k propojení s podnikovým a programovým řízením za pomoci vydávání ad-hoc pokynů, které jsou reakcí poţadavků od projektového manaţera nebo jako instrukce vydané podnikem či programem. e) Ke schválení končení projektu dochází tehdy, pokud projekt jiţ vytvořil nebo dodal všechny produkty či sluţby. Poté je nejlepší čas na ukončení projektu. Můţe nastat i situace, kdy projekt bude ukončen v předčasném termínu. V takovém případě postupujeme stejným způsobem. Výstupem je dokumentace o ukončení projektu a aktualizovaná projektová dokumentace.

2.4.3 Nastavení projektu Před vyčleněním finančních prostředků na samotný projekt je potřeba pochopení prací potřebných na vyprodukování produktů. Pokud se dostatečně prokáţe, ţe projekt není ţivotaschopný, je lepší projekt rovnou ukončit a ušetří se projektové prostředky. Hlavní náplní tohoto procesu je vytvoření manaţerských produktů jako jsou například deníky, registry, záznamy, plány a strategie. V ţádném případě se nevytvářejí nějaké specializované produkty. Jediný manaţerský výtvor je dokumentace o nastavení projektu (PID) a plán revize přínosů. Na prvním místě bychom měli zpracovat projektovou dokumentaci a všechny dostupné informace a pochopit následující cíle. Dokumentace PID popisuje řešení těchto cílů. Cíle nám následně umoţní se bránit větou ve znění: "V ţádném případě, na tento způsob řešení jsme se předem nedohodli." Cíle: a) Nastavení řešení strategie a řízení konfigurace, rizik, kvality a komunikace. Strategií určíme, jak budeme přistupovat k řízení prvků projektu. Nejvyšší strategie podniku se odráţí v samotné strategii projektu a upravují se mu přímo na míru. b) Termíny a způsob, kdy dojde k předání předem dohodnutých produktů podle plánu projektu. Samotný plán projektu jen přibliţně odhaduje vývoj projektu, upřesňuje počet etap (jejich délku) a definuje, které produkty budou doručeny zákazníkovi. Zmiňuje se také o obecných poţadavcích na zdroje, závislosti mezi produkty a o aktivitách.

32

c) Měl by být stanoven jasný a zřetelný důvod, proč má být projekt realizován. Spolu s důvody by se měly upřesnit očekávané přínosy na úkor vyváţených velkých rizik, tzv. obchodní případ. Obchodní případ je základní dokumentace o tom, proč se vůbec projekt realizuje. Říká nám o stěţejních přínosech projektu se zohledněnými riziky, která jsou zodpovědná o výši očekávaných příjmů. d) Určení zodpovědností o rozhodování v organizaci. Jasně určit strukturu a role na projektu. Nezbytná je znalost účastníků projektu o jejich rolích a o jejich vymezeném prostoru na vlastní práci. e) Stanovení rozsahu a způsobu monitorování a reportování vývoje projektu, jinými slovy tzv. progres. Pokud není moţné sledování průběhu projektu, nejsme schopni určit, v jaké fázi se projekt právě nachází. Sledování progresu docílíme tak, ţe budeme porovnávat stav plánovaných etap s dosaţenými výsledky a s reálným stavem projektu. f) Definování strategie o řízení komunikace. Strategie stručně definuje, kdy a jak budou poţadovány informace. Pouhým stanovením rolí, projektových týmů a identifikací všech účastníků nezařídíme jejich vzájemnou spolupráci. Musíme jasně určit, jak budou jednotliví účastníci mezi sebou komunikovat. V jakých časových intervalech, jakou formou a stanovení mnoţství informací. g) Realizace přizpůsobení nastavení projektu PID. Projektový manaţer je povinen přizpůsobit řízený projekt prostředí, ve kterém se realizuje. Okolnímu prostředí se musí bezpodmínečně přizpůsobit celá organizace projektu a projektová dokumentace.

2.4.4 Kontrola etapy Kontrolní mechanismy u probíhajícího projektu jsou nutnou součástí, ať se jedná o velký nebo úplně malý projekt. Měla by být nastavena určitá kontrola jednotlivých etap. Kontrola nemusí být formalizovaná nebo příliš komplexně pojatá. V podstatě se jedná o:

33

Přidělení a odsouhlasení práce. Sledování (monitorování) přidělené práce od začátku do ukončení. Moţnost provádět změny nebo úpravy plánu, pokud si to situace vyţaduje. Poskytnutí informací o daných hlášeních, pokud si to projektový výbor vyţádá. Schopnost zachytit všechny problémy a umět se s nimi vypořádat. Komunikace s projektovým výborem a řešit s ním jednotlivé výjimky.

2.4.5 Řízení dodávky produktů Účelem dodání produktu formalizujeme i řízení vazeb mezi projektovým manaţerem a vedoucím týmu. Jejich spolupráce je zaloţená na akceptaci, vykonávání a dodávání práce. Vedoucím můţe být interní nebo externí pracovník. Má na starosti přípravu a koordinaci jednoho nebo více produktů v celkovém balíku práce. Náplní je přeměňování připravených plánů na projektové produkty. Abychom byli schopni toho dosáhnout, je zapotřebí vykonávání práce takové, která byla odsouhlasena. Dále musí vedoucí týmu a samotný projektový tým vědět, co se vyprodukuje za výsledný produkt, pokud vydají své úsilí, náklady a čas. Podrobné informace o probíhajícím vývoji je potřeba posílat v pravidelných časových intervalech projektovému manaţerovi. Počáteční spouštěcí impuls, který nám říká, ţe se můţe realizovat určitá práce v rámci jedné etapy, se nazývá balík práce. Daná práce se nemůţe začít provádět, pokud nebyla předem schválena. Schvalování balíků práce v rámci jedné organizace (interně) není důleţitá forma. Postačí nám ústní dohoda. Pokud se jedná o externí spolupráci, je potřeba schvalování balíků posunout na formální úroveň, kde můţe dojít i na právní smlouvy. Projektový výbor schválením etapy spouští řízení dodávek produktů. Projektový manaţer oproti tomu spouští práci pro připravení produktů. Hlavní aktivity: Akceptování balíku práce Projektový manaţer předá vedoucímu týmu balík práce podle předem dohodnutých pravidel. Obsahem balíku práce je samotný popis očekávaného produktu a poţadavek na reportování a posílání zpráv o současném stavu. Tyto poţadavky můţeme shrnout a nazvat jako strategie řízení komunikace. Obsah balíku dále popisuje, jak dosáhnout poţadované kvality a konečné předání produktu jako strategie 34

řízení kvality, jak řešit výskyt problémů se změnami a udrţování konfigurace. Verze v pracovním balíku nazýváme strategie řízení konfigurace a přístup k rizikům se nazývá strategie řízení rizik. Realizování balíku práce Celý projektový tým a jejich vedoucí začínají vytvářet produkt a zároveň je třeba intenzivně kontrolovat kvalitu produktu a současně poskytovat potřebné informace projektovému manaţerovi. Poskytnutá zpráva o stavu balíku by měla obsahovat vyhodnocení současného stavu práce balíku, pokrok od poslední zprávy a odhad budoucího vývoje pro následující období. Dodání ukončeného balíku práce Ukončení představuje realizovanou techniku, posuzuje kvalitu a získá schválení produktu. Projektový manaţer obdrţí od vedoucího projektového týmu balík práce, který uţ je jen dokumentací o tom, ţe vytvářený produkt byl dodán a prošel procesem schválení. S tímto předáním je zapotřebí kontrola kvality a záznam konfigurační poloţky o tom, zda byl produkt správně vytvořen a došlo k jeho zaznamenání. Řízení dodávky obsahuje předání prvotních poţadavků na vytvoření produktu projektovým manaţerem, sledování tvorby produktu a koncové předání.

2.4.6 Přechod mezi etapami (Managing stage boundaries , SB) Cílem tohoto procesu je snaha o zajištění a předání dobrých informací projektovému výboru a tyto podklady slouţí k rozhodnutí k pokračování projektu a k ţivotaschopnosti projektu. Za stejným cílem slouţí také rozhodnutí o pokračování projektu z vytvořeného plánu výjimek, ale s tím rozdílem, ţe se větší důraz klade na informace o výjimce neţ o konci etapy. Etapa má za úkol ubezpečit projektový výbor o jejím úspěšném ukončení a ţe následující etapa bude probíhat přesně podle plánu projektu s realizací dané naplánované části. K ujištění je třeba poskytnout informace k jiţ ukončené etapě nebo k současnému dni poskytnutí informací při výjimce a aktuální stav projektových dokumentů. Máme na mysli dokumenty, které zahrnují zdůvodnění projektu, plán projektu, současný stav se zohledněním rizik a seznam zjištěných ponaučení. U konce kaţdé etapy mohou nastat změny a bude potřeba s nimi počítat do další fáze. Můţe dojít ke změně uvnitř projektového týmu, můţe

35

nastat změna v přístupu k probíhajícímu projektu a nebo jiný pohled na vytvářené produkty. Kaţdou změnu je nutno uvést v dokumentaci o nastavení projektu PID a to úpravou specifických dokumentů, ve kterých se tato změna vyskytuje. Projektový výbor má moţnost změny schválit, kdyţ si projektový manaţer zaţádá o pokračování projektu další etapou. Samotný proces přechodu mezi etapami je nejčastěji prováděn na koncích etap, aby zbyl čas pro připravení dokumentace pro další fázi. V druhém případě se řízení přechodu můţe vyskytnout při výjimce. Aktivity v obou případech obsahují: Aktualizace plánu projektu Ukončení etapy projektu je důvod k aktualizaci dokumentů. K aktuálnímu datu musí plán projektu obsahovat všechny informace o uplynulých událostech. Současně se v plánu projektu doplní informace o událostech následující etapy. Příprava plánu pro další etapu V přípravě je nezbytné naplánování následující etapy na úrovni největších detailů pro dodání naplánovaných produktů. Kdyţ dojde ke spuštění přechodu mezi etapami v důsledku výjimky, pak plán přípravy nahradí plán výjimky. Aktualizace obchodního případu Důraz je zaměřen na obnovení informací o nových poznatcích, přínosech, problémech a objevených rizikách. Můţe dojít k aktualizaci i v jiných částech, například změna nákladů. Zpráva o ukončení etapy Popisuje veškeré uskutečněné události z předchozí etapy a vyhodnocuje ukončenou etapu z hlediska pouţitých tolerancí, nápravných opatření a vyřešených problémů s riziky. Není od věci se také zmínit o práci projektového týmu včetně jejich komunikace.

36

2.4.7 Ukončení projektu Poslední etapa v řízení projektu musí obsahovat finální přijmutí vytvářeného produktu. Musí být potvrzeno splnění cílů s odsouhlasenými změnami, které jsou uvedeny v dokumentaci o nastavení projektu PID. Druhá moţnost ukončení projektu tkví v tom, ţe realizování projektu jiţ nepřináší ţádný prospěch a je nejvyšší čas ukončit projekt. Poslední moţnost, kdy je třeba projekt ukončit, nastane v situaci, kdy uţ ztratí své odůvodnění a opodstatnění. Účelem ukončení je, aby byl projekt ukončen po organizovaném a uváţeném rozhodnutí, i kdyţ se jedná o řádné plánované ukončení či o konec předčasný. Zvláště je hodně důleţité co nejvíce zdokumentovat předčasně ukončený projekt. Vytvořením záznamu se sestaví přehled získaných poznatků v průběhu projektu. Aby to bylo moţné zajistit, je potřeba udělat následující: Akceptování produktů uţivateli. Zajištění podpory produktů po ukončení, tedy převzetí finálními uţivateli. Realizování projektu se změnami se porovná se zadáním projektu. Finální podobu dokumentů je nutno porovnat s původní podobou vytvořenou v inicializaci. Přezkoumání neuskutečněných přínosů a dojde k zhodnocení realizovaných přínosů. Přínosy v plánech revizí jsou vytvářeny v etapě nastavení a je pravidelně aktualizován novými poznatky Posouzení všech problémů a rizik. V celkovém souhrnu ukončení projektu jde o to, aby byly uzavřeny veškeré otevřené nebo aktivní dokumenty a běţící systémy. Nedílnou částí je vypracování zprávy o ukončení projektu. Mimo jiné se zdokumentují další aktivity pro koncové uţivatele. Zjištěné poznatky poslouţí jako podklad pro vytvoření zprávy o získaných poznatcích, která poslouţí jako hlavní a vstupní informace pro vytvoření dalších projektů.

37

2.5 Certifikace PRINCE2 2.5.1 PRINCE2 Foundation Základní kurz Foundation má za cíl účastníkům vysvětlit a objasnit základní filozofii, na které je celá metodika PRINCE2 postavena. Účastníkům by měl kurz pomoci pochopit podstatu a pomoci se kvalitně připravit pro zakončení mezinárodní certifikací PRINCE2 Foundation. Základní kurz poskytuje mimo jiné teoretický základ pro vyšší úroveň certifikace Practitioner. Kurz projektového řízení se doporučuje pro manaţery projektů, vedoucí, koordinátory projektů, analytické pracovníky a všechny, kteří buď projekty řídí nebo se přímo na nich podílí, chtějí se seznámit a poznat metodiku PRINCE2 a mají zájem získat certifikát, který potvrzuje jejich znalosti projektového managementu.

2.5.2 PRINCE2 Practitioner Jedná se o pokročilý kurz úrovně řízení projektů podle PRINCE2. Hlavním cílem kurzu je, aby se účastníci procvičili a zdokonalili v řízení projektů a osvojili si jistotu v řízení projektů podle celosvětově uznávané metodiky. Po absolvování kurzu je účastník připraven sloţit certifikační zkoušku PRINCE2 Practitioner. Kurz je vhodný pro manaţery projektů, vedoucí, koordinátory projektů, analytické pracovníky a všechny, kteří si chtějí zdokonalit aplikování metodiky řízení na svých vlastních projektech. Samotná certifikace probíhá tak, ţe kandidát musí prokázat znalosti aplikování metodiky v projektu podporující PRINCE2. Platnost certifikátu je 5 let.

2.5.3 PRINCE2 Professional Nejvyšší certifikace se od předchozích odlišuje tím, ţe předchozí dvě se zaměřují pouze na výuku a míru znalostí pochopení metodiky PRINCE2. Kurz testuje řízení jednoduchého nejednotného projektu v průběhu celého ţivotního cyklu. Sloţení certifikace probíhá v tzv. Assesment centru, kde se prověřuje schopnost pouţít znalosti metodiky v praxi. Nejedná se o ţádný písemný test, ale o dvou a půl denní seminář. Platnost certifikátu je prozatím časově neomezená a v České republice se doposud ţádný seminář neuskutečnil.

38

3 IT projekt pořízení měřícího softwaru 3.1 Seznámení s firmou Pöttinger Společnost Pöttinger byla zaloţena v roce 1871 v Rakousku a přes několik hlavních milníků se společnost v současné době vypracovala mezi hlavního leadera na celosvětovém trhu se stroji na sklizeň píce a stroji na zpracování půdy a setí.

Obr. 10 - Logo firmy Pöttinger15

3.1.1 Historie s milníky Rok

Informace o milníku

1871

Zaloţení firmy

1960

Hlavní motiv zelený program, kde se firma specializovala na mechanizaci prací na loukách a ve velkých sériích produkovala obraceč sena, který se stal opravdovým milníkem v oblasti mechanizace práce ve svahu.

1963

Začal vývoj průkopnického sběracího vozu. Následně se společnost Pöttinger stala největším výrobcem těchto vozů.

1975

Společnost koupila továrnu na výrobu pluhů Bayerische Pflugfabrik v bavorském městečku Landsberg na Lechu a začalo rozšiřování výroby v oblasti strojů na obdělávání půdy.

1991

Do vedení firmy nastoupila čtvrtá generace rodiny Pöttingerových. Sortiment se rozšířil o výkonné stroje pro velkoplošnou sklizeň krmiva.

15

[2014-03-21], [online], Dostupné z WWW: < http://www.poettinger.at/img/landtechnik/collection/logos/Logo_Poettinger_2lines_4c.png >

39

1999

Pokračování dynamického vývoje společnosti Pöttinger zavedením nových polonesených pluhů lisů na kulaté balíky a ovíječek.

2001

Došlo k převzetí firmy Rabe Sätechnik v Bernburgu a tím společnost rozšířila nabídkový program o stroje v oblasti obdělávání půdy a o stroje na pneumatické, mechanické a mulčovací setí.V roce 2004 došlo k rozšíření nabídky o mulčovací secí stroj Terrasem a diskové podmítačetypu Terradisc.

2006

Na veletrhu Agritechnika v Hannoveru byl představen nový typ čelní nesené ţací techniky a-motion, která znamenala obrovský krok kupředu v oblasti čelně nesených ţacích strojů. Společnost byla vyznamenána skotskou společností Royal Highland and Agricultural Society za svá inovativní elektronická řešení ISOBUS.

2007

Dochází k otevření nové výrobní haly ve Vodňanech. Dokončilo se nové zákaznické centrum v Grieskirchenu, kde se začaly organizovat prohlídky závodu, které se stávají opravdovým záţitkem.

2008

2009

Dochází k rozšíření montáţní haly v Griekirchenu a dokončila se současná podoba výrobní haly ve Vodňanech. Otevření nejmodernějšího práškovacího zařízení v centru kompetencí v závodě na secí techniku v Bernburgu. Senáţní vůz Jumbo získává ocenění stroj roku na výstavě Agritechnika.

2012

Došlo k zaloţení třech nových společností na prodej techniky v Irsku, Belgii a ve Velké Británii.

2013

Byla vyvinuta nová generace pneumatických secích strojů Aerosem. Stroj získal ocenění "Stroj roku 2014" na výstavě Agritechnika. Tab. 2 - Milníky firmy Pöttinger

40

3.1.2 Současnost V současné době má firma Pöttinger v provozu tři závody v rámci tří zemí. Hlavní závod je umístěn blízko rakouského Linze v městečku Grieskirchen, v České republice firma působí ve městě Vodňany a v Německu stojí závod v městečku Bernburg. Po více neţ 135 letech fungování podniku jsou nyní v čele firmy bratři Mag. Heinz Pöttinger a Dipl.Ing. Klaus Pöttinger. Nyní je v podniku zaměstnáno 1475 lidí s ročním obratem 303 miliónů eur. Celý koncern se snaţí udrţet výrobní procesy v rámci rodinné atmosféry a chce být podnikem, kde lidé rádi pracují.

Obr. 11 - Podíl na dosaţeném obratu v rámci geografie16

3.2 Organizace firmy Celá struktura fungování výrobního procesu ve Vodňanech je postavena na klasickém liniovém uspořádání řízení. Rozhodování na nejvyšší úrovni provádí ředitelka a ta dále deleguje informace skrze manaţera výroby do jednotlivých oddělení. Hlavní princip spočívá v pravidelné a časté komunikaci mezi řídícími pracovníky jednotlivých oddělení a pracovníky na spodní úrovni, jak je znázorněno na následujícím obrázku. Minimálně jednou za den se konají schůzky, na nichţ jsou řešeny návaznosti výroby na dalších závody, interní problémy nebo řešení reklamací.

16

[2014-03-21], [online], Dostupné z WWW: < http://www.poettinger.at/img/unternehmen/en_umsatzaufteilung.gif>

41

Obr. 12 - Schéma organizace továrny ve Vodňanech

3.3 Hlavní výrobní procesy Společnost Pöttinger má ve svém nabídkovém portfoliu na výběr desítku strojů s několika modifikacemi a rozšířenými úpravami. Z tohoto důvodu bylo vytvořeno několik hlavních výrobních procesů pro výrobu. Ve většině případů aţ na pár výjimečných situací, vychází na jednu vyráběnou modelovou řadu vţdy jeden hlavní proces. Kaţdý hlavní proces spoluutváří několik vedlejších podpůrných procesů, bez kterých by hlavní proces nemohl probíhat a nemohl by být dokončen. Pro náš případ zde uvedu například výrobní proces stroje typu rotační brány Lion 3002. Sloţení procesů je ve zjednodušené formě zobrazeno na následujícím obrázku. Je samozřejmé a nemyslitelné, aby se hlavní procesy v určitých fázích výroby neprotínaly a v určité fázi výroby neběţely souběţně. V našem případě u modelové řady Lion je na výběr hned z několika různých variant stroje. Můţe to být například šířka stroje od 3 m do 5m nebo výběr typu zarovnávacího válce. U většiny strojů s nabídkovou modifikací se hlavní proces rozchází aţ těsně u samého konce, kde se na montáţní lince kompletují jiţ konečné díly stanovené modifikací. Po většinu procesu běţí výroba hromadně jako například dodání materiálu, řezání laserem, svaření, mechanické opracování a lakování. Samozřejmě u většího typu stroje Lion 4002 je proces osamostatněný a běţí souběţně s ostatními.

42

Obr. 13 - Výrobní proces stroje Lion 3002

3.3.1 Pracovní postup dílu do stroje Lion 3002 Pro bliţší představu uvádím výrobní pracovní postup jednoho dílu, který je součástí sestavy stroje Lion 3002, přesněji je to část koncového válce. Jak je vidět na dalším obrázku, kde pracovní postup má číslované na sebe navazující výrobní operace. Číslování operací začíná označením 0010 a končí označením 0070. Tento způsob je dán faktem, ţe se operace snadno od sebe vizuálně odlišují, neţ číslování 01, 02, 03 atd. Kaţdá operace má své identifikační číslo, označení pracoviště a číslo následujícího pracoviště. Některé výrobní operace mohou být vykonány najednou, jako je tomu u operací 0050 a 0060 lakování. Díl je navěšen na lakovací linku a v průběhu je nalakován základovou vrstvou a následně nalakován ţlutou barvou. V uvedeném pracovním postupu není zanesena operace kontrola kvality. Je to z toho důvodu, ţe díl je nový a bylo v předchozí době vyrobeno několik vzorků a ty měly v postupu kontrola tvaru. Více o začlenění kontroly kvality do výrobního procesu je rozepsáno v kapitole 3.4.

Obr. 14 - Ukázka výrobního procesu dílu Konusfederelement 6mm

43

3.4 Začlenění kontroly kvality do výrobního procesu Kvalita vyráběných strojů je řešena pouze průběţným stylem řízení jakosti. Tato skutečnost se nechá vysvětlit tím, ţe v tak obrovském mnoţství výrobních kapacit není k dispozici dostatek kontrolních mechanismů. Výrobní proces běţí bez větších zásahů kontroly kvality, vyjma případů, kdy v průběhu výrobního procesu dojde k odchylce. Pak se do procesu zapojí dočasný podpůrný proces kontroly kvality. Tímto se dostáváme k tématu mojí diplomové práce, proč je potřeba udrţovat kontrolní mechanismy aktualizované a je potřeba jejich modernizace. Ve velkém mnoţství procesů skrze celé portfolio dochází k častému zasahování kontroly. Můţe se jednat o nahlášenou reklamaci z pole na špatnou konstrukci nebo nedodrţený pracovní postup. V tomto případě nastupují kontrolní mechanismy do výrobního procesu na delší dobu. Můţe nastat situace, kdy je zapotřebí dodrţet 100 % kontrolu vyráběných dílů a při nedostatku moderních kontrolních prostředků a kapacit dochází k nedodrţení časového plánu procesu. Zde se začíná objevovat myšlenka mechanizované kontroly a zpracování výsledků. Při měření sloţitějších dílů dochází ke zvýšení časové náročnosti měření a je hlavním cílem se zamyslet nad tím, jak tento čas co nejvíce zkrátit na minimum. Kaţdému není potřeba zdůrazňovat, ţe měření za pomoci svinovacího metru, úhelníku a úhloměru je příliš zdlouhavé. Dopočítávání rozměrů a vytváření výsledných protokolů v programu Microsoft Excel není dobrá cesta na úspěch. Proto je zapotřebí tento podpůrný proces automatizovat pořízením měřícího softwaru s vhodnou měřící periferií. Po důkladné analýze kontrolního procesu byl zjištěn fakt, ţe vytvoření programu v měřícím softwaru prodlouţí potřebný čas na začátku měření, ale s postupem času dojde ke zkrácení měření aţ na 1/5 původního času.

44

Graf č. 1 - Úspora času a zrychlení kontroly dílu za pouţití měřícího softwaru

3.5 Obchodní případ potřeby nového měřícího softwaru Firma Pöttinger působí na trhu s úzkým profilem výrobců dodávajících zemědělskou techniku, ale o to je tvrdší konkurenční boj v této oblasti podnikání. Celý koncern se drţí obchodní strategie ve stylu "hraj, nebo budeš poraţen" a pro to se snaţí dodávat na trh co nejkvalitnější produkty. Aby se mohlo dosáhnout poţadované kvality, je zapotřebí neustále inovování výrobních procesů a mít k dispozici co nejmodernější měřící prostředky. V počátcích firmy se jednotlivé sestavené stroje dělaly pouze v pár kusech a kaţdý stroj byl vytvořen coby originál. Postupem času se začaly rozšiřovat výrobní procesy a bylo dosaţeno technologického skoku ve sloţitosti a funkčnosti strojů. Proces vývoje ale bylo třeba sledovat, kontrolovat a získávat naměřené hodnoty a podle hodnot upravovat návrhy strojů. Začátky měření se odvíjely pouze od toho, jaký byl k dispozici svinovací metr a popřípadě vyrobený zkušební přípravek, takzvaný etalon 17 . Postupem času se začaly objevovat úhelníky, úhloměry, posuvná měřítka a jejich digitalizované náhrady. Vrchol měření a kontroly dílů byly a jsou pouţívány výškoměry, takzvané "nádrhy". V poslední modernizaci byl pořízen do závodu v Grieskirchenu měřící optický stroj Metris K-600 od renomované značky Nikon. 17

Etalon je kontrolní přípravek, který je nastaven podle určité velikosti vzoru nebo podle rozsahu stupnice či úhlového nominálu. Přiloţením a porovnáním etalonu s měřeným dílem niţší přesnosti poznáme vizuálně odchylku dílu a můţeme rychle rozhodnout o správnosti dílu. Například tyč o délce 1000 mm.

45

Přístroj na měření obsahoval pouze implementovaný software na vyhodnocení výsledků v těle přístroje. Tento postup měření probíhal od pořízení Metrisu K-600 v roce 2009 aţ do července roku 2012, kdy se vedení rozhodlo změnit dosavadní přístup ke kontrole vyráběných strojů. Hlavní rozhodovací impuls byl vydán 1.7.2012 ředitelem celého koncernu, panem Ing. Klausem Pöttingerem, který nechal svolat předem plánovanou celodenní schůzku v řídící továrně v Grieskirchenu. Na jednání se začalo debatovat o hlavní myšlence podstaty nové generace měření. Byla vyslovena základní otázka: "Je potřeba zavedení nového měřícího softwaru a jeho příslušenství?" V současné chvíli výroba probíhá s dosavadními měřidly bez větších obtíţí, proč je tedy nutné zavést nový měřící software. Není lepší zaměstnat více zaměstnanců kvality a nechat zaběhnutý systém bez větších změn? V dnešním konkurenčním boji jsme příliš pomalí na rychlost případných změn v procesu a hodně rozměrů pouze odhadujeme. Nejsme schopni přesně určit tvar velkých svařených dílů. Hlavní důvody pořízení softwaru: a) Nemoţnost změření větších dílů a získání sloţitějších rozměrů jako například roztečné kruţnice a úhlové rozměry na velké vzdálenosti. b) Nemoţnost měření svařovacích přípravků. c) Odhadování tvaru kalících forem a lisovacích šablon. d) Pomalé reagování na reklamace z pole a zdlouhavé předání měřících postupů ve všech závodech společnosti Pöttinger. e) Centralizace naměřených protokolů. f) Urychlení vzorování nového dílu.

46

Obr. 15 - Hrubý návrh průběhu zavádění softwaru

3.6 Vize návrhu hardwarové struktury Celá podniková informační infrastruktura je zaloţena na vytvořeném centrálním serveru v Grieskirchenu. Nový měřící software a jeho zálohování bude implementováno na jíţ vytvořené infrastruktuře. Všechny měřící protokoly budou uloţeny na jednom místě, přesněji na síťovém disku "I". Blíţe určená cesta bude: I:\quality\measure_protocols.

Obr. 16 - Schéma vize propojení měřících stanic

47

3.7 Požadavky na nový měřící systém Nový měřící software musí pokrýt všechny současné metody měření a ještě k nim přidat další moţnosti získání ostatních rozměrů. a) Stabilní program Program musí splňovat vysoké kriterium stabilnosti systému bez větších pracovních omezení jako je zadrhávání, pomalé zpracování výsledků, špatná stabilita připojené měřící periferie atd. b) Kompatibilita přesunu měřícího ramene Program musí být připravený na časté odpojování a připojování měřící periferie. Program musí obsahovat moţnost instalace dalších driverů jiné měřící periferie v průběhu jiţ otevřeného měření. c) Moţnost importování CAD modelu. Software by měl obsahovat funkci importování nominálního CAD modelu, ke kterému se bude měření vztahovat. Software musí obsahovat komponentu porovnání tvaru nominálního geomu s měřenou tvarovanou plochou. d) Výstupní reporting s podporou úpravy vzhledu hlavičky a změny zobrazených údajů Výstupní protokoly musí obsahovat moţnost změny veškerých naměřených hodnot. Tím je myšleno například report pouze informace o velikosti průměru, nikoliv souřadnice x,y,z středu kruţnice. Software musí mít moţnost změny titulní hlavičky s názvem měření, číslem měřeného dílu, jménem pracovníka a datem měření. e) Snadná obsluha grafického prostředí Grafické prostředí musí být přívětivé a snadno zapamatovatelné pro obsluhu. Mělo by se předejít tomu, aby pracovník kvality nemusel zdlouhavě hledat programové komponenty, jako je například konstrukce geometrických tvarů. f) Dostupnost v českém jazyce

48

Jelikoţ firma Pöttinger působí ve třech zemích s odlišným mateřským jazykem, musí software nutně obsahovat minimálně tři světově uznávané jazyky a to angličtinu, němčinu a češtinu. g) Uţivatelská podpora Dodavatel softwaru musí do 48 h od nahlášení problému zajistit znovu zprovoznění softwaru. V případě kladení jakéhokoliv dotazu a technické podpory musí dodavatel reagovat odpovědí do 5 pracovních dní. h) Manuál k obsluze Dodaný software musí mít vypracovanou tištěnou literaturu ohledně ovládání a práce s programem. V případě nedostupnosti vypracovaného tištěného manuálu musí software obsahovat přehledně zpracovanou nápovědu. Jazyk není podstatný. Musí být ale v jednom ze tří výše uvedených v bodě f. i) Zaškolení v rámci instalace Dodavatel v rámci instalace software provede zaškolení obsluhy měřícího programu v době nezbytně nutné pro pochopení základních úkonů. j) Podpora 64-bitového operačního systému Nainstalovaný software musí být ve verzi pro 32-bitové i 64-bitové operační systémy. k) Moţnost další aktualizace softwaru Dodavatel musí zaručit dodání a instalaci nových aktualizací současné verze softwaru. V případě vydání nové verze programu musí informovat vedoucího pracovníka. l) Příprava programů v offline reţimu Software by měl obsahovat moţnost instalace na více pracovních stanic, přičemţ na jedné by probíhalo samotné měření s obsluhou a na druhé pracovní stanici by se paralelně vytvářely měřící programy.

49

3.8 Časový plán zavedení softwaru Původní plán zavedení měřícího softwaru do společnosti Pöttinger měl spočívat v postupném zavádění softwaru do všech třech závodů. Vedením firmy bylo rozhodnuto, ţe jako první bude zaveden měřící software v mateřském závodě v Rakousku v Grieskirchenu. Další v pořadí s ročním odstupem následoval náš podnik ve Vodňanech. Jako poslední následoval nejmenší podnik v Německu závod Bernburg. Hlavní důvod postupného zavádění inovace byl finanční aspekt. Zde se nebavíme o částkách v řádu desítek tisíc, ale stovek tisíc za licenci programu a řádově do dvou miliónů za pořízení měřící periferie. Na následujícím obrázku je zobrazen Ganttův diagram o průběhu zavádění softwaru, tak jak proběhlo v našem podniku. Poslední část zavádění byla ukončena teprve před několika měsíci.

Obr. 17 - Ganttův diagram zavedení měřícího softwaru

a) Výběrové řízení: software a periférie Výběrové řízení celé měřící soustavy se odehrávalo pouze v hlavním závodě v Grieskirchenu. Zde má sídlo kompletně celé vrcholové vedení koncernu Pöttinger. Z hlediska financování projektu je tento krok rozhodování pochopitelný. Na ostatní dvě továrny je v tomto případě pohlíţeno pouze jako na dodavatele komponent pro montáţ strojů. Výběrové řízení probíhalo systémem kontaktování vybraných výrobců měřících softwarů a periférií. Informace o všech dodavatelích projektu jsou více popsány v kapitole 3.9. Pro výběrové řízení byly vybrány tři firmy, které splňovaly prvotní poţadavky na měřící systém. Kontaktovaní dodavatelé měli čas na podání nabídek do 20.9.2012. Zbylých deset dní do 30.9.2012 mělo vrcholové vedení na vybrání výherce výběrového řízení. 50

Rozhodovací tým se skládal ze tří členů a komunikace probíhala jen mezi těmito členy. Do role projektového manaţera byl postaven se svou funkcí manaţer kvality, protoţe realizovaný projekt se odehrával v rámci jeho oddělení. Schéma komunikace je znázorněno na následujícím obrázku. Kromě těchto tří osob do výběrového řízení nikdo další nezasahoval. Jako výherce měřícího softwaru byla vybrána firma Delcam s jejich programem Power Inspect. Měřící přístroj byl vybrán od firmy Faro s jejich měřícím ramenem Edge Arm. Oba dva vybraní výrobci nejvíce splnili očekávání v poměru ceny, funkčnosti a kvality. Měřící stanice, nebo-li klasický notebook, byla vybrána od známé firmy Hewlett-Packard. Dne 4.10.2012 byly podepsány smlouvy o dodání produktů, tedy se čtyř-denním zpoţděním oproti původnímu plánu.

Obr. 18 Schéma komunikace pořízení měřící soustavy v Grieskirchenu

b) Grieskirchen: dodání software a periférií Všechny produkty byly dodány do 20 dní od podepsání smluv. Kaţdý produkt byl dodán v krabici zabalený ve výrobním stavu. Sestavení proběhlo podle přiloţených manuálů měřícího ramene. c) Grieskirchen: instalace a zaškolení Sestavení a nainstalování softwaru proběhlo pouze dvěma zaměstnanci kvality. Nainstalování softwaru proběhlo bez větších obtíţí. Jediný problém se vyskytl s autorizačním

51

klíčem zvaný "dongle" 18 . Jelikoţ se dongle nehlásí jako klasické paměťové zařízení, byl problém s jeho implementací v programu Power Inspect. Zaškolení bylo naplánováno za dva měsíce od dodání sestavy. Byl zde vynechán časový interval, který slouţil pracovníkům kvality na seznámení a osahání softwaru vlastníma rukama. Zaškolení provedla rakouská pobočka firmy Delcam. Školení bylo provedeno na ukázkových blocích pouţívaných pro obecné školení. d) Vodňany: dodání software a periférií Na základě zkušeností pouţívání softwaru v Rakousku, bylo stanoveno dodání softwaru a periferie aţ na říjen 2013. V Ganttově diagramu je zřetelné, ţe dodání softwaru do Vodňan bylo zpoţděno oproti Grieskirchenu o deset měsíců. Toto uměle vyvolané zpoţdění mělo za následek to, ţe některé problémy s chybou dílu byly řešeny aţ třikrát déle a bylo spotřebováno více logistických kapacit. Následující schéma zobrazuje komunikaci tří činitelů se zavádějícím postupem. Druhou fázi projektu, zavedení softwaru ve Vodňanech, řešili pouze manaţer kvality koncernu, ředitelka Vodňan a manaţer výroby koncernu. Manaţerovi kvality byl pouze oznámen datum dodání a na předběţné názory nikdo nebral zřetel. Podle Ganttova diagramu je patrné, ţe dodání a instalace produktu proběhla v říjnu 2013. Navzdory tomu ale zaškolení bylo realizováno aţ v únoru roku 2014.

Obr. 19 - Schéma komunikace pořízení měřící soustavy ve Vodňanech

18

Dongle je USB zařízení (vzhledově podobné USB flashce), které obsahuje šifrovací soubory pro spuštění programu s licencí. Pro spuštění a plnohodné funkce sw musí být usb dongle zastrčen v USB portu notebooku.

52

e) Vodňany: instalace Samotný nástup měřícího ramene s měřícím softwarem nebyl příliš jednoduchý a byl poněkud krkolomný. Datum dodání softwaru a měřícího ramene byl 1. 10. 2013. Jeden měsíc bylo rameno zabaleno a leţelo v krabici, protoţe nebyla zaručena synchronizace dodání ramene a notebooku se softwarem. Software byl zaveden do provozu aţ k 1. 12. 2013. f) Vodňany: zaškolení Zaškolení odbornou firmu Metrotest s.r.o. proběhlo aţ koncem února letošního roku, tedy dva a půl měsíce po zavedení do provozu. Firma je třetí strana, která se zabývá dodáním měřících ramen a součást podnikového portfolia je školení softwaru Power Inspect. V té době jsem jiţ byl zaměstnancem firmy na pozici programátora 3D měřícího přístroje a musel jsem se spolehnout na své praktické zkušenosti a znalosti. Obě dvě části k měření (rameno a software) nám bylo dodáno od dodavatele pro Českou republiku. Při předání došlo pouze k podpisu předání zboţí a byla předána faktura za zboţí. My jako pracovníci kvality jsme museli produkt rozbalit, sloţit a připravit do konečného stavu k měření. Protoţe měřící rameno a software je pokaţdé od jiné společnosti, tak nebylo k dispozici dostatek materiálů a návodů. Rameno návod obsahovalo, ale měřící program nikoliv. Podle současných měřících přístrojů, které byly jiţ dříve pořízeny, se nedalo ihned zahájit měření. Podle získaných vědomostí jsem sice věděl, ţe měření probíhá pokaţdé v několika stejných krocích, nebyl jsem schopen ihned aplikovat moje znalosti z důvodu rozdílnosti měřícího softwaru. Postup měření: I. II.

Kalibrace. Spuštění softwaru a připojení ramena.

III.

Vytvoření zarovnání přenesením souřadnic stroje na souřadnice dílu.

IV.

Měření dílu.

V.

Vyhodnocení naměřených údajů.

Nejvíce času bylo stráveno nad problémem, neţ bylo pochopeno uspořádání programových komponent, jako např. vytváření sloţek s měřením, konstrukce geometrických tvarů a vytvoření grafického protokolu. Z postupu měření se hodně času strávilo tím, jak díl správně zarovnat pomocí zarovnání šesti bodů (nebo také 53

jinak rovina-přímka-bod) nebo za pomoci RPS bodů. Po vyřešení problémů informační bariéry je software funkční a práce s ním probíhá 24 hodin 5 dní týdnu. Větší nedostatky, na které se přišlo pouţíváním, rozeberu v další kapitole. g) Bernburg: dodání software a periférií Poslední etapou projektu bylo zavedení měřícího softwaru v německém Bernburgu. Zde se vrcholové vedení ponaučilo z chyb vyplývajících se zaváděním v České republice. Dodání produktů bylo naplánováno zároveň s termínem školení ve Vodňanech. Vzniklé problémy s reklamací většího rozsahu donutily vedení k naplánování školení softwaru na nejbliţší termín po dodání produktů. Komunikace probíhala opět v úplně jiném schématu neţ u dvou předchozích. Ředitelé továren v Rakousku a České republice stanovili po vzájemném uváţení datum pořízení měřící soustavy.

Obr. 20 - Schéma komunikace pořízení měřící soustavy v Bernburgu

h) Bernburg: instalace Uvedení do provozu softwaru v třetí fázi projektu vycházelo z chyb vzniklých při předchozích dvou instalacích. Z toho důvodu instalaci v Bernburgu provedli pracovník IT a zaměstnanec kvality z Grieskirchenu. Uvedení do provozu se urychlilo na základě předchozích zkušeností s instalací. Celková doba strávená nahráním programu byla cca 4 h. i) Bernburg: zaškolení Při zaškolování v německém závodě se ukázala jako pravdivá známá fráze „nejlepší nakonec“. Školení proběhlo výrobcem softwaru Delcam- jejich autorizovanou německou pobočkou. Protoţe školení bylo od začátku plánováno co v nejkratším čase po dodání,

54

nevznikl zde ţádný prostoj měřící sestavy, kdy se museli zaměstnanci se softwarem seznámit sami.

3.9 Vhodní výrobci měřících sestav 3.9.1 Výběrové řízení softwaru pro měření a) Power Inspect Software je postavený na hlavní oblasti porovnání vyrobeného dílu s CAD modelem. Program je připravený na připojení kterékoliv měřící sondy dohráním potřebného driveru. Software je připravený na programování v offline módu a na druhém zařízení můţe souběţně probíhat měření. Program podporuje mezinárodně uznávanou normu Vybraným softwarem se stal proto, ţe společnost Delcam má oficiální zastoupení ve všech třech zemích s rychlou technickou podporou, kde má firma Pöttinger postavené závody. Mimo jiné je software vytvářen pro pouţití na přenosných počítačích s jedním monitorem. Prostředí programu je řešeno stylem, kde se kaţdý pracovník rychle naučí software ovládat. Výstupní protokoly lze upravovat za pomoci HTML a průběh programu ovlivňovat pomocí jazyka Visual Basic.

Obr. 21 - Prostředí softwaru Power Inspect

55

b) Tango 3D Měřící software od české firmy Topmes pojmenovaný Tango!3D pracuje s manuálními i plně automatickými CNC měřícími stroji. Hlavní přednost softwaru je grafické intuitivní rozhraní, které bývá napojeno na dva monitory. Grafické prostředí programu vyniká přehledným navigačním panelem s programovacími bloky, ve kterých je moţno ihned upravovat parametry měření a najíţděcí souřadnice pro měřící stroj. Celé programování je velmi jednoduché a nevyţaduje ţádné větší nároky na školení obsluhy. Měřící software zajišťuje řízení měřící periferie ve třech osách. Nákup softwaru nebyl vhodný z hlediska malé podpory cizích jazyků, navrţené grafické prostředí je určeno pro stolní počítač a nikoliv pro pouţití na notebooku.

Obr. 22 - Prostředí měřícího softwaru Tango 3!D19

3.9.2 Výběr měřící periferie Podle zjištěných vstupních analýz bylo zjištěno, ţe se kriterium výběru měřícího stroje usměrní pouze na lehká měřící ramena, která lze bez větších obtíţí přesouvat z místa na místo. Portálový typ měřícího stroje není pro tuto chvíli hlavním argumentem i přes to, ţe portálové řešení dosahuje daleko větší přesnosti měření, řádově 0,00X mm. Naproti tomu řešení transportních ramen umoţňuje měření v daleko menší třídě přesnosti a to pouze v hodnotách 0,X mm. Výběrové řízení se zaměřilo na dodání měřícího stroje typu manuální rameno, které 19

[2014-03-29], [online], Dostupné z WWW: < http://www.topmes.cz/Technologie/Software/Images/09_Tango!3D_CNC.jpg>

56

pro naše potřeby svařených dílů postačuje. Mezi všemi výrobci a typy ramen se výběr soustředil pouze na dva typy ramen od různých výrobců přibliţně stejné třídy kvality. a) Romer Absolute Arm Rameno představuje špičku mezi přenosnými rameny, které pracuje s absolutními rotačními čítači. Kvalita je bohuţel také kompenzována cenou a proto rameno nebylo vybráno. Rameno pro naše účely častého přenášení není příliš vhodné. Příslušenství je příliš těţké a stavěné na čisté prostředí.

Obr. 23 - Měřící rameno Romer Absolute Arm20

b) Faro Edge Arm Jelikoţ rameno bude pracovat ve velmi prašném a špinavém prostředí, bylo vybráno řešení od společnosti FARO. Měřící rameno bylo pořízeno díky své příznivé ceně, své přenosné hmotnosti a vysokým krytím proti vnikání prachu a vodě. Pracuje na velmi jednoduchém principu třech rotačních čítačů a jednoho 3D gyroskopického čidla. Příslušenství je stavěno na prostředí všech typů. Magnetický drţák na stůl a stativ jsou velkou předností ramene.

20


57

Obr. 24 - Měřící rameno Faro Edge Arm21

3.9.3 Výběr provozní stanice (notebooku) Od provozní stanice bylo pouze vyţadováno, aby splňovala minimální poţadavky výrobců měřících softwarů. Ve větší míře jsou tyto poţadavky přibliţně shodné.

Typ hardwaru

Přesná specifikace

1

Procesor

Alespoň 4-jádrový

2

Operační pamět

Minimálně 4 GB RAM

3

Grafická karta

nVidia nebo ATI Radeon minimáně 1GB

4

Operační systém Windows 7 nebo Windows 8

5

Myš

Tří tlačítková Tab. 3 - Minimální poţadavky pracovní stanice

3.10 Problémy zjištěné v provozu 3.10.1 Chybějící grafická karta Problém s chybějící grafickou kartou se vyskytl poměrně brzy po zavedení do provozu. Měření bez CAD modelu probíhalo bez větších obtíţí. Ale aţ po připojení CAD modelu do 21

[2014-03-24], [online], Dostupné z WWW: < http://www.g2metric.com/wp-content/uploads/2012/09/FARO-Edge-big.jpg>

58

programu se začaly vyskytovat problémy ohledně plynulosti prostředí. U programů menšího rozsahu se začalo ovládání zadrhávat a při měření dlouhých programů program začal padat. Samotný výrobce softwaru má v minimálních poţadavcích uvedeno nutnost grafické karty od výrobce NVIDIA, na kterou je testovaný a odladěný. Pracovní notebook je osazen pouze čtyř jádrovým procesorem Intel Core i5 s integrovaným grafickým čipem Intel HD graphics 4000. Výkon integrované grafické karty nestačí na plynulý provoz softwaru.

Obr. 25 - Ukázka chybového hlášení softwaru22

Následné vyřešení problému: Časté padání programu se vyřešilo částečně tak, ţe bylo nastaveno automatické ukládání programu na 30s. Tudíţ při pádu programu se neztratí naměřená data. Na dodání grafické karty je v tuto chvíli zadán poţadavek a problém by se měl vyřešit v následujících čtyřech týdnech.

3.10.2 Malý dosah měřícího ramene Při začátcích měření nikoho nenapadlo, ţe rozsah záběru měřícího ramene Faro Edge Arm nebude dostačující. Seznamování a ukázka ramene probíhal na vyfrézovaném ukázkovém demo bloku o rozměrech okolo 400 mm. Ale aţ praxe ukázala malý poloměr od snímací sondy k základně ramena. Rameno se vyrábí ve třech velikostech a to v dosahu průměru od 1,8 m, 2,7 m a 3,7 m. Naše rameno ve firmě je prostřední velikosti o záběru kruţnice 2,7 m. V březnu 2014 se vyskytl problém na díle velikosti 3,5 na délku a 2m na výšku. V tuto chvíli se ramenem dalo vţdy měřit pouze jednu stranu a pak to samé identické měření aplikovat na straně druhé. Ovšem zde vznikly dva problémy. Potřebný čas pro 22

[2014-03-21], [online], Dostupné z WWW: < http://www.amk.to/images/discussion/original/784545fdd809cca5dfee9fb78877b3220e08b2dc.jpg>

59

zdlouhavé zarovnání, které musí být provedeno dvakrát a pokud je díl kótovaný od jedné strany k druhé (rozteč), tak tento výsledek nelze ze softwaru získat. Na základě těchto skutečností proběhlo kontaktování dodavatelské firmy o návrh řešení problému. Funkce přesunu měřícího ramene vztaţené k dílu v rámci měření byl znám, ale nikdo nevěděl jak tuto funkci vyuţít.

Obr. 26 - Ukázka reálného případu krátkého ramene

Následné vyřešení problému: Dodavatelská firma nám doporučila pořízení přesouvacího setu "Leap Frog" za 1300 €. Částka nebyla schválena sponzorem projektu (paní ředitelkou) a proto muselo dojít na alternativní metodu. Nejprve se pouţil 2 mm plech s třemi otvory. Ten byl pro naše pouţití vhodný jen na měřící stůl. Poslední aktuální pouţívané řešení spočívá v sestavě tří magnetů se šrouby M6 a navrtané hlavě kuţelovitého tvaru.

3.10.3 Špatná stabilita na stativu Problém se stabilitou byl objeven aţ při řešení předcházejícího problému s přesunem ramene. Faro Edge Arm má dva způsoby uchycení k měřící podstavě. První z nich je uchycení na magnetu, kde dochází k přepólování magnetu za pomoci šroubu na inbus. Druhý způsob pouţívaný na měření velkých dílů spočívá na uchycení na duralovém lehkém stativu. Pokud stojí rameno stativu, je jeho celková výška okolo 2,2 m a těţiště je umístěno přibliţně v 1 m nad zemí. Při neopatrné manipulaci během měření dochází k přesunu ramene jen o několik

60

milimetrů, ale v měření v hodnotách menších neţ 0,1 mm to znamená přerušení programu a zahájit měření od začátku.

Obr. 27 - Špatný podstavec (stativ) ramena

Následné vyřešení problému: Pokud se měří v prostředí, kde pravděpodobnost k posunu podstavy ramene je 100%, je zapotřebí stativ o něco opřít a zamezit (aretovat) posunu alespoň jedné ze dvou os podstavy.

3.10.4 Špatné přesuny na delší vzdálenosti Dokud se měřily menší díly pouze v dosahu měřícího stolu, tento problém se neřešil. Po čtyřech měsících provozu se začaly měřit ohromné svařovací přípravky na pracovištích s automatickými svařovacími roboty. Tyto stroje se nemohou posunovat, a proto se chodí s ramenem a notebookem přímo na pracoviště vzdálené několik desítek metrů. V původním návrhu nákupu se s tímto stylem měření počítalo, ale nikdo to při plánování projektu nedotáhl do konce. V současné době se zatím měřící přístroj přesouvá za pomoci pojízdného stolu z jiného pracoviště. Následné vyřešení problému: Nutnost pořízení speciálního kovového pojízdného vozíku s brzdným systémem kol pro měření v omezeném prostoru. 61

3.11 Celkové náklady projektu Projekt od plánování aţ po realizaci nebyl svým rozsahem příliš velký, ale celkové náklady se přesto vyšplhaly aţ k několika miliónům korun českých. Do projektu od začátku nebyly započítávány platy osob podílejících se na projektu, protoţe lidé jsou stálými zaměstnanci firmy Pöttinger. Náklady na osvětlení, elektriku se také nezapočítávaly z důvodu realizace projektu ve vnitřních prostorách továren.

Poloţka

Cena za kus

Cena celkem

Pořízení a licence software Power Inspect

7 000 €

21 000 €

Měřící rameno Faro Edge Arm

64 000 €

192 000 €

Pracovní stanice (Notebook HP )

890 €

2670 €

Školení

566 €

1700 €

Náklady na dopravu

710 €

710 €

Náklady celého projektu se vyšplhaly na 218080 €, to je 6 106 240 Kč. Tab. 4 - Celkový souhrn nákladů projektu

62

4 Pořízení měřícího software podle PRINCE2 Předchozí bod diplomové práce popisoval průběh skutečného interního projektu, který byl řízen samovolnými prostředky a osobami zaměstnanými ve společnosti Pöttinger. V posledním bodě se pokusím napasovat realizovaný projekt na metodiku PRINCE2. Jsem si vědom toho, ţe zpětné popsání projektu a stanovení charakteristiky jeho průběhu je velmi obtíţné. Po konzultaci s několika lidmi mi bylo vysvětleno, ţe tento krok je skoro téměř nemoţný. Pro náš případ porovnání dvou průběhů projektu a jeho výsledného zhodnocení je to plně postačující. V knize PRINCE2 pro řízení malých projektů od pana Colina Bentleyho je pěkně vysvětleno, jak řídit malý projekt a na co si dát pozor při jeho realizaci. Na tento vzor se pokusím napasovat průběh projektu pořízení měřícího softwaru do firmy Pöttinger. V knize na straně 38 je uvedeno, ţe ţivotní cyklus řízeného podle metodiky PRINCE2 se skládá ze čtyř základních bloků. Uvedené bloky jsou pojmenované:

Obr. 28 - Ţivotní cyklus malého projektu podle PRINCE223

23

[2014-03-28], [online], Dostupné z WWW: ,,,

63

4.1 Získání představy V první části projektu je potřeba si uvědomit, čeho vlastně chceme dosáhnout. Zda bychom neměli pořídit jen elektronické ruční měřící přístroje (elektronická posuvná měřítka, nové výškoměry) a nebo pořízením sofistikovanějších nástrojů povýšit proces kontroly na vyšší úroveň. Je nutné si uvědomit, zda nám zdokonalení kontroly dílů přinese určitý technologický náskok oproti konkurenci a jestli koupě nových měřících prostředků bude do budoucna pro společnost rentabilní. Mezi první atributy získání představy bychom mohli identifikovat obchodní aktivity, které projekt bude podporovat. V našem případě se jedná o lépe kontrolovatelné díly ve výrobě a měření svařovacích přípravků a lisovacích forem. Do jiných odvětví obchodních aktivit projekt zasahovat nebude. Dalším krokem by mohlo být získání dalších podrobnějších informací týkajících se projektu, například vytvořit studii proveditelnosti a zda vůbec bude moţné projekt v naší firmě realizovat. Další krok by bylo vytvoření kompletního popisu projektu nebo-li charta projektu. Její zjednodušená podoba je uvedena dále v textu. Pro správné získání představy by bylo vhodné uspořádat jednání s pracovníky oddělení technologie a IT, kteří jsou nejblíţe dané problematice a kteří by mohli mít uţitečné poznámky ohledně pořízení měřící sestavy. Po realizaci projektu by mohly nastat komplikace, které můţeme nazvat jako seznam rizik. Seznam rizik je uveden v textu v chartě projektu. Mezi další klíčové aktivity patří určení struktury řídícího týmu projektu a identifikovat osoby, které budou na konci projektu vlastníky a uţivateli produktu. Struktura projektového týmu by mohla být sloţena ze tří manaţerů vybraných ze tří továren. Jeden na pozici manaţera výroby, druhý manaţer kvality a třetí pracovník nákupu, který bude spolupracovat s dodavateli produktů. Všechny zastoupené role mají znalosti o správném řízení lidí v týmu a proto ti by byli vhodnými kandidáty. Dále by bylo třeba zjistit, jaké dopady a v jakém rozsahu bude mít projekt na ostatní procesy ve firmě. Můţe se stát, ţe zrychlením měření nemusí logistika obsahovat dost kapacit na odváţení dílů nebo můţe nastat situace, ţe všechny díly nebudou rychle odbavovány kontrolou. Bylo by proto nutné definovat, na jaké procesy by se měřící software pouţíval a naopak kterým skupinám dílů by se úplně vyhnul. Po dokončení projektu by mělo být jasné, kdo bude výsledným uţivatelem měřícího softwaru. Přesným určením osob do budoucna předejdeme organizačním nejasnostem. Dalším aspektem, na který bychom se měli zaměřit, je ovlivnění projektu a dodaného produktu na 64

celkový firemní byznys. Co kdyby lidé pracující na projektu nestíhali řízením projektu své povinnosti a naskytly se neočekávané události k řešení. Uţ samotné reklamace z pole zaměstnají manaţery na delší časové období a měli by také řídit projekt. V druhém případě by nebylo špatné stanovení zástupců, kteří by řídili projekt v nečekaných situacích. Například manaţera výroby by mohl zastupovat mistr výroby a nebo manaţera kvality by mohl zastoupit budoucí uţivatel softwaru, v mém případě moje osoba. Od věci by také nebylo si pozvat specialisty na měřící software a měřící techniku, kteří by udělali pár posudků o nejlépe vyhovujícím softwaru pro naši společnost. Mělo by dojít k nastavení metrik plánovaných produktů, zda má pracovní stanice mít pouze displej o úhlopříčce 15,6" nebo měřící rameno má mít maximální hmotnost o 15 kg. Neměli bychom zapomenout na analyzování oblastí, které by potenciálně mohl realizovaný projekt ovlivnit. Mohlo by se stát, ţe pořízením měřící sestavy by mohly stoupnout ceny výsledných mašin. Nedílnou součástí fáze získání představy je odsouhlasení charty projektu se sponzorem projektu. V našem projektu by chartu musel odsouhlasit jeden ze dvou současných majitelů firmy, buď pan Mag. Heinzem Pöttingerem nebo Dipl.-Ing. Klausem Pöttingerem. Původní plán by mohl obsahovat pořízení softwaru do všech tří továren, ale investor projektu by mohl nesouhlasit s cenou a rozhodnout o pořízení měřící sestavy pouze do dvou továren. Pokud by majitel společnosti schválil všechny body charty projektu, přešlo by se na další etapu projektu nastavení, čili naplánování. Naplánování v počáteční fázi projektu by mělo být pouze orientační. První plánování by mělo ukázat alespoň počet etap potřebných k realizaci.

4.1.1 Analýza současné situace Předběţnou analýzou bychom mohli stanovit důsledky, které by mělo za následek realizování projektu. Analýza by byla nejlépe aplikována na: obchodní případy profilu společnosti, ochotě zaměstnanců přijmout a spolupracovat s nově zavedenými kontrolními mechanismy, úspoře všech dostupných prostředků firmy (finančních, časových), zvýšení prestiţe firmy v konkurenčním prostředí.

65

Ukázka grafů, které by rozhodly pro realizování projektu. První graf by mohl být, zda vůbec zaměstnanci chtějí změnu, druhý graf by mohl ukazovat úsporu prostředků firmy.

Graf č. 2 - Graf ukazující měřítka rozhodnutí pořízení softwaru

Graf na levé straně ukazuje výsledky dotazníku pracovníků firmy, zda chtějí změnu v podobě nového měřícího systému. Graf na pravé straně znázorňuje odhadovaných ušetřených finančních a časových zdrojů.

4.1.2 Charta projektu V popisu projektu nebudu uvádět celou a správnou dokumentaci, ale zaměřím se na hlavní části, které by v uvedeném projektu sehrály klíčové role. Prvotní informace by mohly vypadat následovně: a) Úvodní informace Autor:

Michael Brückbauer

Vlastník:

Mag. Heinz Pöttinger

Zadavatel:

A. Pöttinger, spol. s.r.o.

Označení dokumentu:

Charter_project_3D_measure_final

Verze:

final

Umístění dokumentu:

I:\Project\3D measure\Charter_project_3D_measure_final.pdf

66

b) Obsah V obsahu projektu by byl popsán hlavní záměr realizace pořízení měřícího softwaru. Co by projekt obsahoval z pohledu organizace, technických moţností, výrobních kapacit, nákupu atd. Z obsahu projektu by měl kaţdý jasně pochopit, ţe zlepšením procesu kontroly dílů dosáhneme v současné chvíli pouze pořízením měřícího softwaru. c) Rozsah projektu Měla by být jasně stanovena kritéria rozsahu. V našem případě by se jednalo o nepřesáhnutí částky 6.000,000 Kč, maximální doba realizace 2 měsíce a nebo maximální uvolnění 4 pracovníků. Mohlo by se stanovit, ţe pořízení měřícího softwaru se týká pouze několika oddělení a to úseku kvality a výroby. d) Návrh projektu Druhá část charty by obsahovala detailní návrh projektu. Byly by zde zahrnuty ceny jednotlivých součástí projektu (software, měřící rameno, notebook + příslušenství), data dodání součástí, organizační schéma projektového týmu, organizační role zodpovědností atd.

Obr. 29 - Schéma návrhu vylepšeného propojení měřících softwarů

67

e) Odůvodnění projektu Tato část by obsahovala aktuální a přesvědčivé argumenty, proč bychom měli pořídit měřící software s měřící sestavou. Odůvodnění by mohlo obsahovat analýzu úspor a ohlasy zaměstnanců, viz kapitola 4.1.1 Analýza současné situace. Stanovit potřeby, proč chceme, aby došlo k pořízení měřících sestav. f) Positivní očekávání zákazníka V této části bychom mohli definovat, jaký uţitek z realizování projektu budou mít určité skupiny pracovníků. Vedení firmy by například získalo přesnou statistiku a četnost měření jednotlivých dílů, oddělení kvality by software ulehčil, zpřesnil a zrychlil práci kontroly a oddělení nástrojárny by tím získalo nový způsob seřizování svařovacích a lisovacích přípravků. g) Akceptační kriterium Akceptace projektu by záleţela na dodrţení plánovaného rozpočtu 6 000 000 Kč, dodrţením časového harmonogramu realizace a dodrţení obsahu projektu. Aby nedošlo k situaci, ţe by se pořídilo k softwaru mnoho příslušenství včetně laserového snímače a ve výsledku by nepřinesl pozitivní očekávání z malé frekvence pouţívání. h) Známá rizika Po předběţné analýze bychom mohli odvodit, která rizika by mohla ovlivnit realizování projektu a která rizika by se mohla objevit aţ v ostrém provozu. Pro příklad uvádím čtyři rizika, která by měla negativní dopad na provoz měřícího softwaru. Za kaţdou cenu nemusí být riziko negativní. Mohla by nastat situace, kdy v průběhu plánování se nám naskytne pořídit software se 30% slevou v akci. U rizik bychom měli uvést procentuální výskyt.

68

Název rizika

Důsledky

% dopad

Výskyt v prašném prostředí

Zanesení součástí prachem a tím se můţe vyskytnout chyba stroje

70 %

Přesnost měřící sestavy

Můţe se ukázat, ţe přístroj je příliš přesný či nepřesný

60 %

Moţnost odcizení

Nutnost pořízení nové měřící sestavy

10 %

Dlouhá doba seznámení se softwarem

Obsluha se můţe se softwarem učit delší dobu a dojde ke zpomalení výroby

20 %

Tab. 5 - Seznam rizik projektu

4.2 Plánování Dobrý projekt nestačí jen dobře popsat a navrhnout, ale je zapotřebí ho také co nejlépe naplánovat. V procesu plánování by mělo dojít k jmenování projektového výboru a projektového týmu. Analýzou by se mohlo zjistit, ţe projektový tým nemusí obsahovat pozici manaţera výroby a můţe být zastoupen jinými pracovníky. Navrţené sloţení projektového výboru a týmu je v následující tabulce.

Projektový výbor

Projektový tým

Projektový manaţer

Dva majitelé

Manaţer kvality Vodňany Manaţer kvality Grieskirchen Manaţer kvality Bernburg

Manaţer kvality Grieskirchen

Ředitel továrny Vodňany Ředitel továrny Bernburg

Pracovník nákupu Tab. 6 - Navrţené sloţení projektového výboru a týmu

Ve fázi plánování je nutné přesněji identifikovat rizika, která mohou ohrozit projekt. Ve fázi získání představy byla identifikována čtyři nejpravděpodobnější rizika. Při plánování musíme rizika více podchytit a navrhnout protiopatření.

69

Název rizika

Protiopatření

Výskyt v prašném prostředí

Snaha o co největší čas měření v uzavřené místnosti

Přesnost měřící sestavy

Stanovení upravených směrnic kontroly

Moţnost odcizení Dlouhá doba seznámení se sw

Pořízení zámků na notebook, měřící rameno nebo umístění IP kamery nad pracoviště Soustředit co nejvíce pozornosti na školení obsluhy

Tab. 7 - Protiopatření rizik

Další aspekt pro plánování je stanovení úkolů jmenovanými rolemi. Projektový tým se skládá ze čtyř osob. Je vhodné rozdělit dílčí úkoly mezi všechny rovnoměrně. Návrh úkolů by mohl vypadat takto: Manažer kvality Grieskirchen: Zajištění instalace softwaru na notebooky, testování měřících sestav. Manažer kvality Vodňany:

Školení obsluhy 3D softwaru, kontrola zkušebního provozu v továrnách.

Manažer kvality Bernburg:

Řízení komunikace na projektu, kalibrace měřících sestav.

Pracovník nákupu:

Svolávání schůzek projektu, zápisy z jednání.

Nezbytným aspektem je dobře naplánovaný komunikační plán v průběhu realizace. V našem případě lze částečně odstranit pracovníka nákupu, který by měl pouze na starosti svolávání schůzek a zápisy. Pokud se přesuneme na pohled, jak by to vypadalo z mé pozice, tak hlavní komunikační uzel by měl být vytvořen mezi všemi třemi manaţery kvality a mou pozicí. Komunikace s manaţerem kvality (mým nadřízeným) by probíhala výhradně ústně a komunikace s ostatními manaţery by mohla probíhat na jiţ fungujícím systému emailů v Lotus Notes.

70

Obr. 30 - Navrţené schéma komunikace ve Vodňanech

Mezi další hlavní aspekty by patřilo také odsouhlasení konečné verze charty projektu, kde by bylo jasně patrné, ţe se nakoupí tři měřící soupravy za 6 000 000 Kč. Aby nedošlo k omylu, ţe se pořídí pouze dvě sestavy a budou se půjčovat mezi podniky. Nastavením projektových tolerancí bychom předešli k dohadům o dokoupení nově chybějících příslušenství nebo naopak nové sondy, které by se mohly během testování poškodit. Pokud by se vše naplánovalo a odsouhlasilo projektovým výborem a projektovým týmem, můţeme přejít k etapě realizace. Následující kapitola popisuje návrh průběhu reálného projektu, který by přinesl lepší výsledek.

4.2.1 Návrh plánování etap Pro tento případ bychom mohli vyjít z předchozí kapitoly, kdy projekt neproběhl plně přesně podle plánu. Při realizování se vedení firmy dopustilo několika fatálních chyb, které později ovlivnily průběh projektu. Můţeme vzít jiţ funkční výstupy z projektu a postavit na nich nový plán, který postihne více oblastí s lepším projektovým řízením. Můţeme pouţít skutečný průběh podle Ganntova diagramu z předchozí kapitoly a upravit jej následovně.

71

Obr. 31 - Ganntův diagram pořízení měřícího softwaru

Nyní bychom si mohli přiblíţit samotný průběh projektu. Uţ na první pohled od minulé verze diagramu, je vidět, ţe tímto způsobem by se projekt časově zkrátil. a) Obchodní případ: schválení projektu První etapou projektu by bylo seznámení vedení firmy s námi zamýšleným projektem. Návrh bychom přednesli na předem naplánované schůzce 1.9.2014 v 9:00 ráno v uzavřené společnosti. Pokud by vedení podniku na konci jednání souhlasilo s chartou projektu a realizací pořízení softwaru, bylo by dobré v nejbliţších dnech začít obepisovat námi zvolené dodavatele jednotlivých produktů. Další pondělí na pravidelné schůzce se všemi zaměstnanci by bylo dobré projekt představit všem spolupracovníkům. Je moţné, ţe některý ze zaměstnanců přijde s nějakým převratným a uţitečným nápadem ohledně projektu. b) Výběrové řízení: software a periférie Výběrového řízení by se měli účastnit všichni manaţeři oddělení, kterých se bude dokončený projekt týkat. V našem koncernu by se měli sjet všichni tři manaţeři oddělení kvality, všichni tři manaţeři výroby, vybraní pracovníci IT, předem vybraní pracovníci obsluhy 3D měření a pochopitelně jeden z majitelů firmy nebo jeho jmenovaný zástupce.

72

Do konečného rozhodnutí vybrání produktů je zapotřebí, aby kaţdý ze zúčastněných měl moţnost se vyjádřit. Podle zkušeností z realizovaného projektu by bylo vhodné kontaktovat více neţ jen dva dodavatele softwaru. Pro představu bych ještě rozšířil dodavatele na PC-DMIS, který se kvalitou a zpracováním rovná vybranému Power Inspectu. Při výběrovém řízení by bylo na místě, aby kaţdý výrobce předvedl svůj měřící software na předem vybraném díle firmy Pöttinger. Ukázkové demo bloky by změřily skutečné díly. Vybrané pracovní stanice by měly splňovat minimální poţadavky pro běh softwaru. Předešlo by se tím případným kolapsům softwaru. c) Nákup: 3x software, 3x měřící sestava + 3x notebook Nákup všech komponent projektu by měl proběhnout v jedné fázi. Pořízení by ušetřilo hodně finančních nákladů při následné instalaci softwaru. Při hromadném pořízení by v ţádném případě nedocházelo k dotazům jako: "Uţ nám bude dodán software?", "Proč uţ mají měřící rameno v Rakousku a my stále ve Vodňanech nemáme nic?" Nákup by se tím značně ulehčil a faktura by byla vystavena pouze jedna. d) Dodávka: měřících sestav Dodání zboţí by mělo proběhnout v co nejkratším čase od koupi, aby u všech členů projektového týmu nedošlo k utlumení euforie rozběhnutého projektu. Dodávka by proběhla pouze na jedno místo do Rakouska, kde by proběhly všechny nutné vstupní formality od předání měřících sestav se softwarem aţ po podepsání faktury majitelem firmy panem Mag. Heinzem Pöttingerem nebo Dipl.-Ing. Klausem Pöttingerem. Součástí dodávky by bylo vhodné, aby výrobce předvedl funkčnost všech produktů. Cena je vysoká a míra poškození transportem je značně velká. Zboţí po ukázce by bylo potřeba uklidit do zamčené místnosti a zamezit tím předčasným zničením z nedbalosti některým ze zaměstnanců. e) Instalace: software do notebooků Podle předem domluvených postupů dodání do Rakouska by instalace softwaru na notebooky nebyla příliš obtíţná. IT pracovník instalací prvního notebooku otestuje správnost postupu instalace a pak by snadno aplikoval postup na další dvě stanice. Tím by se zkrátila 73

doba instalace na minimální čas. Při výskytu nějaké chyby by se upravily konfigurace s připojeným měřícím ramenem hned ve všech programech. Na následujícím obrázku je znázorněna vzdálenost mezi podniky Pöttinger.

Obr. 32 - Znázornění továren Pöttinger

f) Testování: měřících sestav Testování softwaru funkčnosti a stability by proběhlo kaţdý den na jednom zařízení zvlášť. V první řadě by se ověřila podpora měřících periférií a pak by došlo k testování připojeného ramena. Postup testu by mohl vypadat následovně: Měření konstrukce by mělo obsahovat co nejvíce sejmutých měřících bodů a měřených geometrických tvarů. Tento test by nám ověřil stabilitu grafické karty notebooku. Další test by proběhl na otestování operační paměti notebooku. Spuštěním běţně pouţívaných programů při práci (Citrix, PötDoc, Lotus Notes, Sap, průzkumník, Team Center) nasimulujeme provoz měření v praxi. Posledním testem by bylo ověření reakcí měřícího ramene na dané úkony. Rychlost odezvy softwaru při stisku tlačítek, rušení signálu při připojení přes wifi.

74

Obr. 33 - Ukázka vhodného dílu pro testování

g) Kalibrace: měřících ramen Dalším krokem by následovala profesionální kalibrace dodavatelskou firmou. Prvotním měřením by se pouze testovala kompabilita všech součástí sestavy, ale nikoliv přesnost. Dodatečná kalibrace by zajistila přesné výstupy měřených dílů. Po kalibraci by byl vystaven kalibrační list, který by se uloţil k ostatním měřícím přístrojům. Pokud by došlo k reklamaci na špatně změřený díl a ukázala by se vina kalibrace, mohli bychom uplatnit náhrady. h) Školení: obsluhy Při splnění předchozích fází projektu bychom začali se školením obsluhy 3D měřícího softwaru. Školení by se účastnili pracovníci ze všech tří továren. Školení by bylo objednáno přímo od výrobce softwaru, který program důkladně zná a bude schopen zodpovědět případné dotazy. Probíhalo by celý týden po 8 hodinách denně. Školení by mělo připravit budoucí obsluhu pro ostrý provoz. Na školení by se měly představit všechny moţné varianty, se kterými se budeme potýkat. Předejdeme tím časovým prodlevám v ostrém provozu. i) Zkušební provoz: v závodech zvlášť Oproti skutečně realizovanému projektu docílíme vyššího efektu hromadným testováním softwaru ve třech závodech souběţně. Na testování by bylo nejlépe stanovit

75

časový horizont jeden měsíc. První týden se bude obsluha seznamovat s prostředím softwaru a s manipulací měřícího ramena. Druhý a třetí týden by se měla obsluha procvičit na měření kaţdodenních dílů dodané na kontrolu. Poslední týden by pracovníci měli uţ zkoušet měřit díly a přípravky na pracovišti a objevovat skryté funkce. j) Zaškolení: dodatečné individuální Po zkušebním provozu je vhodné opět všechny pracovníky pozvat na týdenní přeškolení. Kurzu by se znovu účastnila dodavatelská firma. Pracovníci by po měsíčním provozu sami přišli na záleţitosti, které je potřeba vysvětlit. Můţe se stát, ţe díly jsou příliš křivé pro zarovnání a výsledky neodpovídají skutečným rozměrům. Zároveň mohou všichni pracovníci poskytnout rady ostatním. k) Ostrý provoz: software v provozu Poslední fází projektu je nasazení měřícího softwaru do praxe. Zde by měli pracovníci uţ vyvíjet samostatné měřící programy, měli by být schopní reportovat naměřené hodnoty a být schopní poskytnout vytvořené programy ostatním pracovníkům.

4.3 Realizace Ve fázi realizace bychom měli implementovat stanovené plány do skutečného prostředí. Podle první fáze ţivotního cyklu projektu by se jednalo o přidělení dílčích úkolů jednotlivým členům projektového týmu. Měli bychom ale dbát na rozdělení úkolů, aby se nestalo, ţe jeden člen projektového týmu bude mít na starosti 50 % úkolů a ostatní členové zbytek. Pracovník na pozici nákupu by začal organizovat schůzky. Kaţdá část projektové etapy by měla být řízena zvlášť jako jeden malý projekt. Jednotlivou část a její výstupy lze snadněji kontrolovat vůči plánům projektům daleko lépe, neţ jako celek. I kaţdá část dílčího úkolů by se měla sledovat a zaznamenat. Pořízení softwaru a přenosné medium CD by mělo být popsáno v dílčí zprávě, ţe produkt byl uloţen do kanceláře manaţera kvality. Tuto událost by měl pracovník nákupu zaznamenat a poslat všem členům projektového týmu. Obdobným způsobem by se měl zaznamenat kaţdý krok, aby všichni věděli, co se v danou chvíli na projektu odehrává. Kontrolu průběhu etapy je moţné vystihnout krátkým vývojovým diagramem. Pokud dojde k ukončení etapy podle 76

předpokladu, v našem případě dojde k řádnému proškolení pracovníků se softwarem, tak můţe být rozhodnuto o ukončení etapy zaškolení a můţe se přejít k fázi testování v provozu. Pokud by se ukázalo, ţe některý pracovník nerozumí některým poloţkám v programu, bylo by vhodné ihned upozornit školitele a znovu vysvětlit nedostatky. Pokud bychom přešli k další etapě řádně neukončenou fází školení, tak by se etapa testování značně zkomplikovala. Mohl by nastat i případ, kdy by se školením zjistilo, ţe není nutné proškolit všechny poloţky softwaru, protoţe pro naše účely jsou zbytečné, tak by se formou revize rozhodlo o předčasném ukončení etapy. Tato změna by musela být opět zaznamenána a předána všem členům týmu.

Obr. 34 - Vývojový digram kontroly etap projektu

4.4 Revize a kontrola Poslední fází projektu by bylo zkontrolování a ověření kompletnosti. Měli bychom se zaměřit na to, zda bude produkt schválen zadavatelem a projektovým výborem, v našem případě by to bylo předloţení závěrečné zprávy majitelům podniku. V tu chvíli by uţ musel být projekt ve fázi ostrého provozu na pracovištích kvality. Došlo by k procesu předání měřících sestav s pracovníky kvality. Ihned po předání by bylo vhodné informovat zadavatele projektu, ţe produkty byly předány a proces měření se softwarem tím byl oficiálně zahájen. Vhodným krokem by bylo uspořádání jednání, kde by se projednalo zajištění trvalého provozu měřících sestav. Muselo by se stanovit, v jakých časových intervalech bude 77

prováděna kalibrace, čištění kloubů rotačních čítačů a po případě pravidelný kontrolní servis. Mělo by se stanovit, kdo se bude v dané fabrice nadále o samotné měření starat, kdo bude ukládat výstupní reporty a kdo bude mít na starosti uloţení ukládání přístroje do bezpečného prostředí. Všechny výstupní produkty by měly být porovnány s chartou projektu, zda během budování projektu nedošlo k odchylce od stanového plánu. Je potřeba si uvědomit, proč jsme projekt realizovali a jaké byly jeho cíle. Byly skutečně naplněny? Dospěli jsme podle časového harmonogramu toho, ţe měření se nalézá uţ v ostrém provozu? Měli bychom ale uváţit, zda spuštěním měření v provozu jsme dosáhli plánovaného výsledku. Mohlo by se stát, ţe provoz by byl zahájen, ale očekávání bylo od projektu úplně odlišné. Výsledná zpráva by měla být v jednoduché formě na pár stránek A4, kde budou jasně a stručně vypsány všechny produkty, cena, přínos a kdo se podílel na projektu s jakou mírou úspěšnosti. Na základě zprávy bychom měli zpětně informovat členy projektového týmu a sdělit jim, jak byli na projektu úspěšní. Zda například pracovník nákupu včas sděloval informace o termínech schůzek, nebo zda zprávy z jednání byly doručeny všem členům týmu. Neměli bychom zapomenout na zpětné posouzení řízení projektu, zda výběr tří manaţerů kvality v projektovém týmu byl vhodný a jak se to způsob uspořádání projevil na efektivitě. Posledním krokem by měla být provedena poprojektová revize, kde by hlavní náplní dokumentu bylo, zda měřítka úspěšnosti produktů definována na začátku projektu stále platí. V dokumentu by mohly být jiţ zmíněné procesy se zajištěním trvalého provozu. Jestli jsme pořízením 3D měřícího softwaru dosáhli sníţením počtu reklamací a nebo pouze jsme utratili peníze zbytečně a reklamace se pohybují ve stejných číslech.

78

4.5 Předejití možných problémů s PRINCE2 Na závěr bych rád vybral oblasti projektu, které by pouţitím metodiky PRINCE2 dopadly v globálním hledisku úspěšněji, v některých případech by se problém odstranil úplně nebo by došlo k výrazné úspoře zdrojů. a) Doba průběhu projektu by se zkrátila na poloviční čas, neţ ve kterém byl projekt realizován. b) Došlo by k ušetření lidských zdrojů (čas manaţerů) v závodě Vodňany. c) Byly by vybrány správné hardwarové poţadavky na měřící software. d) Jako měřící laboratoř by byla vybrána speciálně upravená místnost s omezením prašnosti. e) Podstavec stojanu by byl vybrán s ohledem na povrch podlahy. f) Sníţil by se počet reklamací z pole v době zavádění softwaru. g) Došlo by k lepší komunikaci při výběrovém řízení. h) Doposud všechny vytvořené programy softwarem by byly dostupné všem pracovníkům kvality v celém koncernu. i) K naměřeným protokolům by bylo moţné přistupovat vzdáleně přes sluţbu FTP nebo je sledovat za pomoci webového serveru. j) Pracovníci by byli proškoleni a připraveni s hlubšími znalostmi ohledně problematiky měření se softwarem.

79

Závěr Projekt zavádění měřícího softwaru do koncernu Pöttinger byl prvním projektem, do kterého jsem byl zapojen. Nebyl jsem v projektu zainteresován od úplného začátku, nýbrţ v době, kdy proběhlo výběrové řízení o nákupu softwaru, měřící sestava jiţ byla v provozu v závodě v Grieskirchenu a v závodě ve Vodňanech, akorát probíhala fáze dodání produktů. Za tuto krátkou dobu jsem měl moţnost vytvořit si krátký náhled na průběh projektu. Projekt byl od začátku plánován jako běh na dlouhou trať a na projekt bylo pohlíţeno pouze jako na malou nově vznikající součást jiţ zaběhlého výrobního procesu. Vedení firmy si nedokázalo představit ten obrovský potenciál, aţ se projekt dokončí. Z toho důvodu byly některé fáze řešeny špatným způsobem a celková efektivita projektu nebyla taková, jak se od něj na začátku očekávalo. Největší slabinou celého projektu byla špatná organizace a z toho vyplývající špatná komunikační páteř. Výběrové řízení podle mého názoru proběhlo bez ţádných zjevných problémů a software byl vybrán správně. Po zkušenostech, co s ním pět měsíců aktivně pracuji, jsem se naučil vyuţívat všech moţností softwaru a prostředí programu mi nyní přijde vyhovující. Celý projekt byl pod záštitou majitelů firmy, ale pouze v první fázi projektu. Dále uţ vznikaly komunikační bariéry v dodání produktů, instalaci softwaru a jednotlivých školení. V naší fabrice jsme čekali na školení dva a půl měsíce. Tím byl stanoven fakt, ţe s programem jsem se musel naučit sám a tím pádem došlo k opoţděnému efektu nasazení softwaru. Mezitím se nám vyskytly tři velké reklamace z pole, kterým by se dalo podle mého názoru krásně předejít, kdyby byl naplánován konec projektu na přesně stanovené datum, nikoliv stylem, aţ se to udělá, tak to bude. Špatná komunikace měla za následek mimo jiné to, ţe se projekt o něco málo prodraţil oproti původnímu plánu. Školení nebylo naplánováno z ideálního hlediska správně, ale mohl se například upravit styl školení tak, ţe by byl řádně proškolen závod v Grieskirchenu a posléze by proškolení pracovníci naučili se softwarem kolegy ze dvou zbývajících továren. Další problém se vyskytl s měřením větších dílů, kde se aţ v ostrém provozu ukázalo, ţe na měření větších dílů je zapotřebí sada na přesouvání. Pokud by projekt byl správně naplánován podle PRINCE2, kde by byla řádně provedena analýza cílů a byla vypracována případová studie, tak by k tomuto problému nikdy nedošlo. Celý projekt a jeho fáze nejsou doposud nijak zdokumentované a zápisy z jednání neexistují. Ţádná z fází na jejím konci nebyla nikdy ověřena a prodiskutována, a tak se stávalo, ţe například vedení mělo kladné mínění o funkčnosti softwaru ve Vodňanech, ale ve

80

skutečnosti nám nebylo dodáno ani měřící rameno. Z posledních negativních faktorů, které bych rád zmínil, se u projektu nepodařila synchronizace vytvořených programů mezi výrobními závody a kaţdý si tak vytváří programy zvlášť a nemá přístup k programům ostatních závodů. Pokud opomeneme větší či menší nedostatky realizace projektu, tak podle mého názoru dopadl v celku slušně. Ve všech třech závodech jiţ v tuto chvíli probíhá měření za pomoci měřícího softwaru. Občas se objeví chyba z německého závodu, kde byla špatně provedena fáze zaškolení, ale po telefonické a emailové domluvě je vţdy problém vyřešen. Kdyby se někdy v budoucnu vyskytl obdobný projekt na pořízení dalších měřících sestav nebo pořízení nových portálových měřících strojů, rád bych se podílel na projektu ve větší míře. Na průběhu projektu jsem pochopil, ţe špatná komunikace dokáţe projekt ve značné míře znehodnotit a výsledný přínos není 100%. V současné chvíli uţ mám více zkušeností s lidmi v koncernu Pöttinger, znám podnikové procesy, moje bohaté zkušenosti z oblasti 3D měřících strojů jsou rozmanité a věřím, ţe další projekt by byl za mojí spoluúčasti realizován daleko lépe. Na úplný závěr jsem provedl srovnání měřených časů za pomoci softwaru a měření klasickou cestou. Pro deset vyrobených dílů, jsem změřil časy, které byly potřebné pro změření kompletního dílu. Všechny časy se díky softwaru téměř třikrát sníţili, jen v jednom případě, kdy díl je příliš jednoduchý, tak se měřením za pomoci výškoměru dosáhlo lepšího času.

Pořadí měřeného dílu Čas měření klasickou cestou (h) Čas měření se softwarem (h)

1 2 3 4 5 2 0,25 4 0,75 0,5 0,5 0,2 1,5 0,33 0,15 Tab. 8 - Srovnání měření

Průměrný čas měřený klasickou cestou:

2,29 h.

Průměrný čas měřený za pomoci softwaru: 0,92 h. Průměrně ušetřený čas:

2,49 x.

81

6 8 3

7 8 9 10 2,5 0,1 1,25 3,5 0,9 0,25 0,6 1,75

Graf č. 3 - Ukazuje časovou úsporu zavedení 3D měřícího softwaru

Předchozí graf ukazuje časovou úsporu a ještě na úkor zrychlení je potřeba zveřejnit statistiku s reklamacemi. Na následujícím grafu je patrné, ţe počet vystavených reklamací od srpna 2003 do března 2014 má klesající tendenci. Zlom nastává v lednu 2014, kdy se měřící software začlenil do procesu.

Graf č. 4 - Statistika vystavených reklamací

82

Přílohy Příloha 1: Ukázka výstupního měřícího protokolu ze softwaru Power Inspect 2013 R2

Příloha 2: Ukázka prostředí Power Inspect

Příloha 3: Ukázka měření průhybu GEOMU podle CAD modelu

Příloha 4: Ukázka formátování protokolu měření za pomoci HTML

Seznam použité literatury Bibliografie [1] BENTLEY, Colin a Milan PŮDA. PRINCE2 Pro řízení malých projektů. druhé vydání. Praha: EuroAnalysis, s.r.o., 2012. ISBN 978-80-260-2447-7.

Internetové zdroje [1] Autonomní systém. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014, 10.2.2014 [cit. 2014-03-02]. Dostupné z: http://cs.wikipedia.org/wiki/Autonomn%C3%AD_syst%C3%A9m [2] CCLearning: PRINCE2. Process: SB1 Planning a stage [online]. [cit. 2014-02-19]. Dostupné z: http://www.crazycolour.com/prince2/?title=SB1_Planning_a_Stage [3] Certifikační kurz projektového řízení PRINCE2 Practitioner. POTIFOB: Úspěšné projektové řízení s PRINCE2 [online]. [cit. 2014-02-19]. Dostupné z: http://www.potifob.cz/PRINCE2_Practitioner.htm?gclid=COqc4b_io7wCFY1Y3godrjkA3w [4] Ganttův diagram. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014, 14.1.2014 [cit. 2014-02-19]. Dostupné z: http://cs.wikipedia.org/wiki/Gantt%C5%AFv_diagram [5] Historie. PRINCE-2.cz [online]. 2000 [cit. 2014-01-06]. Dostupné z: http://prince2.cz/index.php/index/page/1037_historie-prince2 [6] Information Technology Infrastructure Library. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014, 10.3.2013 [cit. 2014-0219]. Dostupné z: http://cs.wikipedia.org/wiki/ITIL [7] JALLC Project Approach (JPA). North Atlantic treaty organization [online]. 2.8.2013 [cit. 2014-02-19]. Dostupné z: http://www.jallc.nato.int/activities/jpa.asp [8] JINDRA, Jaroslav. Abeceda managementu: Řízení projektu. Metodický portál RVP [online]. 13. 10. 2008. 2008 [cit. 2014-02-19]. Dostupné z: http://clanky.rvp.cz/clanek/s/Z/2698/ABECEDA-MANAGEMENTU---RIZENIPROJEKTU.html/ [9] KLUSOŇ, Martin. PRINCE2, nebo PMI?. In: System Online [online]. [cit. 2014-0219]. IT SYSTEMS 3/2010. ISSN 1802-615X. Dostupné z: http://www.systemonline.cz/sprava-it/prince2-nebo-pmi.htm

[10] Management marketingu - učivo: Projektový management. BLOGSPOT. [online]. [cit. 2014-02-19]. Dostupné z: http://management-marketingu.blogspot.cz/2010/03/1-projektovymanagement.html [11] ManagementMania.com: Smart. Managementmania [online]. ISSN 2327-3658, 1.5.2013 [cit. 2014-02-19]. Dostupné z: https://managementmania.com/cs/smart [12] Metodika PRINCE2®. EUROANALYSIS S.R.O. PRINCE2 pro řízení malých projektů [online]. © 2010-2012 [cit. 2014-02-19]. Dostupné z: http://www.maleprojekty.cz/metodikaprince2/ [13] OTT, Vlastimil. Metoda SMART: Jak zadávat úkoly, abyste byli spokojeni s výsledkem. ADMIN. MÍT VŠE HOTOVO.CZ. Mít vše hotovo [online]. 1.8.2011. 2011 [cit. 2014-02-19]. Dostupné z: http://www.mitvsehotovo.cz/2011/08/metoda-smart-jak-zadavatukoly-abyste-byli-spokojeni-s%C2%A0vysledkem/ [14] PAVLÍČEK, Luboš. ŢIVOTNÍ CYKLUS PROJEKTU: CHARAKTERISTIKA JEDNOTLIVÝCH FÁZÍ.RUP: Ţivotní cyklus projektu [online]. 2005, 13.09.2005 [cit. 201401-04]. Dostupné z: http://objekty.vse.cz/Objekty/Rup3 [15] PMBOK Guide. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014, 15.2.2014 [cit. 2014-02-19]. Dostupné z: http://cs.wikipedia.org/wiki/PMBOK_Guide [16] PMO: Role projektové kanceláře a je vůbec potřeba?. PM Blog [online]. 2013 [cit. 2014-01-10]. Dostupné z: http://pm-blog.cz/11/pmo-role-projektove-kancelare-a-je-vubecpotreba/ [17] PRINCE2. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014, 8.1.2014 [cit. 2014-02-19]. Dostupné z: http://en.wikipedia.org/wiki/PRINCE2 [18] Principy PRINCE2®. PRINCE2® & PRINCE AND ITIL® ARE REGISTERED TRADE MARKS OF THE CABINET OFFICE. PRINCE-2.cz [online]. [cit. 2014-02-19]. Dostupné z: http://prince-2.cz/index.php/video/show_video/1016/shrnuti-principu-metodikyprince2#content [19] Progres. PRINCE2® & PRINCE AND ITIL® ARE REGISTERED TRADE MARKS OF THE CABINET OFFICE. PRINCE-2.sk [online]. [cit. 2014-02-19]. Dostupné z: http://prince-2.sk/index.php/video/show_video/47/Progress-pokrok-meranie-dosiahnutiacielov/1

[20] Project help: Stručná historie řízení projektů. © 2014 MICROSOFT CORPORATION. Podpora[online]. [cit. 2014-02-19]. Dostupné z: http://office.microsoft.com/cs-cz/projecthelp/strucna-historie-rizeni-projektu-HA010351563.aspx#_Toc310511346 [21] Projektový management - úvod: Několik myšlenek při zahájení kurzu. Batcos: Development & Piloting of Basic On-Line Training Courses [online]. 2000 [cit. 2014-01-06]. Dostupné z: http://athena.zcu.cz/batcos/demo_cz/c04m01cz/c04m01u01s03cz/ [22] Rational Unified Process. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014, 23. 3. 2013 [cit. 2014-02-21]. Dostupné z: http://cs.wikipedia.org/wiki/Rational_Unified_Process [23] RUP - Ţivotní cyklus projektu: Metodika RUP. ALDORF, F. VSE. Metodika RUP: diplomová práce F. Aldorfa [online]. 13.9.2005 [cit. 2014-02-19]. Dostupné z: http://objekty.vse.cz/Objekty/Rup3 [24] Řízení projektů. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014, 15.2.2014 [cit. 2014-02-19]. Dostupné z: http://cs.wikipedia.org/wiki/%C5%98%C3%ADzen%C3%AD_projekt%C5%AF [25] SMART metoda. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014, 19.2.2014 [cit. 2014-02-19]. Dostupné z: http://cs.wikipedia.org/wiki/SMART_metoda [26] STANÍČEK, Zdenko RNDr. Řízení projektů: I. díl Podstata řízení projektů. In: System Online [online]. 2002 [cit. 2014-02-19]. Časopis IT system: IT System, 12/2002. ISSN 1802615X. Dostupné z: http://www.systemonline.cz/clanky/rizeni-projektu.htm [27] ŠUBRT, Tomáš Dr. Ing. Okolí projektu. SMEP: Systém multimediální elektronické poblikace [online]. 2013 [cit. 2014-01-18]. Dostupné z: http://etext.czu.cz/php/skripta/skriptum.php?titul_key=77 [28] Témata PRINCE2. PRINCE2® & PRINCE AND ITIL® ARE REGISTERED TRADE MARKS OF THE CABINET OFFICE. PRINCE-2.sk [online]. [cit. 2014-02-19]. Dostupné z: http://prince-2.cz/index.php/index/page/1056 [29] Tenrox. Project Management Software Glossary [online]. [cit. 2014-02-19]. Dostupné z: http://glossary.tenrox.com/PRINCE2.htm [30] T-Systems. T-SYSTEMS. T-Systems [online]. 2011-2013 [cit. 2014-02-25]. Dostupné z: http://www.viahome.cz/t-systems.html

[31] What is PRINCE2. Prince2.com http://www.prince2.com/what-is-prince2

[online].

[cit.

2014-02-19].

Dostupné

z:

[32] Základní informace o Magistrátu hl. m. Prahy. T-SYSTEMS. Praha.eu: portál hl.města Prahy [online]. 1. březen 2011. 2011 [cit. 2014-02-25]. Dostupné z: http://www.praha.eu/jnp/cz/home/magistrat/uredni_deska_a_oznameni/zakladni_informace/in dex.html [33] Ţivotní cyklus a fáze projektů. CZECHTRADE. [online]. 29.6.2011. © 1997-2014 [cit. 2014-02-19]. Dostupné z: http://www.businessinfo.cz/cs/clanky/zivotni-cyklus-a-fazeprojektu-2865.html [34] Ţivotní cyklus projektu. CZECHTRADE. [online]. 31. 5. 2009. © 1997-2014 [cit. 201402-19]. Dostupné z: http://www.businessinfo.cz/cs/clanky/management-zivotni-cyklusprojektu-2786.html [35] Ţivotní cyklus projektu. PODNIKÁTOR.CZ © 2012. Podnikator.cz [online]. 1.3.2013. [cit. 2014-02-19]. Dostupné z: http://www.podnikator.cz/provoz-firmy/management/rizenipodniku/n:16652/Zivotni-cyklus-projektu

Seznam použitých obrázků Obr. 1 - Portálový 3D měřící přístroj ......................................................................................... 8 Obr. 2 - Trojimperativ projektu ................................................................................................ 10 Obr. 3 - Pyramidy v Gíze ......................................................................................................... 11 Obr. 4 - Manaţer projektu musí komunikovat se všemi členy týmu ........................................ 13 Obr. 5 - Hlavní milníky projektu .............................................................................................. 15 Obr. 6 - Časová náročnost dílčích kroků .................................................................................. 16 Obr. 7 - Příklad Ganttova diagramu ......................................................................................... 20 Obr. 8 - Struktura síťové analýzy ............................................................................................. 21 Obr. 9 - Struktura metodiky...................................................................................................... 23 Obr. 10 - Logo firmy Pöttinger................................................................................................. 39 Obr. 11 - Podíl na dosaţeném obratu v rámci geografie .......................................................... 41 Obr. 12 - Schéma organizace továrny ve Vodňanech .............................................................. 42 Obr. 13 - Výrobní proces stroje Lion 3002 .............................................................................. 43 Obr. 14 - Ukázka výrobního procesu dílu Konusfederelement 6mm ....................................... 43 Obr. 15 - Hrubý návrh průběhu zavádění softwaru .................................................................. 47 Obr. 16 - Schéma vize propojení měřících stanic..................................................................... 47 Obr. 17 - Ganttův diagram zavedení měřícího softwaru .......................................................... 50 Obr. 18 Schéma komunikace pořízení měřící soustavy v Grieskirchenu ................................ 51 Obr. 19 - Schéma komunikace pořízení měřící soustavy ve Vodňanech ................................. 52 Obr. 20 - Schéma komunikace pořízení měřící soustavy v Bernburgu .................................... 54 Obr. 21 - Prostředí softwaru Power Inspect ............................................................................. 55 Obr. 22 - Prostředí měřícího softwaru Tango 3!D.................................................................... 56 Obr. 23 - Měřící rameno Romer Absolute Arm ....................................................................... 57 Obr. 24 - Měřící rameno Faro Edge Arm ................................................................................. 58 Obr. 25 - Ukázka chybového hlášení softwaru......................................................................... 59 Obr. 26 - Ukázka reálného případu krátkého ramene ............................................................... 60 Obr. 27 - Špatný podstavec (stativ) ramena ............................................................................. 61 Obr. 28 - Ţivotní cyklus malého projektu podle PRINCE2 ..................................................... 63 Obr. 29 - Schéma návrhu vylepšeného propojení měřících softwarů....................................... 67 Obr. 30 - Navrţené schéma komunikace ve Vodňanech .......................................................... 71 Obr. 31 - Ganntův diagram pořízení měřícího softwaru .......................................................... 72

Obr. 32 - Znázornění továren Pöttinger .................................................................................... 74 Obr. 33 - Ukázka vhodného dílu pro testování......................................................................... 75 Obr. 34 - Vývojový digram kontroly etap projektu .................................................................. 77

Seznam tabulek Tab. 1 - Vysvětlení metody SMART ....................................................................................... 10 Tab. 2 - Milníky firmy Pöttinger .............................................................................................. 40 Tab. 3 - Minimální poţadavky pracovní stanice ...................................................................... 58 Tab. 4 - Celkový souhrn nákladů projektu ............................................................................... 62 Tab. 5 - Seznam rizik projektu ................................................................................................. 69 Tab. 6 - Navrţené sloţení projektového výboru a týmu........................................................... 69 Tab. 7 - Protiopatření rizik ....................................................................................................... 70 Tab. 8 - Srovnání měření .......................................................................................................... 81

Seznam grafů Graf č. 1 - Úspora času a zrychlení kontroly dílu za pouţití měřícího softwaru ...................... 45 Graf č. 2 - Graf ukazující měřítka rozhodnutí pořízení softwaru ............................................. 66 Graf č. 3 - Ukazuje časovou úsporu zavedení 3D měřícího softwaru ...................................... 82 Graf č. 4 - Statistika vystavených reklamací ............................................................................ 82

Seznam příloh Příloha 1: Ukázka výstupního měřícího protokolu ze softwaru Power Inspect 2013 R2 ......... 83 Příloha 2: Ukázka prostředí Power Inspect .............................................................................. 84 Příloha 3: Ukázka měření průhybu GEOMU podle CAD modelu ........................................... 85 Příloha 4: Ukázka formátování protokolu měření za pomoci HTML ...................................... 87

Řízení IT projektu podle metodiky PRINCE2

Recommend Documents