Řízení projektů v národních korporacích

Transkript

1 Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod Řízení projektů v národních korporacích Diplomová práce Autor: Bc. Jiří Drbal Informační technologie a management Vedoucí práce: Ing. Václav Šebek, CSc. Praha Duben 2014

2 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 Jiří Drbal

3 Poděkování: Touto cestou bych rád poděkoval panu Ing. Václavu Šebkovi CSc. za trpělivý přístup a podporu při zpracování mé diplomové práce.

4 Anotace Předmětem diplomové práce Řízení projektů v národních korporacích je objasnění a porovnání teoretických principů metodik projektového řízení proti praktickému průběhu projektového řízení na reálném projektu. V závěru práce je zhodnocen postup řízení skutečného projektu ve společnosti s celostátní působností a navrţeny kroky k zefektivnění procesu řízení projektů v podniku. Klíčová slova: Projekt, řízení projektu, projektový manaţer, metodiky projektového řízení, standardizace projektového řízení, OpenSSO. Annotation The main goal of this diploma thesis: "Project Management in National Corporations" is to clarify and draw a comparison between the theoretical principles of the project management methodology and the practical course of the project management on a real project. In conclusion of the thesis is evaluated the actual project management process in the company nationwide and there are proposed certain steps to streamline the process of project management in the enterprise. Key words: Project, project management, project manager, project management methodology, standardization of project management, OpenSSO.

5 Obsah Úvod Teorie řízení projektů v národních korporacích Projekt Řízení projektu Etapy projektu Metody, analýzy a organizace pouţívané při řízení projektu Strategické analýzy Ganttův diagram Metoda síťového grafu Řízení rizik Další pouţívané metody a analýzy na projektech Organizace projektové struktury Ukončení projektu Metodiky projektového řízení PRINCE PMBOK Ostatní metodiky a normy Software pro řízení projektů Microsoft Project... 26

6 3.2 JIRA Oracle Primavera P6 Enterprise PPM Clarity PPM ProjectLibre Řízení projektu v národní korporaci Metody a technika pouţívané při projektovém řízení v národní společnosti Nejčastěji se opakující chyby při řízení projektu v národní společnosti Praktická část Představení národní společnosti zaměřené na poštovní provoz a logistiku Poţadavky a cíle projektu Cíl projektu OpenSSO Poţadavky na projekt systému OpenSSO Příprava projektu Analýza rizik Zajištění zdrojů projektu Technicko-technologický návrh OpenSSO Realizace projektu Realizace vývojového a testovacího prostředí Technické provedení produkčního a záloţního prostředí Instalace s konfigurací serverů provozního prostředí a klientských stanic Nastavení přístupů a bezpečnostních modulů v OpenSSO... 53

7 5.4.5 Charakteristika zálohování dat a programů aplikace Rizika a scénář řešení nestandardních stavů systému Podpora uţivatelů a monitoring autentizační sluţby Testování systému Pilotní provoz Ukončení projektu Provozní akceptační řízení Předání systému do provozu ICT Vyhodnocení projektu Závěr, návrhy a doporučení Seznam pouţité literatury Seznam zkratek Seznam grafů Seznam tabulek Seznam obrázků Přílohy... 82

8 Úvod Řízení projektů nebo téţ častěji pouţívaný pojem projektový management je obor známý jiţ od dávnověku. Do historického kontextu s řízením projektů lze zařadit největší projekty lidstva, jako například stavbu Velké čínské zdi i pyramid v Egyptě. Organizace řízení toku materiálu na tyto stavby, lidí (otroků) a v neposlední řadě zajištění potřeb všech zúčastněných (voda, jídlo, ubytování) v těchto megalomanských projektech, bylo prozatím to nejsloţitější, co lidstvo dokázalo. Moderní řízení projektů se začalo objevovat a vyuţívat od počátku 20. století. Nejprve bylo spojováno s vojenskými projekty a posléze s vesmírným programem (asi nejznámější je projekt Apollo - přistání na Měsíci). Obor projektového řízení se v současnosti neustále vyvíjí, adaptuje a usazuje do firemních procesů po celém světě. Hlavním cílem projektového řízení je nejen optimalizace a racionalizace matriálu či lidské práce, ale hlavně úspora času a finančních prostředků. Téma řízení projektů je zpracováno ve velkém mnoţství odborné literatury a to nejen v češtině, ale převáţně v anglickém jazyce od různých světově uznávaných odborníků. Velké mnoţství těchto odborných knih bylo přeloţeno do českého jazyka, proto budu v této diplomové práci převáţně vycházet z nich. Dalším zdrojem odborné literatury pro moji praktickou část práce jsou interní dokumenty mého zaměstnavatele, jejichţ jsem spoluautorem. Jelikoţ v oboru projektového managementu neustále dochází k vývoji a zlepšování techniky řízení projektů, nelze vynechat aktuální dění v oboru, a to především materiály uveřejněné na internetu dostupné on-line. Pro zadání mé diplomové práce jsem si zvolil téma Řízení projektů v národních korporacích, jelikoţ pracuji v jedné z největších národních společností v České republice zaměstnávající více neţ 30 tisíc pracujících a působící na národním poštovním trhu. Mé pracovní zařazení je v oddělení provozní akceptace systémů jako pracovník akceptace ITS (kontrola IT projektů předávaných SW aplikaci do provozu IT z hlediska HW, SW, licenční politiky, bezpečnosti aplikací a provozu datové sítě). Mojí vedlejší pracovní náplní je zátěţové testování softwarových aplikací ve společnosti zabývající nejen poštovním provozem a logistikou, ale také IT sluţbami (např. datové schránky, Czech Point atd.). Jsem účastníkem projektů ITS od počátku aţ po závěrečnou akceptaci do rutinního provozu. 7

9 Jako cíl své diplomové práce jsem si zvolil objasnění a porovnání teoretických principů metodik projektového řízení s vyuţitím software pro řízení lidí a projektu aplikované na reálném projektu, jelikoţ jsem nejen dohledovou součástí (akceptační řízení projektu), ale také aktivní osobou v oblasti zátěţového testování software se schvalovací pravomocí o nasazení systému do ostrého provozu ve společnosti. Úvodní teoretická část této diplomové práce je zaměřena na popis a charakteristiky pojmů projekt, řízení projektu a taktéţ popisu jednotlivých částí ţivotního cyklu projektu. Dále zde jsou charakterizovány metodiky pouţívané při projektovém řízení s popisem existujících softwarových aplikací určených pro správu a řízení projektů nejen z komerční sféry, ale také s licencí open source. Získané poznatky z teoretické části práce jsou uplatněny při práci na reálném IT projektu připravovaném na nasazení on-line do produkčního prostředí pro interní i externí zákazníky společnosti nejen v celé České republice. V závěru práce bych chtěl zhodnotit postup při řízení reálného IT projektu ve společnosti s celostátní působností a navrhnout kroky k zefektivnění procesu řízení obdobných IT projektů v podniku s upozorněním na nejčastější chyby provázející projekty. 8

10 1 Teorie řízení projektů v národních korporacích Teorie projektového řízení je velmi dobře objasněna v české odborné literatuře, která vychází z podkladů od zahraničních autorů. V následujících podkapitolách podrobně teoreticky charakterizuji průběh projektu, metody pouţité při řízení projektu a jeho zakončení. 1.1 Projekt Poloţme si otázku, co si fakticky představíme pod pojmem projekt? Tento velmi často pouţívaný výraz v podnikové sféře je sloţité jednoznačně definovat. Mnohé odborné knihy od odlišných autorů se snaţí jednoznačně definovat termín projekt jednou větou. Jednotná definice pojmu projekt neexistuje. Kaţdý autor si tento pojem vykládá podle svého, další odlišnosti vznikají překladem z cizojazyčné literatury. Pokusím se shrnout styčné body z prostudovaných definic do jednoho celku. Z mého pohledu nejlépe vyhovující definice slova projekt je od Vladimíra Němce 1. Projekt je cílevědomý návrh na uskutečnění určité inovace v daných termínech zahájení a ukončení. Z této definice vyplývá záměr, který má následující charakteristické znaky: sleduje konkrétní cíl, definuje strategii vedoucí k dosažení daného cíle, určuje nezbytně nutné zdroje a náklady včetně očekávaných přínosů z realizace záměru, vymezuje jeho začátek a konec. Definice podobné této jdou napříč odbornou literaturou zabývající se projektovým řízením. Velmi podobnou tezi, jen vysvětlenou jinými slovy, zastává například mezinárodní metodika PMBOK: 1 NĚMEC, Vladimír. Projektový management. 1. vyd. Praha: Grada, 2002, s. 12 9

11 Projekt je přechodné úsilí podnikané k vytvoření jedinečného výrobku nebo služby, obecně produktu. 2 Pod výrazem přechodný v této definici si můţeme představit, ţe projekt má začátek, ale také jasně definovaný konec. Slovo jedinečný znamená výrazně odlišný od jiných vytvářených produktů. Jednotícím prvkem při vysvětlování projektu napříč odbornou literaturou jsou ukazatele projektu, takzvaný Trojimperativ. Podle Fialy 3 jsou mezi třemi základními ukazateli projektu čas, náklady a kvalita. Kdeţto Svozilová 4 zmiňuje tři základny projektu čas, náklady a dostupnost zdrojů. Lze prohlásit, ţe mezi těmito třemi parametry existuje vzájemná spojitost. Pro úspěšné řízení projektu je proto zapotřebí si vţdy určit konkrétní časový plán, stanovit finanční stránku projektu a alokovat zdroje (interní - externí zdroje, apod.), jelikoţ všechny tři parametry se navzájem ovlivňují. Pokud by došlo například ke zvýšení investic do projektu, bylo by moţné zkrátit potřebný čas pro uskutečnění projektu s vyuţitím účinnějších zdrojů. V případě zkrácení investic do projektu by se projevil opačný účinek (prodlouţení doby projektu, menší zdroje). Proto je nutné dodrţovat námi nastavené hodnoty limity projektu a je zapotřebí soustředit se na všechny tři ukazatele současně. Časový plán Projekt Náklady Specifikace provedení Obrázek 1: Projektový trojúhelník - Trojimperativ (zdroj: Fiala 5 ) Specifikace provedení co má být vytvořeno a v jaké poţadované kvalitě. Časový plán stanovené termíny, kdy a co má být realizováno. 2 PROJECT MANAGEMENT INSTITUTE. A guide to the Project management Body of knowledge: PMBOK guide. 4 s. 3 FIALA, Petr. Řízení projektů. 1. vyd. Praha: Oeconomica, 2002, s SVOZILOVÁ, Alena. Projektový management. 1. vyd. Praha: Grada, 2006, s FIALA, Petr. Řízení projektů. 1. vyd. Praha: Oeconomica, 2002, s

12 Náklady potřebné pro realizaci činností v rámci projektu. Přesto projekt nelze prohlásit za úspěšný pouze na základě splnění těchto ukazatelů projektového trojúhelníku. Úspěšnost projektu je relativní věc, proto se pro vyhodnocení projektu pouţívají metriky, jejichţ hlavním přínosem je jednoznačnost, měřitelnost a srozumitelnost projektu. Jednoznačnost projektu formalizace struktury projektu, jako je např. název projektu, identifikační číslo projektu, popis cílů, kterých chceme dosáhnout, popis řešení, finanční pokrytí a výkonná sloţka atd. Měřitelnost projektu měření ukazatelů času, kvality a nákladů, jeţ jsou měřitelné, ale také ověřitelné. Srozumitelnost projektu konzistence a pochopitelnost popisu projektu nejen pro neodbornou část týmu projektu. 1.2 Řízení projektu Při řešení podnikových úkolů se vţdy dostaneme do situace, kdy se musíme rozhodnout, zda nám přidělený pracovní úkol, jenţ není rutinní a neodpovídá obvykle řešeným standardům, je projektem nebo ne. Pokud pracovní úkol nelze zvládnout standardně nastavenými podnikovými procesy, je nutné prohlásit úkol za projekt a určit projektového manaţera. Jelikoţ je projektové řízení velmi náročné a tudíţ finančně nákladné, mělo by být pouţito pro dosaţení strategických záměrů společnosti. Nasazení systému projektového řízení do firemního prostředí vyţaduje také splnění mnoha podmínek, mezi něţ patří metodiky a metodická podpora, odborná kvalifikace lidí účastnících se projektu, pouţité technické prostředky, motivační program a jiné. 11

13 V terminologii projektu a jeho řízení je nutné rozlišovat pojmy: projektové řízení a řízení projektu. Toto nejlépe popisuje Doleţal 6 v jeho podání termín projektové řízení vysvětluje obecné principy projektu, kdeţto řízení projektu určuje konkrétní metody a činnosti, jejichţ cílem je úspěšně realizovat daný projekt. Naše téma nejlépe vystihuje Rosenau 7 v jeho podání je řízení projektu jako pět různých manaţerských činností, které lze zjednodušeně popsat procesem sloţeným z pěti kroků: 1. Definování - definování projektových cílů. 2. Plánování - naplánování, jak vy a váš tým splníte podmínky Trojimperativ (cíl), tj. specifikace provedení, časový plán a finanční rozpočet (plán závisí na poměru lidských a materiálních zdrojů, které mají být použity). 3. Vedení - uplatnění manažerského stylu řízení lidských zdrojů, podřízených a jiných (včetně subdodavatelů), který je povede k tomu, že svou práci budou vykonávat efektivně a včas. 4. Sledování (monitorování) - kontrola stavu a postupu projektových prací, abyste včas zjistili odchylky od plánu a mohli jste rychle přistoupit k jejich korekci. (To často vede k úpravám plánu, které si mohou vynutit i změnu cíle [definice], a v důsledku toho i potřebu změny zdrojů.) 5. Ukončení - ověření, že hotový úkol odpovídá aktuální definici toho, co se mělo udělat, a uzavření všech nedokončených prací, např. dokumentace. Jedním z výsledků úspěšného završení projektu je získání zkušeností při řízení projektu. Tyto poznatky, vyzkoušené metodiky a reálné zkušenosti lze uplatnit při realizaci následujících projektů. Důsledkem této činnosti je budoucí úspora nejen peněţních prostředků, ale hlavně času stráveného na projektu. 6 DOLEŢAL, Jan, Pavel MÁCHAL a Branislav LACKO. Projektový management podle IPMA. 7 ROSENAU, Milton D. Řízení projektů. 3. vyd. Brno: Computer Press, s

