• No results found

Řízení kvality informačního systému ve vybrané firmě

N/A
N/A
Protected

Academic year: 2022

Share "Řízení kvality informačního systému ve vybrané firmě"

Copied!
96
0
0

Loading.... (view fulltext now)

Full text

(1)

Řízení kvality informačního systému ve vybrané firmě

Diplomová práce

Studijní program: N6209 – Systémové inženýrství a informatika Studijní obor: 6209T021 – Manažerská informatika

Autor práce: Bc. Vojtěch Třmínek

Vedoucí práce: doc. Ing. Klára Antlová, Ph.D.

(2)
(3)
(4)

Prohlášení

Byl jsem seznámen s tím, že na mou diplomovou práci se plně vzta- huje zákon č. 121/2000 Sb., o právu autorském, zejména § 60 – školní dílo.

Beru na vědomí, že Technická univerzita v Liberci (TUL) nezasahuje do mých autorských práv užitím mé diplomové práce pro vnitřní potřebu TUL.

Užiji-li diplomovou práci nebo poskytnu-li licenci k jejímu využití, jsem si vědom povinnosti informovat o této skutečnosti TUL; v tom- to případě má TUL právo ode mne požadovat úhradu nákladů, které vynaložila na vytvoření díla, až do jejich skutečné výše.

Diplomovou práci jsem vypracoval samostatně s použitím uvedené literatury a na základě konzultací s vedoucím mé diplomové práce a konzultantem.

Současně čestně prohlašuji, že texty tištěné verze práce a elektronické verze práce vložené do IS STAG se shodují.

5. 4. 2019 Bc. Vojtěch Třmínek

(5)

Poděkování

Tímto bych chtěl poděkovat vedoucí mé diplomové práce doc. Ing. Kláře Antlové, Ph.D.

za odborné vedení mé diplomové práce. Dále děkuji konzultantce Ing. Veronice Hajdové za odborné rady při vytváření této diplomové práce.

(6)

Anotace

Tato diplomová práce se zabývá řízením kvality informačního systému ve vybrané firmě.

V první části je stručný popis, co to vlastně je a jak se určuje kvalita softwaru. Druhá část popisuje projektové řízení, které je jedním z nástrojů, jak kvality softwaru dosáhnout. Ve třetí části je případová studie vybrané organizace. Čtvrtá část se zabývá různými vybranými kvalitativními a bezpečnostními normami. V páté části jsou poté v případové studii porovnány s existujícím projektem informačního systému.

Klíčová slova

Informační systém, kvalita softwaru, projektové řízení, vývoj softwaru, standardy, ISO, GDPR

(7)

Annotation

This master thesis presents quality management of information system in selected company. In the first part is a brief description of what is quality and how is quality determined. Second part describes project management, which is one of the tools how to achieve quality of software. In the third part is case study of chosen organization. Fourth part describes various chosen qualitative and security standards. In the fifth part, they are compared with existing project of information system in case study.

Key Words

Information system, software quality, project management, software development, standards, ISO, GDPR

(8)

Obsah

Seznam zkratek ... 11

Seznam tabulek ... 12

Seznam obrázků ... 13

Úvod ... 14

1. Řízení kvality informačního systému ... 16

2. Využití projektového řízení ve vývoji informačního systému ... 19

2.1 Světové standardy a metodiky projektového řízení ... 20

2.1.1 Project Management Body of Knowledge (PM BoK) ... 20

2.1.2 PRojects IN Controlled Environments (PRINCE2®) ... 21

2.1.3 IPMA® Competence Baseline (ICB) ... 22

2.1.4 ISO 21 500 ... 23

2.2 Základní role – zainteresované strany... 23

2.3 Základní role – v projektovém týmu ... 24

2.3.1 Manažer projektu ... 24

2.3.2 Garant výstupu... 25

2.3.3 Člen projektového týmu ... 26

2.4 Základní organizační modely ... 27

2.4.1 Útvarové projektové řízení ... 27

2.4.2 Autonomní projektové řízení ... 28

2.4.3 Maticové projektové řízení ... 29

2.4.4 Síťové projektové řízení – projektová organizační struktura ... 30

2.4.5 Projektová kancelář – rozhraní trvalé a dočasné organizace ... 31

2.5 Modely životního cyklu vývoje softwaru ... 32

2.5.1 Model napiš a oprav ... 33

2.5.2 Stagewise model ... 33

2.5.3 Vodopádový model ... 34

2.5.4 Spirálový model... 35

2.5.5 Agilní metodiky ... 36

2.5.6 Další modely vývoje softwaru ... 37

3. Případová studie organizace ... 39

3.1 Zainteresované strany ... 39

3.1.1 Zadavatel projektu ... 39

3.1.2 Uživatelé projektu ... 39

(9)

3.1.3 Vlastník projektu ... 40

3.2 Projektový tým ... 40

3.2.1 Manažer projektu ... 41

3.2.2 Asistent manažera projektu ... 41

3.2.3 Softwarový inženýr ... 43

3.2.4 Externí konzultanti ... 43

3.3 Organizační model ... 44

3.4 Životní cyklus projektu ... 46

3.5 Návrh zlepšení ... 48

4. Technologické standardy bezpečnosti softwaru ... 52

4.1 Vývoj bezpečnostních standardů ... 52

4.1.1 Standard TCSEC ... 52

4.1.2 ITSEC ... 53

4.1.3 Common criteria ... 53

4.2 Současné bezpečnostní standardy ... 53

4.2.1 Standardy řady ISO ... 55

4.2.2 ISO/IEC 27000 ... 58

4.2.3 ISO/IEC 27001 ... 60

4.2.4 ISO/IEC 27002 ... 63

4.2.5 ISO/IEC TR 13335-3 ... 65

4.2.6 ISO/IEC 27005 ... 65

4.2.7 ISO 9000 ... 67

4.2.8 ISO 9001 ... 69

4.3 Nakládání s citlivými daty ... 70

4.3.1 Předchozí právní předpisy ... 70

4.3.2 General Data Protection Regulation (GDPR) ... 71

5. Případová studie registračního a akreditačního systému z pohledu bezpečnosti. 76 5.1 Hlavní databáze ... 77

5.2 Bezpečnost webových aplikací ... 79

5.3 Infrastruktura ... 80

5.4 Přihlašování do systému ... 81

5.5 Případová studie nakládání s citlivými daty ... 82

5.5.1 Hardware a Software ... 83

5.5.2 Povinnosti a školení zaměstnanců ... 84

5.5.3 Transparentnost zpracování dat ... 85

(10)

5.5.5 Ochrana údajů, přenos a smazání ... 86

5.5.6 Poskytovatelé externích služeb ... 87

5.5.7 Bezpečnost zpracování ... 87

5.5.8 Narušení bezpečnosti dat ... 88

Závěr ... 93

Seznam použité literatury ... 94

(11)

Seznam zkratek

ČSN Česká státní norma

GDPR Obecné nařízení o ochraně osobních údajů (General Data Protection Regulation)

HTTPS Hypertext Transfer Protocol Secure

IEC Mezinárodní elektrotechnická komise (International Electrotechnical Commission)

IIS Internet Information Server

ISMS Systém řízení bezpečnosti informací (Information Security Management System)

ISO Mezinárodní organizace pro normalizaci (International Organization for Standardization)

PaaS Platforma jako služba (Platform as a Service) SaaS Software jako služba (Software as a Service) VPN Virtuální privátní síť (virtual private network)

(12)

Seznam tabulek

Tabulka 1: Časová náročnost technické podpory na příkladech ... 42 Tabulka 2: Časová náročnost podle počtu programátorů ... 44 Tabulka 3: Porovnání mezi principy Business Excellence a normou ISO 9000 ... 68

(13)

Seznam obrázků

Obrázek 1: Schéma PRINCE2® metodiky ... 22

Obrázek 2: Organizační struktura projektu ... 26

Obrázek 3: Útvarové projektové řízení ... 28

Obrázek 4: Autonomní projektové řízení ... 29