14 1.3 Etapy projektu Etapy projektu, druhým způsobem v odborné literatuře nazývané ţivotní cyklus projektu, prochází různými fázemi. Kaţdý autor dělí fáze projektu podle svých zkušeností. Fiala 8 definuje členění projektu na čtyři základní nebo osm podrobných fází. Fialovo základní členění projektu na fáze: fáze koncepční, fáze plánu, fáze realizace, fáze předání. Koncepční fáze je nazývána týmovou analýzou problému, jejíţ podstatou je stanovení proveditelných řešení úkolu. V této fázi dochází k identifikaci potřeb projektu, stanovení strategie s konečným cílem za pomoci vhodných zdrojů s akceptovatelnou mírou rizika. Výsledkem týmové analýzy je vznik rozdílných variant, směřujících k zdárnému vyřešení projektu. Všechny varianty ohodnotíme a zvolíme nejoptimálnější variantu, která nás dovede k cíli. Dále Fiala provádí hodnocení a výběr projektu pomocí vícekriteriální analýzy, kdy jsou projekty hodnoceny podle: finančních ukazatelů, míry rizika, časových ukazatelů, nákladových ukazatelů, nároků na zdroje, ukazatelů kvality. Vyústěním koncepční fáze je vypracování studie proveditelnosti (Feasibility Study). K vypracování studie proveditelnosti je zapotřebí ustanovit projektového manaţera 8 FIALA, Petr. Řízení projektů. 1. vyd. Praha: Oeconomica, 2002, s

15 a specializovaný tým. Cílem týmu specialistů pracujících na studii proveditelnosti je nalézt vhodný způsob řešení projektového problému, aţ do fáze splnění námi stanoveného cíle projektu (úspěšné zakončení projektu ve stanovený čas s optimálními finančními náklady). Konkrétní výstup v závěru koncepční fáze ze studie Fiala 9 definuje tak, ţe studie proveditelnosti by měla být formulována s požadavky vymezenými a očekávanými výstupy: kdo je odpovědný, kdo bude zapojen, analyzovaný návrh, úroveň detailu, způsob a termíny hlášení zpráv, rozpočet. Plánovací fáze plynule navazuje na koncepční fázi, jejím hlavním cílem je vytvoření podrobného plánu projektu. Při této fázi je nutné provést dekompozici projektu na jednotlivé úseky s činnostmi - popsat vzájemné vazby mezi činnostmi, definovat poţadavky na zdroje a stanovit čas potřebný k realizaci projektu. Výstupem plánu projektu je načrtnutí rozpočtu s předpokládanými finančními toky, velmi důleţité je téţ stanovení rizikových faktorů, které nám mohou zabránit v uskutečnění projektu. Grafické znázornění plánu projektu provedeme pomocí Ganttova diagramu, eventuálně modelem síťového grafu. Pro prohloubení znalostí o projektu je nutné pouţít různé metody analýzy, mezi něţ patří analýza zdrojů (heuristické procedury), různé časové analýzy jako jsou (CPM, MPM) a také nákladové analýzy (CPM/COST). Uzavřením fáze plánování je výběr případných kandidátů na dodavatele a návrh struktury organizace projektu. Realizační fáze projektu je jiţ konkrétní práce na projektu spojená s vedením projektu a jeho následná kontrola, zda vše probíhá podle námi stanoveného projektového plánu. V případě, ţe řízení projektu neprobíhá dle námi nastavených parametrů, korigujeme neshody, ať jiţ jsou to odchylky časové (zdrţení v projektu), kvalitativní (špatně napsaný zdrojový kód) nebo finanční (nákladové). Pro kontrolu realizační fáze projektu se vyuţívá metoda výpočtu 9 FIALA, Petr. Řízení projektů. 1. vyd. Praha: Oeconomica, 2002, s

16 Úprava projektu vytvořené hodnoty (co bylo v rámci projektu skutečně vytvořeno v daném časovém úseku s danými náklady). Fáze předání projektu je poslední fází ţivotního cyklu projektu. Vyznačuje se akceptací projektu a předáním výsledného produktu vlastníkovi. V rámci této fáze dochází k ověřování a testování produktu a začlenění do rutinního provozu. Vlastním zakončením projektu je jeho zhodnocení ať jiţ finanční či časové a uschování znalostí zkušeností do znalostní databáze pro budoucí vyuţití na jiných projektech. Naopak jiní autoři odborné literatury přistupují k rozdělení fází projektu z jiného hlediska, jako například Němec 10 popisuje, že každá fáze má svůj začátek a konec. Řízení projektu se při přechodu z jedné fáze do druhé mění, ale od A do C je sjednocují cíle, kvalita, náklady a čas. Předinvestiční fáze Situace Kompozice Přijmout projekt Ne Konec Investiční fáze Dispozice Ano Realizace Fáze provozu a vyhodnocení Provoz projektu Závěrečná zpráva Analýza dat Obrázek 2: Fáze projektu podle Němce NĚMEC, Vladimír. Projektový management. 1. vyd. Praha: Grada, 2002, s NĚMEC, Vladimír. Projektový management. 1. vyd. Praha: Grada, 2002, s

17 Dále je dělí pouze na tři fáze: předinvestiční fáze, investiční fáze, fáze provozu a vyhodnocení. Předinvestiční fáze tvoří základní kámen celého projektu. Odpovědnost za tuto fázi přebírá top management společnosti (zadavatel), jehoţ náplní je naplánování strategie, která nás dovede do stanoveného cíle projektu úspěšného splnění všech poţadavků na projekt. V této fázi je nutno vytvořit základní projektový tým a ověřit proveditelnost všech následujících fází projektu. Investiční fáze je jednou z nejobsaţnějších a nejnákladnějších částí projektu, za tuto fázi zodpovídá jmenovaný manaţer projektu pod dozorem vrcholného managementu. Mezi hlavní části investiční fáze projektu Němec 12 zařazuje tyto kroky: personální zajištění projektu - jmenování členů projektového týmu, organizování projektového managementu - výběr z čistého, útvarového nebo maticového projektového managementu, proces plánování projektu - detailní plán projektu, časový plán projektu, plán rizik, projektová dokumentace - zpracování detailní projektové dokumentace, výběrové řízení, nákupy a financování projektu, realizace projektu - konkrétní provedení projektu, školení - proškolení pracovníků na nový produkt (projekt), zkušební provoz systému - testovací provoz pro odladění nedostatků, akceptace projektu akceptační řízení pro předání projektu do rutinního provozu, předání projektu (systému) k uţívání. 12 NĚMEC, Vladimír. Projektový management. 1. vyd. Praha: Grada, 2002, s

18 Ve fázi provozu a vyhodnocení je výsledný produkt projektového řízení předán do rutinního provozu a provedena analýza získaných dat pro budoucí vyuţití v jiných projektech. Fázi provozu a vyhodnocení lze podle Němce 13 shrnout do následujících bodů: ukončení projektu oficiální uzavření projektu, převedení do rutinního provozu běţný provoz systému, vyhodnocení projektu vyhodnocení průběhu projektu, vyhodnocení personálního obsazení a projektových týmů, závěrečná zpráva projektu, shromáţdění a analýza dat projektu, uloţení znalostí a dat do znalostní databáze. Rozdělení etap projektu na různé mnoţství, jak uvádějí různí autoři, je podle mého názoru účelové. Všichni autoři odborné literatury se snaţí přinést nějakou novou myšlenku do oboru projektového řízení na úkor srozumitelnosti. Asi nejlépe mně osobně vyhovuje dělení ţivotního cyklu projektu na tři etapy podle Vladimíra Němce. 1.4 Metody, analýzy a organizace používané při řízení projektu Tato kapitola nastiňuje existující analýzy, metody a způsoby organizace projektu, vyuţívané projektovým managementem pro smysluplné řízení projektů. Všechny analýzy a metody byly jiţ nesčetněkrát popsány v odborné literatuře, proto je zde uveden pouze jejich základní popis Strategické analýzy Strategické analýzy mají značnou váhu na tvorbu firemní strategie. Umoţňují podnikovému managementu analyzovat stávající situaci a korigovat budoucí kroky firmy k úspěchu. 13 NĚMEC, Vladimír. Projektový management. 1. vyd. Praha: Grada, 2002, s

19 Mezi hlavní strategické analýzy je moţné zahrnout tyto hlavní představitele. SWOT analýza Všeobecně známá analýza SWOT zjišťuje a identifikuje jak soudobé, tak eventuální schopnosti a omezení projektu. Principem je určit silné (Strengths) a slabé stránky (Weaknesses), příleţitosti (Opportunities) a hrozby (Threats) spojené s řešeným projektem. Poterova analýza Poterova analýza zahrnuje výzkum pěti oblastí konkurenčních sil, které ovlivní směrování strategii a chování společnosti. Mezi zkoumané oblasti zahrnuje: příchod potenciální konkurence, stávající konkurenci a soupeření s ní, kupní sílu potencionálních zákazníků, potencionální vliv dodavatelů, hrozbu substitučních výrobků. SLEPT/PEST analýza Analýza SLEPT je totoţná s analýzou PEST. Diferencí je pouze řazení s mnoţstvím vyuţitých faktorů. Pomocí této analýzy vyhodnocujeme eventuální dopady externích změn okolí na řízení projektu. Změny v oblastech působící na řízení projetu: sociální oblast, právní a legislativní oblast, ekonomické oblast, politické oblast, technické oblast. 18

20 1.4.2 Ganttův diagram Za jeden z nejvyuţívanějších nástrojů pro řízení projektů lze povaţovat Ganttův diagram. Grafická jednoduchost a přehlednost nám dokáţe zprostředkovat náhled na skutečnost projektu versus plánovaný postup prací. Grafické znázornění diagramu je provedeno ve dvou osách, v horizontální ose je zobrazen plánovaný čas a ve vertikální ose popis jednotlivých činností. Příklad Ganttova diagramu je uveden v příloze č Metoda síťového grafu Tato grafická metoda je zaloţena na znázornění matematického modelu projektu. Ukazuje posloupnost - cestu aktivit od počátečního aţ do závěrečného uzlu projektu. Pomocí této metody lze určit nejkratší (nejrychlejší) délku doby, za kterou zrealizujeme projekt. Takto stanovená cesta je takzvanou kritickou cestou Řízení rizik Znalostní databáze projektů Tato kvalitativní metoda pracuje na faktu znalostí a ponaučení ze zaevidovaných historických projektů, které jsou uloţeny ve znalostní databázi. Databáze obsahuje zkušenosti, znalosti a závěry z jiţ uzavřených projektů, můţe se také jednat o pozastavené nebo nedokončené projekty. Cílem je neopakovat historické chyby na nových projektech. Expertní hodnocení Taktéţ náleţí ke kvalitativním metodám, základem je hodnocení rizikových faktorů projektu na základě bodové stupnice. Vybraní specialisté hodnotí rizika projektu pomocí bodů a po sečtení všech bodů dojde k vyhodnocení účinku rizik na řízení projektu. 19

21 1.4.5 Další používané metody a analýzy na projektech Zde ve zkratce uvádím následující nejčastěji pouţívané metody v projektovém řízení. Metoda WBS (Work Breakdown Structure) je metodou plánování na rozklad produktů pro dosaţení cíle projektu. Metoda PERT (Program Evaluation and Review Technique) pracuje na principu zhodnocení činností a průběhu kritické cesty projektu. Matice zodpovědnosti základním principem matice je vymezení kompetencí a zodpovědnosti členů projektového týmu v rámci projektu Organizace projektové struktury Obvyklá organizační struktura společnosti ve většině případů neodpovídá potřebám námi realizovaného projektu. Proto je nutné uzpůsobit typ organizačního členění pro potřeby projektového řízení v závislosti na časovém omezení projektu, jeho velikosti a personální náročnosti na zdroje podniku. Z tohoto důvodu volíme konkrétní typ organizačního uspořádání projektové struktury. V odborné literatuře do V. Němce 14 jsou uvedeny tři základní typy organizace projektového managementu. Útvarový projektový management je pouţitelný zejména pro jednoduché projekty malého rozsahu. Osoby zúčastněné na projektu nadále setrvávají ve svém původním organizačním zařazení v liniové struktuře a podléhají svému původnímu vedení. Pouze v rámci projektu jsou řízeny projektovým manaţerem. Čistý projektový management je nasazován pro menší mnoţství dlouhodobých a rozsáhlých projektů, které jsou realizovány paralelně se stávající organizační strukturou. Nově vzniklá projektová struktura je výlučně vyhrazena pro řešený projekt. Zaměstnanci společnosti jsou převedeni ze stávajícího pracovního zařazení pod projektového manaţera řešícího konkrétní 14 NĚMEC, Vladimír. Projektový management. 1. vyd., 2002, s 72 20

22 projekt. Pokud je naplánován nový velmi rozsáhlý projekt, je moţné zaloţit novou nezávislou organizaci, která by řešila pouze tento projekt. Maticový projektový management je vyuţitelný při souběţné realizaci mnoha středně velkých projektů. Maticová projektová struktura je postavena na jiţ fungující liniové organizační struktuře a pouze se doplní o útvar projektového řízení. Při realizaci této struktury nedochází ke změně pracovního zařazení pracovníků, zaměstnanci nadále zůstávají podřízeni svému nadřízenému, ale také vedoucímu projektového týmu. Hlavní nevýhodou tohoto organizačního nastavení jsou rozpory v otázce pravomocí při řízení výkonných pracovníků. Mohu pouze konstatovat, ţe zajisté existuje mnoho dalších metod analýzy pouţívaných v projektovém řízení. Vţdy při vedení projektu je nutné, aby si projektový manaţer stanovil preference, vše co potřebuje o projektu vědět. Podle těchto předpokladů si vybere optimální postupy vyhovující danému projektu a nastaví organizační strukturu. 1.5 Ukončení projektu Závěrečná fáze projektu sestává z fyzického převedení funkčního pilotního provozu projektu do rutinního (operativního) provozu. Tímto krokem pro projektového manaţera práce na projektu ještě nekončí Je nutno provést oficiální úkon uzavření projektu formálně závěrečnou zprávou. Závěrečná zpráva je výsledný dokument zpracovaný projektovým manaţerem z podkladů získaných v průběhu trvání projektu. Obsahuje vyhodnocení průběhu projektu z hlediska financí, časové náročnosti, vyhodnocení personálního obsazení a projektových týmů. Na konci tohoto dokumentu je prohlášení o ukončení projektu s konstatováním, ţe jiţ nebudou poţadovány ţádné finanční prostředky po uzavření projektu (pokud není součástí projektu jiné ustanovení). Závěrečným krokem při ukončení projektu je shromáţdění a analýza dat získaných v průběhu projektu. Zpracovaná a formalizovaná data je nutno uloţit do znalostní databáze pro budoucí vyuţití v následujících projektech. 21

23 Zhodnocení a úspěšnost projektu je moţno interpretovat shodou zainteresovaných stran projektu na splnění všech jeho zadaných podmínek. Podle Doleţala 15 lze projekt povaţovat za úspěšný, pokud: je projekt funkční, jsou splněny požadavky zákazníka, jsou uspokojena očekávání všech zainteresovaných stran, je výstupní produkt projektu na trhu včas, je výstupní produkt v plánované jakosti a ceně, je dosahována předpokládaná návratnost vložených prostředků, je vliv na životní prostředí a okolí obecně v normě. Pro úspěšnost projektu jsou významné i tzv. měkké faktory: vyřešení konfliktů s okolím, kvalifikační připravenost obsluhy, motivace projektového týmu apod. Shrnutí kapitoly 1 V kapitole 1 jsem se snaţil představit teorii vedení projektů s postoji různých autorů. Podle mého názoru z odborné literatury vyplývá, ţe kaţdý autor má trochu odlišný náhled na problematiku projektového řízení. Jedním ze styčných bodů odborných svazků jsou metody, analýzy a organizační struktury pouţívané pří řízení projektů. 15 DOLEŢAL, Jan, Pavel MÁCHAL a Branislav LACKO. Projektový management podle IPMA. 1. vyd. Praha: Grada, 2009, s

24 2 Metodiky projektového řízení Metodické řízení projektu je jedním ze základních kamenů pro úspěšné dokončení projektu v termínu s vyuţitím plánovaných zdrojů projektu, a to nejen finančních. Následující popis základních metodik projektového řízení shrnuje všeobecně známé informace z odborné literatury. 2.1 PRINCE2 Metodika PRINCE2 (Projects in Controlled Eviroment) pojednává o efektivnosti řízení projektů na základě strukturovaného pracovního postupu. Vznik metodiky je datován do roku 1989 ve Velké Británii. Hlavní podstatou metodiky je vedení projektu na principu znalostí a zkušeností kladných či záporných získaných z mnoha jiţ dokončených projektů. Univerzálnost této metodiky je moţné prokázat tím, ţe ji lze aplikovat do řízení jakéhokoliv projektu bez ohledu na rozsah a typ organizace. PRINCE2 definuje sedm základních principů jak postupovat v řízení projektu, které lze shrnout do následujících bodů: 16 odůvodnění pokračování podnikání, poučit se ze zkušeností předcházejících projektů, definované role a odpovědnosti v projektu, správa projektu po etapách, řízení projektu podle výjimek, zaměření se na produkty, přizpůsobit se prostředí projektu. Všechny tyto zásady napomáhají dobrému vyuţití metodiky PRINCE2 v praxi. Je ale nutné podotknout, ţe by metodika neměla být uplatňována přílišným normativním způsobem, ale pouţita tak, aby dostatečně přispěla k úspěchu projektu. 16 PRINCE2, Best Management Practice. Managing successful projects with PRINCE2. s

25 2.2 PMBOK Metodika PMBOK (v současnosti je nazývána A Guide to the Project Management Body Of Knowledge) vznikla v Project Management Institute (PMI) roku Jedná se o jednu z nejstarších metodik projektového řízení na světě. Poslední verze metodiky pochází z roku 2013, byla vydána v 5. edici a rozdělena do následujících částí: Purpose of the PMBOK Guide. 1.2 What is a Project? 1.3 What is Project Management? 1.4 Relationships Among Portfolio Management, Program Management, Project Management,and Organizational Project Management. 1.5 Relationship Between Project Management, Operations Management, and Organizational Strategy. 1.6 Business Value. 1.7 Role of the Project Manager. 1.8 Project Management Body of Knowledge. Podstatou metodiky PMBOK jsou identifikované znalostní oblasti projektového řízení s řídícími procesy. Tato metodika je tvořena komplexním souhrnem poznatků, technik a taktéţ souvisejících procesů rozdělených do 5 skupin procesů s 10 znalostními oblastmi pro řízení projektů. 2.3 Ostatní metodiky a normy Řízení projektů celosvětově zaţívá boom z důvodů úspory času a peněz, celkově lze říci všech zdrojů projektu. Proto je snaha o co nejekonomičtější vedení projektů převáděna do 17 PROJECT MANAGEMENT INSTITUTE. A guide to the project management body of knowledge (PMBOK guide). 5th ed. 1 s. 24

26 vzniku a pouţívání standardizovaných metodik nebo norem. Následující uváděné metodiky doplňují portfolio světově pouţívaných standardů. IPMA (International Project Management Association) mezinárodní sdruţení projektových manaţerů zabývajících se standardizací projektového řízení. ITIL (Information Technology Infrastructure Library) mezinárodně uznávaná metodika vyuţívající princip procesního řízení organizace. COBIT (Control Objectives for Information and Related Technology) - sbírka praktik, jejichţ pomocí lze dosáhnout vytyčených strategických cílů organizace s pouţitím dostupných zdrojů a minimalizací ITC rizika. ČSN/ISO (Guidelines to Quality in Project Management) mezinárodní směrnice managementu kvality a řízení jakosti pro společnosti orientované na procesy projektového managementu. Shrnutí kapitoly 2 Řízení rozsáhlého projektu bez metodické podpory je v současnosti téměř nemyslitelné. Přesto podle mého názoru většina pracovníků v IT má v současnosti k dispozici řádu metodik a postupů, mnozí se pyšní různými certifikáty, např. certifikací ITIL. Přesto se velmi málo projektových manaţerů těmito postupy a metodikami řídí. 25

27 3 Software pro řízení projektů Základem úspěšného řízení jakéhokoliv projektu je organizace a optimalizace kroků prováděných projektovým manaţerem s vyuţitím výpočetní techniky se specializovaným softwarem. Výběr software pro řízení projektů je velmi specifický. Neexistuje universální systém, který by splnil očekávání projektového manaţera, pouze některé systémy se těmto poţadavkům blíţí. Projektové nástroje je moţné obecně rozdělit na dvě kategorie open source software versus komerční software. Pro open source software platí, ţe není závislý na konkrétním dodavateli, podpora je řešena komunitou okolo programu, je k dispozici otevřený kód a největší výhodou je nulová cena. Kdeţto komerční software je za úplatu, má uzavřený kód, ale za výhodu lze povaţovat nasazení a podporu od dodavatele s komplexnějšími funkčnostmi plus různé moduly pro podnikové systémy. V následujících podkapitolách představím nejpouţívanější projektové nástroje v ČR z obou kategorií software. 3.1 Microsoft Project Jedním z nejznámějších komerčních softwarů pro projektové řízení je Microsoft Project Standard nebo Professional od světoznámé americké společnosti Microsoft. Tento nástroj nabízí komplexní podporu řízení projektů s moţnostmi plánování, správy projektů a úkolů, eviduje stav zdrojů vyuţitých pro řízení práce projektového manaţera. Mezi největší výhody tohoto software patří podpora různorodých analýz a metod např. CPM, PERT, Ganttův diagram. Dále nabízí přehled peněţních toků, sledování termínů projektu. Jeho hlavní výhodou je týmové sdílení informací mezi lidmi zainteresovanými na projektu. Tento produkt je určen především pro specializované firmy zabývající se profesionálním řízením nebo vedením projektových týmů. 26

28 3.2 JIRA Dalším v řadě softwarů pro projektové řízení je nástroj JIRA od společnosti Atlassian. Tento software je specifický snadnou tvorbou analýz, workflow managementem a funkcí týmového plánování. Popis funkcí nástroje JIRA 18 : softwarová podpora projektového řízení, organizace a sledování workflow, service Level Management (SLA), tvorba a přiřazení úkolů jednotlivým pracovníkům, zadávání požadavků a jejich prioritizace, organizace řešení, sledování aktivity týmu, stav plnění úkolů, sdílení informací, dokumentů, obrázků, tabulek a grafů, tvorba přehledných reportů, analýz a grafů, přiřazení přístupů a práv jednotlivým týmům nebo jednotlivcům, vnitropodniková komunikace. 3.3 Oracle Primavera P6 Enterprise PPM Oracle Primavera Enterprise PPM (Project Portfolio Management) 19 je softwarový nástroj zaměřený na řízení a správu projektů. Primavera je počítačový systém s komplexním řešením náročného projektu. V tomto programu jsou propojeny úkoly s konkrétními rolemi členů projektového týmu. Součástí systému je také nástroj aplikovatelný na určitého člena týmu, zajištující vyhodnocení se statistikou na daného pracovníka. 18 JIRA plánování práce a řízení projektů. [online] Oracle. Primavera Enterprise Project Portfolio Management [online]

29 3.4 Clarity PPM Nástroj Clarity PPM (Project Portfolio Management) je zaměřen na změnu procesů a projektové řízení. Je velmi dobře vyuţitelný při vzniku nového produktu s podporou automatizace všech procesů souvisejících s projektem. Pomocí nástroje Clarity PPM 20 je moţné řešit následující úlohy: podporu procesu vývoje nových produktů a řízení jejich životního cyklu, automatizaci řízení vzniku nových produktů, podporu organizačních činností v rámci procesu vývoje nových produktů, automatizaci a podpora řídící dokumentace, řízení IT aktivit organizace s vazbou na návrh nových produktů, automatizaci poskytování odborných služeb. Následující soupis příkladů, jeţ je moţné zpracovat pomocí nástroje Clarity PPM, dokládá všeobecnou pouţitelnost software nejen při řízení projektu: vývoj nových produktů (New Product Development), řízení poptávky (Demand Management) řízení životního cyklu, řízení projektů (Project Management), řízení lidských kapacit (Resource Management), finanční řízení projektů (Financial Management), řízení projektových portfolií (Portfolio Management). 3.5 ProjectLibre Zástupce open source software ProjectLibre vznikl z nástroje OpenProject v roce Tento nástroj je moţné aplikovat jako náhradu za drahé komerční programy. Vyuţití tohoto nástroje je zcela zdarma pro jakékoliv řízení projektů, plánování zdrojů a kapacit atd. ProjectLibre 20 CA Technologies. CA Clarity PPM [online]

30 pracuje na základě standardních projektových metod. V následujících řádcích uvádím výstupy pouţitelné pro řídící pracovníky: Ganttův diagram, Network diagram (síťový diagram), PERT diagramy, WBS (Work Breakdown Structure). 21 Shrnutí kapitoly 3 Existuje velmi mnoho dalších specializovaných nástrojů pro aplikaci v projektovém řízení, které lze v praxi vyuţít. Je pouze na zváţení uţivatele, který nástroj by mu nejlépe vyhovoval funkčností a cenovou politikou (je nutné počítat nejen s náklady na pořízení, ale také na implementaci nástroje). Já osobně dávám přednost svobodnému software (ProjectLibre). Tento nástroj je velice jednoduchý a přehledný, jeho nezanedbatelnou výhodou je kompatibilita s Microsoft Project. 21 ProjectLibre [online]

31 4 Řízení projektu v národní korporaci Národní korporaci lze charakterizovat jako národní společnost, jejíţ pobočky jsou lokalizovány pouze v zemi původu. Tato společnost provozuje své ekonomické aktivity na jednom národním trhu, s moţností zprostředkování sluţeb ostatních zahraničních partnerů. Národní korporace se řídí zákony země, v níţ vykonává svoji činnost, popřípadě zákony společenství Evropské unie. V následující kapitole představím principy a metody vyuţívané při projektovém řízení ve státním podniku, v němţ jsem zaměstnán. Dále budu pokračovat výčtem nejčastějších chyb, se kterými jsem se setkal na různých projektech. 4.1 Metody a technika používané při projektovém řízení v národní společnosti Společnost působící na celorepublikovém trhu poštovních sluţeb musí nutně vyuţívat metody a techniky týmové spolupráce při řízení projektů. Bez efektivní spolupráce pracovníků napříč republikou nelze kvalitně vyvinout a předat IT projekt do rutinního provozu. Hlavním nástrojem projektového manaţera při řízení projektu je firemní projektová metodika. Bohuţel tato metodika není do současné chvíle ve firmě zpracována do pouţitelného stavu, tudíţ nelze podle ní postupovat. Proto je řízení projektů občas chaotické a závislé na znalostech projektového manaţera. Všechny projekty probíhající ve firmě jsou řízeny centrálně z Prahy. Proto je nutné vyuţít techniku zprostředkující komunikaci mezi projektovými týmy z celé republiky, a to za pomoci video konferencí. Hlavní devizou vzdálené komunikace je úspora času a nákladů, a to nejen na cestování. Technické zařízení se softwarem pouţívané pro video komunikaci je od společnosti Microsoft Product Live Meeting Hardwarové zařízení integrující v sobě prostorové kamery se směrovými mikrofony je Microsoft RoundTable. Tímto zařízením jsou vybaveny specializované zasedací místnosti určené pro videokonference. 30

32 Dalším pomocníkem projektového manaţera je softwarový nástroj pro řízení projektů, naše společnost nasadila a vyuţívá software Clarity PPM (detailní popis v kapitole 3.4). V tomto nástroji jsou integrovány moduly pro komplexní řízení a správu procesů projektu. Bohuţel tento nástroj je jen částečně naimplementován a vyuţívá ho pouze malá část projektových manaţerů. 4.2 Nejčastěji se opakující chyby při řízení projektu v národní společnosti Na základě mých praktických zkušeností z projektového řízení představím chyby, které lze shrnout do následujícího přehledu. Zde uvádím nejčastěji se opakující pochybení, která se vyskytují v našich firemních projektech. Velká část projektů se dostane do potíţí nebo naprosto ztroskotá z důvodu podcenění zásadních oblastí, které od projektu očekáváme. Nejpřehlednější souhrn chyb vznikajících při projektovém řízení zpracovala společnost PricewaterhouseCoopers 22 do následujícího seznamu, proto ho zde uvádím: nejasné cíle, nedostatečné plánování, nejasné vymezení rolí a odpovědností, chybně stanovený rozpočet projektu, nesprávně stanovený časový harmonogram, podcenění komunikace a jednání se zainteresovanými stranami, nedostatečné nebo neefektivní řízení změn, nedostatečné či nevhodně vybrané lidské zdroje, nedostatečné řízení rizik, nedostatečný zájem klíčových zainteresovaných stran. Z vlastní zkušenosti mohu říci, ţe jsem se v naší firmě setkal se všemi těmito chybami, proto je zde podrobněji analyzuji. 22 PwC. Poradenské služby: 10 nejčastějších chyb při řízení projektu. 31