Obrázek 5: Maticové projektové řízení ... 30

Obrázek 6: Síťové projektové řízení – projektová organizační struktura ... 31

Obrázek 7: Schéma modelu napiš a oprav... 33

Obrázek 8: Schéma modelu Stagewise ... 34

Obrázek 9: Základní struktura vodopádového modelu... 35

Obrázek 10: Schéma spirálového modelu životního cyklu ... 36

Obrázek 11: Prostředí aplikace YouTrack... 48

Obrázek 12: Třída norem ISO/IEC 27000 ... 58

Obrázek 13: Procesní model Systému řízení bezpečnosti informací (ISMS) ... 61

Obrázek 14: Proces managementu pro řízení rizik ... 66

Obrázek 15: Přehled funkcionalit systému ... 77

Obrázek 16: Schéma fungování přístupu k systému ... 78

Obrázek 17: Schéma serverové infrastruktury ... 81

(14)

Úvod

Řízení kvality softwaru a projektové řízení jsou v dnešní době nezbytnou součástí lidské činnosti jak v podnikatelské sféře, tak správních či jiných institucích. V celé řadě těchto orgánů je masově využívána informační technologie, která umožňuje a zjednodušuje práci všech zúčastněných a celého společenského systému. Bez těchto technologií by byl současný život velmi komplikovaný. Cílem této diplomové práce je na základě teoretických znalostí v oblasti řízení kvality poukázat na způsob jejich uplatnění pomocí projektového řízení. Toto téma bylo zvoleno na základě pracovní zkušenosti ve zkoumané firmě.

Součástí diplomové práce je případová studie pro projekt informačního systému, která porovnává uvedená teoretická východiska se zjištěnými praktickými skutečnostmi. Autor této práce se v období pěti let osobně účastnil a spolupracoval na vývoji tohoto projektu informačního systému a jeho provozu. Zkoumaný projekt je Registrační a Akreditační systém speciálně vyvinutý pro pořádání mezinárodních sportovních akcí. Kvůli zaměření firmy na největší sportovní akce je nutné, aby daný systém dosahoval prvotřídní kvality, která by firmě zajistila konkurenční výhodu v celosvětovém měřítku, neboť IT odvětví je v dnešní době vysoce soutěživé. A pokud by daný systém byl oficiálně certifikován, pro zákazníky by to byl jasný signál kvality a bezpečnosti daného softwaru a pro firmu značná výhoda před ostatními firmami na stejném trhu. Splnění požadavků normy zaručuje vysokou pravděpodobnost stálosti kvality softwaru a dodatečných služeb.

Diplomová práce je pro přehlednost rozdělena do tří částí. První z nich vysvětluje pojem kvalita, a co obnáší řízení kvality.

Ve druhé části je podrobně rozebráno projektové řízení jakožto prostředek řízení kvality a způsob, jak dosáhnout lepší kvality a spokojenosti současných nebo potenciálních zákazníků. Od představení světových metodik projektového řízení, přes jednotlivé role, až po modely životního cyklu. Jejich výběr pro diplomovou práci byl určen na základě souvislosti s konkrétním projektem v případové studii a popřípadě pro pochopení historických souvislostí.

(15)

Třetí část je případovou studií dané organizace, v níž je realizován zkoumaný projekt. Tato část případové studie se zabývá organizační strukturou firmy a samotnou organizací práce na daném projektu.

Čtvrtá část je věnována technickým normám a jejich přispění pro bezpečnost a kvalitu projektu. Jsou zde blíže představeny ISO normy řady 9000 a 27000 a také nové nařízení Evropské Unie a to Obecné nařízení o ochraně osobních údajů, více známé pod anglickou zkratkou GDPR, které se zabývá pravidly pro zpracování a uchovávání citlivých dat.

V poslední páté části je na případové studii ukázáno, jak je problematika bezpečnosti a zpracování dat prováděna na zkoumaném projektu informačního systému.

(16)

1. Řízení kvality informačního systému

Pojem kvalita lze definovat tak, že výstupy implementovaného projektu splňují požadavky, které jsou na ně kladeny a to ne jenom samotný software, který je zde vytvářen, ale i celý proces vývoje který k tomuto softwaru vede. Pro řízení kvality vývoje informačního systému je nutné stanovit jasné, jednoznačné a přesné požadavky a to jakým způsobem se budou dokazovat, že byly splněny. Kvalitu tak neurčuje pouze to, zda vytvořený systém obsahuje velké množství funkcí, na jaké technologii funguje či zda obsahuje nějaké chyby, ale i celý proces provázející životní cyklus daného systému. (Otta, 2016)

Zavedeným způsobem, jak zajistit kvalitu projektového řízení je dodržovat projektové metodiky a normy jako jsou například PM BoK, PRINCE2 nebo ISO 9000:2000.

V normě ISO 9000 je kvalita definována jako míra, do které soubor základních charakteristik splňuje požadavky. Požadavky jsou definovány v normě ISO 9000 jako potřeba nebo očekávání, které jsou uvedeny, obecně implikovány nebo jsou povinné.

(Hoyle, 2003)

Základní činnosti vedoucí k řízení kvality při implementaci informačního systému se dají rozdělit do tří po sobě jdoucích kroků a to:

 Vytvoření plánu řízení kvality

 Kontrola kvality

 Zajištění kvality

První z těchto kroků určuje zásady pro stanovování plánu činností a prvků, které ve výsledku povedou k úspěšnému a kvalitnímu projektu. Kdo tyto činnosti bude vykonávat a podle jakých kritérií bude kontrolován výsledek. Další klíčovou součástí je i plán testování, který by měl být sestaven již na začátku projektu a měl by mimo jiné obsahovat cíle, požadavky a předpoklady testování, typy a rozsah testování, souhrn nástrojů kterými se bude testovat a kritéria úspěšnosti testů. Pro zaručení úspěšného výsledku testování je vhodné seznámit s plánem testování i zákazníka a tento plán si nechat schválit.

(17)

Druhý krok se již zabývá samotným procesem kontroly kvality. Zahrnuje analyzování výstupů projektu a vyhodnocení jestli splnily veškeré požadavky určené v prvním bodě a to plánování. Také určuje, že je nutné definovat způsoby, jak by se mohli eliminovat příčiny případných nedostatků.

Poslední třetí krok určuje, že aplikováním dříve definovaných bodů lze dosáhnout zajištění kvality. Tyto body obsahují přesně stanovené a naplánované činnosti, které povedou k systematickému zlepšení procesů implementace informačního systému. Případný seznam nedostatků by měl obsahovat možná rizika a pravděpodobnost jejich uskutečnění. Dále by měl obsahovat také konkrétní činnosti pro odstranění těchto rizik nebo jejich zmírnění.

(Svozilová, 2011)

Řízení kvality v daném projektu se dá rozdělit do dvou částí na řízení kvality výstupů, což je zajištění kvality vytvářeného informačního systému a řízení kvality projektových prací, kam patří dodržování harmonogramu, rozdělování práce, komunikace a školení zákazníků v používání tohoto informačního systému atd.

Zvláště u projektů vývoje softwaru je však zadání zákazníka často definováno pouze hrubě a sám zákazník často ani netuší, co chce. V tomto případě jsou vhodnější agilní přístupy k vývoji softwaru, kde je na začátku projektu nadefinována pouze kostra systému a podrobnější definice a požadavky jsou přidávány postupně.

Pro demonstraci takovéhoto řešení řízení kvality byl vybrán informační systém liberecké firmy zabývající se vývojem softwaru používaného pro sportovní akce po celém světě napříč širokou škálou sportů. Tento informační systém zajišťuje registraci a akreditaci všech účastníků takovýchto akcí, má specifickou funkcionalitu, která odpovídá potřebám zajištění tohoto druhu akcí, a nedávají moc smysl pro použití v jiném odvětví. Pro informační systém této velikosti a významu je nutné plánovat a aktivně provádět řízení kvality.