33 Nejasné cíle vznikají tím, ţe není přesně definován cíl nebo cíle projektu. Pokud nemáme jasné očekávání od cíle projektu, pravděpodobně nebudeme schopni své úmysly objasnit všem zúčastněným stranám na projektu a dopracovat se do úspěšného konce. Jak se vyhnout chybě při plánování projektu přesně definovat cíle, sjednotit poţadavky a očekávání od všech členů projektu. K jednotlivým cílům projektu přiřadit metriky a měřit jejich hodnoty. Nedostatečné plánování pokud nevytvoříme detailní plán projektu s podrobným popisem, můţe dojít k ohroţení celého projektu. Jak se vyhnout chybě zajistit detailní popis projektového plánu a stanovit milníky projektu. Dále je nutné nechat si schválit projektový plán všemi důleţitými členy projektu a provádět kontrolu plánu se skutečností. V případě nesrovnalosti v plnění plánu je potřeba ihned plán aktualizovat. Nejasné vymezení rolí a odpovědností pokud nejsou jednoznačně vymezené role a odpovědnosti členů projektového týmu, coţ můţe vést k rozporům a můţe vyústit v ohroţení cíle projektu. Jak se vyhnout chybě v předprojektové fázi jasně definovat role s odpovědností všech členů projektového týmu. Určit jednoznačný způsob komunikace pracovníků a zavést reporting pro kontrolu postupu práce na projektu. Chybně stanovený rozpočet projektu při nesprávně zpracovaném rozpočtu projektu je moţné předpokládat váţné komplikace s vyústěním v neakceptovatelný výsledek projektu. Jak se vyhnout chybě provést analýzu projektového plánu a stanovit reálné finanční výdaje pro všechny plánované projektové fáze. Je také dobré konzultovat finanční rozpočet se sponzorem projektu. Nesprávně stanovený časový harmonogram - nereálně stanovené termíny úkolů nebo jejich časový rozsah vede k ohroţení plánovaného harmonogramu projektu. Jak se vyhnout chybě odhadnout potřebný čas na projekt a určit kritickou cestu k cíli projektu. Pravidelně si upřesňovat harmonogram s členy projektového týmu a průběţně 32

34 kontrolovat plnění časového plánu. Pokud plán projektu neodpovídá skutečnosti, je nutné plán upravit podle reality. Podcenění komunikace a jednání se zainteresovanými stranami při nedostatečné nebo vyloţeně špatné komunikaci členů projektového týmu můţe dojít aţ ke krachu projektu. Jak se vyhnout chybě stanovit pevnou organizační strukturu projektu s nastavenými procesy komunikace, coţ znamená předávat projektové informace kolegům alokovaným na projektu a totéţ poţadovat po spolupracovnících. Nedostatečné nebo neefektivní řízení změn - při řízení projektu dochází k různým změnám, to vše je způsobeno vnitřními nebo vnějšími vlivy působícími na projekt. Jak se vyhnout chybě tento problém lze řešit efektivním procesem řízení změn a tak splnit poţadavky projektu. Proto doporučuji zmodifikovat plán projektu podle změnového poţadavku a minimalizovat počet pracovníků zabývajících se touto změnou (z důvodu přehlednosti procesu). Nedostatečné či nevhodně vybrané lidské zdroje - výběrem kvalitních pracovníků vhodných pro konkrétní projekt můţeme předejít problémům v průběhu projektu a dosáhnout cíle. Jak se vyhnout chybě provádět průběţnou kontrolu personálních zdrojů projektu z hlediska vědomostí a kapacit. Pokusit se vcítit do chování členů projektového týmu a tím předcházet problémům na projektu. Především snaţit se vhodně motivovat členy projektového týmu, aby bylo dosaţeno konkrétního cíle. Nedostatečné řízení rizik - pokud neprovedeme včasné odhalení rizika na projektu, dojde k váţným problémům při řízení projektu, které se projeví ohroţením plánu projektu nebo rozpočtu. Jak se vyhnout chybě nejvhodnější je zřídit roli risk manaţera a opakovaně si ověřovat rozpoznaná projektová rizika. Nedostatečný zájem klíčových zainteresovaných stran - pokud členové projektového týmu nejsou schopni přijmout cíl projektu, můţe tento problém vést k nezdaru celého projektu. 33

35 Jak se vyhnout chybě dostatečně zainteresovat všechny osoby spolupracující na projektu. Všem členům týmu podrobně vysvětlit, čeho chceme dosáhnout prostřednictvím tohoto projektu. Shrnutí kapitoly 4 Jak jsem jiţ naznačil, řízení projektu v národní společnosti zabývající se poštovním provozem a logistikou má svá specifika. Přestoţe se jedná o největší stání firmu u nás, která se musí řídit předpisy a zákony platnými pro státní podniky, zejména co se týká výběrových řízení a zadávání zakázek, tak se ani této společnosti nevyhnou zdokumentované problémy týkající se projektového řízení. 34

36 5 Praktická část V praktické části diplomové práce řeším IT projekt zabývající se řízením přístupu k firemním sluţbám a aplikacím z jednoho místa ve společnosti Česká pošta, s.p. Tento projekt se nazývá Nasazení systému OpenSSO Enterprise. Projekt přímo navazuje na další souběţně probíhající projekty (Upgrade AIM LDAP CA, Upgrade AIM LDAP CAS) se souhrnným názvem Konsolidace IdM a AIM. Na všech uvedených projektech také spolupracuji, ale nejsou předmětem řešení v této diplomové práci. OpenSSO je open source software pro centrální řízení přístupu ke sluţbám a aplikacím různých serverových platforem (SSO je zkratka pro sluţbu Single Sign-On) a je firmám poskytován s komerční podporou. Program je zaloţen na produktu Sun Java System Access Manageru, jehoţ systémové jádro je totoţné s řešenou aplikací OpenSSO Enterprise. Tato aplikace byla původně vyvinuta společností SUN Microsystém, která byla v roce 2009 odkoupena společností Oracle. V následujících kapitolách se soustředím zejména na technickou stránku projektu. Detailně popíši zátěţové a funkční testování, proces provozní akceptace s převzetím systému do rutinního provozu ICT, jelikoţ všechny zmíněné oblasti jsem osobně zpracoval a korespondují s mým pracovním zaměřením ve státním podniku. Veškerá přiloţená schémata objasňující technickou stránku projektu jsem vytvořil v programu Microsoft Visio Data a charakteristiky popisovaného systému jsem upravil a anonymizoval vzhledem k ochraně citlivých údajů ve firmě. 5.1 Představení národní společnosti zaměřené na poštovní provoz a logistiku Základem této diplomové práci je zpracování reálného projektu ve společnosti Česká pošta, s.p. V této firmě jsem zaměstnán v oddělení provozní akceptace ITS, jako specializovaný pracovník akceptačního provozního se zaměřením na předání nového systému IT systému do rutinního provozu. 35

37 Společnost Česká pošta, s.p. je právnickou osobou, jejímţ sto procentním vlastníkem je stát. Zakladatelem je Ministerstvo vnitra České republiky. Obrázek 3: Logo společnosti (zdroj: Česká pošta, s.p.) Společnost Česká pošta, s.p., je největší zaměstnavatel v České republice (v roce zaměstnanců, z toho 71% ženských zaměstnanců) 23. V současné době obstarává cca 3403 poboček včetně výdejních a partnerských míst. Hlavní činností pošty garantovanou ze zákona je poskytování univerzálních poštovních sluţeb v rámci celé České republiky, coţ podle výkladu Českého telekomunikačního úřadu znamená, ţe univerzální služba je minimální soubor služeb, který je přístupný za stejných podmínek všem koncovým uživatelům, za dostupnou cenu a ve stanovené kvalitě. 24 Pod pojmem univerzální sluţba je zahrnuta základní korespondence obyvatel s veřejnou správou a státními úřady. Jedná se o obyčejné a doporučené zásilky, obyčejné a doporučené slepecké zásilky, balíky, cenná psaní a poštovní poukázky. Jiţ před ukončením monopolu České pošty na doručování zásilek do 50 g se rozšířilo podnikatelské zaměření na poskytování elektronických sluţeb pro zákazníky, jako například sluţba Czech POINT, bankovní sluţby Poštovní spořitelny, DINO - dluhové inkaso obyvatelstva. V současnosti se tento státní podnik připravuje na poskytování servisu IT sluţeb pro veřejnou správu (státní úřady a ministerstva). Z toho důvodu byl usnesením vlády z dubna 2012 zřízen odštěpný závod České pošty pro poskytování IT sluţeb. Tímţ se de facto Česká pošta stala jedním z největších komplexních poskytovatelů IT sluţeb v České republice. 23 Česká pošta, s.p. [online]. 24 Český telekomunikační úřad [online]. 36

38 5.2 Požadavky a cíle projektu Hlavní podstatou mnou řešeného projektu OpenSSO je zajištění centrální autentizace a autorizace uţivatele do klíčových aplikací společnosti. V technickém detailu se jedná o jednotnou vrstvu, která má za cíl povolit přístup uţivatele k vnitropodnikovým systémům. Další vlastností je poskytovat informace o identitě uţivatele s definicí politik pro chráněný přístup k navazujícím aplikacím. Přestoţe samotný produkt poskytuje moţnosti správy identity uţivatele, tato funkce není v tomto nasazení vyuţita Cíl projektu OpenSSO Cíl projektu OpenSSO Enterprise v prostředí státního podniku jsem rozčlenil na několik oblastí, kdy kaţdá část sleduje své vlastní záměry. Jedná se o následující cíle: řízení oprávnění přístupu uţivatele z jednoho místa, zajištění bezpečnosti firemních dat nasazením silné centrální politiky hesel, napojení klíčových komponent OpenSSO na bezpečnostní systém envision, komplexní optimalizace přístupů a identit uţivatelů firemních systémů. Nejdůleţitější funkcí aplikace OpenSSO je poskytování zabezpečeného přístupu z internetu k aplikacím vyuţívaných ve společnosti Požadavky na projekt systému OpenSSO Aplikace OpenSSO je navrţena a zkonfigurována tak, aby splňovala kvalitativní předpoklady poţadované hlavním IT architektem společnosti. Mezi hlavní technické poţadavky aplikace OpenSSO patří následující parametry: 1. Způsobilost aplikace obslouţit 200 paralelních poţadavků za sekundu při souběţném provozu dvou produkčních aplikačních serverů OpenSSO. 2. Doba odezvy přihlašovací obrazovky za méně neţ 15 sekund. 37

39 3. Odbavení poţadavku na přihlášení (odeslání přihlašovacího formuláře) za méně neţ 25 sekund. 4. Odhlášení uţivatele z SSO systému za méně neţ 15 sekund. 5. Nalézt mezní počet poţadavků za sekundu a určit počet virtuálních uţivatelů, při kterém dojde k zahlcení, případně k pádu systému OpenSSO. Jednou z mých hlavních náplní této praktické části diplomové práce je ověření konfigurace systému, zda splňuje technické parametry, a to provedením zátěţového testu s vyhodnocením. Do základních poţadavků na systému také zahrnuji nepřetrţitou dostupnost systému OpenSSO, coţ pro takto kritický systém znamená dostupnost 24/7 a 365 dní v roce. Nelze také opomenout poţadavky na bezpečnost implementovaného systému. Jelikoţ se jedná o bezpečnostní systém hlídající přístup k firemním datům, musím definovat informace, které poţaduji pro úspěšné provedení provozní akceptace systému. Všechny následující informace vyplní dodavatel do dokumentu skutečného provedení aplikace a předá je k akceptačnímu řízení. V dokumentu skutečného provedení poţaduji následující informace: metodiku přidělování oprávnění pro administrátorské účty v OpenSSO, architekturu autentizace do OpenSSO a metodiku pro integraci aplikací do OpenSSO, seznam klíčových binárních a konfiguračních souborů, autorizační schéma do administrace OpenSSO, seznam běţících sluţeb OpenSSO, postup provádění aktualizací aplikace, metodiku vytváření aplikačních účtů a rolí pro aplikace integrované do OpenSSO. 5.3 Příprava projektu Příprava projektu nasazení sluţby OpenSSO se skládá z analýzy moţných rizik hrozících při implementaci aplikace a návrhu architektury řešení projektu. 38

40 5.3.1 Analýza rizik Rizika jsem stanovil na základě neformálního přístupu a zkušeností s podobnými projekty ve společnosti. Výstupem z nalezených rizik jsou opatření, která je nutno provést na úrovni logické, fyzické nebo administrativní bezpečnosti, abych sníţil zranitelnost systému. Zabezpečení přístupu k službám a aplikacím - při nenasazení systému nebude moţné řídit oprávnění k přístupu z jednoho místa. Nebude moţné zvýšit zabezpečení firemní sítě centrální politikou silných hesel. Výpadek služby OpenSSO v případě technické poruchy (např. nedostupnosti) systému OpenSSO je nemoţné, aby klient (interní eventuálně externí) přistupoval k firemním aplikacím nebo sluţbám. Hrozí riziko ztráty klientů. Klient by vyuţil konkurenční společnost, výpadek systému by se promítl do ekonomického výsledku organizace. Migrace aplikací do nového systému - v současné chvíli aplikace ve firmě včetně klientské zóny vyuţívají systém Access Manager pro zajištění autentizace. Přechod ze systému Access Manager na OpenSSO vyţaduje úpravy na straně aplikací. Hrozí organizační riziko na straně společnosti při koordinaci jednotlivých projektů migrace přesměrovávaných aplikací. Paralelní provoz Access Manageru a OpenSSO - pro zabezpečení průběhu migrace všech aplikací z Access Manager na OpenSSO je nutné udrţovat v běhu dvě centrální autentizační sluţby. Pokud jsou uţivatelům přístupné obě aplikace napojené jak na staré, tak i na nové řešení, dojde k dezorientaci uţivatele. Jelikoţ jeden systém přihlášení není kompatibilní s druhým, bude poţadováno opakované přihlášení Zajištění zdrojů projektu Mezi hlavní a nejsloţitější úkoly na projektu je zajištění zdrojů, a to jak interních tak externích. Tento projekt je specifický rozsahem záběru a dopadem na veškeré firemní suţby. Proto top management rozhodl o vyuţití poradenských sluţeb externí společnosti. Finanční zdroje byly alokovány z rozhodnutí výkonného managementu v řádech milionů. 39

41 Na základě řádného výběrového řízení byla vybrána společnost AMI Praha a.s. Tato společnost poskytne své znalosti se zkušenostmi a provede implementaci systému Acces Manageru OpenSSO v prostředí velké národní společnosti. Na základě spolupráce s externí firmou byl vybudován společný projektový tým na bázi útvarového projektového managementu. Personální obsazení na projektu je stanoveno na základě firemních předpisů týkajících se projektového řízení ICT. Testování software s akceptačním provozním řízením a předáním dokončené aplikace do produkčního provozu provádím já z titulu mé firemní funkce. Top management ustanovil projektovou radu a projektového manaţera, konkrétně byly do procesu zahrnuty tyto funkce a podnikové útvary: odbor řízení projektů a změn projektový manaţer, tým specialistů poradenské společnosti zahrnující koordinátora projektu, IT specialisty na identity management, útvar architektury informačních a komunikačních technologií (AICT), útvar bezpečnosti informačních a komunikačních technologií (BICT), oddělení licenčních politik, útvary provozu centrálních systémů(pcs), oddělení hardware a operačních systémů, oddělení softwarových aplikací, oddělení dohledu IT systémů, oddělení databází, odbor provozu datové sítě, akceptace informačních technologií a systémů (AITS) zastoupená autorem diplomové práce. Všechny tyto útvary provedly jmenování zástupce do projektového týmu. Jmenovaní zaměstnanci předávají pracovní úkoly do svých technických oddělení a kontrolují jejich plnění, které předkládají v rámci projektu. Personální zajištění projektu zahrnuje nasazení velkého počtu pracovníků (interních i externích), coţ má dopad na náročnost organizace projektu a sladění všech navazujících kroků pro úspěšnou realizaci a nasazení OpenSSO do produkčního prostředí. 40

42 5.3.3 Technicko-technologický návrh OpenSSO V této kapitole jsem zpracoval technický a technologický popis s návrhem implementace OpenSSO v interakci na navazující systémy, čímţ je míněn popis fungování systému s detailní charakteristikou komponent a prostředí. Z důvodů přehlednosti a jednoznačnosti jsem vytvořil následující schémata popisující zapojení OpenSSO s návaznými systémy. OpenSSO je povaţován za jeden z nejkritičtějších firemních systémů, proto je nutné vytvořit vývojové a testovací prostředí pro optimální odladění aplikace. Samozřejmostí u takto kritického systému je vytvoření záloţního systému pro případ výpadku produkčního prostředí (primární záloţní prostředí je 1:1). Produkční prostředí je provozováno v primárním serverovém centru a záloţní systém je provozován v odděleném záloţním datovém centru. Z důvodů bezpečnosti provozu se lokality primárního a záloţního centra zeměpisně liší, mají oddělené síťové datové připojení, elektrické zdroje (jiné okruhy vysokého napětí) a další zabezpečení Technologický popis systému Systém OpenSSO umoţňuje koncovému uţivateli (internímu nebo externímu) přistupovat ke sluţbám aplikacím uvnitř datové sítě společnosti po provedení následujících úkonů. V okamţiku zaslání HTTP poţadavku koncového uţivatele na zabezpečený systém je tento poţadavek zachycen policy agentem. Policy agent je bezpečnostní sluţba pro validaci příchozího poţadavku k ověření doby platnosti session tokenu předaného pomocí cookies. Pokud není tento token platný, policy agent zahájí proceduru autentizace uţivatele pomocí směrování na OpenSSO přihlašovací rozhraní. Prostřednictvím tohoto rozhraní je uskutečněno ověření identity uţivatele za podpory určeného autentizačního způsobu. Po provedení úspěšné autentizace je uţivateli generován nový SSO token, jehoţ prostřednictvím je směrován zpět na policy agentem zabezpečený systém. V tento okamţik se policy agent opětovně pokusí o validaci SSO tokenu a zahájí proceduru autorizace poţadavku pro přístup 41

43 k zabezpečenému systému. Na základě vyhodnocení výsledku agenta je uţivatel autorizován nebo odmítnut. Kompletní proces přihlášení koncového uţivatele pomocí OpenSSO jsem popsal v následujícím diagramu. OpenSSO Prohlížeč Policy agent Aplikace GET/app Přesměrování OpenSSO GET/login goto=/app Autentizace SSO cookie GET/app vložené SSO Je uživatel autorizován k přistupu /app? Vyhodnocení ANO Bezpečnostní procedura Povolení přístupu /app Odpověď od /app Obrázek 4: Diagram procesu přihlášení OpenSSO (zdroj: Oracle upraveno autorem) Charakteristika modulů služeb systému OpenSSO V následující části stručně charakterizuji hlavní funkční moduly pro uţivatele systému OpenSSO. 25 Pro přehlednost jsem připojil schéma na obrázku č. 5. Autentizační služba (Authentication Service) tato sluţba ověřuje identitu uţivatele (uţivatelské logovací údaje) vůči přednastaveným autentizačním modulům systému SSO. Po 25 Sun OpenSSO Enterprise 8.0 [online]. 42

44 úspěšné kontrole a přihlášení uţivatele pomocí autentizační sluţby dojde k vytvoření relace pro přístup ke klientským sluţbám a aplikacím uvnitř podnikové sítě. Služba pro kontrolu autorizační politiky (Policy Service) - umoţňuje kontrolu pravidel nastavených pro autorizaci uţivatele a ověřuje práva přístupu k zabezpečené aplikaci. Veškerá pravidla a nastavení jsou uloţena v OpenSSO Config Store. Protokolovací služba (Logging Service) provádí zápis do provozních systémových logů aplikace OpenSSO. Vyuţití této sluţby je vázáno nejen na systém OpenSSO, ale také pro systémově integrované klientské sluţby nebo aplikace. Relace služeb (Session Service) je centrální sluţba, jejímţ hlavním účelem je aktivně uchovávat informace o skupině zalogovaných uţivatelů do SSO systému. Mezi hlavní parametry této sluţby patří vytvoření jedinečného identifikátoru pro přihlášení uţivatele do systému, časové zneplatnění po uplynutí doby platnosti relace a zálohování logů o přihlášení nebo odhlášení. Služba Federation Services zajišťuje sdílení totoţnosti (identity) uţivatele pomocí protokolu SAML mezi počítači s různými platformami a operačními systémy do různých domén. Služby datového uložiště uživatelských účtů (Identity Repository Service) tento modul integruje firemní uloţiště uţivatelských účtů do systému OpenSSO. Pro firemní uloţiště je pouţita aplikace LDAP. 43

45 Doména Aplikační server Aplikace 1 Aplikace 2 Aplikace 3 J2EE Security Policy Agent ClientSDK OpenSSO API OpenSSO Login Page Aplikace 4 Obrázek 5: Schéma zapojení OpenSSO (zdroj: Oracle upraveno autorem) Návrh řešení v aplikačně datové oblasti Návrh řešení systému OpenSSO v aplikační datové oblasti je nedílnou součástí přípravy projektu. Za všechny návrhy a úpravy zodpovídá úsek architektury IT. Tento úsek zapracuje výsledné řešení do administrátorské provozní dokumentace, která se překládá k akceptačnímu řízení. Jelikoţ nám systém OpenSSO zabezpečuje centrální autentizaci a single-sign-on pro rozhodující aplikace podniku s velkým mnoţstvím spolupracujících aplikací, proto musíme nezbytně navrhnout datovou zónu pro integraci systému do stávající ITC infrastruktury podniku. Výsledné řešení aplikační datové oblasti splňuje následující charakteristiky. Softwarové řešení vazeb, coţ znamená rozhraní na aplikace a ostatní subsystémy je řešeno pomocí API Acces Manageru pro všechny aplikace v podniku. Softwarové řešení celé aplikace je provedeno tříúrovňovou architekturou. Prezentační rozhraní, jinak také nazývané prostředí klienta je řešeno přístupem přes přihlašovací obrazovku, kde uţivatel zadá jméno a heslo. Administrační konzole správce aplikace, správce operátora a vzdáleného správce je 44

46 přístupná pomocí protokolu HTTP + SSL, pomocí zabezpečeného přístupu. Administrace navrţených aplikačních serverů GlassFish je taktéţ dostupná přes konzoli se zabezpečeným protokolem. HTTP. Další fází zabezpečení je to, ţe prostup k administrační konzoli je dovolen pouze ze speciálního segmentu sítě a je zablokován ze síťového Load Balanceru Technický návrh vývojového a testovacího prostředí Technický návrh vývojového a testovacího prostředí taktéţ spadá do působnosti úseku architektury IT. Také tento krok v přípravě projektu je pečlivě zadokumentován. Návrh vývojového s testovacím prostředím je velmi důleţitý pro návrh a integraci aplikace do produkčního prostředí. Pokud kvalitně odladíme aplikaci před vlastním nasazením do rutinního provozu, předejdeme komplikacím, které mohou vést aţ k nezdaru celého projektu. Optimálně synchronizované testovací prostředí s produkčním prostředím nám zabezpečí kvalitní otestování funkcionality OpenSSO. Dále nám umoţní minimalizovat riziko změn, a také časové prodlevy na projektu v případě rozdílů mezi jednotlivými prostředími. Architekturu vývojového a testovacím prostředí jsem schématicky zpracoval na obrázku č. 6. Toto prostředí je nasazeno v rámci intranetu společnosti a není přístupné z veřejného internetu. Vývojové prostředí navrhované aplikace je totoţné s testovacím prostředím z důvodu úspory finančních prostředků na projekt. Vypracoval jsem popis funkčnosti vývojového prostředí, které je určeno pracovníkům architektury a má následující posloupnost funkcionalit. Vývojový pracovník přistupuje v rámci intranetu k internímu i externímu portálu, je moţné simulovat více současně přistupujících uţivatelů pomocí zátěţového testu. Odtud je jeho poţadavek směrován na Load Balancer, který rovnoměrně rozděluje zátěţ na obě testovací instance OpenSSO. Systém OpenSSO ověří existenci uţivatele pomocí LDAP účtu a vrátí odpověď vývojovému pracovníkovi. 45

47 Interní uživatel <aplikace> Externí portál <aplikace> Interní portál Load Balancer Testovací OpenSSO 02 Testovací OpenSSO 03 LDAP Obrázek 6: Vývojové a testovací prostředí (zdroj: vlastní) Technický návrh produkčního prostředí Systémový návrh technického provedení jsem schématicky znázornil na obrázku č. 7 a popsal v následujících řádcích. Uţivatel (externí nebo interní) poţádá o ověření identity přes firemní externí firewall, který ho přesměruje na server zpracovávající poţadavek o přístupu. Tento server se dotáţe přes interní firewall, zda je identita uţivatele poţadujícího přistup k aplikaci nebo sluţbě známá, a ověří uţivatele pomocí aplikace OpenSSO, která spolupracuje s uloţištěm identit LDAP serverem. Po ověření identity je uţivatel přesměrován na poţadovanou firemní aplikaci. 46

48 Webové služby a aplikace Interní uživatel Firewall Externí uživatel Firewall Systémové řízení přístupu k aplikacím OpenSSO - autentizace, autorizace. Uložiště oprávnění, identit pro AM Access manager Directory server LDAP Obrázek 7: Obecné schéma architektury OpenSSO (zdroj: vlastní) V této kapitole jsem se snaţil přiblíţit problematiku technické přípravy projektu s analýzou rizik a zajištěním rozsáhlých zdrojů pro realizaci tak obsáhlého projektu. 5.4 Realizace projektu Uskutečnění projektu OpenSSO je vyvrcholením analýz a příprav na uvedení systému do aplikovatelného stavu. Této fáze se zúčastní všichni zainteresovaní pracovníci na projektu ať jiţ interní nebo externí. Vyuţijeme veškeré alokované zdroje na projekt, a to nejen personální. 47

49 5.4.1 Realizace vývojového a testovacího prostředí V počáteční fázi realizace projektu se nejdříve nainstaluje a zkonfiguruje vývojové prostředí OpenSSO. Jelikoţ vývojové a testovací prostředí jsou identická, dojde vlastně k současnému vytvoření obou prostředí. Seznam hardware a software vývojového prostředí jsem zpracoval do tabulky č. 1. Instalace testovacího prostředí spadá do kompetence oddělení architektury ICT, ta v součinnosti s dodavatelskou firmou zajistí kompletní instalaci a konfiguraci systému. Poznatky a konfigurační soubory vyuţijeme při budování provozního prostředí. Logický název serveru sso1t_as1 test 1 Fyzický název serveru HW parametry serveru core; 6 GB RAM; 68 GB HDD HW platforma serveru Solaris Sparc 64 bit SW komponenty Glassfish Enterprise Server v2.1.1, Oracle OpenSSO 8.0 sso1t_as2 test core; 6 GB RAM; 68 GB HDD Solaris Sparc 64 bit Glassfish Enterprise Server v2.1.1, Oracle OpenSSO 8.0 Tabulka 1: Hardware a software testovacího a vývojového prostředí (zdroj APD; autorem). upraveno Technické provedení produkčního a záložního prostředí Architekturu skutečného provedení produkčního prostředí jsem zobrazil na obrázku č. 8. Pro snazší pochopení technického provedení produkčního prostředí jsem sestavil a popsal seznam prvků s jejich funkcemi. Externí uživatel je osoba fyzická nebo právnická přistupující k firemní infrastruktuře a to sluţbám nebo aplikacím z prostředí otevřeného internetu. 48

50 Aplikace externího uživatele jsou takové aplikace nebo sluţby třetích stran, které přistupují z veřejného internetu k síťové infrastruktuře společnosti. Webový aplikační firewall je systém, který poskytuje komplexní ochranu webových aplikací vyuţívaných společností. Kompletní síťový provoz aplikací je veden přes tento firewall a zahrnuje přístupy z různých webových prohlíţečů, jako jsou IE, Chrome, Firefox a Safari na všechny aplikace uvnitř datové sítě. Mezi hlavní činnosti firewallu náleţí přihlašování uţivatelů pomocí klientských certifikátů, jejich ověřování vůči CRL (Certificate Revocation List - seznam revokovaných certifikátů) a transformaci obsahu do hlavičky poţadavku na přihlášení, která je následně zpracována certifikačním modulem OpenSSO. Následující podstatnou funkcí firewallu je ukončování příchozích SSL spojení navazovaných uţivateli. Brána B2B (Business to Business) je brána integrující data z koncových systémů pro výměnu informací mezi firemními obchodními partnery. Tato brána poskytuje sluţbu pro výměnu různých datových zdrojů společnosti prostřednictvím spolupráce (např. souborem XML - Extensible Markup Language). Hlavní náplní brány je komunikace, zpracování a sledování obchodních vztahů se zákazníky pomocí webového rozhraní. Proxy server je aktivní prvek, takzvaný zprostředkovatel mezi klientem a cílovým serverem. Odděluje intranet (lokální počítačovou síť) od prostředí otevřeného internetu. Externí portál je webové portálové rozhraní pro externí firemní klienty společnosti. Zprostředkovává přístup k nabízeným sluţbám a aplikacím naší společnosti. Load Balancer (vyvažování zátěže) je speciální softwarová aplikace pro vyvaţování zátěţe generované uţivateli podnikových sluţeb nebo aplikací. Při zasílání poţadavků na systém SSO dojde k rozdělení zátěţe mezi aplikační servery. Korektní nastavení Load Balancerů nám zajistí, aby v okamţiku výpadku jednoho aplikačního serveru došlo k okamţitému přepnutí provozu na funkční server, a zamezí zasílání poţadavků na nefunkční stroj. Vše musí proběhnout v řádu vteřin tak, aby nebyl uţivatel omezen při přihlášení. 49