Naopak kdyby se jednalo o daleko menší projekt, není nutné se tak podrobně zabývat analýzou a zlepšováním procesů. Postačí pouze zjednodušená verze projektového řízení a řízení kvality. Obvykle čas strávený a prostředky vložené do tohoto procesu by neadekvátně zvýšily náklady na daný projekt a následné promítnutí těchto nákladů do

(18)

zvýšení ceny výsledného produktu, by mohly mít negativní výsledky. Stačí pouze provádět činnosti, které pomohou dosažení cílů konkrétního projektu. (Otta, 2016)

Jedním ze způsobů jak pomoci snížení nákladů na aktivity řízení kvality je vypracování podrobného popisu procesů a šablon, kterých se pokud možno všechny budoucí projekty budou držet.

Jiří Otta publikoval na webových stránkách SystemOnLine několik článků zabývajících se řízením kvality v procesu implementace informačního systému. Vysvětlil zde nutnost aktivního řešení této otázky řízení kvality a propojil je příklady z jeho dlouholeté praxe auditora. (Otta, 2016)

Kvalitu softwaru definuje i jeho zabezpečení proti ztrátě či odcizení dat. Vývojem bezpečnostní situace v České republice a v Evropě, ale také i přehledem jednotlivých bezpečnostních standardů se zabývá ve své knize Systém managementu bezpečnosti informací Martin Drastich. (Drastich, 2011)

V článku nazvaném „Quality management in the 21st century enterprises: Research pathway towards Industry 4.0“ publikovaném v lednu roku 2019 v časopise „International Journal of Production Economics“ se sice autoři zaměřují spíše na průmysl 4.0, ale obecné závěry se dají využít i na řízení kvality v jiných odvětvích než pouze v průmyslu. Zvláště ty, které se zabývají důležitostí lidského přístupu a flexibilitou. (International Journal of Production Economics, 2019)

Článek v časopise Computer Standards & Interfaces z března 2019 se zabývá studií, která poukazuje na to, že řízení podnikových rizik, které vychází ze správně vedeného projektového řízení a řízení kvality, má přímý pozitivní dopad na konkurenceschopnost dané společnosti v odvětví informačních technologií. (Computer Standards & Interfaces, 2019)

K podobnému názoru dospěli i v časopise Business Research Quarterly z ledna 2015.

Empirickou studií provedenou na 230 španělských IT společnostech dokázali, že existuje značná závislost mezi managementem kvality a vyšší konkurenceschopností firem.

(Business Research Quarterly, 2015)

(19)

2. Využití projektového řízení ve vývoji informačního systému

Kvalita softwaru není jen o dobře fungujícím kódu, ale jde i o jiné aspekty celého projektu.

Zvláště v agilním přístupu, kdy je pozornost věnována především spokojenosti zákazníka před obyčejným psaním kódu. Je to o tom, za jak dlouho bude takový software dodán.

Jakou úroveň služeb k tomu zákazník dostane atd. V první fázi ke kvalitnímu systému vede správně fungující projektové řízení, ze kterého netěží pouze firma, ale i zákazníci.

Začlenění projektového řízení do procesů firmy může značně zkrátit čas potřebný k dodání finálního produktu, v tomto případě informačního systému, zákazníkovi.

Mít správně rozvržené pracovní povinnosti a kompetence jednotlivých pracovníků a manažerů projektu umožňuje hladký průběh projektového řízení a tudíž i napomáhá kvalitě.

Dle definice od Doležala (2016, s. 16): „Projektovým řízením (project management) se rozumí soubor norem, doporučení a best of practice zkušeností, popisujících, jak řídit projekt. Vzhledem k různorodosti projektů jako takových se veskrze jedná spíše o všeobecně platné skutečnosti, určitou filozofií přístupu k řešení dané problematiky než o konkrétní a podrobné směrnice, návody apod.

Projektové řízení je způsob přístupu k návrhu a realizaci procesu změn (tj. projektu) tak, aby bylo dosaženo předpokládaného cíle v plánovaném termínu, při stanoveném rozpočtu s disponibilními zdroji tak, aby realizovaná změna nevyvolala nežádoucí vedlejší efekty.

Jinými slovy – aby vznikl úspěšný projekt.

Zahrnuje především samotné řízení jednotlivých projektů, vytvoření organizační struktury a koordinaci projektů z hlediska termínů a disponibilních zdrojů.“

Projektové řízení se dá z hlediska času rozdělit do pěti základních částí, které představují koncepční posloupnost aktivit (Doležal, 2016):

 Část definování – definování cíle a účelu projektu

 Část plánování – naplánování jakými metodami a postupy budou splněny cíle

(20)

 Část vykonávání – samotná realizace řešení

 Část monitorování – kontrola postupu práce a odhalení případných odchylek od plánu

 Část ukončení – ověření, že výsledek odpovídá specifikaci v zadání, vyhotovení dokumentace a vyhodnocení projektu (feedback)

Způsobem jak zajistit, že zákazník dostane informační systém v dobré kvalitě i podle mezinárodních měřítek, je použití jedné z následujících známých celosvětových standardů a metodik, které jasně určí, zda software obsahuje všechny sounáležitosti.

2.1 Světové standardy a metodiky projektového řízení

Existuje mnoho standardů, norem a vyhlášek, které řeší přístup k vytváření projektů. Mezi hlavní, světové standardy a metodiky patří PM BoK, ICB, PRINCE2® a do jisté míry i ISO 21 500. Tyto si jsou velice podobné, protože vycházejí ze stejné základní filozofie, i když se liší místem vzniku nebo způsobem zpracování. Jejich cílem je aby si pracovníci na projektech dokázali vzájemně porozumět, pochopit se a efektivně spolupracovat na společném cíli.

Přesto je nutné tyto standardy vnímat spíše jako pomůcku než striktní návod, protože každý projekt je jedinečný. Co funguje v jednom projektu, se nemusí osvědčit v druhém.

Tím, že tyto standardy jsou psané, tak aby byly co nejobecnější a daly se využít při projektech ze široké škály oborů, nejsou tyto standardy příliš konkrétní.

Dalším důležitým faktorem v projektovém řízení jsou především lidé. Lidé jsou různí a liší se například zkušenostmi, pracovní morálkou, pohledem na věc atd. (Doležal, 2016)

2.1.1 Project Management Body of Knowledge (PM BoK)

Tento standard vytvořilo profesní sdružení firem a individuálních projektových manažerů, Project Management Institute, PMI®. Toto sdružení má přes půl milionu aktivních členů po celém světě.

(21)

A Guide to the Project Management Body of Knowledge, neboli PMBoK, vznikl již v roce 1996. V době psaní této práce se tento standard nacházel ve verzi 5 a nadále probíhá vývojem. (Řeháček, 2013)