51 Interní portál - je webové portálové rozhraní pro zaměstnance společnosti slouţící pro přístup k sluţbám a aplikacím společnosti. OpenSSO jsou hlavní autentizační a autorizační servery společnosti, jeţ poskytují funkci jednotného přihlášení a generují cookie, potřebné pro prokázání identity uţivatele v aplikacích integrovaných se sluţbou OpenSSO. Dále to je sluţba prezentačního rozhraní pro přihlášení uţivatele jménem, heslem a URL se závěrečným ověřením klientského certifikátu oproti LDAP účtu uţivatele. Taktéţ zprostředkovává funkci přenosu ověření uţivatele mezi rozdílnými doménami a vyuţívá protokol SAML (standardizovaný Framework Security Assertion Markup Language). LDAP (Lightweight Directory Access Protocol) je hlavní uloţiště identit zaměstnanců a klientů společnosti. Je to také specializovaný standardizovaný komunikační protokol adresářových sluţeb fungující na portech TCP/IP. Funguje na základě identifikačních dat, jeţ jsou uloţena v záznamech, které jsou uspořádány ve stromové struktuře. Zkušenosti získané při instalaci a konfiguraci vývojového a testovacího prostředí plně vyuţijeme pro sestavení produkčního a záloţního prostředí. Produkční prostředí běţí v primárním datovém centru, kdeţto záloţní prostředí je sice naprosto totoţné, ale umístěné do jiného datového centra pro případ výpadku hlavního centra. Na zprovoznění primárního se záloţním prostředím spolupracují všechny zúčastněné útvary. Do těchto útvarů počítám dodavatelskou firmu, oddělení architektury s oddělením instalace hardware a operačních systémů a také budoucí provozní administrátory systému. 50

52 <aplikace> Aplikace externího uživatele Externí uživatel Webový aplikační firewall Proxy server Brána B2B Interní uživatel Externí portál Load Balancer Interní portál Server sso1- as1 <opensso> Server sso1- as2 Záložní server LDAP Obrázek 8: Architektura produkčního prostředí OpenSSO (zdroj: vlastní) 51

53 5.4.3 Instalace s konfigurací serverů provozního prostředí a klientských stanic Instalaci a konfiguraci serveru systému OpenSSO provádí specialisté oddělení hardware a operačních systémů náleţející pod úsek provozu ICT v součinnost s ostatními útvary. Hardwarovou a softwarovou konfiguraci systému jsem rozepsal v tabulce č. 2. Pro upřesnění uvádím hardware serveru. Coţ je UltraSPARC T3 skládající se z 16 core CPU (sun verze 4) taktovaných na 1,6 GHz, dále z 64 GB operační paměti a z pevného disku 4*300 GB. Logický název serveru Fyzický název serveru HW parametry serveru sso1_as core; 12 GB RAM; 70 GB HDD sso2_as core; 12 GB RAM; 70 GB HDD sso3_as3_z core; 12 GB RAM; 70 GB HDD HW platforma serveru Solaris Sparc 64 bit Solaris Sparc 64 bit Solaris Sparc 64 bit SW komponenty Glassfish Enterprise Server v2.1.1, Oracle OpenSSO 8.0 Glassfish Enterprise Server v2.1.1, Oracle OpenSSO 8.0 Glassfish Enterprise Server v2.1.1, Oracle OpenSSO 8.0 Tabulka 2: Seznam HW a SW produkčního prostředí OpenSSO (zdroj APD; upraveno autorem). Ke klientské části mohu pouze uvést toto. Za klientskou stanici je povaţován jakýkoliv standardní osobní počítač připojený k internetu a vyuţívající podporovaný internetový prohlíţeč systémem OpenSSO (Microsof IE, Mozilla, Chrome, Safari). Samozřejmě v současnosti mnozí uţivatelé vyuţívají různá mobilní zařízení (tablety, mobily atd.), jeţ jsou také podporována. 52

54 5.4.4 Nastavení přístupů a bezpečnostních modulů v OpenSSO Jelikoţ se jedná o zásadní firemní bezpečnostní systém řídící autentizaci, na nějţ je kladen velký důraz a poţadována absolutní bezpečnost, uvádím zde přehled bezpečnostních nastavení systému. V aplikaci je nastaveno zabezpečení SSL pro přenos dat pomocí protokolu TCP/IP na ochranu transferu citlivých dat. V tabulce č. 3 shrnuji zabezpečení komunikace pro různé komponenty systému. Proces komponenta Komunikace Load Balancer Komunikace GlasFish - OpenSSO Komunikace OpenSSO - LDAP SSL ANO NE ANO Tabulka 3: Zabezpečení komunikace (zdroj APD; upraveno autorem). Následující rozdělení rolí různých uţivatelů je důleţité pro pochopení funkce zabezpečení systému. V aplikaci OpenSSO existují tři typy uţivatelů systému, jeţ definují role a zásady pro přidělování uţivatelských přístupů. Administrátor: přistupuje k administrativní konzoli pomocí jména a hesla, přistupuje k datům koncových uţivatelů, přistupuje k provozní konfiguraci. Aplikace (interní, externí): loguje se k OpenSSO pomocí jména a hesla, přistupuje k datům koncových uţivatelů, nemá přístup k administrativní konzoli. 53

55 Koncový uţivatel (interní, externí): autentizuje se prostřednictvím aplikace pomocí jména a hesla nebo certifikátu, nemá přístup k administrativní konzoli, nemá přístup k datům ostatních uţivatelů Charakteristika zálohování dat a programů aplikace Ve vývojovém a testovacím prostředí je prováděno zálohování programového vybavení pomocí adresářů. Zálohování provozních dat je realizováno pomocí access/error logovacích souborů a debug souborů sluţeb. Standardně je zálohována konfigurace operačního systému a ostatních sluţeb nutných pro běh aplikace. Postup zálohování jsem uvedl v příloze č. 2 a vychází z doporučení o postupu zálohování od společnosti Oracle. Produkční prostředí je zálohované stejným způsobem jako testovací prostředí. Rozdíl je pouze ve speciálních serverech, které jsou určené pro zálohy podnikových sluţeb a aplikací Rizika a scénář řešení nestandardních stavů systému Za hlavní riziko pokládám výpadek aplikačního serveru OpenSSO. Pokud dojde k výpadku aplikačního serveru, coţ je Glassfish Enterprise Server verze 2.1.1, na kterém běţí autentizační systém, dojde k ovlivnění běhu celé sluţby nedostupnosti aplikace. Pro reálnou představu co vše můţe způsobit nedostupnost aplikace, zde uvádím moţné příčiny výpadku systému OpenSSO. Pokud dojde k zaplnění souborového systému pro logy aplikace, hrozí reálné riziko pádu aplikace. V případě poškození souborového systému při restartu serveru nemusí aplikace naběhnout do funkčního stavu. Dále je moţný výskyt technické poruchy nebo např. poţáru a v tomto případě můţe dojít k fyzickému poškození hardware. Nejjednodušším řešením je, pokud nedojde k poškození pevného disku, přemístit stávající pevný disk s nepoškozenými daty na nový hardware. V opačném případě, coţ znamená kompletní zničení hardware, je nutné provést plnou obnovu dat ze zálohy. 54

56 Rizikem výpadku jen jednoho serveru aplikace je sníţení výkonu celého systému OpenSSO na polovinu. Uţivatelé a aplikace vyuţívající tento server budou přesměrováni na jiný server, jenţ bude přetěţován a můţe takzvaně zatuhnout. Pomocí následujících kroků osvětlím scénáře řešení obnovy serveru. Obnovu serveru zrealizuje určený administrátor spravující OpenSSO. Další kroky obnovy aplikačního serveru závisí na konkrétním druhu výpadku. Doporučuji nejprve zkontrolovat příčinu výpadku serveru a po té se rozhodnout, zda provedeme plnou nebo pouze částečnou obnovu serveru. Pokud nedojde k poškození hardware, můţeme provést částečnou obnovu serveru. Proto definuji následující postup. Pokud určíme závadu jako zaplnění souborového systému na disku například logy, přesuneme logy na zálohovací server, čímţ dojde k uvolnění místa na disku a k zprovoznění aplikace. V případě poškození souborového systému opravíme pouze poškozenou část systému. Nahradíme poškozené části zkopírováním nových částí, například knihoven systému. Komplikovanější je plná obnova serveru systému. Ta nastane při fyzické závadě hardware. Následujícími kroky obnovíme funkcionalitu systému. Základní krok je instalace nového operačního systému Solaris. Navazujícím krokem je nastavení systému s provedením instalace aktuálních záplat. Na aktuálním operačním systému zprovozníme aplikační server GlassFish spolu s aplikací OpenSSO. Pokud existuje neporušená záloha systému, vyuţijeme ji. Závěrečnou fází je spuštění aplikačního serveru s aplikací. Samozřejmostí je provedení kontroly funkčnosti systému OpenSSO Podpora uživatelů a monitoring autentizační služby Neméně důleţitou součástí projektu OpenSSO je podpora všech uţivatelů systému s kontrolním monitoringem autentizační sluţby. Proto zde uvádím, jak je podpora uţivatelů řešena. Je zajišťována celopodnikovým útvarem podpory koncových uţivatelů, neboli takzvaným helpdeskem. Helpdesk zabezpečuje zákaznické a informační sluţby externím 55

57 a interním klientům prostřednictvím telefonu (hlasového kanálu), zpracováním elektronické pošty ( em). Další náplní call centra je zajištění technické a metodickou podpory pro firemní strategickou aplikaci APOST. Jedná se o linuxovou distribuci, soubor aplikací poštovního provozu společně se zákaznickými sluţbami pro vydavatele tisku, a to vše na bezplatných telefonních linkách. Pro svoji činnost helpdesk vyuţívá jednu z nejmodernějších technologií firmy CISCO Systems IP telefonii. Dostupnost aplikace OpenSSO je nastavena na 24/7, coţ znamená, ţe se uţivatelé (interní, externí) mohou k aplikaci přihlásit kdykoliv. Proto v případě nedostupnosti systému je nutné, aby dohled aplikace měl kontakt nejen na hepldesk, ale také na administrátora aplikace a všechny správce připojených aplikací k OpenSSO. Monitoring aplikace a serverů provádí specializované oddělení dohledu IT. Hlavní úkolem dohledu serverů je odhalit potencionální výpadek sluţby za pomoci sledování definovaných parametrů sluţby OpenSSO. Na základě včasného odhalení výpadku sluţby je moţné minimalizovat nedostupnost aplikace nebo ji efektivně naplánovat. Pro úplnost uvádím parametry monitoringu aplikace OpenSSO uvedené v administrátorské provozní dokumentaci, které v následujících řádcích vysvětlením: 26 latence odezvy serverů aplikace provádění pingu na aplikaci, velikost místa v diskových oddílech kontrola volného místa na disku, Load Balaning serverů - rozdělování zátěţe na jednotlivé servery, vyuţití operační paměti RAM sledování paměti, aby nedošlo k přetečení RAM, mnoţství běţících procesů na serveru sledování vytíţení CPU, počty přihlášených uţivatelů kontrola proti distribuovaným útokům, sledování síťových protokolů jedná se o protokoly HTTP, HTTPS, SSH, FTP atd., sledování platnosti SSL certifikátů ochrana před neplatnými certifikáty. 26 ČESKÁ POŠTA, s.p. Administrátorská provozní dokumentace. Praha,

58 5.4.8 Testování systému Jedním z nejdůleţitějších kroků při vývoji a implementaci IT projektu je ověření korektní funkce projektovaného systém. Zjednodušeně řečeno - aplikace má dělat to, co je od ní poţadováno při stanovené zátěţi informačního systému. V následujících řádcích popisuji mnou realizovaný zátěţový test systému OpenSSO na produkčním prostředí aplikace. Taktéţ uskutečním akceptační test na vyprojektované aplikaci. Funkční testy uskutečnila dodavatelská firma jiţ po realizaci instalace a konfigurace serverů aplikace Zátěžové testování OpenSSO V úvodu praktické části projektu OpenSSO jsem popsal technické poţadavky na produkční prostředí aplikace. Jedná se o následující parametry, které musí systém splnit, abych ho mohl prohlásit za akceptovatelný do rutinního provozu. Způsobilost aplikace obslouţit 200 paralelních poţadavků za sekundu při souběţném provozu dvou produkčních aplikačních serverů. Dalším parametrem testu je nalezení mezního počtu poţadavků za sekundu, které vedou k zahlcení nebo k pádu systému OpenSSO. Součástí zátěţového testu je mnou vypracovaná závěrečná zpráva z měření s vyhodnocením testu. K vypracování testu jsem vyuţil volně dostupný specializovaný testovací software JMeter. Tento software vyuţíváme v naší firmě pro komplexní zátěţové testování aplikací předávaných do správy provozu IT. Pro představu, Apache JMeter je softwarový open source nástroj pro provádění zátěţových testů. Lze vyuţít pro měření výkonnosti a k vytvoření zátěţe pro webové aplikace. JMeter dokáţe simulovat reálnou zátěţ na testovaném systému OpenSSO. Test jsem provedl za pomoci JMeteru verze 2.8 zobrazený na obrázku č. 9. S podporou tohoto nástroje jsem naprogramoval testovací skript, který jsem nadále optimalizoval pro pouţití v systému OpenSSO. 57

59 Obrázek 9: Apache JMeter verze 2.8 s otevřeným skriptem pro testování OpenSSO (zdroj: vlastní) Závěrečná zpráva z měření zátěžového testu OpenSSO s vyhodnocením testu Cíl zátěžového testování Zátěţový test systému OpenSSO má za cíl nalézt mezní počet poţadavků za sekundu a počet virtuálních uţivatelů (VU), při kterém dochází k zahlcení, případně k pádu systému OpenSSO. Tento stress test systému vykonám na systému, jenţ vyuţívá Load Balancer pro vyvaţování zátěţe produkčních serverů. Předmět zátěžového testování Předmětem zátěţového testu je zatíţení následujících produkčních serverů aplikace OpenSSO: 58

60 sso1_as1 dostupný pod DNS sso1-as1.subdomena.doména.cz na adrese IP 10.XXX.XXX.XXX, běţící na hardwaru serveru 31-04, sso1_as2 dostupný pod DNS sso1-as2. subdomena.doména.cz na adrese IP 10.XXX.XXX.XXX, běţící na hardwaru serveru Architektura zatěžovaného systému Následující schéma obrázek č. 10 zobrazuje umístění prvku OpenSSO v konkrétních zónách operačního systému s popisem architektury zatěţovaného systému skutečných fyzických serverů. <device> Server Oracle Sparc <zone> Server sso1_as OpenSSO node 1 <device> Server Oracle Sparc Core: 4 RAM: 12 GB HDD: 70 GB <zone> Server sso1_as OpenSSO node 2 Core: 4 RAM: 12 GB HDD: 70 GB <OpenSSO> OpenSSO Oracle OpenSSO 8.0 Centrální autentizační server LDAP Obrázek 10: Produkční prostředí OpenSSO zatěţovaného systému, fyzická architektura (zdroj: vlastní) Architektura zátěžového testu Zátěţ systému OpenSSO je generována ze dvou zátěţových generátorů (serverů), které jsou umístěny v primárním datovém centru obrázek č. 11. Oba zátěţové generátory směřují svoji zátěţ na Load Balancer, který je pravidelně rozděluje mezi aplikační servery sso1-as1. 59

61 subdomena.doména.cz a aplikační server sso1-as2. subdomena.doména.cz. Pro generování zátěţe jsem pouţil softwarový nástroj Apache JMeter 2.8. Generátory zátěže GZ-3 GZ-4 Switch Uživatel Router Externí firewall Interní firewall LoadBalancing Server31-04 Server31-05 Záložní server31-01 Obrázek 11: Architektura zátěţového testu OpenSSO (zdroj: vlastní) Testovací scénář Testovací scénář vychází z vydefinovaných poţadavků projektu na systémem OpenSSO. Coţ znamená, ţe na zatěţované aplikační servery OpenSSO postupně přistupovali generovaní virtuální uţivatelé (VU) přes Load Balancer. Rychlost náběhu VU byla 1 VU / 1s na kaţdém generátoru zátěţe. Limit počtu VU nastavený v kódu skriptu byl VU. Kaţdý VU načetl 60

62 přihlašovací formulář, provedl přihlášení, 1 minutu čekal a následně provedl odhlášení. Tyto činnosti byly VU neustále opakovány. Při kaţdé iteraci byly odstraněny cookies. Parametry běhu testu: Počet VU: Doba náběhu VU: virtuálních uţivatelů sekund Naměřené hodnoty Zátěţový test produkčního prostředí OpenSSO jsem úspěšně zrealizoval s následujícími výstupy. Grafy jsou výstupem open source modulů integrovaných do Apache JMeteru software pro zátěţové testování. Doba trvání testu: 1:22 h Graf 1: Počet vyřízených poţadavků za sekundu (zdroj: vlastní - vygenerováno v JMeteru) 61

63 Graf 2: Počet vyřízených poţadavků za sekundu systémem OpenSSO (Thread Group * 2 = celkový počet vláken; 4500 * 2 = 9000) (zdroj: vlastní - vygenerováno v JMeteru) Graf 3: Vytíţení CPU serverů OpenSSO a navazujících serverů LDAP (zdroj: vlastní - vygenerováno v JMeteru) 62

64 Vyhodnocení zátěžového testu Zátěţový test - stress test produkčního prostředí OpenSSO jsem úspěšně zrealizoval. Výstupem stress testu produkčního prostředí serverů OpenSSO je následující zhodnocení. Korektně bylo na systému OpenSSO vyřízeno více neţ 480 poţadavků za sekundu, odesílaných od více neţ 9000 virtuálních uţivatelů. Dále jsem prokázal, ţe hranice počtu virtuálních uţivatelů, které dokázal jeden server OpenSSO obslouţit, činila 4500 VU. Po dosaţení těchto hodnot začal systém vracet chyby a test byl ukončen. Celková doba běhu testu 1:22 h. Mnou provedený zátěžový test potvrdil způsobilost nasazení systému OpenSSO do produkčního prostředí firmy Akceptační testování Pro ověření funkčnosti implementované aplikace SSO jsou vyhrazeny akceptační testy. Tyto testy jsem zrealizoval ještě před spuštěním aplikace do pilotního provozu. Připravené testovací scénáře, jeţ jsou součástí projektové dokumentace, prověří připravenost aplikace pro nasazení do rutinního provozu. Na základě podkladů testovacích scénářů jsem provedl následující posloupnost akceptačních testů. V následujících řádcích jsem popsal druhy scénářů pro test provozní akceptace aplikace: scénář č. 1 registrace uţivatele pomocí aplikace OpenSSO a získání přihlašovacích údajů pro další činnost uţivatele, scénář č. 2 přihlášení pomocí uţivatelského jména a hesla získaného po provedení registrace uţivatele je prezentováno na obrázku č. 12, scénář č. 3 přihlášení pomocí firemního certifikátu, scénář č. 4 pokus o přihlášení jménem a heslem za pomocí neexistujících údajů, předpoklad je zamítnutí přihlášení neznámého uţivatele, je zobrazen na obrázku č

65 Obrázek 12: Akceptační testování OpenSSO login (zdroj: firemní intranet) Obrázek 13: Akceptační testování OpenSSO - chyba přihlášení (zdroj: firemní intranet) 64

66 Všechny podmínky akceptačního testování jsem úspěšně zrealizoval na základě stanovených příkladů - scénářů akceptačního testu. Lze konstatovat, že jsem provedením akceptačního testu ověřil způsobilost aplikace OpenSSO ke spuštění do pilotního provozu Pilotní provoz Pod pojmem pilotní provoz nebo také pilotní testování aplikace si lze představit zkušební fungování systému v reálném IT provozu. To znamená ověření korektní funkčnosti aplikace OpenSSO na produkčním prostředí při zapojení do reálného okolí oproti simulaci v testovacím prostředí. Nejdůleţitějším cílem pilotního provozu je ověření technického řešení autorizace a autentizace uţivatele pomocí OpenSSO tak, aby se reálně identifikovala všechna bezpečnostní rizika finálního technického řešení. Výsledným řešením pilotního provozu je technicky a formálně nasazená aplikace pro klienty do rutinního provozu. Vedlejším cílem pilotního provozu je ověření moţnosti implementace nových, doposud nevyvinutých aplikací. Po spuštění provozního prostředí OpenSSO v pilotním provozu s testovacími interními uţivateli a aplikacemi na jeden kalendářní měsíc je moţné připravit administrativní ukončení pilotu a převést aplikaci do plného provozu (soupis migrovaných aplikací příloha č. 3). Na základě všech dostupných informací a mnou provedených testů byl systém OpenSSO oficiálně spuštěn do pilotního provozu. Následujícím krokem po úspěšném pilotním provozu OpenSSO je akceptační řízení a předání systému plně pod správu odboru provozu centrálních systémů. 65

67 5.5 Ukončení projektu Po úspěšném otestování aplikace a nasazení do pilotního provozu nastupuje fáze ukončení projektu. Tato závěrečná fáze je specifická provedením provozního akceptačního řízení IT systému a následným předáním systému do rutinního provozu. Akceptační řízení OpenSSO spadá do mé pracovní kompetence, proto jsem provedl komplexní proces provozní akceptace Provozní akceptační řízení Provozním akceptačním řízením je myšlen proces kontroly implementace nově vyvinutého informačního systému (aplikace), jiţ provozovaného systému, téţ implementace systému, u kterého byla provedena zásadní změna, jeţ má podstatný dopad na jeho rutinní provoz, eventuálně účinek na související IT systémy a technologie. Rozhodujícím parametrem, kde i změna v nasazovaném systému do provozu podléhá provoznímu akceptačnímu procesu, závisí na tom, zda: provádíme implementaci zcela nové sluţby informačního systému nebo informační a komunikační technologie, provádíme změnu architektury provozovaného informačního systému nebo informační a komunikační technologie, má změna dopad do souvisejících centrálních technologií (např. síťové okolí). Celý proces provozního akceptačního řízení v naší organizaci jsem zobrazil a popsal v diagramu na obrázku č. 13. Za procesním diagramem popisuji detailní postup práce na závěrečné časti projektu. Jelikoţ se jedná o zásadní proces mající dopad na převzetí systému do správy útvaru provozu ICT sluţeb, vyspecifikoval jsem zde nalezené nedostatky předávaného systému do rutinního provozu. 66

68 Požadavek na akceptaci Kompeltnost podkladů Ne Doplnění podkladů Ano Zahájení akceptačního řízení Posouzení rozsahu akceptace Posouzení úseků (BICT, HW, atd.) Dílčí akceptační protokoly Vytvoření závěrečného hodnocení Závěrečný ackeptační protokol Hodnocení akceptace : A Ne Hodnocení akceptace: B, C Ne Neakceptováno hodnocení D Ano Předání do provozu ICT Ano Návrh a realizace mimořádných postupů Závady odstraněny Ano Prohlášení o odstranění závad Ne Požadavek na odstranění závad Akceptováno do provozu Obrázek 14: Schéma procesu provozního akceptačního řízení ve společnosti (zdroj: vlastní) Formálním začátkem akceptačního řízení je podání písemného poţadavku na zahájení provozního akceptačního řízení projektovým manaţerem OpenSSO. Tento poţadavek byl předán mé osobě jako odpovědnému pracovníkovi akceptace autentizačního systému. Součástí poţadavku na zahájení je předání kompletní dokumentace potřebné k akceptaci. 67

69 Dokumenty, které mi byly předány projektovým manaţerem, na jejichţ základě provedu akceptační řízení projektu OpenSSO: popis nové sluţby informačního systému nebo informační a komunikační technologie, detailní technický a technologický návrh, administrátorská a provozní dokumentace, metodika připojení aplikací k OpenSSO, dokumentace k zajištění dostupnosti OpenSSO z prostředí internetu. Následné mnou provedené vyhodnocení předané dokumentace umoţnilo oficiální zahájení provozního akceptačního řízení. Ideální doba trvání akceptace je podle vnitřního předpisu stanovena na 10 pracovních dnů. Tuto dobu lze na poţádání všech zúčastněných stran prodlouţit z různých důvodů např. doplnění podkladů, ověření skutečného stavu systému atd. Posouzením rozsahu akceptačního řízení se dostávám k vlastní pracovní náplni. Jelikoţ OpenSSO je naprosto nový systém, který bude začleněn do infrastruktury podniku, musím zahrnout do akceptačního řízení kompletní personální strukturu pracovníků v IT a utvořit z ní akceptační tým. Zde uvádím seznam firemních útvarů IT akceptačního týmu, které jsem začlenil do procesu provozního akceptačního řízení OpenSSO: oddělení hardware a operačních systémů, oddělení softwarových aplikací, oddělení dohledu IT systémů, oddělení databází, odbor provozu datové sítě, oddělení standardizace a licenčních politik (pokrytí software licencemi a licenční politiky), odbor bezpečnosti ITC, oddělení akceptace IT systému (zastoupené autorem této práce, v pozici vedoucího týmu provozní akceptace). 68

70 Všechny výše jmenované útvary (mimo odd. akceptace IT systémů) mají za povinnost vypracovat dílčí akceptační protokol s hodnocením. V tomto protokole se vyjadřují pouze za svoji odbornost oddělení vyplývající z jejich kompetencí. V následujícím odstavci popisuji stupnice s moţným hodnocením, stejný princip hodnocení je taktéţ pouţit v závěrečném akceptačním protokole. 27 Charakteristiky hodnocení provozního akceptačního řízení Hodnocení A - označuje, ţe akceptovaný informační systém - aplikace nebo jeho část nevykazuje ţádné chyby. Systém je dostatečně objasněn v přiloţené dokumentaci. Koresponduje s vnitřními IT předpisy a politikami firmy. Výsledek pilotního provozu systému nevykazuje ţádné závady. Hodnocení B - označuje, ţe akceptovaný informační systém aplikace, vykazuje drobnější neshody a chyby, které ale nebrání převzetí aplikace do rutinního provozu. Není nutno přijímat specifická opatření pro dodrţení SLA (Service Level Agreement) útvarem provozu centrálních systémů. Hodnocení C - označuje, ţe akceptovaný informační systém aplikace, zahrnuje četnější neshody a chyby. Tyto chyby neumoţňují dodrţet poţadovaná provozní kritéria a SLA. Podmínkou pro provozování aplikace a dodrţení provozních kritérií je přijetí mimořádných opatření. Hodnocení D - označuje, ţe akceptovaný informační systém aplikace obsahuje velmi váţné neshody a vady. Hodnocené vady neumoţňují provozování systému ani s přijetím mimořádných opatření. Hodnocení N uděluje pracovník akceptačního řízení mimořádně, a to v případě, ţe informační systém je mimo kompetenci hodnotícího pracovníka. 27 ČESKÁ POŠTA, s.p. Akceptace IS do provozu. 69

71 Vypracované dílčí akceptační protokoly s hodnocením od odborných útvarů IT zúčastněných na akceptačním řízení byly předány mé osobě, vedoucímu týmu akceptace OpenSSO. Jakoţ to vedoucí pracovník týmu akceptace projektu OpenSSO mám za povinnost provést závěrečnou analýzu a vyhodnocení na základě podkladů dílčích akceptačních protokolů dodaných odpovědnými pracovníky odborných úseků. Výslednou analýzu s hodnocením jsem shrnul v závěrečném akceptačním protokolu o převzetí do provozu centrálních systémů informačních a komunikačních. Na základě podkladů a znalosti systému jsem indikoval tyto závady s různými stupni hodnocení. Vyhodnocení zjištěných akceptační závad na projektu OpenSSO Lokalizované závady z oblasti architektury zjistil jsem nekompletní popis architektury systému chybějící popis adresace části komponent Load Balanceru. Chybějící popis konektivity z internetu, externí IP adresace, a dále chybějící soupis sluţeb/aplikací pouţitých v OpenSSO. Hodnocení: D nelze akceptovat pro závaţné nedostatky. Lokalizované závady z oblasti provozuschopnosti aplikace detekoval jsem nekorektní nastavení Load Balancingu, coţ je nutné pro korektní zajištění SSL terminací a ověření CRL. Ověřil jsem, ţe neexistuje smlouva o podpoře OpenSSO. Hodnocení: D nelze akceptovat pro závaţné nedostatky. Lokalizované závady z oblasti bezpečnosti zjistil jsem, ţe nebyly provedeny penetrační testy, je také nutné provést bezpečnostní shodu aplikace. Chybí dokument s konkrétním bezpečnostním nastavením OpenSSO. Hodnocení: D nelze akceptovat pro závaţné nedostatky. Lokalizované závady v oblasti záložního a testovacího prostředí v záloţním prostředí není korektně zajištěn Load Balancing OpenSSO, nastavení neodpovídá primárnímu prostředí. 70