Základním přístupem je procesní pojetí problematiky, kdy je management chápán jako proces a definován jako sled manažerských sekvenčních funkcí. (http://ekonomika- managment.studentske.cz/2009/02/postklasicke-teorie-pojeti-pristupy.html)

2.1.2 PRojects IN Controlled Environments (PRINCE2®)

PRINCE2® je další procesní metodika, byla vytvořena společností AXELOS. První verze této metodiky vznikla v roce 1989 jako standard zaměřený na projekty informačních systémů veřejné státní správy. Tato první verze vznikla za účelem předcházení negativních jevů v projektech, jako je například překročení rozpočtu nebo zpoždění projektu. Druhá verze metodiky z roku 1996 byla již zobecněna pro použití u všech typů projektů. Tato druhá verze byla v roce 2009 revidována do stávající podoby. (Doležal, 2016)

Mezi základní prvky metodiky patří:

 Sedm hlavních principů – mezi něž náleží například jasně definované role a odpovědnosti, zaměření na dodávaný produkt aj.

 Sedm témat – kterým má být věnována pozornost během celé doby fungování projektu. Obchodní příklad, organizace, kvalita, plány, rizika, změny a progres.

 Sedm procesů – probíhajících v rámci projektu

Schéma na obrázku 1 ukazuje jednotlivé fáze životního cyklu v případě metodiky PRINCE2.

(22)

Obrázek 1: Schéma PRINCE2® metodiky Zdroj: Doležal, 2016, s. 29.

2.1.3 IPMA® Competence Baseline (ICB)

ICB byl vytvořen a je spravován profesní organizací International Project Management Association a na rozdíl od předchozích dvou metodik využívá ICB kompetenční přístup k problematice. To znamená, že standard místo soustředění se na přesnou podobu definování procesů a jejich konkrétní aplikace, se zabývá kompetencí, schopností a dovedností projektových manažerů a ostatních členů týmů.

Tento standard vznikal v Evropě v šedesátých letech a díky značně odlišným národním normám v jednotlivých státech ICB nediktuje konkrétní podobu procesů, ale spíše doporučuje určité procesní kroky, které je vhodné aplikovat na určité projektové situace.

Jako klíčová je nutnost správného obsazování pracovních pozic vhodnými týmovými rolemi. Standard tudíž ponechává značný prostor kreativitě a vlastnímu názoru.

I přes odlišnou formu standardu je jeho základní filozofie, používané metody a postupy, takřka totožná s ostatními standardy. Projektové řízení je rozděleno do tří základních kompetenčních oblastí (Doležal, 2016):

 Technická kompetence – metody, techniky a nástroje

(23)

 Behaviorální kompetence – měkké dovednosti

 Kontextová kompetence – integrační a systémové dovednosti a znalosti

2.1.4 ISO 21 500

V předchozích letech se řízením projektů zabývaly ISO normy řady 10 000, které sestávaly z doplňkových návodů a příruček popisující některé oblasti v rámci systémů řízení kvality.

Tato směrnice byla postupem času nahrazena směrnicí ISO 21 500:2012 Guidance on project management, v češtině vydanou o rok později jako ČSN ISO 21 500 Návod k managementu projektu. Základní forma přesto zůstává i přes jistou modernizaci. Jak už název napovídá, jedná se o návod k základní terminologii a popisu systému řízení kvality v projektovém řízení. Ale nejedná se o tzv. systémovou normu, tudíž se podle ní nedá certifikovat jako v případě standardu PMI® nebo standardu IPMA®.

ISO 21 500 se pojmově shoduje s PMI® PM BoK verze 5 a kromě toho jsou v ní obsaženy definice kompetencí lidí pracujících na projektech jako je tomu ve standardu IPMA® ICB.

(Doležal, 2016)

2.2 Základní role – zainteresované strany

Jedná se o osoby nebo organizace, které jsou aktivně zapojené do projektu nebo jsou tímto projektem ovlivněné nebo jejich zájmy, ať již pozitivně či negativně. V angličtině tomu odpovídá výraz stakeholder. Tyto zainteresované strany mohou mít značný vliv na průběh projektu nebo jeho výsledek. Z toho plyne, že zainteresované strany nelze identifikovat pouze interně v rámci jedné organizace. I ostatní subjekty, jako jsou například zákazníci, uživatelé, dodavatelé atd., mohou být projektem jakkoli dotčeni. (Svozilová, 2011), (Young, 2007)

 Zadavatel projektu – má zájem projekt zrealizovat, respektive docílit z něj požadovaného užitku

 Uživatelé projektu – osoby, které budou pracovat s dokončeným projektem

(24)

 Vlastník projektu – osoba, s autoritou a pravomocí k rozhodování o zásadních aspektech projektu

Bývá obvyklé, že některé nebo všechny výše uvedené role splývají do jedné, ale není tomu tak vždy.

Dále je potřeba zohlednit i zájmy tzv. dotčených stran. Jsou to tací, kteří nepatří do žádné z výše uvedených skupin, ale přesto se jich projekt přímo či nepřímo dotýká. Patří sem například vedoucí úseků, další pracovníci, konkurence, odbory, obyvatelé přilehlých lokalit, ochránci přírody apod. (Doležal, 2016)

2.3 Základní role – v projektovém týmu

Základní složkou organizační struktury spojené s konkrétním projektem je řídící tým projektu, který sestává z manažera projektu, případných asistentů manažera projektu, garantů jednotlivých výstupů, specialistů a případně i dalších pracovníků. Hlavním úkolem vedoucích týmů projektu je organizovat, řídit a vést projekt. (Doležal, 2016)

Nejdůležitější role v projektovém týmu lze vnímat následovně:

2.3.1 Manažer projektu

Manažer projektu je zodpovědný za správné naplánování a realizaci projektu, tedy dosažení cílů projektu a jejich kompatibilitu s očekávanými přínosy, za které však již nezodpovídá. V průběhu vypracovávání projektu může manažer delegovat svou zodpovědnost za splnění jednotlivých dílčích činností na garanty jednotlivých výstupů.

(Doležal, 2016)

Manažer projektu je standardně zodpovědný za dodání projektu ve sjednaném rozsahu při splnění termínu a rozpočtu, včetně lidských zdrojů, tak aby byl výsledek kompatibilní s očekávanými přínosy. Dále je zodpovědný za postup projektu v čase, plnění dílčích milníků, dodržování rozsahu a požadavky na zdroje. Vyžádá-li si to situace i včasnou reakci na nepříznivý trend vývoje projektu a včasné informování vlastníka projektu o všem podstatném.

(25)

Naproti tomu manažer projektu nikdy nezodpovídá za formulaci základní listiny projektu, za kterou zodpovídá sponzor projektu, ani za vlastní tvorbu výstupů projektu, za tu zodpovídá garant výstupu.

Manažer projektu má pravomoc delegovat svoji zodpovědnost za splnění výstupů na další členy projektového týmu, především garanty výstupů. Po domluvě s příslušným liniovým manažerem nominovat členy projektového týmu. Akceptovat nebo odmítnout dokončenou část projektu dodanou garantem výstupu. Schvalovat realizaci změn, pokud se nejedná o velké změny se zásadním dopadem na výslednou podobu dokončeného projektu.

Operativně úkolovat a řídit členy projektového týmu, anebo jednat s okolím projektu o záležitostech projektu. (Šochová, 2014)

2.3.2 Garant výstupu

Garant výstupu projektu je zodpovědný za správný, včasně vytvořený výstup projektu a s dodržením rozpočtu. Dále výstup musí být kompatibilní s cílem projektu a následným očekávaným užitkem. V případě komplexních projektů může být garant výstupu i manažer příslušného podprojektu. V průběhu projektu může delegovat svoji zodpovědnost za splnění jednotlivých dílčích činností na přidělené členy projektového týmu.

Garant výstupu je standardně zodpovědný za věcnou a odbornou kvalitu výstupu se splněním termínu a nepřekročením rozpočtu daného výstupu projektu. Dále má za úkol formulovat zadání pro přidělené členy týmu a dozor nad nimi, zdali plní zadání v požadovaném rozsahu dle specifikace a dodržování časového plánu. Případně i včasnou a adekvátní reakcí na nepříznivý vývoj v rámci realizace výstupu a včasné informování manažera projektu o všem podstatném.

Na rozdíl od manažera projektu garant výstupu nikdy nezodpovídá za stav projektu.

Garant výstupu má pravomoc delegovat zodpovědnost za splnění výstupů na členy dílčího týmu a operativně je řídit a úkolovat. Dále může volit způsob provedení, technologii a případné dodavatele v rámci tvorby příslušného výstupu při podmínce dodržení rozsahu projektu, nákladů a časového rámce projektu. A má možnost odmítnout nesrozumitelné

(26)

nebo nekompletní zadání. Pokud zadání přijme, přijme tím i plnou zodpovědnost za dosažené výstupy v jakosti, nákladech i čase. (Doležal, 2016)

2.3.3 Člen projektového týmu

Další členové projektového týmu, kteří mají na starosti jednotlivé dílčí úkoly, které povedou ke zdárnému konci projektu. Tito členové se spolupodílejí na tvorbě postupu, harmonogramu a dalších plánovacích aktivitách daného projektu. Musí plnit přiřazené úkoly ve stanovených termínech a kvalitě, zároveň ale také musejí provádět i nenaplánované či mimořádné činnosti. Přímo se zodpovídají vedoucímu svého projektu.

Podle velikosti projektu a počtu členů týmu záleží na tom, jak moc budou zatíženi, kolik týmových rolí a jaké z nich budou vykonávat. V ideálním případě by měly být obsazeny všechny role. Členové týmu se musejí často v průběhu projektu potýkat s určitými bariérami.

Na následujícím schématu je příklad základní organizační struktury s různými členy projektového týmu.

Obrázek 2: Organizační struktura projektu Zdroj: Doležal, 2016, s. 41.

(27)

2.4 Základní organizační modely

Vhodné organizační uspořádání závisí na spoustě faktorů, mezi něž například patří typ organizace, komplexnost a rozsah projektů. Organizační uspořádání může být trvalé, dočasné, pouze po dobu trvání daného projektu nebo koexistování obou. Mezi trvalou a dočasnou organizační strukturou je nezbytné definovat určitá rozhraní a vazby, které umožní tok informací, koordinaci a řízení.

Prostřednictvím druhotných organizačních struktur vznikají určité přechodné vztahy, které umožňují koordinování činnosti různých projektových týmů a činnosti liniových pracovníků z různých útvarů, kterým jsou případně přiřazovány odpovídající projektové pravomoci a zodpovědnosti bez ohledu na jejich liniové zařazení. Tím se v těchto druhotných organizačních strukturách uplatňují specifické formy potlačení vztahů nadřízenosti a podřízenosti pracovníků.

2.4.1 Útvarové projektové řízení

Model útvarového projektového řízení nevytváří požadavky na změny ve stávající organizační struktuře. Tento model je tudíž vhodný pro řízení menších projektů, snadno realizovatelných v rámci jednoho oddělení v organizaci. Pracovníci zůstávají na svých stálých liniových pozicích a jsou řízeni prostřednictvím svých liniových vedoucích.

Základním komunikačním nástrojem jsou pravidelné pracovní porady koordinačního charakteru pro pracovníky, kteří se podílejí na daném projektu. (Svozilová, 2011)

Díky formě této organizace se zachovávají existující expertní skupiny ve společnosti, ale tudíž je náročné získat potřebné lidské zdroje pro projekt. Existují bariéry a omezení pro horizontální tok informací mezi jednotlivými útvary společnosti a informační toky fungují spíše vertikálním směrem uvnitř každého útvaru. Z následujícího obrázku je patrné, že jediné skutečné řídící místo projektu je na vrcholu struktury v osobě vrcholového manažera útvaru nebo přímo i generálního ředitele. (Doležal, 2016)

(28)

Obrázek 3: Útvarové projektové řízení Zdroj: Doležal, 2016, s. 47.

2.4.2 Autonomní projektové řízení

Tato organizační struktura je vytvořena výhradně pro projektové účely při realizaci jednoho rozsáhlého projektu. Jednotliví členové projektového týmu jsou po celou dobu realizace daného projektu uvolněni ze svého běžného pracovního umístění. Toto uspořádání se obvykle využívá pro strategicky náročnější a významnější projekty ve společnosti. (Doležal, 2016)

Autorita a pravomoci o rozhodování jsou zastoupeny jedinou rolí v projektu a to rolí projektového manažera, který má na starosti veškeré plánování, organizování a kontrolu nad pracemi souvisejícími s realizací projektu. Jednotlivá specializovaná projektová oddělení jsou vytvářena dle potřeb projektu s ohledem na jejich velikost, složení a odbornost jednotlivých pracovníků, jak je vidět na následujícím obrázku. (Young, 2007)

(29)

Obrázek 4: Autonomní projektové řízení Zdroj: Doležal, 2016, s. 47.

2.4.3 Maticové projektové řízení

Maticová organizační struktura je výhodná pro řešení různých projektů, protože dává projektovému manažerovi k dispozici veškeré zdroje pod jeho přímou kontrolu. Je však v běžné firemní realitě obtížně realizovatelná. Proto je běžnější a výhodnější uvolňovat zdroje pro projekt pouze na omezenou dobu nebo na částečný úvazek.

Jednotliví členové projektového týmu zůstávají na svých stálých pozicích v rámci běžné organizační struktury, na kterých plní své běžné i projektové úkoly. Jako je znázorněno na obrázku 5. Mohou takto pracovat i na více projektech zároveň. (Doležal, 2016)

(30)

Obrázek 5: Maticové projektové řízení Zdroj: Doležal, 2016, s. 48.

2.4.4 Síťové projektové řízení – projektová organizační struktura

Jedná se o vztahy mezi jednotlivými realizovanými projekty a kmenovou organizací, která je tvořena odbornými odděleními a vrcholovým vedením organizace, nehledě na velikosti.

Často bývá minimalistická. Výhodou tohoto modelu je, že je vysoce flexibilní a umožňuje řešení složitých projektů, které spočívá v řízení sítě paralelně probíhajících projektů, řízení vztahů mezi kmenovou organizací a jednotlivými projekty, ve stanovení priorit jednotlivých projektů, v alokaci disponibilních zdrojů, komunikaci a motivaci.

Tento model u nás není příliš běžný, obvykle se s ním jde setkat u vývoje software. Kdy trvalou organizaci tvoří malá skupina stálých zaměstnanců, a pro vývoj jednotlivých projektů jsou ostatní členové projektového týmu najímáni mimo organizaci. Po úspěšném dokončení projektu jsou tito externí vývojáři buďto přeřazeni na jiný projekt nebo je s nimi spolupráce ukončena.

(31)

Významný faktorem pro úspěch a dosažení cílů organizace je volba vhodného organizačního uspořádání pro daný typ organizace. Nehledě na to jaký model bude zvolen jako základ, všichni významní aktéři ve společnosti by jej měli dobře znát a to z pohledu jak trvalé, tak i dočasné organizace. Projektový manažer by měl znát funkční procesy dané společnosti a stejně tak by linioví manažeři měli znát základní principy řízení projektů. Co možná nejpřesnější vymezení rolí, zodpovědností a pravomocí jednotlivých aktérů může podpořit efektivitu a úspěch a odstranit zbytečné zmatky, konflikty a kompetenční spory uvnitř organizace.

Pokud je společnost tzv. projektově orientovanou, tedy znamená, že více než padesát procent jejích kapacit je alokováno v projektech, zcela zásadní pro tuto společnost je dobré vymezení a popis subsystému integrovaného manažerského systému. Organizační struktura může například vypadat jako na obrázku níže. Organizace s pokročilou orientací na projekty je obvykle velmi flexibilní s decentralizovanými pravomocemi a efektivním zvládáním změn. (Doležal, 2016)

Obrázek 6: Síťové projektové řízení – projektová organizační struktura Zdroj: Doležal, 2016, s. 50.

2.4.5 Projektová kancelář – rozhraní trvalé a dočasné organizace

Pokud organizace mívá velké množství projektů, tak je pro ni výhodné zavést do trvalé organizační struktury oddělení, které tvoří určité rozhraní mezi trvalou organizací a

(32)

projekty. Toto oddělení se většinou nazývá projektová kancelář a není nijak pevně stanoveno, jak má vypadat. V základu by jen mělo pokrýt následující hlavní funkce:

 Funkce definiční - útvar slouží především k projektování struktur organizace řízení projektů a jejich implementaci do integrovaného manažerského systému

 Funkce kontrolní - útvar slouží jako kontrolní orgán projektů organizace, provádí audity a další kontrolní aktivity

 Funkce realizační - útvar projektových manažerů, kteří jsou nasazováni na různé projekty a v mezidobí jsou organizačně sdruženi za účelem předávání zkušeností, vzdělávání apod. Případně může být tato funkce chápána i jako „pozice“ pro osvědčené nenasazené projektové manažery, s nimiž se v dohledné době počítá pro konkrétní projekty, a pro projektové manažery – juniory, kteří jsou dlouhodobě připravováni do seniorských pozic

 Funkce podpůrná – ve smyslu místa nebo zařízení, kde se mohou různé projektové týmy scházet nebo ho využívat pro svoji práci. Je to například zasedací místnost, kopírka, informační subsystémy nebo softwarové aplikace, které jsou používány k řízení projektů

Uvedená pojetí projektové kanceláře se mohou různě prolínat, avšak je vhodné co nejvíce organizačně oddělit funkce realizační a kontrolní. Projektová kancelář by správně měla být co možná nejvíce nezávislým oddělením v rámci trvalé organizace a která je podřízená nejvyššímu vedení. Jen takhle lze zajistit objektivní a nestranný přístup vůči ostatním organizačním útvarům a umožňuje posuzování všech projektů z hlediska celé organizace.

(Doležal, 2016)

2.5 Modely životního cyklu vývoje softwaru

Součástí projektového řízení jsou následující metodiky vývoje softwaru. Což jsou v podstatě komplexní návody a postupy zkoumající správný vývoj aplikace s větším nadhledem. Metodiky se obecně nezabývají konkrétními způsoby jak danou operaci provést nebo čím ji provést.

(33)

2.5.1 Model napiš a oprav

Vznikl v úplném prvopočátku vývoje softwarových programů. Nejedná se však o uměle vytvořený model, spíše než to, se jedná o zcela spontánní a přirozený způsob jak lidé pracují. Nejdříve dojde k naprogramování aplikace a jejímu následnému uvedení do provozu, kde po té dochází k opravování veškerých chyb. Tyto kroky jsou znázorněny na obrázku 7. Tento model je značně neefektivní. Proto se často využívá jen u malých projektů, kde je jeho využití ospravedlnitelné. (Kadlec, 2004)

Obrázek 7: Schéma modelu napiš a oprav Zdroj: Upraveno dle (Kadlec, 2004)

2.5.2 Stagewise model

Tento model je založen na striktní posloupnosti jednotlivých fází, které tak rozdělují vývojový cyklus. Tyto fáze jsou Definice problému, specifikace požadavků, návrh a architektura, implementace integrace a provoz. A jsou znázorněny na obrázku 8.

Nejzásadnějším problémem v tomto modelu je absence jakékoli zpětné vazby. Postup vývoje směřuje pouze kupředu. Nedochází k žádným revizím, nehledají se žádná rizika, nehodnotí se dosavadní výsledky a ani nedochází k návratu do předchozích fází projektu za účelem upravení požadavků. K návratu bylo možné až po samotném dokončení celého cyklu, tedy po dodání. (Kadlec, 2004)

Implementace Dodání

aplikace

Oprava chyb,

rozšiřování

(34)

Obrázek 8: Schéma modelu Stagewise Zdroj: Upraveno dle (Kadlec, 2004)

2.5.3 Vodopádový model

Vodopádový model vznikl v sedmdesátých letech s cílem klást větší důraz na způsob vedení vývoje softwaru. Hlavním rozdílem oproti předchozímu modelu a zároveň největším přínosem Vodopádového modelu je zakomponování zpětné vazby na konci každé fáze vývoje. Pokud po dokončení jednotlivých fází vývoje očekávaný stav neodpovídá žádoucímu, lze například upravit specifikaci, doladit návrh nebo zvolit jiné podmínky testů a podobně. Vodopádový model je všeobecně považován za vynikající výchozí bod pro vývoj softwaru. Je jednoduchý, lze snadno kontrolovat dosažený pokrok a umožňuje vracení se o krok zpět během vývoje. Což ilustruje obrázek 9.

Naopak ale existují i jeho nevýhody, například dlouhé dodací doby, určitá nepružnost modelu a způsob dodání systému najednou, kdy zákazník dlouhou dobu nevidí žádnou aktivitu a pak dostane hotový kompletní produkt. (Kadlec, 2004)

Definice problému

Specifikace požadavků

Návrh

Architektura

Implementace

Integrace

Provoz

(35)

Obrázek 9: Základní struktura vodopádového modelu Zdroj: Upraveno dle (Kadlec, 2004)

2.5.4 Spirálový model

Spirálový model vznikl v roce 1985 a dodnes věrně odráží skutečný životní cyklus širokého spektra systémů. Spirálový model byl reakcí na některé nedostatky vodopádového modelu. A to použitím iterativního přístupu a důslednou analýzou rizik. Dále také určuje jinou posloupnost jednotlivých fází projektu. Idea je, že na začátku projektu je složité načrtnout podrobné specifikace požadavků a jednotlivé funkce, a tudíž by se měl stanovit pouze obecný rámec. A posléze se vyvine část systému, který se dále po vytvoření prokonzultuje se zákazníkem a ten poté dodá zpětnou vazbu, podle které se doplní podrobnější specifikace. To znamená, že vývoj probíhá v opakovaných krocích jinak zvaných iteracích. Na svoji dobu to byla revoluční koncepce a zcela změnila chápání životního cyklu. (Kadlec, 2004)

Jednotlivé kroky během vývoje softwaru ve spirálovém modelu jsou popsány obrázkem 10.

Definice problému

Specifikace požadavků

Návrh

Architektura

Implementace

Integrace

Provoz

(36)

Obrázek 10: Schéma spirálového modelu životního cyklu

Zdroj: Diagnostika a testování elektronických systémů [online]. [cit. 2019-02-26]. Dostupné z:

http://www.umel.feec.vutbr.cz/bdts/index.php/embedded-systemy/vyvojove-modely

2.5.5 Agilní metodiky

Agilní metodiky se vyznačují podstatně menší měrou formálnosti oproti klasickým metodikám. Agilní metodiky se soustředí hlavně na spolupráci, komunikaci a připravenost na změnu. Jde o to, aby pracovní tým byl pokud možno co nejvíce produktivní a efektivní a aby výsledný produkt byl dodán v prvotřídní kvalitě a v co nejkratším čase. Cílem agilních metodik není nějaký produkt, ale hodnota zákazníka neboli jeho spokojenost.

(Šochová, 2014, s. 13)

U agilního vývoje neexistuje žádný přesně definovaný postup nebo model, kterého by se vývojáři měli nebo museli striktně držet. Spíše se jedná o způsob myšlení a řešení problémů. Myšlenku agilního vývoje softwaru přibližuje následující manifest (Agilemanifesto, 2001):

 Jednotlivci a interakce před procesy a nástroji

 Fungující software před vyčerpávající dokumentací

(37)

 Spolupráce se zákazníkem před vyjednáváním o smlouvě

 Reagování na změny před dodržováním plánu

Při vývoji softwaru je složité odhadnout čas a náklady pro vytvoření aplikace. Obvykle také dochází ke změně zadání ze strany zákazníka, protože sám na začátku ani neví, co chce.

Lean metoda

Lean metoda je založena na omezování rozdělané práce, to znamená, že v danou chvíli se pracuje jen na tom, co je přesně známé a definované. Jedná se o převedení „systému tahu“

do vývoje informačních technologií. Takzvaně přestat vyrábět na sklad, ale až tehdy, když je to potřeba. Podle základních doporučení by se nemělo pracovat na něčem, co se později ani nepoužije, tento čas by měl být využit efektivněji. Zpětná vazba by se měla zjišťovat již během vývoje, aby se předešlo časovým ztrátám po dokončení vývoje a možnému předělávání aplikace. Čím později padne rozhodnutí, tím více informací bude do té doby možno získat. Dále může pomoct delegování zodpovědnosti na jednotlivé členy týmu, což povede k jejich většímu zapojení a též i motivaci na rozdíl od klasických topdown firemních struktur. (Šochová, 2014, s. 18-19)

2.5.6 Další modely vývoje softwaru

Jedná se o různé modely, které vycházejí z vodopádového modelu a snaží se odstranit jeho nedostatky. (Kadlec, 2004)

 Test Development – vodopádový model je rozšířen na konci každé fáze o specifikaci a provádění testů

 Exploratory Programming – předchůdce iterativního přístupu spočívá ve vyvinutí pouze základní kostry podle základních požadavků, které se poté rozšiřují o konkrétní připomínky a specifičtější požadavky zákazníků

 Prototyping Model – vodopádový model kde se nejdříve vytvoří prototyp systému

(38)

 Evolutionary/Incremental Model – Evoluční či Inkrementální model je předchůdcem iterativního programování

(39)

3. Případová studie organizace

V následujících odstavcích se nachází popis a srovnání organizační struktury firmy a všech rolí konkrétního projektu ve zkoumané firmě. Záměrem této studie je porovnat a propojit teoretická východiska s těmi praktickými.

3.1 Zainteresované strany

Zainteresované strany, které se aktivně účastní tohoto konkrétního projektu, by se daly rozdělit do tří skupin.

3.1.1 Zadavatel projektu

Zadavatelem projektu je obvykle sportovní federace anebo organizační výbor, kteří si koupí licenci na tento registrační a akreditační systém. V rámci kontraktu je zahrnuta konfigurace systému pro potřeby dané plánované události. Dále kontrakt může obsahovat i dodatečný vývoj nové funkcionality či úpravu stávajícího chování systému. Ve formě alokovaného času, což je součet celkového odpracovaného času všech vývojářů pracujících na určitém zadání. Zákazník samozřejmě očekává bezchybný funkční systém, dalšími chtěnými vlastnostmi jsou jednoduchá obsluha, kompatibilita všech součástí a použití moderních technologií. Zadavatelem projektu se stává jakýkoli zákazník, který projeví zájem o tento registrační a akreditační systém a následně si zakoupí jeho licenci. To vede k tomu, že i přesto, že se jedná o jeden a ten samý informační systém, tak má vícero zadavatelů, kteří mohou, ale nemusejí mít stejné požadavky a cíle.

Každý ze zadavatelů představuje jednu sportovní federaci, například Mezinárodní Basketbalová federace (FIBA), Mezinárodní a Evropská Házenkářská federace (IHF a EHF), Mezinárodní Plavecká federace (FINA) a Evropský Olympijský výbor (EOC).

3.1.2 Uživatelé projektu

Tímto pojmem se myslí koncoví uživatelé, kteří zčásti budou stejní jako zadavatelé

(40)

určen pro registraci všech účastníků a umožňuje široké komplexní řešení celé plánované události. Mimo jiné sem patří organizační výbor dané události, sportovci a jejich doprovod, média, externí dodavatelé a bezpečnostní složky. Tito všichni musejí být akreditováni a tudíž i zaregistrováni, ať již sami sebou nebo někým jiným. Ne všichni uživatelé mají zkušenosti s počítači a informatikou všeobecně, proto musí být systém pro ně dostatečně přehledný a jednoduchý na pochopení.

3.1.3 Vlastník projektu

Vlastníkem projektu by se v tomto případě dala označit zkoumaná firma, jejíž vedení má za cíl, jakožto v jakémkoli jiném odvětví, za co nejnižších nákladů vytvořit a provozovat co nejlepší a konkurence schopný výrobek nebo službu, v tomto případě informační systém.

Vlastníkem je proto, že pouze prodává licenci k používání svého softwaru. Jedná se o koncepci Software jako služba (SaaS), kdy poskytovatel webové aplikace pouze poskytuje možnost s aplikací pracovat, nikoli však aplikaci samotnou. Aplikace je hostována na vzdáleném serveru a klient k ní přistupuje prostřednictvím internetu. Na stejném principu funguje například sada aplikací Google Apps. Další podobná koncepce je Platforma jako služba (PaaS), kde si zákazník pronajímá nástroje na vývoj aplikací a vlastní aplikaci si musí vyvinout sám. Hranice mezi oběma koncepcemi může být někdy poněkud nejasná.

(Velte, 2011)

3.2 Projektový tým

Projektový tým tvoří již konkrétní zaměstnanci pracující na vývoji a chodu projektu po celou jeho dobu životnosti. Projektový tým pro tento projekt je značně skromný a sestává se ze čtyř lidí. To nutně vede k tomu, že jeden člen týmu zastává i vícero týmových rolí.

(41)

Základní rozdělení rolí je následující:

3.2.1 Manažer projektu

Celý tento projekt stojí na práci projektového manažera, který toho o tomto informačním systému ví nejvíce, zároveň má také nejvíce zkušeností z celého týmu. Jeho další rolí, kromě řízení a plánování projektu, je komunikace se zákazníky. Ať již se jedná o školení či diskutování o budoucím vývoji. Manažer by měl být flexibilní, umět efektivně využívat dostupných informací. V případě nutnosti najít alternativy postupu.

Manažer projektu se nachází uprostřed všeho dění a měl by se starat o řízení činností a vztahů uvnitř projektu, motivování členů projektového týmu a každodenní řízení procesů.

(Svozilová, 2011, s. 31)

Dle definice projektových rolí podle Doležala, by se v tomto případě dala Manažeru projektu přisoudit i role Garanta výstupu. Kdy je zodpovědný za správný a včasný výstup projektu. (Doležal, 2016)

3.2.2 Asistent manažera projektu

Zkoumaný projektový tým se skládá ze dvou asistentů projektového manažera. Jejich hlavní aktivitou je komunikace se zákazníky a jejich technická podpora. Což zahrnuje školení, správná konfigurace systému a případně i pomoc s obtížnými kroky v registračním či akreditačním workflow1. Dále také příprava dokumentace. Každý z asistentů má přidělené určité zákazníky, zadavatele projektu. A každý z asistentů má jednoho zadavatele projektu jako svoje hlavní zaměření, ale zároveň má i sekundární, tak aby existovala zastupitelnost například v případě nemoci, dovolené nebo služební cesty. Každý z nich

1 Workflow (v překladu: průběh práce, pracovní postup) V informatice, ale také jiných oborech lidské působnosti se takto označuje způsob pracovního postupu, nebo také celý pracovní proces. Složitější operace jsou zde rozvrženy a rozepsány do jednotlivých bodů a dílčích prací.

Zdroj: https://it-slovnik.cz/pojem/workflow/?utm_source=cp&utm_medium=link&utm_campaign=cp

(42)

musí znát jak je nakonfigurovaný systém pro daného zákazníka, znát zákaznické kontaktní osoby, historii komunikace a další specifika daného zadavatele projektu.

Dále vzhledem k malé velikosti projektového týmu je jejich další rolí, testování systému a hledání chyb. Tato role je označována jako tester. Cílem testera je odhalit veškeré chyby v systému, které se objevily během vývoje, nebo špatnou konfigurací. Druhy testování jsou Testování jednotek, Integrační testování, Systémové testování a Akceptační testování.

V prvním případě se jedná o Testování jednotek, které má za cíl otestovat, zda funguje nově přidaná funkcionalita, tím že se otestuje jen daná část systému a vyzkoušejí se všechny možné kombinace vstupů. Dalším krokem jsou Integrační testy, které zkoumají, zda přidání nové funkcionality neovlivnilo chování staré funkcionality nebo správný chod systému jako celku. Posledním krokem testerů je Systémové testování, což je simulování chování z pohledu zákazníků, jak oni budou systém v praxi sami používat, zdali je systém pro ně dostatečně srozumitelný a práce v něm uživatelsky přívětivá. Akceptační testování již následně provádí sám zákazník, zdali mu systém případně nová funkcionalita vyhovují.

(Patton, 2002)

Tabulka 1: Časová náročnost technické podpory na příkladech Akce

Velikost akce [počet registrovaných

účastníků]

Počet hodin strávených technickou podporou

Winter European Youth

Olympic Festiva 2019 6 700 240

Women’s EHF EURO 2018 7 900 180

FIBA EuroBasket 2017 11 500 130

Youth Olympic Games 2016 16 800 450

Zdroj: Vlastní

Jak je patrné z dat v předchozí tabulce, časovou náročnost podpory projektu určuje rozsah sportovní akce, ale neplatí vždy, že větší počet účastníků také znamená více času stráveného podporou. Dalším určujícím faktorem je to, zda se jedná o multi sportovní akci, či jen akci pro jeden sport. Dále také jak moc je místní organizační výbor akce zkušený s podobným typem akcí.

(43)

3.2.3 Softwarový inženýr

Posledním, ale neméně důležitým členem týmu je vývojář. Vývojář má na starosti samotné programování aplikace a návrh logiky pro řešení zadání.

Správný vývojář se také musí průběžně seznamovat s novými technologiemi a umět je adaptovat pro jeho vlastní práci.

Kromě stálého vývojáře, který je součástí zkoumaného týmu, se dle potřeb využívá i pomoci od vývojářů z jiných pracovních týmů, zejména pokud se jedná o doplňující součásti systému, jako například mobilní aplikace na zařízeních Android a iOS.

Na takto velkém projektu je nedostatečné mít pouze jednoho vývojáře. Ten svým úsilím stačí pouze na konfiguraci pro nové a stávající zákazníky, opravy chyb a pouze drobné rozšiřování funkcionality. A díky tomu se práce na velkých rozšířeních a nových modulech systému protahuje.

3.2.4 Externí konzultanti

Pro správnou definici požadavků a následné naprogramování systému je nutné zcela pochopit danou problematiku a pracovní postupy. K vysvětlení těchto postupů se dají využít externí konzultanti, kteří mají bohaté zkušenosti s danou problematikou a i určitý pohled zvenčí či nadhled. Nejsou limitováni pouze znalostí jednoho konkrétního systému či firemní business logikou.

Vždy když se objeví nový projekt, tak je snahou dozvědět se od zákazníka co nejvíce informací, aby služby firmy byly co možná na nejvyšší úrovni. Ale občas spolupráce se zákazníkem z nějakého důvodu je nedostatečná a v tuto chvíli je lepší doplnit si informace i z jiného zdroje. Do současné doby bylo služeb externích konzultantů využito pouze dvakrát, ale již se plánují další konzultace k novým projektům, které jsou zatím v rané fázi vývoje.

(44)

3.3 Organizační model

V praxi je dosti složité identifikovat konkrétní modely organizační struktury různých firem, neboť se mohou z části prolínat a kombinovat.

Organizační model z pohledu fungování zkoumané firmy jako celku představuje model Autonomního projektového řízení. Kdy ke každému novému projektu jsou přiřazeni pracovníci. Hlavním kritériem pro jejich výběr je jejich specializace, ale také momentální pracovní zatížení. Je běžnou situací, že většina pracovníků spolupracuje na dvou a více projektech zároveň. Tímto se tato organizační koncepce lehce přibližuje k Maticovému projektovému řízení, kdy je pohyb jednotlivých pracovníků či celých projektových týmů řízen aktuální poptávkou po pracovní síle na jednotlivých projektech. Toto uzpůsobení dokáže minimalizovat požadavky na celkový počet kmenových zaměstnanců a tím i snižovat náklady spojené s najímáním pracovní síly.

V následující tabulce jsou zachyceny různé situace k programování a jejich časová náročnost podle počtu souběžně pracujících softwarových inženýrů.

Tabulka 2: Časová náročnost podle počtu programátorů Celkový počet

odpracovaných hodin

Počet dní za kolik bude projekt hotov 1 Programátor 2 Programátoři 3 Programátoři Rozšíření

funkcionality 8 1 >1 >1

Nový modul 360 45 32 23

Celý systém 840 105 70 48

Zdroj: Vlastní

Tato tabulka vychází z interních firemních statistik o počtu hodin strávených vývojem jednotlivých projektů. Z toho vyplývá určité zkreslení, protože se jedná o různé projekty, které mají částečně jiné požadavky a rozsah, a také se jedná o různé programátory, kde každý pracuje jinak rychle, ale pro představu je to dostačující.

Zároveň v posledních letech se ve zkoumané firmě stále více využívají externí pracovníci, kteří jsou najímáni na výpomoc s některými projekty nebo jejich částmi. Tímto se do firemní organizační struktury vypůjčují i prvky ze Síťového projektového řízení a to

(45)

konkrétně rozdělení na kmenové a externí pracovníky. Jsou najímáni jak externí programátoři z vybraných libereckých firem, tak se ale také jedná i o jeden projektový tým z Ukrajiny. K tomuto řešení se firma uchýlila, protože již nebylo možné nalézt v Libereckém kraji dodatečnou volnou programátorskou pracovní sílu a najímání si externistů například z Prahy by bylo finančně náročné, značně finančně náročnější než v případě východní Evropy. Nicméně jejich pracovní kvality nebo morálka zdaleka nedosahují takových kvalit jako v případě kmenových zaměstnanců. Možná také díky jazykové bariéře. Jejich výsledná práce musí být vždy zkontrolována a otestována a případně i opravena interním zaměstnancem, protože poměrně často jejich software obsahuje chyby nebo funkcionalita nepokrývá veškeré možné situace, které mohou nastat v případě používání zákazníkem. To staví značný tlak na testery a projektové manažery daných projektů a vyloženě plýtvá jejich časem. Zde by stálo za to zjistit, zda je vůbec výhodné nechat práci na těchto externích pracovnících a poté opravovat jejich kód, nebo zda by nebylo lepší a časově výhodnější, kdyby to naprogramoval rovnou kmenový zaměstnanec.

Toto řešení se nezdá příliš vhodné. Naopak, jako zajímavý nápad se jeví organizační model Projektová kancelář, kde existuje zvlášť oddělení, které by se staralo o celkovou integraci v rámci všech projektů a zajištění používání stejných moderních technologií. Vzhledem k velkému počtu souběžně běžících projektů a dalších, které přibývají, by toto řešení mohlo být pro firmu z dlouhodobého hlediska lukrativní. Projektová kancelář by prospěla lepšímu plánování projektových struktur organizace a efektivnějšímu využívání pracovních sil. V druhé řadě by projektová kancelář mohla sloužit jako kontrolní orgán napříč všemi projekty, stejně tak jako vzdělávací útvar, který by měl na starosti školení a předávání zkušeností novým zaměstnancům nebo funkci preventivní, tak aby se na nových projektech neopakovaly stejné chyby jako v těch předchozích. Jistou náhradu za Projektovou kancelář zastává v současné době projektový ředitel, který má na starosti management jednotlivých projektů a jejich projektových manažerů. Ale projektů k řízení je příliš mnoho pro jednoho člověka, lepší by bylo použít komplexnější řešení jakým je Projektová kancelář.

I když ve firmě vždy při realizaci nového projektu již dochází k určité analýze požadavků a plánování rozvržení pracovních rolí mezi stávající zaměstnance, centrální plánování, které má dokonalý přehled napříč všemi projekty a přehled o pracovní vytíženosti jednotlivých

References

Related documents

Mezi dané nástroje se řadí webové stránky, inzerce pomocí služby Google AdWords, komunikace na sociálních sítích Facebook a Instagram a obsahový marketing

ERP systémů je na světě celá řada a orientace v nich je poměrně těžká. Tyto produkty jsou dodávány jak zahraničními, tak domácími dodavateli. Proto prvním krokem

Aby se lépe využil prostor hal, je potřeba se s břemeny pohybovat i vertikálně a využít tak například skladování v regálech. K tomu se používají nejrůznější

Hlavním cílem této diplomové práce byla optimalizace stávajícího IS kvality, která spočívá v nasazení nového řešení IS pro podporu řízení s využitím BI řešení,

 doplňkových služeb UKN. Tyto koncepce jsou Knihovní radě předkládány vedením UKN. b) Knihovní rada se vyjadřuje ke globálním principům přidělování

Hlavním cílem disertační práce je ověření aplikace Greinerova modelu v podmínkách České republiky k řízení podnikatelských jednotek a vytvoření metodiky

nejen význam pro účely mzdového zařazení. Podle nového označení funkcí je ihned patrné, do kterého útvaru zaměstnanec patří a jakou má funkci. Nová označení se

Mezi jeho odpovědnosti patří mimo jiné výběr projektového týmu, udržování blízkého pracovního vztahu se sponzorem, definování a plánování projektu, identifikace a