72 Hodnocení: D nelze akceptovat pro závaţné nedostatky. Lokalizované závady v dokumentaci je nekompletní administrátorská provozní dokumentace, neodráţející skutečný stav instalovaného systému. Hodnocení: D nelze akceptovat pro závaţné nedostatky. Lokalizované závady v oblasti bezpečnostního monitoringu zjistil jsem, ţe aplikace OpenSSO není napojena na bezpečnostní monitoring společnosti. Hodnocení: C akceptovatelné s váţnými výhradami. Lokalizované závady v hardwarové evidenci a licenčním souladu bylo mi potvrzeno, ţe hardware serveru UltraSPARC T3 není zaveden v operativní evidenci HW a evidenci SAP. Instalované servery GlassFish 2.11 nemají zajištěnou plnou komerční podporu. Hodnocení: C akceptovatelné s váţnými výhradami. Lokalizované závady ve vzdělávání administrátoři aplikace nebyli školeni pro administraci aplikace OpenSSO. Hodnocení: C akceptovatelné s váţnými výhradami. Lokalizované závady v zálohování a archivaci dat není nenastaven proces archivace logů podle instalačního postupu. Hodnocení: B akceptovatelné s drobnými výhradami. Lokalizované závady v začlenění do infrastruktury centrálního a záložního výpočetního střediska v záloţním datovém centru není plně zprovozněna agregace síťových portů. Hodnocení: B akceptovatelné s drobnými výhradami. Lokalizované závady v havarijním plánu a plánu obnovy nebyl proveden havarijní plán a plán obnovy, nutné provést co nejdříve tyto plány. Hodnocení: B akceptovatelné s drobnými výhradami. 71

73 Na základě těchto zjištěných závad v rámci provozního akceptačního řízení jsem vystavil negativní závěrečný akceptační protokol s hodnocením: D - systém OpenSSO nelze akceptovat pro závažné nedostatky. Z výše jmenovaných důvodů aplikaci nelze převést pod správu provozu ICT a do rutinního provozu. Následujícím logickým krokem po mém závěrečném hodnocení stupněm D (aplikace OpenSSO je neakceptovatelná) je, ţe neprodleně informuji projektového manaţera o negativním výsledku akceptace. Navazující proces následující po zamítnutí provozní akceptace systému je součinnost projektového manaţera s vedoucím týmu akceptačního řízení a zainteresovaných pracovníků odborných úseků. Projektový manaţer spustí proces na odstranění zjištěných závad bránících převzetí aplikace do rutinního provozu. Po odstranění indikovaných nedostatků je nutné, aby projektový manaţer opětovně poţádal o nové akceptační řízení. Při vypořádání závad a ověřování skutečností bránícím převzetí aplikace OpenSSO do provozu jsem zjistil, ţe společnost Oracle vyvíjející tento autentizační software, přestane na konci roku 2014 vyvíjet a poskytovat komerční podporu. Skončí podpora produktů Sun OpenSSO, Sun Identity Manager (Oracle OpenSSO a Oracle Waveset) a Sun Directory Server EE (Oracle Directory Server EE). Všechny výše zmíněné závady brání úspěšnému provoznímu akceptačnímu řízení a převzetí do rutinního provozu Předání systému do provozu ICT Proces formálního předání autentizačního systému OpenSSO do provozu nelze provést z výše uvedených důvodů a nalezených chyb. Proto systém zůstává i nadále v pilotním provozu a v současnosti probíhá odstraňování vad bránících převzetí systému do provozu. Za systém je i nadále zodpovědný projektový manaţer a za správu systému zodpovídá dodavatel s odborem architektury. 72

74 5.6 Vyhodnocení projektu Je velmi těţké provést vyhodnocení projektu OpenSSO. Hlavním důvodem, proč nelze jednoznačně kladně hodnotit projekt je to, ţe do konce měsíce března 2014 nebyl projekt provozně akceptován do rutinního provozu z důvodů výše uvedených závad v závěrečném akceptačním protokolu. Chyby detekované při procesu akceptace jsou sice postupně odstraňovány, ale do současné doby nebyly stoprocentně odstraněny detekované závady s hodnocením D nelze akceptovat pro závaţné nedostatky, a proto nelze převzít aplikaci do správy provozu. V současné chvíli není moţné kvalitativně garantovat SLA (Service Level Agreement) pro aplikaci OpenSSO a zajistit bezproblémový rutinní běh systému ve firemním provozu ICT. Moţná některé čtenáře této diplomové práce překvapí, ţe nikde neuvádím časový harmonogram projektu (Ganttův diagram) v původně naplánovaném harmonogramu bylo stanoveno zahájení projektu od ledna 2012 a ukončení v prosinci 2013, kdy měly být kompletně převedeny všechny firemní aplikace vyuţívající OpenSSO. Bohuţel doposud se tak nestalo, čímţ se naplnilo jedno z predikovaných rizik (paralelní provoz AM a OpenSSO). Časový skluz na projektu byl také způsoben zdrţením na souběţně probíhajících projektech Upgrade AIM LDAP CA, Upgrade AIM LDAP CAS. Všechny uvedené důvody zapříčinily prozatímní nedotaţení projektu do úspěšného konce. 73

75 Závěr, návrhy a doporučení Hlavním cílem této diplomové práce bylo objasnění a porovnání teorie řízení projektu v národní firmě versus praxe na reálném projektu. Jako odborný garant (člen projektového týmu) projektu nasazení autentizačního celopodnikového systému OpenSSO ve společnosti s celostátní působností jsem spolupracoval na vývoji a průběhu projektu. Osobně jsem navrhl a zrealizoval zátěţové testování aplikace s akceptačními testy. Taktéţ jsem provedl analýzu a vyhotovil provozní akceptační řízení systému pro předání aplikace do rutinního provozu se závěrečným doporučením v současnosti nepřebírat systém do provozu. V závěru práce bych chtěl zhodnotit postup celého projektu a navrhnout kroky k zefektivnění procesu řízení projektů ve společnosti. V realizovaném projektu jsem identifikoval několik výše uvedených problémových oblastí, nebojím se říci kritických míst projektu. Jednou z nejváţnějších mnou objevených neshod je končící podpora produktu Sun OpenSSO (do konce roku 2014). Tento problém vrhá stín na pozdější ţivotaschopnost nově spuštěného systému. Bez oficiální firemní podpory bude velmi nákladné udrţovat zabezpečený systém v běhu a zajistit pro aplikaci externí servisní smlouvu 24/7. Rozhodnutí o dalším směřování projektu je teď v rukou firemního top managementu ICT. Mezi další závaţné lokalizované závady lze také zařadit chybějící penetrační testy s bezpečnostní shodou systému, nekompletní dopracování - nastavení systému v záloţním centru a nepřesná nebo chybějící provozní dokumentace. Všechny tyto zjištěné problémy brání v současné době převzetí systému OpenSSO do rutinního provozu. Samostatnou a neméně závaţnou kapitolou jsou mé postřehy k řízení projektů v národní společnosti. Pokud si poloţíme otázku Jak je teorie řízení projektů uplatňována v praxi?, lze pouze konstatovat, ţe uplatňování teorie v praxi v naší organizaci je velmi tristní. Z mé účasti na projektu vyplynulo, ţe v podniku neexistuje jedno centralizované oddělení zabývající se řízením celopodnikových projektů ICT. Proto mé doporučení zní, vytvořit novou podnikovou strukturu, v níţ by vznikl jediný odbor řízení projektů a změn se specializací na ITC projekty. Ve světle toho zjištění vyplynulo, ţe chybí jednotná metodika projektového řízení. V kaţdém oddělení, v němţ je zaměstnán specialista projektového řízení, jsou projekty řízeny podle jeho vlastní metodiky (pokud nějaká vůbec existuje). Můj návrh zní - vybrat a aplikovat jednotnou 74

76 metodiku projektového řízení pro všechny firemní úseky. Není nutné striktně implementovat vybranou metodiku, ale vytvořit logickou metodiku projektového řízení, která bude mít podporu jak formální, tak neformální všemi řídícími strukturami společnosti. Dalším logickým návazným krokem by mělo být proškolení projektových specialistů v implementované metodice řízení projektů. Na základě mnou navrţených změn k odstranění identifikovaných nedostatků je moţné efektivně uspořit nejen čas strávený na projektech, ale i další firemní zdroje. V případě aplikace doporučených řešení by společnost mohla ušetřit nejen nemalé finanční prostředky, ale také psychiku svých zaměstnanců, kteří by nebyli vystavováni zbytečnému stresu. 75

77 Seznam použité literatury Bibliografie: [1] ROSENAU, Milton D. Řízení projektů. 3. vyd. Brno: Computer Press, 2007, x, 344 s. Business books. ISBN [2] NĚMEC, Vladimír. Projektový management. 1. vyd. Praha: Grada, 2002, 182 s. ISBN [3] FIALA, Petr. Řízení projektů. 1. vyd. Praha: Economica, 2002, 174 s. ISBN [4] SVOZILOVÁ, Alena. Projektový management. 1. vyd. Praha: Grada, 2006, 353 s. ISBN [5] DOLEŢAL, Jan, Pavel MÁCHAL a Branislav LACKO. Projektový management podle IPMA. 1. vyd. Praha: Grada, 2009, 507 s. Expert (Grada). ISBN [6] BARKER, Stehen COLE, Rob. Projektový management pro praxi. 1. vyd. Praha: Grada Publishing, a.s s. ISBN [7] SCHWALBE, Kathy. Řízení projektů v IT. 1. vyd. Překlad David Krásenský. Brno: Computer Press, 2007, 720 s. ISBN [8] POSNER, Keith a Michael APPLEGARTH. Projektový management: [příručka rad, metod a nástrojů pro vedoucí a členy týmů, kteří chtějí dobře a efektivně zvládat své úkoly a povinnosti]. 1. vyd. Praha: Portál, 2006, 111 s. Management do kapsy, 7. ISBN [9] PRINCE2, Best Management Practice. Managing successful projects with PRINCE2. 5th ed. London: TSO, 2009, 210 s. ISBN [10] PROJECT MANAGEMENT INSTITUTE. A guide to the project management body of knowledge (PMBOK guide). 5th ed. Newtown Square: Project management institute, 2013, 589 s. ISBN

78 Další zdroje: [11] ČSN ISO ed.2: Systémy managementu jakosti Směrnice pro management jakosti projektů. Praha: Úřad pro technickou normalizaci, metrologii a státní zkušebnictví, [12] PwC. Poradenské služby: 10 nejčastějších chyb při řízení projektu. Praha, [13] ČESKÁ POŠTA, s.p. Administrátorská provozní dokumentace. Praha, [14] AMI a.s. Metodika a migrace LDAP a AM. Praha [15] ČESKÁ POŠTA, s.p. Akceptace IS do provozu. Praha, Elektronické zdroje: [16] SIEGELAUB, M. Jay. How PRINCE2 can complement PMBOK and your PMP [online] Dostupné z WWW: [17] Česká pošta, s.p. [online]. [cit ]. Dostupné z: [18] Český telekomunikační úřad [online]. [cit ]. Dostupné z: [19] Sun OpenSSO Enterprise 8.0 [online]. 2013[cit ]. Dostupné z: [20] JIRA plánování práce a řízení projektů. [online] [cit ]. Dostupné z: [21] Sun GlassFish Enterprise Server 2.1 [online]. 2013[cit ]. Dostupné z: [22] Oracle. Primavera Enterprise Project Portfolio Management [online] [cit ]. Dostupné z: [23] CA Technologies. CA Clarity PPM [online] [cit ]. Dostupné z: [24] ProjectLibre [online]. [cit ]. Dostupné z: 77

79 Seznam zkratek Zkratka ITS HW SW CPM MPM PERT IdM AIM CA CAS LDAP HTTP HTTPS SSH FTP CPU SAML API ICT URL AM SSO VU Vysvětlení Informační a technologické systémy Hardware Software Critical Path Method Metra Potential Method Program Evaluation and Review Technique Identity Management řešení Access and Identity Management, tzn. Access Management řešení a Identity Management řešení Certifikační autorita externí uţivatelé Certifikační autorita interní uţivatelé Lightweight Directory Access Protocol Hypertext Transfer Protocol Hypertext Transfer Protocol Secure Secure Shell File Transfer Protocol Central Processing Unit Security Assertion Markup Language Application Programming Interface Information and Communication Technologies Uniform Resource Locator - definice doménové adresy serveru Access Management Single-sign-on Virtuální uţivatel 78

80 Seznam grafů Graf 1: Počet vyřízených poţadavků za sekundu (zdroj: vlastní - vygenerováno v JMeteru). 61 Graf 2: Počet vyřízených poţadavků za sekundu systémem OpenSSO (Thread Group * 2 = celkový počet vláken; 4500 * 2 = 9000) (zdroj: vlastní - vygenerováno v JMeteru) Graf 3: Vytíţení CPU serverů OpenSSO a navazujících serverů LDAP (zdroj: vlastní - vygenerováno v JMeteru)

81 Seznam tabulek Tabulka 1: Hardware a software testovacího a vývojového prostředí (zdroj APD; upraveno autorem) Tabulka 2: Seznam HW a SW produkčního prostředí OpenSSO (zdroj APD; upraveno autorem) Tabulka 3: Zabezpečení komunikace (zdroj APD; upraveno autorem)

82 Seznam obrázků Obrázek 1: Projektový trojúhelník - Trojimperativ (zdroj: Fiala) Obrázek 2: Fáze projektu podle Němce Obrázek 3: Logo společnosti (zdroj: Česká pošta, s.p.) Obrázek 4: Diagram procesu přihlášení OpenSSO (zdroj: Oracle upraveno autorem) Obrázek 5: Schéma zapojení OpenSSO (zdroj: Oracle upraveno autorem) Obrázek 6: Vývojové a testovací prostředí (zdroj: vlastní) Obrázek 7: Obecné schéma architektury OpenSSO (zdroj: vlastní) Obrázek 8: Architektura produkčního prostředí OpenSSO (zdroj: vlastní) Obrázek 9: Apache JMeter verze 2.8 s otevřeným skriptem pro testování OpenSSO (zdroj: vlastní) Obrázek 10: Produkční prostředí OpenSSO zatěţovaného systému, fyzická architektura (zdroj: vlastní) Obrázek 11: Architektura zátěţového testu OpenSSO (zdroj: vlastní) Obrázek 12: Akceptační testování OpenSSO login (zdroj: firemní intranet) Obrázek 13: Akceptační testování OpenSSO - chyba přihlášení (zdroj: firemní intranet) Obrázek 14: Schéma procesu provozního akceptačního řízení ve společnosti (zdroj: vlastní) 67 81

83 Přílohy Příloha č. 1 Náhled Ganttova diagramu projektu OpenSSO. 82