Vysoká škola ekonomická v Praze

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií

Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie

Diplomant: Bc. Klárka Hvězdová Vedoucí diplomové práce: Ing. Tomáš Bruckner, Ph.D. Recenzent: Ing. Petr Venclík

INTEGRACE PORTÁLU B2E VE FIRMĚ ŠKODA AUTO A.S.

školní rok 2006/2007

Klárka Hvězdová

Integrace portálu B2E ve firmě Škoda Auto a.s.

Poděkování

Ráda bych poděkovala vedoucímu práce Ing. Tomáši Brucknerovi, Ph.D. za velmi praktické a podnětné rady. Zároveň bych chtěla poděkovat svému muži Ing. Ondřeji Švábovi za pomoc při tvorbě obrázků a formátování výsledného dokumentu.

-2-

Klárka Hvězdová


Prohlášení

Prohlašuji, že jsem diplomovou práci zpracovala samostatně a že jsem uvedla všechny použité prameny a literaturu, ze kterých jsem čerpala.

V Praze dne

………………………………. podpis

-3-

Klárka Hvězdová


Abstrakt Cílem práce je detailní zmapování etapy analýzy projektu integrace portálu B2E ve firmě Škoda Auto a.s. V práci jsou také srovnány postupy uplatňované při projektu s obecnými metodickými návody. Následně jsou obecné návody přizpůsobeny podmínkám projektu běžícího ve velké společnosti s velkým počtem budoucích uživatelů. Hlavním cílem práce však bylo vytvoření sady klíčových pravidel, která zohledňují specifika velkého projektového okolí. Výsledků práce bylo dosaženo aktivním zapojením v projektu Portálu B2E. Autor sám byl účastníkem projektu, podílel se na analýze projektu a výsledné zkušenosti jsou spolu s teoretickými znalostmi analyzovány a rozebrány v této práci. Práce přináší unikátní pohled na kategorizaci projektů ne pouze podle tradičních kritérií důležitosti projektu a počtu členů projektového týmu. V celé práci je prakticky ukázáno, že při kategorizaci projektu je zcela zásadní také kritérium velikosti projektového okolí. Projektovým okolím je myšlen počet budoucích uživatelů, počet hardwarových a softwarových prostředků, kterých se řešení dotkne, počet lidí zasahujících do projektu shora a další. První tři kapitoly práce postupně objasňují současnou situaci ve firmě, analýzu nového řešení a způsob řízení celého projektu. Ve všech těchto kapitolách jsou skutečné postupy projektu doplněny o komentáře a hodnocení s přihlédnutím k teoretickým návodům metodik pro systémovou integraci. V závěrečné kapitole Sada klíčových pravidel jsou načerpané poznatky shrnuty a převedeny do třinácti pravidel, která jsou doporučena k obohacení stávajících metodik v případě projektů s velkým projektovým okolím. Zde ukázaná pravidla by měla výrazně přispět ke zvýšení pravděpodobnosti úspěšnosti projektů.

-4-

Klárka Hvězdová


Abstract Subject of this diploma work is detailed mapping of analytic phase of project portal B2E integration at Škoda Auto a.s. This work also compares project procedures including general guidelines. These general guidelines are then customized to the conditions of a project in the environment of a large company with large number of users. The primary objective of this work was to develop a set of key rules which will take into account the specifics of the project’s vast environment. Results of this work have been achieved through to active participation of the author at the project of portal integration. The author has been involved in the project, participated in the analytic phase and the resulting experience along with theoretic knowledge has been analyzed in this work. This work brings a unique view at categorization of projects not only according to traditional criteria of project importance and number of project team members. The whole work demonstrates in very practical way that the scale of the project’s environment is another very important criterion of project categorization. By the project environment is meant the number of future users, number of hardware and software devices affected by the project, number of leader-persons who could change the course of the project etc. First three chapters deal with the existing situation at the company, the analysis of the new solution and methods of managing the project. In these three chapters, real working procedures are completed with comments and assessments with regard to formal guidelines for system integration. The last chapter summarizes experience and knowledge acquired during the project to thirteen rules which are recommended to enhance existing methodologies used for projects implemented in vast environment. The rules demonstrated here should contribute considerably to increased likelihood of a project’s success.

-5-

Klárka Hvězdová


Obsah Úvod ...........................................................................................................................................9 1

Intranet ve ŠKODA AUTO a.s. ......................................................................................11 1.1 Současný stav intranetu ve ŠKODA AUTO a.s. .........................................................11 1.1.1

HomePage............................................................................................................12

1.1.2

Stránky oddělení ..................................................................................................13

1.1.3

Aplikace ...............................................................................................................14

1.2 Proč změna k B2E.........................................................................................................14 1.3 Shrnutí 2

......................................................................................................................21

Analýza projektu..............................................................................................................24 2.1 Ujasnění požadavků na systém .....................................................................................24 2.1.1

Dotazníky uživatelům ..........................................................................................26

2.1.2

Dotazník na autory obsahu ..................................................................................28

2.2 Technologie ..................................................................................................................29 2.2.1

Kontextový diagram ............................................................................................30

2.2.2

Single Sign-On (SSO)..........................................................................................31

2.2.3

Systém pro správu uživatelů ................................................................................32

2.2.4

Požadovaná platforma..........................................................................................32

2.3 Struktura portálu ...........................................................................................................33 2.3.1

Uživatelské role ...................................................................................................33

2.3.2

Procesy.................................................................................................................34

2.4 Funkční model ..............................................................................................................34 2.4.1

Standardní portálové funkce ................................................................................34

2.4.2

Management obsahu ............................................................................................34

2.4.3

Správa dokumentů ...............................................................................................36

2.4.4

Struktura zobrazovaných portletů ........................................................................36

2.5 Uživatelské rozhraní .....................................................................................................38 2.6 Portálové rozhraní.........................................................................................................39 2.7 Aplikace vybrané pro prototyp a pilotní fázi ................................................................40 2.7.1

TRAM..................................................................................................................40

-6-

Klárka Hvězdová


2.7.2

IDIS......................................................................................................................41

2.7.3

Telefonní seznam.................................................................................................41

2.7.4

Jídelníček .............................................................................................................41

2.7.5

Organizační struktura...........................................................................................41

2.7.6

Moji lidé...............................................................................................................42

2.8 Bezpečnost ....................................................................................................................43 2.8.1

Bezpečnost platformy ..........................................................................................43

2.8.2

Autentizace ..........................................................................................................43

2.8.3

Autorizace............................................................................................................43

2.8.4

Komunikační kanály ............................................................................................44

2.8.5

DMZ (Demilitarizovaná zóna).............................................................................44

2.8.6

Životnost relace (Session Lifetime) .....................................................................45

2.8.7

Záloha a obnova systému.....................................................................................45

2.8.8

Specifická omezení ..............................................................................................45

2.9 Shrnutí 3

......................................................................................................................45

Řízení projektu.................................................................................................................48 3.1 Metodika SEP ...............................................................................................................48 3.1.1

Cíle metodiky SEP...............................................................................................50

3.1.2

Vývojové směry metodiky SEP...........................................................................51

3.1.3

Fáze metodiky SEP..............................................................................................51

3.2 Zdroje projektu .............................................................................................................53 3.2.1

Finanční zdroje ....................................................................................................54

3.2.2

Lidské zdroje........................................................................................................56

3.2.3

Řídící tým ............................................................................................................57

3.3 Časové hledisko projektu..............................................................................................59 3.3.1

Důležité milníky projektu ....................................................................................61

3.4 Dokumentace projektu..................................................................................................62 3.4.1

Business Blue Print (Portál).................................................................................64

3.4.2

Komponenta SSO ................................................................................................64

3.4.3

Standardy .............................................................................................................65

3.4.4

Aplikace ...............................................................................................................65

3.4.5

Doplňující dokumenty .........................................................................................65

3.4.6

Zdrojové dokumenty............................................................................................67

3.5 Záruky kvality...............................................................................................................69 3.6 Shrnutí

......................................................................................................................70

-7-

Klárka Hvězdová

4


Sada klíčových pravidel...................................................................................................71 4.1 Sada klíčových pravidel pro řízení projektů s velkým projektovým okolím přehled ..................................................................................................................................71 4.2 Sada klíčových pravidel pro řízení projektů s velkým projektovým okolím detail......................................................................................................................................72 4.2.1

Lidé ......................................................................................................................72

4.2.2

Časová náročnost projektu...................................................................................72

4.2.3

Správa multiprojektového prostředí.....................................................................73

4.2.4

Pořádek v integrované oblasti..............................................................................76

4.2.5

Spolupráce s budoucími uživateli ........................................................................77

4.2.6

Projektový paradox ..............................................................................................77

4.2.7

Management obsahu interního portálu ................................................................77

4.2.8

Organizační struktura...........................................................................................78

4.2.9

Dynamické nastavování osobního portálového prostředí....................................78

4.2.10 Terminologie........................................................................................................78 4.2.11 Životnost relace (Session Lifetime) .....................................................................79 4.2.12 Lidské zdroje........................................................................................................79 4.2.13 Projektová dokumentace......................................................................................79 Závěr .........................................................................................................................................80 Literatura:..................................................................................................................................82 Slovník použitých termínů a zkratek ........................................................................................84 Slovník zmiňovaných technologií a produktů ..........................................................................95 Příloha 1 – Specifikace činnosti zmíněných oddělení ..............................................................98 Příloha 2 – Plánování jednotlivých fází projektu....................................................................100

-8-

Klárka Hvězdová


Úvod Práce mapuje část analýzy projektu zavedení portálu B2E1 ve firmě ŠKODA AUTO a.s. Zaměřuje se na specifika systémové integrace ve velké společnosti, která je jak z technologického hlediska, tak z metodického hlediska svázána koncernovými standardy. Na druhou stranu ale podnik díky koncernovým partnerům získává přístup k již hotovým řešením. Tato řešení může společnost buď za výhodných podmínek přejmout a snadněji implementovat ve svém prostředí nebo přímo využívat kapacity partnera (běžící aplikace, hardware a další) prostřednictvím webových služeb a přenosových linek. V práci je zároveň podrobně rozebrán i přístup řízení projektů a některá jeho specifika ve velké firmě s velkým počtem uživatelů budoucího řešení a velkým počtem členů projektového týmu. Portál B2E má ve firmě ŠKODA AUTO a.s. nahradit stávající verzi intranetu a stát se rozcestníkem, ze kterého budou mít zaměstnanci přístup ke všem nutným informacím a do všech potřebných aplikací. Portál se tak má stát úložištěm veškerých služeb, které mohou zaměstnanci potřebovat. Jedná se tedy o jakýsi sjednocující integrační prvek, pomocí kterého budou zaměstnanci přistupovat k dalším systémům. Téma je zvoleno s ohledem na fáze projektu, kterých měl autor možnost se zúčastnit. Projekt B2E byl zahájen v lednu 2005 a předpokládaný konec je odhadován na březen 2007. Projekt se tedy nachází v ideálním stadiu dovolujícím jak zmapování minulých etap, tak rozbor zajímavých a stěžejních etap analýzy. Práce si klade za cíl zmapování průběhů etap analýzy skutečného projektu systémové integrace a případné srovnání s metodikami používanými k systémové integraci. Zároveň se práce snaží konkretizovat obecné metodické návody a přizpůsobit je co nejvíce situaci projektu B2E (velký projekt, velký projektový tým). Odvážným a možná trochu troufalým cílem práce je sjednocení praktických zkušeností z průběhu reálného projektu s teoretickými návody metodik pro systémovou integraci a vytvoření sady klíčových pravidel, která jsou v současném projektovém řízení opomíjena a nedoceňována. Výsledná sada klíčových pravidel určených pro problematiku řízení

1

Business to employee.

-9-

Klárka Hvězdová


velkých projektů s velkým projektovým okolím obohacuje a doplňuje stávající návody, vzory a metodiky. Vzniklá sada klíčových pravidel by měla výrazně přispět ke zvýšení úspěšnosti projektového řízení ve velkých firmách. Pro dokonalý přístup k informacím je nezbytně nutné začlenit se určitým způsobem do probíhajícího projektu. Společnost ŠKODA AUTO a.s. nabízí pro tuto potřebu ideální pracovní pozici, pozici „diplomant“. Diplomant se částí svého pracovního času věnuje samotnému projektu a část času věnuje sepisování diplomové práce. Na druhou stranu i přes výhodný přístup ke zdroji informací nese práce jistá omezení. Ta vyplývají jednak z obecných omezení diplomové práce, jako jsou nedostatečná praxe či teoretické znalosti studenta. Zároveň však musíme brát v potaz, že podílení se jen na části projektu přináší určitá zkreslení ohledně mapování již proběhlých fází a ohledně celkového firemního kontextu projektu. Práce přináší ucelený pohled na problematiku integrace portálového řešení. Portálové řešení se v mnoha podnicích stává hlavním komunikačním a integračním prostředkem firmy, a to jak v rovině internetových prezentací, tak v rovině interní komunikace. Integrace tohoto systému proto velmi závažně ovlivňuje chod především nevýrobních procesů společnosti. Vedle systémů pro řízení vztahů se zákazníky, partnery a dodavatelským řetězcem se do popředí zájmu dostávají i systémy řídící interní komunikaci. Komunikace uvnitř firmy následně předurčuje i celkovou úspěšnost firmy na trhu. Není tedy pochyb o tom, že uspokojivé vypořádání se s tímto zadáním má velký přínos pro každou společnost. Materiál je určen pro všechny IT odborníky, kteří zavádějí nebo se chystají zavést portálové řešení. Přináší praktické zkušenosti, záludnosti a jiné těžkosti provázející integrační projekt. Čtenář se tak může vyvarovat některých chybných postupů a naopak využít fungujících schémat a doporučení. Zároveň práce naznačuje i obecné, často opakované chyby z oblasti projektového řízení, které mají klíčový dopad na budoucí úspěšnost či neúspěšnost projektu. Z hlediska řízení projektů přináší práce nový pohled na některé zažité postupy a vytyčuje nové a zásadní kritické faktory úspěšnosti projektů. Z tohoto pohledu je práce vhodná pro všechny pracovníky firem uplatňujících projektové řízení.

-10-

Klárka Hvězdová


1 Intranet ve ŠKODA AUTO a.s. Tato kapitola naznačuje souvislosti ospravedlňující projekt portálu B2E. U každého projektu je nutné se ještě před prvotními počátečními přípravnými pracemi zastavit a určit si následující: •

jaká je současná situace problémové oblasti v naší firmě

•

jaké je naše plánované řešení

•

a nejdůležitější – jaké přínosy přinese naše řešení celé firmě. Především třetí bod je velmi zásadní a není výjimkou, že se v praxi setkáváme

s projekty, které jsou perfektně naplánovány, dojdou zdárného konce a přesto je jejich přidaná hodnota pro podnik jako takový nulová. Mohou to být především inovativní projekty aktivního IT oddělení, které prahne po technologických novinkách a umí je před představenstvem náležitě vychválit a zdůvodnit jejich nasazení v podniku. Kolikrát se ale stane, že jsou tyto žhavé novinky pro firmu nadbytečné, a že se starým řešením podnik dosahoval stejných zisků jako po zavedení nového systému. Podobným problémem může být i úřednický syndrom, kdy manager posuzuje svoji vlastní úspěšnost podle počtu podřízených, podle množství spravovaných aplikací či podle počtu běžících projektů. Právě tato snaha může vést některé managery k rozběhnutí projektů, které nejsou organizovány v zájmu dobra firmy, ale v osobním zájmu daného managera. Následující řádky se snaží odpovědět na tři výše zmíněné otázky. 1.1

Současný stav intranetu ve ŠKODA AUTO a.s.

Společnost Škoda Auto a.s. v rámci svých informačních zdrojů využívá intranet k zajištění publikování důležitých interních informací a jejich sdílení mezi jednotlivými útvary. Za tímto účelem je na vnitřní síti zřízen server intranetu, kam jednotlivé útvary umísťují své prezentace. Tyto prezentace mají být informačního charakteru a mají obsahovat důležité informace o práci daných útvarů. Dále jsou na intranetu zveřejněny výstupy z některých aplikací. HomePage intranetu je spravována zvláštním oddělením a zpřístupňuje informace z různých i externích zdrojů. Počet uživatelů vnitřní sítě (tudíž i uživatelů intranetu) je přibližně sedm tisíc lidí, počítá se s nárůstem uživatelů až k deseti tisícům lidí.

-11-

Klárka Hvězdová

1.1.1


HomePage

Zaměřme se na tyto funkční prvky HomePage: •

Rolovací menu s výběrem jednotlivých oddělení

•

Report z informačních systémů

•

Vyhledávání

•

Novinky z intranetu

•

Výběr z tisku

•

Zpřístupněný intranet

•

Jídelní lístek

•

Aktuální počasí

Rolovací menu s výběrem jednotlivých oddělení

Jednoduché rolovací menu, které neobsahuje žádnou hierarchičnost zobrazovaných oddělení. Umístěno v pravé části horní lišty. Odkazuje čtenáře na stránky příslušného oddělení. Report z informačních systémů

Ručně vkládaná informace o stavu sledovaných informačních systémů. Např.: „Všechny sledované systému fungují bez omezení.“ Umístěn v horní centrální části. Vyhledávání

Vyhledávání ve firemním telefonním seznamu. Výstupem je tabulka všech zaměstnanců zadaného příjmení s kontaktními údaji. Jedna z nejpoužívanějších aplikací intranetu. Nepodporuje vyhledávání zahraničních koncernových partnerů, přestože ve firmě ŠKODA AUTO a.s. podobná aplikace existuje. Novinky z intranetu

Zde se zobrazují informace, které jednotlivá oddělení publikují na svých stránkách jako novinky.

-12-

Klárka Hvězdová


Výběr z tisku

Tato část HomePage je dodávána externí firmou a zobrazuje výběr z tuzemského tisku s tématikou automobilového průmyslu. Zpřístupněný intranet

Statický obsah internetových zdrojů, které jsou přístupné všem uživatelům sítě ŠKODA AUTO a.s. (včetně uživatelů, kteří nemají Internet jako takový zpřístupněn). Obsahuje www stránky firmy ŠKODA AUTO a.s., stránky města Mladá Boleslav, kulturní přehledy apod. Jídelní lístek

Obsah, v podobě přehledné tabulky, dodávaný externí firmou, která jednou týdně ručně mění menu jídelního lístku. Jedna z nejpoužívanějších informací intranetu. Aktuální počasí

Výstup z aplikace, která shromažďuje hydrometeorologické a energetické údaje z oblasti závodu. 1.1.2

Stránky oddělení

Proces publikování v současnosti probíhá následovně: •

Každé oddělení určí zodpovědné osoby (redaktory), kteří pracují na vývoji stránek pro své oddělení.

•

Redaktoři jsou proškoleni v programu FrontPage a je jim přidělen přístup do adresáře daného oddělení na pracovní vývojový server (obsah tohoto serveru není nikde zveřejněn).

•

Při změně obsahu adresáře daného oddělení na pracovním serveru redaktor emailem upozorní administrátora intranetového serveru na nutnost aktualizace příslušného adresáře.

•

Administrátor po pracovní době (redaktoři navzájem nemusí vědět o souběžných úpravách stejného adresáře) zkopíruje obsah pracovního serveru na server intranetu, tím dochází ke zveřejnění změněného obsahu.

Redaktoři mají definovány jen obecné požadavky na obsah a technické aspekty prezentací. Stránky musí obsahovat:

-13-

Klárka Hvězdová


•

informace o náplni práce oddělení

•

odkazy na organizačně podřízená oddělení spolu se základními informacemi o podřízených odděleních

•

jméno a kontakt na redaktory

•

datum poslední aktualizace

1.1.3

Aplikace

V současné době je ve firmě ŠKODA AUTO a.s. v provozu asi stovka aplikací [ša4]. Evidence aplikací je velmi problematická až skoro nemožná a to z důvodu nejednotné správy veškerých aplikací. Některé aplikace jsou provozovány centrálně pro interní zákazníky firmy, ale většinu aplikací spravuje oddělení, které příslušnou aplikaci navrhlo, vytvořilo a zprovoznilo. Tudíž je dohledání konečného čísla počtu aplikací prakticky nemožné. Co se týče přístupnosti aplikací. Některé aplikace jsou přístupné už přes současný intranet. Jiné aplikace jsou čistě majetkem daných oddělení a tedy na intranetu absolutně nezávislé. S nasazením nového intranetu se počítá s těmito kroky: •

Převedení některých současných intranetových aplikací na nový portál B2E

•

Zpřístupnění některých současných aplikací pomocí portálu

•

Zpřístupnění některých současných aplikací pouze pomocí odkazu na portálu (odkaz spustí samostatně běžící aplikaci mimo portálové prostředí)

•

Ponechání některých aplikací v současném stavu bez jakéhokoli začlenění do portálu

• 1.2

Ukončení provozu některých aplikací Proč změna k B2E

Z výše popsaného je na první pohled zřejmé, že současný stav nemůže vyhovovat ani formálním kritériím společnosti ani věcným požadavkům uživatelů [ša1], [ša2], [ša7]. Nejvýraznějšími nedostatky jsou následující aspekty. Z důvodu nesourodosti celého obsahu publikovaných informací dochází ke špatné orientaci uživatele. Stejná informace je na stránkách různých oddělení

-14-

Klárka Hvězdová


publikována na jiném místě, v jiné struktuře a s jiným grafickým zpracováním. Uživatel tak hledáním potřebných informací ztrácí mnoho času, někdy požadovanou informaci nenalezne vůbec, na každé stránce se musí přizpůsobovat jiným pravidlům ovládání a zvykat si na jiné umístění navigace. Zároveň se publikované informace vymykají požadavkům a standardům společnosti. Některá oddělení zveřejňují informace, které absolutně odporují požadavkům firmy, ale dané oddělení je subjektivně hodnotí jako relevantní. Také vizuální stránka webových prezentací je ponechána na rozhodnutí jednotlivých odděleních a jejich redaktorů. Absolutně tak není dodržována jednotná firemní kultura, jejíž součástí je právě standardizovaný design interních i externích webových stránek. Intranet zároveň nepřináší žádné další možnosti současných informačních technologií. Nijak není podpořeno projektové řízení zejména s ohledem na funkci sdílení dokumentů, která není ve společnosti ŠKODA

AUTO a.s. vyřešena na

odpovídající úrovni ani na jiném místě. Pro podporu managementu chybí uživatelsky přehledné výstupy z mamutích systému jako je například SAP HR, které by přinesly velký plus pro rozhodovací procesy a ani další používané aplikace nejsou pomocí současného intranetu náležitě zpřístupněny. Hlavní příčiny zmíněných nedostatků současného intranetu jsou zřejmě tyto: nulová provázanost současných aplikací, nejednotný vzhled intranetu (částečně vychází z předešlého) a nedostatečné využití možností ICT technologií. Pro ilustraci následují CRT stromy poukazující na příčinné souvislosti mezi nedostatky současného intranetu.

-15-

Klárka Hvězdová


Špatný vztah zaměstnanců k vlastní organizaci

Oblíbené zapisování přístupových parametrů na post-it lístky

Uživatelsky nepříjemné pracovní prostředí

Ztráta

Zvýšené náklady

Někteří pracovníci sdělí své přístupové parametry jiným

Někteří pracovníci (např. sekretářka vedoucího) musí pracovat s daty, která nemají primárně přístupná

Nepřehledná a nejasná správa uživatelských rolí a oprávnění

Zvláštní specialisté pro každý systém

Mnoho uživatelských jmen a hesel Uživatel často přepíná mezi systémy

Aktuální stav business aplikací sdělován na intranetu

Pro vývoj aplikací nejsou definovány společné standardy

Nulová provázanost systémů

Obrázek 1: CRT nulové provázanosti aplikací v současném intranetu. [autor]

-16-

Klárka Hvězdová



Špatná podpora celopodnikových pravidel a konvencí

Uživatel je používáním intranetu znechucen

Uživatel nenajde hledanou informaci

Uživatel používáním intranetu ztrácí mnoho času

Špatná orientace uživatelů

Publikované informace neodpovídají požadavkům firmy

Uživatel si na každé stránce musí zvykat na jiné ovládání a jinou strukturu

Nejednotný vzhled intranetu

Obrázek 2: CRT nejednotného vzhledu současného intranetu. [autor]

-17-

Není dodržována jednotná firemní kultura a design

Klárka Hvězdová



Snížení konkurenceschopnosti podniku

Zvýšené náklady

Špatná komunikace uvnitř firmy

Špatná podpora rozhodovacích procesů managerů

Není podpořena správa a sdílení dokumentů

Chybí uživatelsky příjemné výstupy z ostatních systémů (např. SAP)

Intranet nepřináší možnosti současných ICT

Obrázek 3: CRT nevyužívání možností ICT v současném intranetu. [autor]

Z výše zmíněného vyplývají některé zásadní požadavky na nový portál B2E. Z designového hlediska by měl portál podporovat jednotné šablony pro tvorbu dílčích součástí intranetu. Tím se zabrání nejednotné struktuře publikovaných informací. Samozřejmostí by mělo být i automatické generování některých výstupů namísto dosavadních ručně upravovaných tabulek. Portál by měl také implementovat další nadstandardní funkce založené na samostatných aplikacích: Příkladem může být podpora projektového managementu. Především funkce sdílení informací a podpora řízení projektu (administrace úkolů, grafická prezentace návaznosti činností apod.). Další takovou nadstavbou intranetu by mohl být Document Management System, který by usnadňoval a zpřehledňoval správu, zveřejňování a sdílení dokumentů. Zároveň jsou na prostředí nového intranetu kladeny požadavky v potřebě unifikovaného prostředí pro přístup k dalším již fungujícím aplikacím. Možnosti

-18-

Klárka Hvězdová


zpřístupnění jednotlivých aplikací na portálu byly popsány výše. Portál musí také podporovat funkce elektronického workflow, který se ve firmě již používá, a celkově splňovat nároky procesního přístupu a SOA. Pro ilustraci přínosů současného portálu firmě Škoda Auto a.s. následují FRT stromy vyřešení stávajících problémů.

Dobrý vztah zaměstnanců k vlastní organizaci

Uživatelsky příjemné pracovní prostředí

Bezpečně chráněná data a přístupová oprávnění

Snížené náklady

Speciální přístupové požadavky řešeny na úrovni uživatelských skupin

Správa uživatelských oprávnění na úrovni uživatelských skupin Jedno uživatelské jméno a heslo

Společný HelpDesk pro všechny systémy

Uživatel se přihlásí do intranetu a tím získá přístup ke všem dalším systémům

Všechny systémy přístupné z intranetu

Obrázek 4: FRT provázaných aplikací přístupných z intranetu. [autor]

-19-

Přesně definované standardy pro vývoj nových aplikací

Klárka Hvězdová



Dobrá podpora celopodnikových pravidel a konvencí

Uživatel je používáním intranetu nadšen

Uživatel lehce nachází hledanou informaci

Publikované informace odpovídají požadavkům firmy

Intranet uživateli šetří čas a zpříjemňuje jeho práci

Snadná orientace uživatelů

Na každé stránce stejné ovládání a struktura

Jednotný vzhled intranetu

Obrázek 5: FRT jednotného vzhledu intranetu. [autor]

-20-

Je dodržována jednotná firemní kultura a design

Klárka Hvězdová



Zvýšení konkurenceschopnosti podniku

Snížení nákladů

Zlepšení komunikace uvnitř firmy

Velmi kvalitní a rychlá podpora rozhodovacích procesů managerů

Podpora sdílení a správy dokumentů

Uživatelsky příjemné výstupy z ostatních systémů (např. ze SAPu)

Intranet naplno využívá možností současných ICT

Obrázek 6: FRT využití možností současných ICT v intranetu. [autor]

Ze stromů budoucí reality je zřejmé, že největší přínosy může organizace zavedením portálu očekávat v oblasti zlepšení vztahů zaměstnanců k vlastní organizaci. Portál je budován tedy především pro zaměstnance, kterým má ulehčit, zpříjemnit a zjednodušit jejich každodenní práci. Zároveň ale v konečných důsledcích přináší portál i snížení nákladů a zvýšení konkurenceschopnosti podniku. A to už jsou hodnoty, na které business slyší a které se dají vyčíslit v nejoblíbenější jednotce všech metrik – v penězích. 1.3

Shrnutí

Kapitola nám přinesla odpovědi na základní otázky, které musí předcházet každému projektu ještě před zahájením fáze analýzy. Zodpovědět by se mělo především následující: jaká je současná situace, jaká je plánovaná situace a jaké jsou přínosy plánované situace pro firmu jako celek. Současný intranet má několik zásadních nedostatků. Předně intranet jako takový není provázán s dalšími systémy a aplikacemi. Uživatelé však tyto aplikace denně používají a jejich stav (aplikace xy funguje bez problémů/aplikace zy není dostupná) je sdělován právě na intranetových stránkách. Uživatel je tudíž nucen přecházet ze

-21-

Klárka Hvězdová


systému do systému, což znepříjemňuje jeho práci. Zároveň nulová provázanost běžících systémů a aplikací přináší nutnost ručního logování do každého systému zvlášť. Uživatelé pak vlastní mnoho hesel a uživatelských jmen. Což je za prvé nepříjemné a za druhé to často vede k zapisování přístupových parametrů na papírky nalepené na monitoru a následné ztrátě bezpečnosti. Další nevýhodou neprovázaných systémů je celková grafická i strukturální nejednotnost. Prakticky každá stránka intranetu má vlastní design, a to i přesto, že se jedná o stránky na stejné logické úrovni (např. stránka oddělení). To vede jednak k nerespektování firemních koncepcí a pravidel a jednak k matení uživatelů, kteří stejnou informaci (např. kontaktní údaj) nachází na stránkách různých oddělení na různých místech. Nezřídka uživatelé hledanou informaci nenalézají vůbec, protože není definován žádný povinný minimální obsah všech intranetových prezentací jednotlivých oddělení. Druhým zásadním nedostatkem současného intranetu je nevyužití možností současných ICT technologií. V dnešní době se dodavatelé předhánějí v nabídce nástrojů pro zlepšení vnitropodnikové komunikace, pro efektivní správu a sdílení dokumentů, pro snazší a jednodušší podporu řízení projektů a další. Je škoda alespoň některého z nejvíce postrádaných řešení (např. DMS) v tak velké firmě nevyužít. Co se týče plánovaného stavu, tak o řešení je víceméně rozhodnuto ještě před začátkem projektu. Portálové řešení se jeví jako ideální prostředek odstranění všech neduhů současného intranetu. A konkrétní dodavatel je dán koncernovými pravidly. Výběr byl tudíž jednoduchý: IBM WebSphere Portal, od kterého se očekává vyřešení současných problémů interních stránek. A jaké přínosy může od nasazení portálu očekávat firma jako celek? Především se dá počítat se zlepšením a zpříjemněním práce uživatelů informačních systémů ve firmě. To by mělo přispět k větší spokojenosti zaměstnanců a jejich loajalitě vůči vlastní organizaci. Jednotným přístupem do všech aplikací se dále zcela jistě zvýší bezpečnost přístupových procedur. Otázku snížení nákladů bych viděla až ve středně vzdálené budoucnosti (horizont 2 – 5 let). Ke snížení nákladů by totiž mělo dojít při vývoji nových aplikací, které budou mít již portálem přesně definované standardy a tím jednotné některé vyvíjené části. Dále by řešení mohlo přispět ke sjednocení podpory a správy jednotlivých aplikací, což může vést ke snížení nákladů, ale také nemusí.

-22-

Klárka Hvězdová


Nepřímo ovlivněné snížené náklady bych viděla spíš u zlepšení podpory rozhodovacích procesů vysokých managerů. Ti budou mít díky portálu k dispozici prakticky v reálném čase různé přehledy, výstupy jiných aplikací a reporty v přehledné a dobře strukturované formě, které jim napomůžou se lépe, rychleji a kvalifikovaněji rozhodovat. Tuto kapitolu musíme brát jako nedílnou součást procesu zmapování analýzy projektu Portál B2E. Zodpovězení těchto otázek je součástí správné a zodpovědné analýzy každého projektu. Bez vyřešení a vyjasnění současného stavu a bez důkladné analýzy očekávaných přínosů by neměl začínat žádný projekt.

-23-

Klárka Hvězdová


2 Analýza projektu Zmapování analýzy projektu integrace portálu je jeden z cílů definovaných v úvodu této práce. Do etap analýzy bychom podle metodiky MMDIS [Buchalcevová, 2005] mohli zařadit následující fáze: úvodní studie (UST), globální analýza a návrh (GAN), detailní analýza a návrh (DAN). I metodika SEP2 pokrývá tyto fáze, i když jednotlivé fáze nejsou striktně odděleny. Tato kapitola nám tedy přináší pohled, jakým způsobem proběhla analýza při integraci portálu ve firmě Škoda Auto. Zároveň je v kapitole poukázáno na některá problematická místa etap analýzy a zdůrazněny jsou pozitivní příklady z projektu. Vzhledem k pravidlům metodiky SEP proběhlo nejprve upravení obecných požadavků metodiky na konkrétní aspekty projektu (tailoring metodiky). Podle těchto konkrétních aspektů pak pokračoval celkový postup. 2.1

Ujasnění požadavků na systém

Stále ještě velké množství projektů vývoje informačních systémů krachuje, je dokončeno po termínu, nedodrží finanční hledisko projektu či jinak neodpovídá přáním zadavatele. Jedním z důvodů tohoto neutěšeného stavu je i nedostatečná spolupráce s budoucími uživateli vyvíjeného systému. Příčin těchto v zásadě komunikačních bariér je více. Důsledky jsou však vždy obdobné. Funkcionalita, uživatelské prostředí nebo jiné parametry systému se více či méně odlišují od potřeb uživatele. Uživatel má pak před sebou řešení, od kterého čekal ulehčení své práce, ale které mu v konečném výsledku nepřinese žádnou přidanou hodnotu a naopak do něj byly investovány nemalé prostředky. Především je důležité míti na paměti to, že uživatel je pro nás jedinečný a unikátní zdroj informací ohledně funkční a uživatelské specifikace vyvíjeného systému. Jedině člověk, který s danou problematikou dennodenně přichází do kontaktu a budoucí informační systém bude používat většinu svého pracovního času, nám může konkrétněji popsat, bez čeho se systém neobejde, co by v systému uvítal, co se v systému určitě nesmí objevit a co jsou nejvýraznější možná rizika a úskalí. Člověk z oboru si také

2

Koncernová metodika používaná ve společnosti Škoda Auto při vývoji IS. Blíže k metodice viz

kapitola 3.1 Metodika SEP.

-24-

Klárka Hvězdová


nejlépe uvědomí všechny potřebné odborné souvislosti, které je nutné systémem pokrýt a ošetřit. Informatik má pak kromě vývoje vlastního systému za úkol od uživatele tyto cenné zkušenosti, poznatky a informace získat. Tento předpoklad někdy naráží na problém najití společného jazyka. Pokud by požadavky na systém definoval informatik, bude se zřejmě vyjadřovat formou modelovacích jazyků, přesných grafů a jasných use-case diagramů. Oproti tomu formulace od uživatelů bývají vágní, nepřesné, velmi fuzzy a jen stěží použitelné jako specifikace systému. Uživatel také často vůbec nechápe, co po něm informatik vlastně požaduje. Nepochopení již v počátcích této vzájemné komunikace odsuzuje celý projekt k zániku již v úvodní etapě. Úlohou informatika v této etapě projektu je převést výraz „kontextový diagram“ do několika vět popisujících podstatu kontextového diagramu a opačným postupem porozumět uživatelovým vágním formulacím a převést je do jednoznačné řeči diagramů a modelů. Jedině tak se obě strany navzájem pochopí a může se naplno rozvinout oboustranná činorodá komunikace, která dává stabilní základ pro vznik kvalitního systému. Ve firmě ŠKODA AUTO a.s. byly požadavky na systém ze strany uživatelů zjišťovány následujícím způsobem. Uživatelům byly rozeslány dotazníky, které v první části obsahovaly stručný, ale jasně definovaný zamýšlený obsah spolu s funkcionalitou budoucího Portálu. V druhé části dotazníku bylo uživateli položeno přibližně deset otázek, které se různou formulací vět snažily zjistit prakticky totéž. Co Portál z pohledu toho kterého uživatele musí bezpodmínečně obsahovat, co by bylo příjemné, kdyby Portál obsahoval, co je nežádoucí apod. Uživatelům bylo jasně řečeno, že svoji invenci nemají podřizovat žádným finančním nebo technologickým omezením. Dotazování bylo naměřeno dvěmi směry, za prvé na uživatele, kteří jsou administrátory obsahu, a za druhé na uživatele, kteří jsou pouze čtenáři obsahu. Tím bylo získáno mnoho podnětných a cenných informací z obou stran portálového prostředí. Dotazování uživatelů proběhlo v projektu ukázkově. Jak vyplývá z níže uvedeného rozboru, dotazníky přinesly jasné a relevantní odpovědi, které nasazení portálu výrazně obohatí a snad výraznou měrou přispějí ke spokojenosti budoucích uživatelů a celkově příjemné práci s interním portálem. Za povšimnutí stojí i zajímavost zohledňující zkušenosti s ohromným množstvím zúčastněných uživatelů. Prostor pro vyjádření všech zájemců byl poskytnut pouze v úvodní části analýzy. Po sesbírání

-25-

Klárka Hvězdová


množství připomínek byl vyhlášen „stop stav“, který nepřipouštěl další náměty ze strany uživatelů. Tím bylo zabráněno nezvládnutelné situaci, kdy by se denně rojily další a další připomínky a návrhy uživatelů. Další požadavky na změny byly povoleny pouze vybranému okruhu uživatelů, kteří měli spolu se členy projektového týmu možnost formou change managementu zadávat požadavky a návrhy na změny. Tento model fungoval výborně.

Obrázek 7: "stop stav" námětů uživatelů. [autor]

2.1.1

Dotazníky uživatelům

Na dotazník odpovědělo 243 uživatelů [ša1]. Z jejich odpovědí mimo jiné vyplynulo, že práci s intranetovými stránkami věnují měsíčně v průměru 14,5 hodiny, což je číslo relativně vysoké. Níže jsou vypsány další důležité poznatky stran uživatelů. Jako první jsou zmíněny nejzávažnější informace, směrem dolů priorita požadavků klesá. Informace, které by portál určitě měl obsahovat

•

Kontaktní informace všech zaměstnanců

•

Informace o zaměstnancích odpovědných za určitou činnost

•

Organizační struktura útvaru

•

Pracovní náplň a další informace o útvaru

-26-

Klárka Hvězdová


•

Služby poskytované jiným útvarům

•

Předpisy, normy, pokyny a formuláře

•

Informace specifické pro každý útvar (např. útvar zodpovědný za služební auta zde má uvedeny termíny zkoušek vozů apod.)

Největší problémy současného intranetu

•

Nedostatečná aktualizace

•

Nepřehlednost a nesrozumitelnost stránek

•

Špatná struktura a logika stránek

•

Nejednotnost stránek (jak nejednotnost v rámci jednoho útvaru, tak nejednotnost mezi webovými prezentacemi různých útvarů)

•

Nefunkčnost odkazů

•

Není definován povinný minimální obsah stránek

•

Vyhledávání

•

V kontaktních údajích nejsou zahrnuta čísla služebních mobilních telefonů

•

Chybí uvedení celých jmen útvarů (jsou uvedeny pouze zkratky)

•

Chybí stručný popis útvaru

•

Chybí seznam služeb, které jednotlivé útvary poskytují

Závěry

Z průzkumu zřetelně vyplynulo, že nejdůležitější a nejpřínosnější jsou pro většinu uživatelů standardní informace o jednotlivých odděleních, jako kontaktní údaje zaměstnanců, informace o útvaru a organizační struktuře útvaru a další. Jako zásadní jsou také považovány odkazy na formuláře a

žádosti, které jsou ve velké firmě

používány téměř denně (ne-li několikrát za den), takže jejich zpřehlednění a lepší dostupnost ušetří zaměstnancům mnoho času. Analýzou dotazníků byly formulovány některé další zásadní body, jejichž splnění bude Portál vyžadovat: •

Pevné zakotvení výše zmíněných informací ve struktuře budoucích stránek

•

Určení standardního (neměnného) umístění daných informací v rámci navigace

-27-

Klárka Hvězdová


•

Přesné definování povinného minimálního obsahu stránek oddělení

•

Povinnost autorů stránek vkládat všechny specifikované informace a včas je aktualizovat

•

Použití automatizovaného systému pro správu obsahu (odpadnou problémy s nefunkčností odkazů, nepřehledností a nejednotností stránek)

•

Povinnost autorů stránek udržovat veškeré informace aktuální (zastaralé a neaktuální informace uživatele značně matou a odrazují od dalšího používání stránek)

•

Fulltextové prohledávání všech intranetových stránek, s volitelným omezením na určitý útvar či typ dokumentu

• 2.1.2

Zahrnout do kontaktních údajů i čísla na služební mobilní telefony Dotazník na autory obsahu

Na dotazník odpovědělo 108 zaměstnanců [ša2] zabývajících se tvorbou obsahu intranetových stránek. Ve všech případech je pro ně administrace obsahu intranetu jenom vedlejší činností. Vytvářením a správou se zabývají v průměru 4 hodiny měsíčně. Informace, které by portál určitě měl obsahovat

•

Základní informace o oddělení

•

Organizační strukturu oddělení

•

Kontaktní údaje zaměstnanců daného oddělení

•

Funkci, působnost a konkrétní činnost přiřadit konkrétním zaměstnancům

•

Formuláře a dokumenty ke stažení

•

Aktuální informace

Největší problémy současného intranetu

•

Nesnadná aktualizace stránek (časová náročnost aktualizace může autory odrazovat od přidávání aktuálních informací) (viz Kapitola Intranet ve ŠA 1.1)

-28-

Klárka Hvězdová

•


Stránky jsou statické a nejsou předpřipraveny žádné automatické součásti pro správu obsahu (autoři tak musí ručně upravovat odkazy a navigaci, což vede k chybám a nekonzistencím)

•

Zapomínání aktualizování německé části intranetu.3

Závěry

Nevyhnutelným se jeví zavedení systému pro správu obsahu (Content Management System). Jednou z hlavních funkcí by měla být nabídka šablon struktury a vizuální podoby stránek. Tím bude dosáhnuto jednotného vizuálně-funkčního prostředí, které bude zároveň odpovídat požadavkům firemní kultury. Velmi žádanou se také jeví funkce pro automatické generování standardních částí obsahu stránek jako jsou organizační hierarchie, kontakty a další. Velkým oříškem je pak vyřešení problému mnohojazyčnosti budoucího portálu. Ideální by bylo automaticky generované workflow pro překlad/aktualizaci německé (anglické) části obsahu. Otázkou zůstává, nakolik tuto funkcionalitu bude podporovat vybrané řešení. Technologie4

2.2

Portál musí být dostupný z počítačů umístěných jak v závodě Mladá Boleslav, tak v závodech Vrchlabí a Kvasiny a reprezentačních prostor v Praze. Výše zmíněné lokace mají i v současnosti přístup do ŠKODA AUTO a.s. počítačové sítě. Zároveň musí portál umožňovat zobrazování portletů z ostatních koncernových portálů a naopak. V budoucnu se počítá s přístupem na portál také prostřednictvím nových terminálů (informačních kiosků) umístěných v budovách výroby. Výhledově (v dalších fázích rozvoje systému) může být uvažováno i o zpřístupnění portálu pomocí mobilních zařízení (kapesních počítačů, mobilních telefonů apod.). Nepožaduje se přístupnost portálu pro dceřiné společnosti v Bosně a Hercegovině a na Ukrajině, které nejsou ani v interní síti Volkswagen.

3

V současnosti intranet podporuje českou a německou mutaci, s přechodem na portál se počítá i

s anglickou verzí. 4

Informace obsažené v této kapitole vycházejí z údajů v [ša7].

-29-

Klárka Hvězdová

2.2.1


Kontextový diagram

Schéma zobrazuje kontext umístění portálu B2E mezi dalšími portálovými řešeními a samostatnými aplikacemi v rámci infrastruktury Volkswagen. B2E Portal Context

Audi Mynet

VW Händler

UMS

B2E Škoda Auto

Portal for dealers, importers and partners (B2B Škoda Auto)

Internet presentation (www.skoda-auto.com)

Intranet ŠKODA AUTO (temporarily)

Standalone Applications ŠKODA AUTO

Obrázek 8: kontextový diagram. [ša7]

Portál B2E představuje infrastrukturu pro integraci následujících prvků:

-30-

Klárka Hvězdová


B2E Portal Context – detailed view

TAM (SSO)

User Management System

Users

Portlet applicaton

J2EE applications

Day Communiqué

B2E Portal Škoda Auto

DAVE (portal administration)

SAP applications, reports

Documentum

MS Project Server

Workflow system(s)

.Net Applications

Other VW Group portals

VW Händler Portal

B2B ŠKODA AUTO

Current Intranet ŠA (temporary links)

Obrázek 9: kontextový diagram detail. [ša7]

2.2.2

Single Sign-On (SSO)

Jedním ze zásadních požadavků na B2E portál je vyřešení otázky Single Sign-On. Komponenta SSO zjednodušuje autentizaci a autorizaci uživatele. Uživatel se přihlašuje pouze jednou, a to při vstupu do portálu. Další aplikace a citlivý obsah už přihlašovací údaje po uživateli nevyžadují a prověření probíhá na základě údajů k přihlášení do portálu. SSO musí umožňovat přístup do aplikací těchto typů: •

J2EE

•

SAP

•

B2B portál

•

AUDI Mynet5

5

Interní portál firmy Audi.

-31-

Klárka Hvězdová

•

VW Handler Portal6

•

.NET


Tato komponenta bude velmi pravděpodobně založena na produktu IBM Tivoli Access Manager (TAM), který je kompatibilní se SSO infrastrukturou v AUDI a VW. 2.2.3

Systém pro správu uživatelů

Se vznikem nového portálu se počítá i s vybudováním systému pro správu uživatelů. UMS systém (User Management System) musí být kompatibilní s UMS systémy v AUDI a VW. UMS systém je důležitý z hlediska procesu definování nového uživatele a definování a správy jeho přístupových práv do jednotlivých aplikací. UMS systém tedy komunikuje se SSO komponentou, kde jsou definována přístupová práva uživatelů. 2.2.4

Požadovaná platforma

Pro integraci Portálu B2E se jako nejvhodnější jeví platforma uvedená v následující tabulce. Tak by totiž byly nutné pouze minimální zásahy do stávající situace. Hardware

IBM z pSeries

Operační systém

IBM AIX 5.3

Aplikační server

WebSphere Application Server 6.0.2

Portálový server

WebSphere portal server 5.1.0.3 či vyšší

Portal DATA cousin

Oracle 10g x

Web Server

IHS 6.0.2

Reverse Proxy

Web-seal 5.1.3

ACCESS manager

Tivoli ACCESS manager 5.1.3

LDAP

IBM directory server 6.0

Řízení obsahu

Day Communiqué 3.5.5

Řízení dokumentů

Documentum 5.2.4

6

Interní portál firmy Volkswagen.

-32-

Klárka Hvězdová


Spolupráce

IBM Workplace Collaboration

JDK

IBM JRE 1.4

Tabulka 1: nejvhodnější platforma. [ša7]

Struktura portálu7

2.3 2.3.1

Uživatelské role

Základní uživatelské role, které vzniknou na rozhraní portálu, jsou rozděleny do čtyř skupin a definovány následovně: Centrální portálové role: •

Administrátor portálu

•

Administrátor uživatelských rolí

•

Uživatel portálu

•

HelpDesk Obsahová část:

•

Manažer zodpovědný za obsah

•

Supervizor komunikačního kanálu a subkanálu8

•

Redaktor

•

Čtenář obsahu Aplikace:

•

Vývojář aplikací

•

Administrátor aplikací

•

Vlastník dat

•

Uživatel jednotlivých aplikací

7


8

Systém tří úrovní publikování blíže objasňuje kapitola 2.4.2.

-33-

Klárka Hvězdová

2.3.2


Procesy

•

Přístup do portálu

•

Správa uživatelů

•

Správa dokumentů a obsahu portálu

•

Management portálových aplikací

•

Podpůrné procesy Funkční model9

2.4 2.4.1

Standardní portálové funkce

Každá stránka portálu bude mít kromě specifické obsahové části i další obsahověfunkční prvky. Tyto prvky jsou nezávislé na té které stránce, zobrazují se vždy na stejném místě a logicky doplňují funkčnost portálu. •

Navigace

•

Vyhledávání o Základní o Pokročilé

•

Personalizace a osobní nastavení

•

Mnohojazyčnost

•

Tisk

•

Alerty

•

Nástroj pro řízení obsahových změn

2.4.2

Management obsahu

Vzhledem k potřebě velké otevřenosti portálu z hlediska obsahu byl proces rozšiřování obsahu jasně definován. Portál je rozdělen do několika logických částí, které jsou navzájem nezávislé. Tyto individuální tématické bloky se nazývají „komunikační

9


-34-

Klárka Hvězdová


kanály“. Komunikační kanály se skládají dohromady jako puzzle a vzniká tak celkový obsah portálu. Jednotlivé části komunikačních kanálů (komunikační subkanály) mohou být zobrazeny v různých sekcích portálu. Celkové puzzle je tak variabilní v čase a prostoru (umístění konkrétní informace v různých částech portálu) a odpovídá aktuálním potřebám. Každý komunikační kanál má svého supervizora (první úroveň správy), který určuje základní strukturu, obsah a další rozvoj komunikačního kanálu. Supervizor komunikačního kanálu také konkrétně definuje komunikační subkanály a jejich supervizory. (Práce supervizora komunikačního kanálu podléhá schvalování vrchním managerem zodpovědným za celkový obsahu portálu.) Supervizor komunikačního subkanálu (druhá úroveň správy) schvaluje a uvolňuje k publikování informace připravené redaktorem. Redaktor (třetí úroveň správy) připravuje informace k publikování v portálu.

Obrázek 10: logická struktura komunikačních kanálů – obecně. [ša7]

-35-

Klárka Hvězdová


Obrázek 11: logická struktura konkrétního komunikačního kanálu. [ša7]

2.4.3

Správa dokumentů

Standardní DMS systém (Document Management System) s funkcemi sdílení dokumentů, ukládání, archivace dokumentů, vyhledávání dokumentů a další. 2.4.4

Struktura zobrazovaných portletů

Portál bude rozdělen do šesti základních sekcí tzv. „záložek“. Každá záložka se poté bude skládat z několika portletů10. Můj portál

Informace zobrazené v záložce Můj portál jsou úzce spjaty s konkrétním přihlášeným uživatelem. Jsou zde zobrazeny informace týkající se docházky, přesčasů, čerpání příspěvku na stravné a další témata svázána přímo s čtenářem. Záložka Můj portál může zobrazovat i další uživatelem nastavené informace (např. odkaz na často používané aplikace, oblíbené odkazy, oblíbené portlety z portálu

10

Portlet je základní stavební kámen portálu. Je to objekt, který nese specifickou informaci nebo

funkčnost. Může zobrazovat jak statické informace, tak výstupy z různých aplikací.

-36-

Klárka Hvězdová


apod.), se kterými uživatel může volně pracovat: přeskupovat je, přidávat, ubírat, měnit, mazat apod. Moji lidé

Záložka Moji lidé je určena vedoucím pracovníkům, kteří řídí určitou skupinu lidí. Pouze oni mají sekci Moji lidé aktivní. Část této sekce bude podobná záložce Můj portál. Manager bude mít přístup k podobným informacím o svých podřízených, jako má každý zaměstnanec ke své osobě. Zároveň v této sekci může manager u svých podřízených definovat a spravovat přístupová práva (role) k jednotlivým aplikacím, které jsou v managerově kompetenci. Informace v této sekci jsou zobrazovány vzhledem ke skupině lidí, kteří jsou danému managerovi podřízeni. Tyto seznamy může manager dále filtrovat a parametrizovat. Pro každé téma je k dispozici také agregovaná sumarizace dat nebo naopak detail konkrétního zaměstnance. Oddělení

Sekci Oddělení představují intranetové stránky jednotlivých oddělení. Stránky jsou vytvářeny pomocí pevně daných grafických šablon, které odpovídají úrovni oddělení v organizační struktuře a zohledňují množství zobrazovaných informací. Stránky jednotlivých oddělení zároveň zobrazují navigaci v rámci organizační struktury společnosti11. Informace

Všeobecné informace, které nejsou nijak přizpůsobeny danému uživateli, jsou zobrazeny v záložce Informace. Jedná se třeba o telefonní seznam zaměstnanců, nové aktivity firmy ŠKODA AUTO a.s., inzeráty, nabídky pracovních příležitostí, výběr z tisku a další obecné informace.

11

Navigace může na první pohled vypadat jednoduše, ve skutečnosti se ale jedná o relativně

složitou a náročnou záležitost. Organizační struktura totiž není neměnná a často dochází k menším i větším změnám. Je pak na portálu, aby se s těmito změnami dokázal náležitě vypořádat. Tzn. automatické vytvoření příslušných adresářů pro nová oddělení, přejmenování původních starých adresářů, případné převedení obsahu a kontaktování administrátora.

-37-

Klárka Hvězdová


Reporting

Tato sekce má za úkol rychle a efektivně umožnit přístup k informacím, které jsou směrodatné a důležité především pro management. Jedná se hlavně o různé reporty, koncentrované výstupy z rozličných externích (i komerčních) zdrojů a další. Projekty a týmy

Tato záložka v maximální možné míře podporuje týmovou spolupráci a projektové řízení. Hlavní důraz je kladen na funkci sdílení informací. Uživateli má být také umožněna personalizace této sekce. Čtenář by měl vidět přehledný seznam projektů a týmů, kterých je členem, spolu se základními informacemi o každém projektu a možností prokliku do konkrétního projektového prostoru. Uživatelské rozhraní12

2.5

Uživatelské rozhraní musí odpovídat potřebám uživatelů, ale také plně respektovat standardy koncernové identity (Škoda StyleGuide). Portálové okno bude rozděleno na horní popisnou část, kde uživatel volí konkrétní sekci (Můj portál, Moji lidé,…). Navigace v dané sekci pak probíhá v levé vertikální části, kde uživatel volí mezi jednotlivými tématy dané sekce. Obecné portálové funkce jsou zobrazeny v horní horizontální navigační liště. Ve zbylém prostoru je zobrazen specifický obsah stránky.

12


-38-

Klárka Hvězdová


Obrázek 12: navigace v portálu. [ša7]

Portálové rozhraní13

2.6

Je nutné zvlášť specifikovat rozhraní mezi SSO komponentou a aplikacemi. Prvně jmenované rozhraní bude přizpůsobeno požadavkům komponenty SSO. Komunikace mezi aplikacemi pak bude probíhat výhradně na bázi standardů pro komunikaci aplikací. Je třeba však brát ohledy na to, že portál musí umět pracovat jak s již existujícími aplikacemi, tak s aplikacemi nově vzniklými.

13


-39-

Klárka Hvězdová


Aplikace vybrané pro prototyp a pilotní fázi14

2.7

Pro prototyp a pilotní fázi byly vybrány jen nejpoužívanější a nejzásadnější aplikace. Ostatní aplikace se budou implementovat postupně v průběhu dalších rozvojových fází portálu. Úkolem prototypu je především ověření fungování komponenty SSO. Proto bylo při výběru aplikací dbáno také na to, aby každá aplikace zastupovala jeden platformový směr (J2EE, SAP, …). V tomto okamžiku se musíme zmínit o výhodách, které přináší silné koncernové partnerství. V německé společnosti Audi, která je stejně jako firma ŠKODA AUTO a.s. součástí koncernu Volkswagen, bylo vybudováno rozlehlé IT centrum s velkou kapacitou výkonných hardwarových prostředků. Není proto důvod, proč této skutečnosti nevyužít. Společnosti ŠKODA AUTO a.s. jsou tyto kapacity za výhodných podmínek poskytovány. Mnoho z aplikací tedy nepoběží na interních prostředcích, ale budou formou SLA poskytovány jako služba společností Audi. Vzhledem k tomuto faktu vyvstávají některé obtíže především rozhodovacího charakteru. U každé aplikace (hlavně půjde o nově vznikající aplikace) bude nutné stanovit formu vlastnictví. Určit, zda aplikace bude běžet ve firmě ŠKODA AUTO a.s. nebo bude poskytována firmou Audi. Roli zde hrají náklady na vlastnictví (TCO) hardwarových prostředků, průchodnost přenosových linek, požadovaná doba odezvy a další. Velké množství aplikací pracuje s rozsáhlými databázemi. Objem přenosu dat oběma směry (mezi Škodou a Audi) tedy bude obrovský. I s tímto se musí počítat. Na druhou stranu v Audi existuje spousta aplikací, u kterých by bylo vhodné použít je i pro firmu ŠKODA AUTO a.s. Pak není nic jednoduššího, než uzavřít s firmou Audi SLA smlouvu o poskytování této aplikace. Ušetří se tím náklady na vlastní vývoj a zrychlí se nasazení příslušné aplikace ve ŠKODĚ AUTO a.s. 2.7.1

TRAM

TRAM je aplikace určená k plánování služebních cest. V současné době běží na hardwarových prostředcích ŠKODA AUTO a.s. Zahrnuje tyto náležitosti: •

Požadavky na služební cestu (formuláře, zdroj SAP BSP)

14


-40-

Klárka Hvězdová


•

Rezervace – letenky, ubytování, půjčovny aut (zdroj SAP BSP)

•

Schvalovací proces (workflow)

•

Reporting (SAP BSP – zdroj z SAP R/3)

•

Podpůrné procesy – např. požadavek na peněžní zálohu (SAP R/3 – nedoporučuje se jako portálová aplikace)

2.7.2

IDIS

IDIS je webová aplikace určená k optimalizaci skladových zásob (v závislosti k zásobám dealerů, ročnímu období a dalším faktorům ovlivňujícím pohyb zásob). Základem je databáze Oracle, do ní jsou jednou denně importována data z aplikace SAP. IDIS je aplikace provozovaná ve firmě ŠKODA AUTO a.s. Uživatelské role jsou spravovány vlastní databází administrovanou přes webové rozhraní. 2.7.3

Telefonní seznam

Telefonní seznam v současné době existuje jednak jako aplikace firmy ŠKODA AUTO a.s. a jednak jako aplikace TELIS běžící v Audi, která zpřístupňuje kontaktní údaje na zaměstnance celého koncernu. Pravděpodobně bude pouze potřeba implementovat aplikaci TELIS do nového portálu a graficky změnit její výstupy, aby se podobaly výstupu současné aplikace. Tyto výstupy jsou přehlednější a uživatelé jsou na ně zvyklí. Zdrojem dat pro telefonní seznam je SAP HR (PD, PA), který je aktualizován jednou denně. 2.7.4

Jídelníček

Pokud externí firma zajišťující stravování nevyvine vlastní aplikaci pro prezentaci jídelního menu, bude současný manuálně spravovaný jídelníček v nezměněné podobě zpřístupněn na portálu. 2.7.5

Organizační struktura

Tato aplikace v současnosti neexistuje. Mapování organizační struktury by mělo probíhat automaticky a to na základě údajů z databáze SAP HR PD15. K organizační

15

Organizační struktura uložená v databázi SAP však nemusí odpovídat aktuální organizační

struktuře. Vzhledem ke změnám organizační struktury a rychlosti probíhání schvalovacích procesů nové

-41-

Klárka Hvězdová


struktuře se zároveň zobrazí i kontaktní údaje zaměstnanců daného oddělení. Zdrojem pro tyto údaje bude výstup z aplikace Telefonní seznam. Půjde tedy jen o jiný pohled na výstup telefonního seznamu16.

Obrázek 13: organizační struktura s kontakty. [ša7]

2.7.6

Moji lidé

Tato aplikace má v budoucnu (nyní neexistuje) managerům přinášet přehledy a statistiky podřízených. Aplikace bude hlavní částí sekce Moji lidé. Základní funkcí bude výpis všech podřízených spadajících pod daného managera. V tabulce budou zároveň

organizační struktury může docházet k dočasným nesrovnalostem. Tyto nesrovnalosti se vyskytují především u vyššího vedení a představenstva. Právě z těchto důvodů se muselo přistoupit k „úhybnému manévru“. Organizační struktura jako taková je jednou měsíčně oficiálně schvalována a podepisována. Neodpovídající organizační struktura by vrcholným vedením nebyla schválena. Proto se organizační struktura pro výše popsané účely portálu pojmenovala jako „organizační uspořádání“ (což je termín používaný i v SAPu), tudíž už nepodléhá schvalování představenstva. 16

Fotografie zaměstnance bude muset být vkládána ručně redaktorem (fotografie není součástí

databáze SAP).

-42-

Klárka Hvězdová

uvedeny

přesčasy


a

dny

volna

podřízených.

V budoucnu

se

počítá

se

zpřístupněním dalších informací. Bezpečnost17

2.8

Portál B2E musí splňovat bezpečnostní požadavky definované speciálně pro tento portál (viz níže) a ostatní bezpečnostní politiky firmy ŠKODA

AUTO a.s. a koncernu

Volkswagen. 2.8.1

Bezpečnost platformy

Bezpečností platformy je myšleno bezpečnostní nastavení prostředí, např. nastavení prostředí operačního systému. V tomto prostředí je pak nainstalován middleware a potřebné aplikace. Musí být tedy definovány bezpečnostní standardy pro všechny typy prostředí v rámci B2E. 2.8.2

Autentizace

Autentizační proces do portálu a do všech dalších aplikací přístupných přes portál je vyřešen komponentou SSO. Komponenta SSO (založená na produktu IBM Tivoli Access Manager) má na starosti jednak provedení prvotní autentizace uživatele při přihlášení do portálu, za druhé vyřizuje požadavky dalších aplikací (přístupných přes portál) na ověření uživatelovy totožnosti. V praxi je pak situace následující. Uživatel se přihlásí do portálu. V momentě spuštění aplikace, která vyžaduje jeho autentizaci, vznese aplikace požadavek na autentizaci uživatele. Tento proces je však uživateli zcela skrytý, neboť požadavek na autentizaci je vyřízen SSO komponentou, která předá autentizační informace dané aplikaci. Uživatel pak žije v přesvědčení, že jeho autentizace proběhla pouze jednou a to při přihlášení do portálu. 2.8.3

Autorizace

Problematika autorizace je součástí UMS (User Management System) systému. UMS systém bude pravděpodobně další koncernovou výhodou, která bude společností Audi poskytována jako služba. Přesto bych ráda zmínila některé otázky vyvstávající v této souvislosti. UMS systém velké společnosti s několika tisíci uživatelů musí být opravdu

17


-43-

Klárka Hvězdová


robustním, stálým a transparentním řešením. Problém je, že už v samotné jednotce UMS systému se setkáme s nutností integrace několika serverů se záznamy o uživatelích. Je tedy potřeba náležitě zanalyzovat a vyřešit veškeré duplicity, nekonzistence a nesrovnalosti a vytvořit systém, který přinese každému uživateli naprostou jedinečnost a jednoznačnost. To jsou složitosti číhající uvnitř systému. Ale zapotřebí je také definovat situaci vně systému. A to jakým způsobem budou jednotlivé aplikace přistupovat k datům o uživatelích. Zde nastává problémů několik. Za prvé je nezbytné předem určit, které stávající aplikace budou nuceny se systémem UMS komunikovat a zvážit, zda je vzájemná komunikace vzhledem k charakteru aplikace vůbec možná. Za druhé narážíme na problém některých aplikací (zde hovoříme spíše o velkých systémech typu SAP), které používají vlastní rozlišování uživatelských rolí a oprávnění. I tyto třecí plochy je nutné náležitě ošetřit. A celkem nasnadě je skutečnost, že pro nově vznikající aplikace je nanejvýš vhodné (téměř nezbytné) vytvořit řadu standardů, které budou definovat závazná pravidla pro ošetření oblasti uživatelských oprávnění. Tyto standardy v budoucnu ušetří mnoho času, financí a zbytečné námahy a zásadně přispějí ke zvýšení bezpečnosti. 2.8.4

Komunikační kanály18

Upřednostňované řešení komunikace mezi klientem a serverem je bezpečnostní komunikační kanál. Veškerá probíhající komunikace je tak čitelná pouze pro daného klienta a daný server. 2.8.5

DMZ (Demilitarizovaná zóna)

Demilitarizovaná zóna vyjadřuje, že každá část infrastruktury je instalována do určité zóny. Neexistuje žádná část systému, která by byla vně DMZ. Komunikace s aplikacemi potom probíhá pouze na předem definovaných portech, které jsou otevřeny na firewallu.

18

Zde jsou myšleny technologické komunikační kanály. Nezaměňovat s komunikačními kanály

jako logickou strukturou obsahu portálu.

-44-

Klárka Hvězdová

2.8.6


Životnost relace (Session Lifetime)

Tento bezpečnostní atribut jednoduše určuje životnost relace s aplikací19. Počítá se s vypršením limitu po 30 minutách nečinnosti. Požadavek pro další fáze projektu je na možnost určení různých časových limitů pro různé aplikace. 2.8.7

Záloha a obnova systému

Standardem pro zálohu a obnovu systému bude produkt IBM Tivoli Storage Manager. Každá část portálu B2E tedy musí odpovídat požadavkům tohoto produktu. 2.8.8

Specifická omezení

Specifická omezení souvisejí s možnostmi jednotlivých vývojových platforem a jejich bezpečnostními možnostmi20.

2.9

Shrnutí

Kapitola se dotkla všech oblastí, které bylo nutné objasnit a vyřešit v rámci etap analýzy. Kladnou reakci zaslouží výborně zvládnuté dotazování uživatelů před nastartováním celého projektu. U tak velkého počtu budoucích uživatelů je pole působnosti dotazování ohromné. Zároveň je důležité uvědomit si negativní aspekt této skutečnosti. Uživatelů je mnoho a připomínek, námětů a dotazů k budoucímu systému může být ještě víc. Důležité je potom aplikovat pravidlo „stop stavu“ uživatelských

19

Teoreticky se jedná o zřejmou a lehce pochopitelnou záležitost. Prakticky však narážíme na

několik nejasností. Důležité je se zamyslet, kde tento atribut uchovávat. Na výběr máme buď úroveň samotné aplikace nebo možnost uchovávat údaj o životnosti relace již v middlewaru. Toto rozhodnutí zásadně ovlivní budoucí variabilitu tohoto atributu, ale i jeho správu a možnosti změn nastavení. Vzhledem k tomu, že v dalších fázích rozvoje se počítá se zpřístupněním většiny aplikací, musí se brát v potaz, že některé aplikace (např. různé schvalovací procedury, kdy uživatel před schválením studuje mnoho dalších dokumentů, ale okno se schvalovacím formulářem je při tom stále aktivní) vyžadují mnohem vyšší dobu životnosti než ostatní aplikace. 20

Např. v Java 2 Security, je několik souborů, které definují, jaké protokoly může aplikace

používat ke komunikaci s okolím. Toto bezpečnostní opatření napomáhá předcházet nežádoucímu a nebezpečnému chování aplikací.

-45-

Klárka Hvězdová


návrhů a uživatele zahrnout pouze do úvodní fáze analýzy. V dalších fázích povolit připomínky a návrhy pouze uzavřenému okruhu lidí a to striktně procedurou change managementu. Co se týče analýzy technologií použitelných pro projekt, situace se nijak nelišila od jiných projektů v kterékoli jiné společnosti. Bylo potřeba náležitě zmapovat stav současných aplikací ve firmě a rozhodnout, jakým způsobem budou stávající technologie integrovány s novým řešením. Za povšimnutí možná stojí fakt, do jak velké míry je firma svázána koncernovými pravidly. Jak již bylo řečeno dříve, produktové řešení bylo známo bez nutnosti výběrového řízení. Tím byla situace na jednu stranu ulehčena o povinnost organizace výběrového řízení, na druhou stranu nepřinášela možnosti svobodného výběru. Další část analýzy se týkala struktury portálu. Definování logických i funkčních prvků budoucích intranetových stránek. Kromě nutnosti určení struktury záložek a jejich obsahu byl v této části analýzy také jasně definován tříúrovňový schvalovací proces publikování informací. Především jde o navržení logické struktury procesu publikování (tzv. komunikační kanály, blíže v kapitole 2.4.2 Management obsahu), která jednak definuje hierarchii schvalování a jednak předurčuje budoucí vlastnictví jednotlivých obsahových částí portálu. Při analýze uživatelského rozhraní byl velký důraz kladen na sjednocení designových a obsahových složek jednotlivých stránek. Portál by měl také uživatelům přinést snadnou a přehlednou navigaci, která zefektivní jejich práci. Zároveň se celé uspořádání portálu snažilo přinést co nejširší možnosti automatizace publikování standardních údajů (kontaktní údaje, organizační uspořádání apod.), a to vzhledem k usnadnění práce správců obsahu jednotlivých oddělení. Portál jako takový není pouze nástrojem informační integrace uvnitř firmy, ale měl by přinést i integraci z pohledu aplikací. To je pravděpodobně technologicky nejobtížnější část nasazení portálu už vzhledem k problematické správě současných aplikací naznačené v kapitole 1.1.3 Aplikace. Pro účely ověření fungování především komponenty jednotného přihlašování (SSO) bylo vybráno několik aplikací, které zastupují různé platformové směry, které je potřeba v portálu integrovat. V prototypu a pilotní fázi bude tedy integrována aplikace SAPu, webová aplikace využívající databázi

-46-

Klárka Hvězdová


Oracle, aplikace běžící ve firmě Audi, aplikace dodávaná externí firmou a organizační struktura generovaná z údajů v SAPu. Analýza bezpečnosti se z velké části týkala bezpečnosti přístupu, a tedy komponenty SSO a souvisejícího procesu autentizace. Následně byla řešena autorizace uživatele s přihlédnutím k problematice různých struktur uživatelských rolí a oprávnění v jednotlivých aplikacích. Byly řešeny i další aspekty bezpečnosti, jako jsou rozmístění serverů uvnitř demizón, bezpečnost komunikačních kanálů a v neposlední řadě prvek session lifetime, který má zabránit neoprávněnému přístupu v případě nepřítomnosti oprávněného uživatele a spuštěné aplikace.

-47-

Klárka Hvězdová


3 Řízení projektu Jedním z cílů této práce bylo konkretizování obecných metodických návodů a jejich přizpůsobení situaci projektu s velkým projektovým okolím. Tato kapitola přináší důležité aspekty projektového řízení konkrétně projektu Portálu B2E. Přímo u jednotlivých problémových oblastí jsou potom popsány návrhy a postupy, které nejlépe vyhovují tomuto projektu, případně nedostatky a náměty ke zlepšení průběhu a řízení samotného projektu. 3.1

Metodika SEP

Pro vývoj a integraci Portálu B2E ve firmě ŠKODA

AUTO a.s. byla použita

koncernová metodika SEP [ša8] (System Entwicklungs Prozess21). Tato metodika je určená k řešení vývoje systémů v koncernu Volkswagen. Pro všechna koncernová informatická oddělení má metodika SEP charakter směrnice, pro ostatní odborné útvary je povinnost jejího používání ošetřena organizačním pokynem. Následuje kategorizace metodiky SEP podle [Buchalcevová, 2005]. položka

význam, hodnoty číselníku

ID metodiky

SEP

Název metodiky

System Entwicklungs Prozess

Zkratka

SEP

Autoři

koncern Volkswagen

Rok vzniku

není znám

21

System Engineering Process (proces vývoje systému).

-48-

Klárka Hvězdová

Zaměření


PM22 projektová metodika

Rozsah

fáze ujasnění zadání, odborný koncept, návrh systému, realizace systému, zavedení systému dimenze metodika implicitně nedefinuje role metodika implicitně nedefinuje

Váha metodiky

MM23 střední

Typ řešení

NEW, INT, UPG, TYP, USE

Doména

CSW24 obecný SW

22

Metodika SEP sice zmiňuje problematiku multiprojektového prostředí, osobně jsem ale našla

právě pouze tu zmínku. Metodika upozorňuje na nutnost synergického efektu z průběhu více projektů najednou, ale tím její poselství končí. Obávám se, že právě zde je v globálním měřítku celého podniku zakopán pes. Ve velké společnosti probíhá současně desítky projektů najednou. Není výjimkou, že cíle některých projektů jsou navzájem buď a) podobné b) shodné c) protichůdné. Na nutnost „vytěžování“ výstupů z jednoho projektu do projektů druhých metodika upozorňuje. Nijak ale tuto skutečnost neřeší. Není naznačena nutnost multiprojektového řízení, nutnost implementace globální podnikové architektury a její následné používání ke správě projektů. 23

Metodika SEP by se z určitého úhlu pohledu mohla jevit jako těžká metodika. Jednotlivé fáze

projektu jsou detailně popsány, metodika oplývá velkým množstvím podrobných textových šablon pro tvorbu související dokumentace a je propracován i systém zpětné vazby od uživatelů metodiky směrem ke správcům metodiky, takže metodika se rozvíjí, obohacuje a žije. Přesto jsem zvolila váhu metodiky střední a to vzhledem k nedefinovaným dimenzím a rolím projektu. 24

zvláštním

Zde jsem jako doménu metodiky SEP specifikovala obecný SW. Metodika skutečně žádným způsobem

nerozebírá

specifika

jednotlivých

aplikačních

domén

definovaných

v

[Buchalcevová, 2005]. Přesto jsou pomocí metodiky SEP řízeny projekty všech ostatních domén. (To je celkem logické, vzhledem k tomu, že metodika SEP má charakter směrnice, jak bylo zmíněno v úvodu kapitoly.)

-49-

Klárka Hvězdová

Přístup k řešení


SEP klasický – vlastní vývoj (nový a rozšiřující vývoj) SEP OO – objektově orientovaný vlastní vývoj SEP SAP – zavedení, rozšíření, změna verze a rollout šablon standardního softwaru SAP SEP SSW – výběr standardního softwaru SEP malé zakázky – při náročnosti realizace menší než 30 člověkodnů

Slovní charakteristika

viz následující odstavce

Poznámka Tabulka 2: kategorizace metodiky SEP. [autor]

3.1.1

Cíle metodiky SEP

Metodika jako celek je nastavená pro koncernové prostředí, tedy pro velké prostředí s množstvím současně probíhajících projektů. Proto je v metodice kladen velký důraz na synchronizaci a “meziprojektový” přístup25, tzn. prolínání a vzájemné využívání výsledků v rámci různých projektů. Z tohoto důvodu je nezbytné při každém projektu dbát na parametrizovatelnost a znovupoužitelnost vyvíjených komponent. Velké prostředí, se kterým metodika SEP pro vývoj systémů pracuje, zároveň ovlivňuje i nutnost ošetření spolupráce s odbornými útvary, pro které je systém vyvíjen26. Nemělo

25

V metodice je sice na meziprojektový přístup kladen velký důraz, jak ale bylo zmíněno u

kritéria Zaměření metodiky v tabulce Tabulka 2: kategorizace metodiky SEP, metodika na tuto problematiku pouze poukazuje (třebaže „velmi důrazně“), ale nijak problémovou oblast neřeší. Multiprojektová oblast je tak řešena pouze na úrovni požadavku na parametrizovatelné a znovupoužitelné komponenty. Jejich znuvupoužitelnost však není žádný způsobem organizována. 26

Metodika SEP opravdu velmi dbá na dostatečnou komunikaci s věcnou oblastí projektu

(s businessem). Z mé zkušenosti tak dochází až k obdivuhodnému začlenění uživatelů do fáze Ujasnění zadání. To není samozřejmě pouze vlivem dobře specifikované metodiky, ale záleží také na lidech, kteří metodikou používají, jejich výkladu dané metodiky a jejich míře následování pravidel metodiky a kreativitě při jejím používání. V tak velkém podniku se logicky nabízí velké pole působnosti v oblasti dotazování uživatelů. Velmi oceňuji, že je tato možnost bezezbytku využívána a uživatelé mají ještě před závaznou specifikací požadavků na systém (někdy dokonce ještě před zahájením projektu) možnost ze svého pohledu pohovořit o připravovaném systému či aplikaci, upozornit na důležité aspekty a „být při tom“, když se rozhoduje, jakým směrem se bude vývoj připravovaného systému ubírat.

-50-

Klárka Hvězdová


by tedy docházet k situacím, kdy je odborný útvar (obvykle zákazník daného systému) seznámen až s celkovým výsledkem práce a nemůže zasahovat do průběžných fází vývoje27. Připomínky a náměty odborného útvaru obvykle ušetří mnoho prostředků (finančních, časových i kapacitních). Hlavní cíle metodiky SEP: •

Podpora jednotných a sledovatelných procesů vývoje informačních systémů v celém koncernu.

•

Minimalizace ztrát a požadavků na změny informačních systémů.

•

Snadnější a rychlejší orientace pracovníků v nových projektech informačních systémů.

•

Podpora projektů přesahujících jednotlivé značky v rámci koncernu. Struktura přístupu metodiky SEP

3.1.2

Vývojové směry metodiky SEP

Metodika SEP popisuje pět vývojových směrů: •

SEP klasický - vlastní vývoj (nový a rozšiřující vývoj).

•

SEP OO - objektově orientovaný vlastní vývoj.

•

SEP SAP - zavedení, rozšíření, změna verze a rollout šablon standardního softwaru SAP.

•

SEP SSW - výběr standardního softwaru.

•

SEP malé zakázky - při náročnosti realizace menší než 30 člověkodnů.

3.1.3

Fáze metodiky SEP

Všech pět vývojových směrů má jednotnou koncepci. Na jedné straně jsou fáze vývoje a na druhé straně oblasti činností. Pro každou fázi vývoje je definován souhrn aktivit.

27

Co se týče průběžného zasahování uživatelů do projektu. Vzhledem k obrovskému množství

uživatelů se jeví vhodnější pouze úvodní dotazování. Průběžné zasahování do projektu je povoleno pouze vybraným uživatelům a členům projektového týmu.

-51-

Klárka Hvězdová


Jednotlivé aktivity se dále rozpadají na metody, nástroje a pomůcky, kterými je daná aktivita podpořena. Zároveň je definován výsledek dané aktivity. Příkladem aktivity pro fázi Ujasnění zadání v klasickém vývojovém směru je Odhadnutí náročnosti. Aktivita Odhadnutí náročnosti je podpořena metodou Odhadu na bázi plánu projektu, nástrojem MS Project, pomůckou PM-Function Point a výsledkem celé aktivity je Odhad náročnosti. Fáze vývoje jsou tyto: •

Ujasnění zadání – popis cílů, první rámcové analýzy. Výstupem je návrh dalších fází.

•

Odborný koncept – analýzy (datový a funkční model, procesy, uživatelské prostředí). Výstupem je schválený závazný dokument specifikace požadavku.

•

Návrh systému – Výstupem je dokument návrhu systému.

•

Realizace systému – vyhotovení a otestování systému. Výstupem je provozuschopný systém.

•

Zavedení systému – kompletně realizovaný systém je zaveden do produktivního prostředí. Výstupem je samotný provoz systému. Oblasti činností jsou následující:

•

Fázový model – odborné výsledky umožňující provoz systému.

•

Synchronizace / opakované použití – meziprojektová spolupráce, obecné programování parametrizovatelných komponent vhodných pro opakované použití, používání již existujících komponent, využívání standardů přesahujících jeden projekt apod.

•

Řízení projektu – plánování, řízení a výkaznictví projektu.

•

Zajištění kvality – zaměření na řízení kvality procesu vývoje a snaha o předcházení problémům. Velkou předností metodiky SEP jsou šablony dokumentů s přesně určenou

strukturou obsahu. Uživatel metodiky je tak veden téma po tématu, které náležitosti projektu je ještě potřeba zpracovat a v jaké úrovní detailu se na právě řešenou problematiku dívat.

-52-

Klárka Hvězdová

3.2


Zdroje projektu

Jedním ze zásadních faktorů úspěšnosti projektu jsou zdroje. Především tedy finanční, protože od nich se odvíjí ostatní možnosti. Se schválenými dostatečnými zdroji projekt stojí a padá. Neschválí-li sponzor finanční rozpočet projektu, projekt bude záhy ukončen bez ohledu na probíhající etapu. Zároveň zde platí obecné pravidlo železného trojúhelníku. Tři veličiny (náklady, čas, požadavky) jsou těsně provázány a jejich vzájemná poloha předurčuje kvalitu výsledného produktu. Standardně se projekty potýkají se situací, kdy jedna z trojice veličin je fixní, druhá je zadaná a třetí se pak přirozeně přizpůsobuje předešlým dvěma. Fixní jsou nejčastěji povolené náklady na projekt (schválený rozpočet), zadány bývají požadavky na systém a z těchto veličin vyplyne potřebný čas nutný k naplnění projektového zadání. Bude-li zadavatel požadovat nižší čas při stejné kvalitě, bude tím pádem muset do projektu investovat vyšší náklady nebo slevit z určitých požadavků na vyvíjený systém.

Obrázek 14: železný trojúhelník. [autor]

Proti pravidlu železného trojúhelníku se z teoretického hlediska nedá nic moc namítnout. Z hlediska praxe si však použití železného trojúhelníku dokážu představit pouze v průběhu projektu, případně při změnovém řízení. Na začátku projektu, jsou všechny tři (respektive čtyři – vezmeme-li v potaz i závislou veličinu kvality) veličiny velké neznámé. Nevíme, na jak vysoké náklady se nám podaří sponzora přesvědčit, nevíme, jaké budou detailní požadavky na systém, a bez počátečních analýz nemůžeme

-53-

Klárka Hvězdová


ani přesně odhadnout časové hledisko projektu. V prvopočátcích projektu jsme tedy na značně tenkém ledu, ať už diskutujeme jakoukoli veličinu. 3.2.1

Finanční zdroje

Jak již bylo naznačeno výše, s finančními zdroji je problém. A to nejen problém s jejich získáním a s jejich dostatečnou výší, ale také problém vůbec definovat jaká ta dostatečná výše je. Kvalifikovaně a v odpovídající úrovni určit na začátku projektu finanční rozpočet, který bude co možná nejlépe odpovídat potřebám projektu po celou dobu průběhu. Je zřejmé, že bez podrobné analýzy potřebný odhad finančních zdrojů udělat nemůžeme. A dostáváme se k projektovému paradoxu. Před tím, než předstoupíme před sponzora projektu s prosbou o finanční prostředky, nás čeká přípravná fáze projektu. Přípravná fáze projektu, která probíhá za situace, kdy projektový tým neví, zda bude jeho projekt schválen a požadovaný finanční obnos se převede ve prospěch projektu a kdy projektový tým prakticky nemá přidělené žádné nákladové prostředky, aby mohl přípravnou fázi projektu vůbec uskutečnit.

Obrázek 15: projektový paradox. [autor]

Pokud se zamyslíme ještě hlouběji a uvědomíme si, co všechno můžeme do přípravné fáze projektu zahrnout, zjistíme, že označení „přípravná fáze“ vůbec není na místě. Potřebujeme-li totiž sponzora opravdu přesvědčit a z druhé strany, požaduje-li

-54-

Klárka Hvězdová


sponzor opravdu přesvědčující a pádné argumenty, tak se v průběhu životního cyklu projektu podle [Buchalcevová, 2005] dostáváme v „přípravné fázi“ někam na úroveň Detailní analýzy a návrhu. A to už rozhodně nemůžeme nazvat „přípravnou fází“. To je ovšem extrémní případ, kdy před sponzora předstupujeme prakticky s hotovým návrhem řešení (jenže to asi právě sponzor nejvíc ocení – a zaplatí). Každopádně před schválením finančního rozpočtu proběhne na projektu spoustu práce. Minimálně studie proveditelnosti a odhad časové a finanční náročnosti. A já se ptám, z kterých zdrojů jsou tyto práce financovány? Z kterého nákladového účtu plynou prostředky externím dodavatelům, kteří se na těchto pracích zhusta podílejí? A odpovídám si, jak nejlépe umím. Interní zaměstnanci věnují projektu svůj „volný čas“, který je opravdu buď jejich volným mimopracovním časem (nebuďme směšní) a nebo pouze tzv. „volným časem“, kdy zaměstnanci sníží své úsilí v činnosti jim standardně přidělené a „přebytečné“ kapacity přesunou na projektové práce. U externích pracovníků je situace možná ještě složitější. Pravděpodobně je jejich práce dočasně financována z jiných, již běžících projektů se schváleným rozpočtem a po schválení nového projektu jsou finanční resty navzájem vyrovnány. Oba přístupy představují opravdu „krásné, čisté“ řešení. Náležitě jsou využity různé kličky a šedivá místa, které firma nabízí. Společnost se nachází v situaci, kdy pro řízení projektů máme nesčetně metodik a přístupů s detailně popsanými procesy „celého“ životního cyklu projektu. A mě zaráží fakt, že v této době je finanční hledisko (a o peníze jde v businessu vždycky až na prvním místě) „přípravné fáze“ projektu tak hluboce podceněno, nezpracováno a troufám si říci přecházeno s „přimhouřenýma očima“. Podcenění způsobu financování „přípravné fáze“ je podle mého názoru silným kritickým faktorem úspěchu projektů. Počáteční analýzy jsou zcela stěžejním místem určujícím budoucí kvalitu a úspěch celého projektu. Při špatně zpracované analýze projektu, při špatně provedených odhadech nákladů projektu, při špatném odhadu časové náročnosti projektu, zkrátka při špatně vypracované „přípravné fázi“ projektu nemůžeme očekávat uspokojující výsledek celého projektu. A na jaké úrovni mohou být vypracovány práce, které zaměstnanec dělá ve svém „volném čase“? Pro ilustraci důsledků neuspokojivého a netransparentního způsobu financování „přípravné fáze“ projektu uvádím strom současné reality (CRT) podle TOC [Basl, 2003].

-55-

Klárka Hvězdová


Obrázek 16: CRT způsobu financování "přípravné fáze" projektu. [autor]

3.2.2

Lidské zdroje

Co se týče lidských projektových zdrojů, jenom bych se ráda pozastavila nad problematikou externích členů projektového týmu, tedy především nad mírou přiměřenosti externích pracovníků. Externí pracovníci mohou být velkým přínosem a oživením projektového týmu. Pomineme-li aspekty sociálního charakteru, které však mohou být jak pozitivní tak negativní, s externími pracovníky jsou především spojovány vyšší znalosti a zkušenosti. A to jak znalosti a zkušenosti projektového charakteru (řízení projektů, průběh projektů, životní cyklus projektů a další), tak znalosti technologické, týkající se samotného řešení. Obrácenou stranou mince jsou otázky ohledně důvěryhodnosti externistů, jejich ceny a jejich skutečným přínosem pro projekt a firmu. Je proto vhodné se nad touto otázkou zamyslet a zvolit vhodnou mírů externích pracovníků a to nejen pro průběh projektu, ale i pro provoz a běžný chod organizace.

-56-

Klárka Hvězdová

3.2.3


Řídící tým28

Dodavatel: vedoucí oddělení EOM29 (Procesní a systémová integrace – Prodej a marketing) Zadavatel: vedoucí oddělení ZP (Personální ekonomie a sociální služby) Další: •

vedoucí oddělení GK (Optimalizace výrobních nákladů)

•

vedoucí oddělení EO (Informační systémy a organizace)

•

vedoucí oddělení EOE (Procesní a systémová integrace – Řídící a podpůrné procesy)

•

vedoucí oddělení EOS (IT Governance a řízení servisu) Vedoucí projektu:

•

koordinátor oddělení EOM/4 (Procesní a systémová integrace – Importér)

•

pracovník oddělení ZP/1 (Personální statistika a analýzy) Administrátor projektu:

•

pracovník oddělení EOM/4 (Procesní a systémová integrace – Importér) Project leader:

•

externí pracovník – vedoucí projektu Tým 1: Business procesy a Intranet Vedoucí týmu: pracovník oddělení ZP/1 (Personální statistika a analýzy) Členové týmu:

•

programátor oddělení EOM/5 (Procesní a systémová integrace – Zákazník)

•

koordinátor oddělení EOE/1 (Procesní a systémová integrace – Řídící a podpůrné procesy – Lidské zdroje)

28


29

Podrobnější specifikace pracovní náplně jednotlivých oddělení viz Příloha 1.

-57-

Klárka Hvězdová

•


pracovník oddělení EOE/3 (Procesní a systémová integrace –Řídící a podpůrné procesy – Finanční účetnictví)

•

pracovník oddělení EOP (Procesní a organizační management)

•

koordinátor oddělení EOT/2 (Procesní a systémová integrace – Management zakázek a výroba)

•

externí pracovník – vedoucí projektu

•

externí pracovník - analytik

•

externí pracovník – systémový architekt

•

externí pracovník – softwarový architekt Tým 2: Architektura Vedoucí týmu: koordinátor oddělení EOS/3 (IT Governance a řízení servisu),

hlavní architekt IT Členové týmu: •

koordinátor oddělení EOI/6 (ICT služby – Solution Building Blocks)

•


•

dva externí pracovníci – systémový architekt

•

externí pracovník – senior softwarový architekt

•

externí pracovník – softwarový architekt Tým 3: Aplikace Vedoucí týmu: koordinátor oddělení EOM/4 (Procesní a systémová integrace –

Importér) Členové týmu: •

koordinátor oddělení EOS/3 (IT Governance a řízení servisu), hlavní architekt IT

•

koordinátor oddělení EOE/4 (Procesní a systémová integrace – Řídící a podpůrné procesy – Cross Application)

•

koordinátor oddělení EOT/2 (Procesní a systémová integrace – Management zakázek a výroba)

-58-

Klárka Hvězdová


•


•

dva externí pracovníci – systémový architekt

•

externí pracovník – softwarový architekt Tým 4: Provoz Vedoucí týmu: koordinátor oddělení EOS/1 (IT Governance a řízení servisu –

Řízení IT služeb) Členové týmu: •

koordinátor oddělení EOS/1 (IT Governance a řízení servisu – Řízení IT služeb)

•

koordinátor oddělení EOI/6 (ICT služby – Solution Building Blocks)

•


•


•

externí pracovník – systémový architekt

3.3

Časové hledisko projektu

Průběh projektu Portál B2E byl naplánován na 20 měsíců (05/2006 – 12/2007), viz příloha 2. Ovšem s názvem Projekt B2E Portál se ve firemních dokumentech setkáváme již přibližně na začátku roku 2005 [ša3]. To je dalších 16 měsíců navíc (celkem tedy 36 měsíců), kdy se projekt portálu B2E ve firmě diskutuje a hlavně, kdy se jím někdo zabývá a pracuje na něm. Jak bylo naznačeno v podkapitole Finanční zdroje (kapitola 3.2.1) je pracující na projektu v této fázi jako externí pracovník placen buď z jiných běžících projektů nebo jako interní zaměstnanec věnuje projektu svůj „volný čas“. A perlička. Před projektem Portál B2E proběhl ve firmě ještě další projekt se stejným cílem. Projekt Scopus (později přejmenován na projekt KLL30) měl také za úkol implementovat portálové řešení intranetu. Projekt Scopus měl na konci srpna 2004 [ša6] již kompletně vypracované zadání projektu a v průběhu roku 2004 byla externím dodavatelem zpracována detailní studie proveditelnosti [ša5]. Dotazování uživatelů ohledně požadované funkčnosti proběhlo zřejmě koncem roku 2003, protože k 2. lednu

30

Projekty KLL (Konzernleitlinien) = projekty pro zavádění nových koncernových hodnot. Více

o projektu KLL viz kapitola3.4.6 Zdrojové dokumenty

-59-

Klárka Hvězdová


2004 jsou již datovány výsledky [ša1], [ša2]. Z těchto faktů si troufám usuzovat, že první relevantní zmínka o portálovém řešení firemního intranetu musí být nejpozději z období poloviny roku 2003.

Obrázek 17: časová řada projektu. [autor]

Asi nemá smysl rozebírat naprosto zřejmý kritický faktor úspěchu projektu, a to celkovou časovou náročnost projektu, kdy myšlenka interního portálu se ve firmě převaluje už čtyři roky. Znovu se ale musím pozastavit nad chybějící analýzou krachu původního projektu Scopus. Zkrachovalý projekt je také projekt a utopené náklady, které v něm firma ztratila, by neměly zabránit tomu, aby byl projekt náležitě zdokumentován, a to včetně závěrečného zhodnocení a analýzy projektu jako celku. Právě rozšiřování a řízení znalostí průběhu projektů (jak úspěšných tak neúspěšných) může být cenným a důležitým faktorem ovlivňujícím procento dokončených projektů ku nedokončeným. Stejně jako metodiky řízení projektů podléhají určitým inovacím a změnám po každém použití, měly by být i zkušenosti z průběhů samotných projektů zaznamenávány, analyzovány a následně využívány pro zlepšení projektového řízení ve firmě.

-60-

Klárka Hvězdová

3.3.1


Důležité milníky projektu31

Z předchozí podkapitoly vyplývá, že důležitých milníků projektu bylo mnoho. Každý projekt měl samozřejmě vlastní časový plán (harmonogram posledních dvou projektů viz Příloha 2). Následující milníky se týkají nejaktuálnější verze projektu Portálu B2E. Etapa prototypu

Nejdůležitějšími cíli této etapy jsou následující: •

Ověření správného fungování autentizace k aplikacím pomocí komponenty SSO

•

Systém pro správu dokumentů a obsahu Portálu

•

Ověření integrace do Portálu pro různé technologie (J2EE, SAP, portlety z jiných portálů)

•

Ověření různých způsobů autorizace (anonymní uživatel, uživatel Windows, uživatel s heslem, uživatel s kartou MFA) V této etapě proběhne zaškolení administrátorů Portálu a členů projektového

týmu. Etapa přípravy pilotu

Cílem této etapy je připravení systému pro pilotní běh. Náležitostmi pilotního běhu jsou tyto: •

HomePage (navigace, rozložení stránky, design odpovídající standardu StyleGuide)

•

Správa obsahu (šablony pro publikační systém, publikační systém samotný, workflow pro překlad jak strojový, tak ruční)

•

Aplikace (telefonní seznam, jídelní lístek, zobrazování organizační struktury včetně kontaktů, sekce MojiLidé se statistikami přesčasů a dovolených podřízených)

•

Obecné portálové funkce (vyhledávání, mnohojazyčnost, autorizace a oprávnění, personalizace, rozložení pro tisk)

31


-61-

Klárka Hvězdová

•


Administrátorské funkce (logování, monitorování, správa uživatelů) V této etapě budou zaškoleni především administrátoři obsahu Portálu, ale již i

uživatelé a řídící pracovníci. Etapa pilotu

V této etapě je již požadován plně funkční Portál dostupný všem uživatelům sítě ŠKODA AUTO a.s. v České Republice. Obsah Portálu by měl odpovídat obsahu současného Intranetu, portálové funkce budou optimalizovány na výkon nutný pro běžné každodenní používání. V této etapě tedy proběhne: •

Optimalizace portálových funkcí

•

Migrace obsahu současného Intranetu do Portálu

•

Migrace/vytvoření stránek jednotlivých oddělení

•

Integrace aplikací

•

Vývoj nových aplikací Dokumentace projektu32

3.4

Dokumentace provázející celý životní cyklus projektu Portál B2E je rozdělena do několika samostatných skupin, které se však navzájem odkazují. Některé skupiny jsou spíše obecného charakteru a postihují systém jako celek. Právě dokumenty z těchto obecnějších skupin jsou poté doplňovány a detailněji rozpracovány v dokumentech rozebírajících z určitého pohledu velmi podrobně konkrétní část systému. Proces tvorby základních dokumentů projektu byl bolestivý, zdlouhavý a náročný, jak už se u velkého projektu dá očekávat. Ráda bych však ale zmínila drobný osobní postřeh, který v mém vědomí zůstal jako nezodpovězená otázka. Mluvit budu především o dokumentu Specifikace požadavků, ale v menší míře se tento námět týká i tvorby ostatních dokumentů. Jak je zmíněno níže, dokument Specifikace požadavků probíhal v režii personálního oddělení spolu s nápomocí externí firmy. Potud nic zvláštního. Situace,

32


-62-

Klárka Hvězdová


kdy je za specifikaci požadavků zodpovědné oddělení personalistiky, přináší spoustu výhod, ale samozřejmě i některá drobná omezení. Všechny hlavní výhody spadají pod jednoduchou rovnici „kdo bude systém používat, ať si určí náležitosti“. Zároveň i přenesení odpovědnosti za specifikaci požadavků na oddělení personalistiky odpovídá obecné potřebě, aby „business sféra“ byla odpovědná za nastavení „business pravidel“ v navrhované aplikaci (systému). Nevýhodou tohoto postupu je, že lidé z personalistiky obvykle nemají potuchy o formálních náležitostech specifikace požadavků. Tento problém je v případě projektu Integrace portálu B2E ve firmě Škoda Auto vyřešen externí firmou, která dodává know-how tvorby dokumentu Specifikace požadavků. Situace vypadá jednoduše a přehledně. Mě ale zaráží za prvé fakt, jak velkou měrou se externí firma na dokumentu Specifikace požadavků podílí, a za druhé, a to především, že externí firma pomáhající oddělení personalistika s tvorbou dokumentu Specifikace požadavků je tatáž externí firma, která vystupuje v pozici dodavatele navrhovaného systému. Na první pohled je zřejmé, že dodavatel má (nebo by alespoň měl mít) velmi dobré znalosti navrhovaného systému33. Teoreticky tedy může urychlit a zjednodušit projekt tím, že nesmyslné a neproveditelné návrhy utne rovnou ve fázi specifikace požadavků34 a naopak do dokumentu začlení uživateli neznámé charakteristiky nabízeného systému, které „zadarmo“ přinesou další funkcionalitu. To vypadá všechno moc hezky. Přesto ve mně nepřestal hlodat červíček pochybností. Pokud externista, který mi pomáhá s tvorbou specifikace požadavků, je zároveň externistou, který mi zanedlouho přijde systém implementovat. Neuzpůsobí náhodou specifikaci požadavků tak, aby urychlil a zjednodušil projekt tím, že s ním ve fázi implementace bude mít méně práce, a to za podmínek uživateli neznámého omezení funkcionality systému?

33

Tady jen drobná poznámka. Fascinuje mě, s jakou jistotou vám dodavatelé budou schopni

předvádět svoji perfektní znalost nabízeného systému a nebetyčné praktické zkušenosti s ním. A to i přes to, že nabízený systém je zcela nová verze, která nebyla dosud nikde implementována. 34

Mluvíme o situaci, kdy je již uzavřen výběr konkrétního systému. V některých firmách může

probíhat výběr systému právě až po fázi specifikace požadavků. To je zcela odlišná situace. Zde vzhledem ke koncernovým pravidlům byl implementovaný systém předem znám.

-63-

Klárka Hvězdová

3.4.1


Business Blue Print (Portál)

Dokumenty v této skupině se bezprostředně týkají každé oblasti budoucího portálu. Na obecné úrovni definují veškeré náležitosti vyvíjeného systému. Vzhledem k obsáhlosti tématu jsou však omezeny určitou mírou abstrakce. Proto jsou v těchto dokumentech nezbytné četné odkazy na více detailnější rozpis určitých částí portálu. Dokumenty této skupiny jsou: Dokument specifikace požadavku

Dokument obsahuje co nejdetailnější specifikaci požadavků na Portál B2E. Dokument byl zhotoven především oddělením personalistiky ve spolupráci s externí firmou. Dokument návrhu systému

Systémová specifikace Portálu B2E. Portál sám o sobě je prázdná schránka několika obecných portálových funkcí (vyhledávání, struktura portletů, úprava pro tisk atd.), kterou je potřeba blíže popsat z hlediska požadovaných dalších integrovaných modulů (SSO, aplikace, výstupy z databáze SAP a další). Matice komunikačních kanálů

Konkrétní návrh jednotlivých komunikačních kanálů (logických celků obsahu portálu) spolu s předpokládanými odpovědnostmi jednotlivých oddělení. 3.4.2

Komponenta SSO

Komponenta SSO je tak zásadní a rozhodující pro úspěšné završení celého projektu Portálu B2E, že je nezbytné ji velmi podrobně zpracovat v samostatné dokumentaci. Dokument specifikace požadavku

Vzhledem k jednoznačnosti zadání se ustoupilo od samostatného dokumentu specifikace požadavku na komponentu SSO a jako takový je brána příslušná kapitola v dokumentu specifikace požadavku celého Portálu. Dokument návrhu systému

Technologicky a systémově popsané všechny náležitosti týkající se komponenty SSO. U tak zásadní komponenty je zároveň požadován plně funkční prototyp, jehož dokumentace bude zpracována v příslušné skupině dokumentů (Dokumentace k prototypu).

-64-

Klárka Hvězdová

3.4.3


Standardy

Dokumentace ke standardům systému je nezbytná jak pro externí dodavatele, tak pro budoucí interní vývoj a správu. Infrastruktura

Tato část dokumentace popisuje současný stav infrastruktury (verze operačních systémů, databází, middlewaru atd.) ve ŠKODA AUTO a.s. Aplikace

Tyto standardy definují, co musí splňovat aplikace, aby bylo možné ji snadno implementovat jak do SSO konceptu, tak do celého portálu. Provoz

Standardy pro provoz, profylaxi, monitoring a podporu Portálu B2E. 3.4.4

Aplikace

Aplikace budou do portálu buď migrovány v podobě stávajících aplikací nebo budou vyvíjeny zcela nově. U migrovaných aplikací postačí pravděpodobně pouze dokument návrhu aplikace (případně dokument návrhu migrace aplikace), ale u nových aplikací je zapotřebí obou dokumentů, jak dokumentu specifikace požadavků na novou aplikaci, tak dokumentu návrhu aplikace. Dokument specifikace požadavků na aplikaci

Povinně u nově vznikajících aplikací. Dokument návrhu aplikace

Bude existovat jak pro migrované, tak pro nové aplikace. 3.4.5

Doplňující dokumenty

Dokumentace k prototypu Migrace původního intranetu

Dokument, ve kterém je popsán průběh migrace současného intranetu na nový Portál B2E. Migrace se skládá z části převodu statického obsahu intranetu a převodu aplikací provozovaných na současném intranetu. Vzhledem k velmi liberálním pravidlům pro

-65-

Klárka Hvězdová


aplikace na současném intranetu bude provoz některých aplikací se startem nového portálu ukončen. Ostatní aplikace budou uzpůsobeny Portálu a to buď na náklady příslušného oddělení, které aplikaci vlastní, nebo oddělením informatiky (u aplikací důležitých pro více oddělení). Uživatelské role a oprávnění

Uživatelské role budou zpracovány především v dokumentu týkajícím se komponenty SSO. Pokud to však bude nutné, bude podrobný rozbor uživatelských rolí a oprávnění zpracován v samostatném dokumentu, který se stane součástí dokumentace SSO. Procesy

Implementace portálu a jeho zavedení samozřejmě ovlivní některé podnikové procesy. Proto je nezbytný dokument popisující tyto pozměněné či nově vzniklé procesy jako např. procesy správy uživatele, správy portálu a portálových aplikací atd. Koncept školení

Požadavky na školení pro zavedení portálu a s tím spojené činnosti. Uživatelská dokumentace

Uživatelská dokumentace bude připravena firmou ŠKODA AUTO a.s. Mluvíme zde o uživatelských manuálech, prezentačních slidech, demo ukázkách apod. Informační kampaň k zavedení portálu

Dokument bude připraven firmou ŠKODA AUTO a.s. a popisuje způsob informování budoucích uživatelů. Zaměřuje se na možnosti co nejefektivnějšího informování uživatelů už v průběhu vývoje řešení. Seznamuje s výhodami, možnostmi a funkčností nového Portálu a “láká” uživatele k jeho používání. Rozvoj portálu (vize a strategie)

Obsahuje dlouhodobé plánování rozvoje portálu B2E. Dokument bude připraven interně firmou ŠKODA AUTO a.s. Integrace SAP aplikací

Jasné definování způsobu integrace aplikací SAP do Portálu B2E.

-66-

Klárka Hvězdová

3.4.6


Zdrojové dokumenty

Dokumenty, které nejsou přímou součástí dokumentace projektu B2E, přesto jsou pro projekt důležité, a to jako výchozí zdroje a analýzy. Dokumenty projektu KLL

Poznatky, analýzy a dokumentace z projektu, který předcházel projektu B2E35. ŠKODA AUTO a.s. StyleGuide

Závazná designová pravidla odpovídající korporátní identitě. Těchto pravidel se musí držet vzhled aplikací, portletů a vzhled portálu jako celku.

35

Projekt KLL pro mě (na pracovní pozici diplomanta) zůstal poněkud utajen. Samozřejmě jsem

měla přístup ke všem vzniklým dokumentům, ale z jakési úcty „o mrtvých jen v dobrém“ jsem se nikdy nedozvěděla, jaké byly hlavní příčiny krachu projektu KLL. Dokonce ani nevím, zda se někdo zabýval analýzou příčin krachu projektu KLL ještě před tím, než byl nastartován zcela obdobný projekt. Každopádně stojí za povšimnutí, že člověk, který měl projekt KLL na starosti, už ve firmě nepracuje. Nevím ovšem, zda projekt zkrachoval kvůli odchodu hlavního člověka nebo zda hlavní člověk projektu „byl odejit“ z důvodu krachu jeho projektu. Projekt KLL byl, jak již jsem řekla, projekt prakticky totožný projektu B2E. Cílem bylo stejně tak jako u současného projektu implementovat nový zaměstnanecký portál. Dokumenty, které jsem měla možnost vidět, jsou kvalitní a propracované, i když je fakt, že projekt evidentně zkrachoval v mnohem útlejším stádiu než je stádium analýzy, kterého jsem se na projektu B2E účastnila já.

-67-

Klárka Hvězdová


Obrázek 18: struktura dokumentace. [ša7]

-68-

Klárka Hvězdová


Záruky kvality36

3.5

Principy kvality jsou postavené na systematickém přístupu k přípravě řešení. Požadované kvality jako takové nemůže být dosaženo pouze kontrolami a dohledem. Jádro kvality je založené na použité metodice a řízení celého projektu. Základní principy pro záruku kvality jsou následující: •

Zástupci firmy ŠKODA AUTO a.s. jsou součástí projektového týmu

•

Vizualizace. Zásadní výsledky jsou prezentovány také ve formě obrázků, grafů a grafických modelů.

•

Projektové řízení. Součástí projektového řízení je minimalizace rizik, pravidelné koordinační schůzky a další standardní procedury týkající se řízení projektových aktivit.

•

Používání podkladů SEP pro strukturu a obsah dokumentace.

•

Týmová práce, týmové schůzky, oboustranné schůzky dodavatele a zadavatele před uzavřením konkrétních úkolů. Specifické požadavky firmy ŠKODA AUTO a.s.

•

Podpis smlouvy (SLA) s firmou Audi.

•

Sledování procesu vývoje.

•

Projektový plán (Ganttův diagram, s možností sledování naplňování důležitých milníků projektu).

•

Kontrola kvality výsledků.

•

Průběžné stanovování budoucích cílů.

•

Sledování kvalitativních indikátorů.

36


-69-

Klárka Hvězdová

3.6


Shrnutí

V kapitole je podrobně představena koncernová metodika SEP, která je ve firmě Škoda Auto používána při vývoji informačních systémů. Z pochopitelných důvodů je velká pozornost věnována zdrojům projektu, a to jak finančním, tak lidským. V podkapitole 3.2.1 Finanční zdroje je nadnesen projektový paradox. Mluvíme zde o situaci, kdy některé části projektu musí být uskutečněny ještě před schválením finančního rozpočtu projektu. Problémem tedy je, z čeho jsou práce na těchto částech projektu financovány. V podkapitole 3.2.2 Lidské zdroje je zase nastíněna problematika míry přiměřenosti externích pracovníků. Neméně důležitým aspektem je kromě finančních i lidských zdrojů také problematika časové náročnosti projektu, která je nastíněna v kapitole 3.3 Časové hledisko projektu. V kapitole je popsána téměř absurdní situace, kdy projekt portálu se ve firmě Škoda Auto táhne už několik let. V závěru kapitoly je poukázáno na nutnost kvalitní a dostatečně rozsáhlé a detailní dokumentace. U projektu s tak velkým projektovým okolím (a tak dlouhou dobou trvání, kdy se členové projektového týmu téměř kompletně změnili) je přístupná a dobře strukturovaná dokumentace prioritním komunikačním prostředkem. V této souvislosti je třeba dbát na jasně definovaný systém a strukturu ukládání jednotlivých dokumentů, který uživatelům přinese snadné vyhledávání a využívání potřebných informací. Principy kvality přejal projekt Portálu B2E z již předem definovaných principů kvality platících u projektů firmy Škoda Auto obecně. Principy kvality tedy vycházejí z požadavků definovaných metodikou SEP a běžně aplikovaných u všech běžících projektů.

-70-

Klárka Hvězdová


4 Sada klíčových pravidel Jedním z nejočekávanějších cílů této práce bylo sjednocení praktických zkušeností z projektu s teoretickými návody metodik a vytvoření sady klíčových pravidel. Měla vzniknout sada pravidel a poznatků, které jsou v současném projektovém řízení opomíjeny, a to především s přihlédnutím ke specifickým charakteristikám velkého projektového okolí. Vzniklá sada klíčových pravidel je představena v této kapitole. Vzhledem k charakteristice projektu je i výsledná sada klíčových pravidel upotřebitelná především ve velkých firmách a korporacích a u velkých projektů s větším počtem jak budoucích uživatelů, tak členů projektového týmu. Sada klíčových pravidel obohacuje dosavadní návody, praktiky a vzory metodik pro řízení projektů a to především se zohledněním specifik velkých projektů a velkých projektových prostředí, na které obecné metodické návrhy nemusí platit 100%. Sada klíčových pravidel rozhodně nemá ambice stát se jediným platným návodem pro řízení velkých projektů, pouze doplňuje stávající metodiky v některých dříve nezohledňovaných kritériích. Velký počet členů projektového týmu a velký počet zasahujících stran do projektu přináší v projektovém řízení jistá omezení, ale z druhé strany je přínosné naplno využít možností většího počtu účastníků. Zde předkládaná sada klíčových pravidel pro řízení projektů s velkým projektovým okolím si klade za cíl výrazně přispět ke zvýšení úspěšnosti projektů ve velkých firmách a být nápomocnou při řešení problémů spojených s projektovým řízením jako takovým. 4.1

Sada

klíčových

pravidel

pro

řízení

projektů

s

projektovým okolím - přehled 1. Náležitě dbát na důležitost lidského faktoru jako uživatele metodiky. 2. Udržet časovou náročnost projektu v rozumných mezích. 3. Správa multiprojektového prostředí. 4. Pořádek v integrované oblasti. 5. Rozumná spolupráce s budoucími uživateli. 6. Projektový paradox. 7. Management obsahu interního portálu. 8. Dynamika organizační struktury firmy. 9. Tlačítko „Obnov standardní nastavení“. 10. Terminologie.

-71-

velkým

Klárka Hvězdová


11. Session Lifetime. 12. Lidské zdroje. 13. Projektová dokumentace. 4.2

Sada

klíčových

pravidel

pro

řízení

projektů

s

velkým

projektovým okolím - detail 4.2.1

Lidé

Lidé jsou nejdůležitějším činitelem v průběhu projektu. Mohli bychom zabřednout až do filosofických debat o významu lidí ve všech spektrech lidského počínání. Nedoporučuji tento faktor podcenit. Obrovskou pravdu má tvrzení, že všechno je v lidech. Proto je třeba mít na zřeteli, že sebevhodnější metodiku, sebedetailnější popis procesu integrace či vývoje systému, prostě jakýkoli návod usnadňující řešení projektového zadání budou používat lidé. A záleží na jejich schopnostech, jejich zkušenostech, jejich vůli a motivaci, jejich kreativitě a jejich snaze. Lidský činitel v závěru nejvíce ovlivní celkový výsledek projektu. 4.2.2

Časová náročnost projektu

Ve firmě Škoda Auto trvá všechno velmi dlouho. I malý nevýznamný požadavek musí oběhnout dlouhé kolečko po aspoň deseti odděleních firmy, a to v nejhorším případě ještě ve formě papírového formuláře. Moderní monitorovací systémy vám umožní sledovat, kde se váš požadavek právě nachází. Ale po oběhnutí celého kolečka se vám formulář vrátí s poznámkou, že k vašemu požadavku je nutný vyplnit jiný formulář, který je ke stažení na jiné webové stránce. Tato praxe se sice jistě s postupem času mění a vyřizování požadavků se zrychluje, ale v lidech je tato zkušenost hluboce zakořeněna a podvědomě s dlouhým časovým horizontem počítají i při průběhu projektu. Projekt interního portálu je ve firmě diskutován již čtyři roky. Těžko analyzovat příčinu tak těžkopádného a dlouhotrvajícího průběhu projektu. Přesto si jedno zobecnění dovolím. Nedovolte jakémukoli projektu, aby trval více než půl roku (…dobře, v některých případech můžeme schválit i rok). Každý projekt můžeme rozdělit. Například pomocí inkrementálního přístupu můžeme každou iteraci pojmout jako samostatný projekt. A nemusíme po jednotlivých podprojektech požadovat ani výstupy funkčního charakteru. Každou část projektu naplánovanou jako etapu projektu můžeme pojmout jako samostatný projekt a tak k němu i přistupovat. Tím dosáhneme menší časové náročnosti

-72-

Klárka Hvězdová


podprojektů a větší jistoty celkového zvládnutí zadání. Projekt integrace portálu se dá velmi dobře rozdělit i z hlediska obsahu a integračního charakteru projektu. V prvním projektu implementovat samotný portál a s úpravami migrovat obsah interních stránek. V druhém projektu lze využít fungujícího portálu jako integrační platformy a postupně integrovat jednotlivé aplikace (opět lze rozdělit na více projektů). 4.2.3

Správa multiprojektového prostředí

Speciálně ve velkých firmách používajících projektový přístup je nutné náležité ošetřit multiprojektové prostředí. Správou multiprojektového prostředí není myšleno multiprojektové řízení. Podstata multiprojektového řízení je v efektivním alokování omezených

zdrojů

mezi

více

souběžně

běžících

projektů.

Podstata

správy

multiprojektového prostředí je v dokumentaci a správě projektových dat všech projektů. Tento koncept je blízký Bázi projektových dat metodického rámce MeFIS, blíže viz [Buchalcevová, 2005]. Základními požadavky na správu multiprojektového prostředí by mělo být sledování probíhajících projektů a inteligentní vyhledávání v anotacích jednotlivých projektů.

-73-

Klárka Hvězdová


Obrázek 19: první úroveň správy multiprojektového prostředí. [autor]

Pečlivou správou anotací všech projektů zabráníme zásadním kolapsům, kdy ve firmě běží dva projekty s opačným cílem.

Obrázek 20: kolize cílů. [autor]

-74-

Klárka Hvězdová


Zároveň bychom snad porovnáním anotací běžících a uskutečněných projektů mohli zabránit dalšímu extrému, a to dvěma projektům se stejným cílem.

Obrázek 21: stejné cíle. [autor]

Pro všechny ostatní projektové vedoucí bude dále nanejvýš užitečné mít přehled o souběžně či v minulosti běžících projektech, které se svojí charakteristikou mohou dotýkat jeho projektu, prolínat se s jeho projektem, či se jinak vzájemně ovlivňovat. Další úroveň správy multiprojektového prostředí je potom schopnost podniku opravdu přetěžovat komponenty37 jednotlivých projektů do ostatních projektů a dosahovat tak velkolepého synergického efektu. Vytvářet znovupoužitelné a parametrizovatelné komponenty, pečlivě vést jejich agendu, umožňovat efektivní vyhledávání v této bázi, její třídění a jednoduché využívání obsažených dat, to jsou hlavní cíle a přínosy druhé úrovně správy multiprojektového prostředí. Jako další, třetí úroveň bychom mohli očekávat automatizaci tohoto procesu.

37

Za slovem komponenta si klidně můžeme představit i termín webová služba. Ovšem správou

webových služeb by se ve firmě měl zabývat katalog služeb, který by byl pro naše účely příliš omezený.

-75-

Klárka Hvězdová


Obrázek 22: druhá úroveň správy multiprojektového prostředí. [autor]

4.2.4

Pořádek v integrované oblasti

Chceme-li integrovat určitou část firemního prostředí, měla by být tato oblast náležitě zmapována a její struktura absolutně známa budoucímu integrátorovi. Podobně jako nemá smysl čekat spasení od outsourcingu oblasti, kterou naše firma nezvládá, nemůžeme od integrace čekat vyřešení problémů, které jsou způsobeny špatnou správou určité části firemního prostředí.

-76-

Klárka Hvězdová

4.2.5


Spolupráce s budoucími uživateli

Náležitá spolupráce s uživateli systému, kteří mohou nejlépe vyjádřit své požadavky, již byla mnohokrát diskutována a, troufám si tvrdit, dodavatelé informačních technologií již s tímto velmi důležitým aspektem projektového řízení vesměs počítají. Ve velké firmě je tato komunikace na jednu stranu relativně obtížná, ale na druhou stranu máme v obrovském množství uživatelů obrovské pole působnosti pro veškeré dotazování, rešerše a průzkumy. V projektu Portálu B2E se velmi osvědčilo zahrnout uživatele pouze do fáze úvodního dotazování. Zkušenosti ukázaly, že přespřílišné náměty uživatelů jsou v tak velkém počtu pouze na obtíž a projekt jako takový pouze zdržují. Doporučeno je tedy uživatele důkladně zpovídat na začátku projektu a změny a zpodrobňování požadavků v průběhu projektu umožnit pouze členům projektového týmu, případně vybrané skupině uživatelů. 4.2.6

Projektový paradox

Detailně určit, z jakých zdrojů bude financována přípravná fáze projektu38. Ujasnit si, s jakými zdroji bude projekt moci disponovat v období před schválením projektového záměru a příslušného finančního rozpočtu projektu. Podrobnější rozbor tohoto problému viz kapitola 3.2.1 Finanční zdroje. 4.2.7

Management obsahu interního portálu

Uvědomíme-li si rozsáhlý počet autorů interního portálu, je zřejmé, že je nanejvýš nutné přesně definovat logickou strukturu schvalovacích procesů publikovaných materiálů. Společnost musí především přesně a jasně definovat celofiremní pravidla publikování, jejichž dodržování musí být striktně vyžadováno po všech účastnících publikačního procesu. Jedině díky tomu můžeme docílit stavu, kdy je tak velký obsah, jako je obsah intranetových stránek velké firmy, alespoň formálně a teoreticky udržitelný, odpovídající požadavkům společnosti a relevantní k potřebám a přáním firmy. Konkrétní implementace tohoto pravidla v projektu Portálu B2E viz kapitola 2.4.2 Management obsahu.

38

Objasnění přípravné fáze projektu a projektového paradoxu viz kapitola 3.2.1 Finanční zdroje.

-77-

Klárka Hvězdová

4.2.8


Organizační struktura

Organizační struktura velké firmy je velká složitá matice různých hierarchií, závislostí a vztahů. Ve firmě Škoda Auto je organizační struktura dynamická a v určitých časových intervalech (přibližně jednou za měsíc) schvalována nejvyšším vedením. Organizační struktura portálu však takovou dynamičnost podporovat nemůže. Organizační struktura portálu bude vycházet z organizačního uspořádání uloženého v SAPu, ve kterém se také mohou vyskytovat dočasné nesrovnalosti v porovnání s aktuální organizační strukturou firmy. Tyto nesrovnalosti, které by se objevily i na portálových stránkách jako platná organizační struktura, by však vedení neschválilo. Elegantním a jednoduchým řešením tohoto problému bylo pojmenování portálové organizační struktury jinak než souslovím „organizační struktura“. Proto se v portálu začalo používat označení ze SAPu (kde byl podobný problém zřejmě také kdysi řešen), a to označení „organizační uspořádání“. 4.2.9

Dynamické nastavování osobního portálového prostředí

Současné informační technologie umožňují spoustu vlastního nastavení používaného systému. Stejně tak portál umožňuje vytváření vlastních záložek, vytváření vlastních položek v jednotlivých záložkách a další a další osobní nastavení. Bohužel současná verze portálu nepodporuje jednoduchou funkčnost a tím je záchranné tlačítko „obnovit standardní nastavení“. V informatických firmách vyvíjejících portálové řešení zřejmě nemají

zkušenosti

s opravdovým

„uživatelem“,

který

je

nadšen

moderními

technologiemi, ale postupným odebíráním a přidáváním záložek a položek v portálu ztratí základní funkčnost nutnou k výkonu své pracovní činnosti. 4.2.10 Terminologie

Asi relativně obecný problém, který se nevztahuje pouze k našemu projektu. Je důležité v co nejranějším stadiu projektu definovat jednotnou terminologii, která jednoznačně a co nejnázorněji vystihuje podstatu věci. Je třeba se také zaměřit na to, aby výrazy vystihující věcnou část řešení nekolidovaly s obecně používanými výrazy oblasti informatiky. V projektu Portálu B2E se vyskytlo logické označení části portálu jako „komunikační kanál“. Ovšem komunikační kanál je i čistě informatický výraz, který má vlastní význam. V průběhu projektu pak toto synonymní označení dvou různých skutečností může přinést nejedno nedorozumění.

-78-

Klárka Hvězdová


4.2.11 Životnost relace (Session Lifetime)

Dobře analyzovat tento aspekt chování portálu, také vzhledem k budoucímu rozšiřování integrovaných aplikací. Portál by měl umožňovat jednoduše nastavit session lifetime každé aplikaci nezávisle. Blíže viz kapitola 2.8.6 Životnost relace (Session Lifetime). 4.2.12 Lidské zdroje

Náležitě analyzovat míru přiměřenosti externích pracovníků. Externí pracovníci mohou do firmy přinést znalosti, zkušenosti a vnější nadhled, ale zároveň nesou riziko úniku informací, riziko důvěryhodnosti externisty a riziko neodpovídajícího přínosu pro projekt vzhledem k nákladům na externího pracovníka. Tato problematika je v rámci projektu řešena v kapitole 3.2.2 Lidské zdroje a v kapitole 3.4 Dokumentace projektu. 4.2.13 Projektová dokumentace

V moderních metodikách a především v těch agilních je často diskutován smysl a účel rozsáhlé projektové dokumentace. Podepisuji se pod požadavek, že u každého dokumentu musí být znám jeho účel. V dalších bodech agilních metodik týkajících se dokumentace však souhlasit nemůžu. Stejně tak jako lehké metodiky se hodí pro menší projekty s menším projektovým týmem, stručná dokumentace se hodí pro tytéž projekty a ne pro velká projektová prostředí. U projektů s velkým projektovým týmem a velkým projektovým okolím je dokumentace hlavním a často i jediným nástrojem, jakým členové projektového týmu a lidé z okolí projektu sdílejí závazné projektové informace. Proto u velkých projektů ve velkých firmách doporučuji detailní, kvalitní a rozsáhlou dokumentaci. Neopomenout kvalitní systém ukládání a dobrou přístupnost a vyhledávání dokumentů pro všechny zúčastněné.

-79-

Klárka Hvězdová


Závěr V úvodu práce bylo naznačeno, že přizpůsobení obecných metodických návodů konkrétním potřebám konkrétního projektu je proces bolestivý a nesnadný, ale z druhé strany velmi zásadní a silně ovlivňující úspěch či neúspěch projektu. Během mapování etap analýzy projektu Portál B2E a během rozboru jednotlivých aspektů řízení projektu Portálu B2E se ukázalo, že nejen tailoring metodiky je zcela zásadním hlediskem. Také kategorie projektu velmi silně ovlivňuje metody použitelné ke správnému zvládnutí celého projektu. A proto kromě hodnocení projektu podle zažitých kritérií důležitosti projektu a počtu členů projektového týmu je nutné se pozastavit také nad velikostí projektového okolí. Celá práce se týká projektu s velkým projektovým okolím. Tzn. že projekt probíhá ve velké firmě, výsledné řešení je určeno pro velký počet uživatelů (řádově tisíce), výsledné řešení se dotkne velkého množství stávajících hardwarových i softwarových prostředků a také je vysoký počet lidí, kteří mohou projekt zvenku ovlivňovat (zde jsou myšleni především členové představenstva a sponzoři). Toto jsou všechno aspekty, které velmi silně ovlivňují způsob, jakým musí být projekt řízen, a velmi silně ovlivňují i metody a praktiky, které mohou být pro řízení použity. A práce celá velmi prakticky ukazuje, že pro řízení projektu s velkým projektovým okolím je opravdu potřeba velmi specificky upravit obecné návody metodik, některé metody absolutně nepoužít a naopak doplnit stávající návody o klíčová pravidla naznačená v předcházející kapitole. V práci se podařilo pečlivě a detailně zmapovat etapu analýzy projektu Portálu B2E a jednotlivé fáze doplnit komentáři a hodnoceními zohledňujícími obecné metodické postupy a principy. Zároveň se podařilo dojít až do zdárného cíle a představit čtenáři sadu klíčových pravidel, o které je nutné obohatit současné metodiky v případě řešení projektu s velkým projektovým okolím. To byl vysoko mířící cíl práce, který se však podařilo vyplnit bezezbytku. Práce přináší především onu sadu klíčových pravidel, která vychází z poznatků nasbíraných v průběhu etapy analýzy a je shrnutím celé práce. V práci samotné jsou pak diskutovány přístupy jednotlivých metodik vzhledem ke konkrétním situacím projektu a jsou doporučovány nové postupy, které výrazně přispívají ke zvládnutí projektu s velkým projektovým okolím.

-80-

Klárka Hvězdová


Dosažené výsledky jsou použitelné pro úpravu metodik pro vývoj a integraci IS. Práce poukazuje na nutnost zohlednění kritéria velikosti projektového okolí při úvodní kategorizaci projektu. Zároveň mohou výsledky pomoci i při řešení problémů řízení u konkrétních projektů potýkajících se s problematikou velkého projektového okolí.

-81-

Klárka Hvězdová


Literatura: [Austin, 2004]

Austin, D., Barbir, A., Ferris, C., Garg, S.: Web Services Architecture Requirements, W3C Working Group Note 11 February 2004. [online]

http://www.w3.org/TR/2004/NOTE-wsa-reqs-

20040211 [Basl, 2003]

Basl, J., Majer, P., Šíma, M.: Teorie omezení v podnikové praxi. Grada Publishing, 2003, ISBN 80-247-0613-X.

[Buchalcevová, 2005]

Buchalcevová A.: Metodiky vývoje a údržby informačních systémů. Grada Publishing, 2005, ISBN 80-247-1075-7.

[cssi]

Česká

společnost

pro

systémovou

integraci:

http://www.cssi.cz. [ibm]

IBM: http://www.ibm.com/cz.

[Maso, 2001]

Maso, B.: Java 2 Security. White Paper Java, 2001.

[ša1]

Škoda Auto a.s.: Výsledky dotazníku na uživatele stránek. Interní dokument firmy Škoda Auto a.s., 2004.

[ša2]

Škoda Auto a.s.: Výsledky dotazníku na autory stránek. Interní dokument firmy Škoda Auto a.s., 2004.

[ša3]

Škoda Auto a.s.: Projekt B2E Portál. Interní dokument firmy Škoda Auto a.s., 2005.

[ša4]

Škoda Auto a.s.: B2E databáze. Interní dokument firmy Škoda Auto a.s., 2006.

[ša5]

Unicorn Systems a.s.: WebSphere Portal Feasibility Study. Interní dokument firmy Škoda Auto a.s., 2004.

[ša6]

Dědek, M., Němec, V.: Portál pro zaměstnance – zadání.

-82-

Klárka Hvězdová


Interní dokument firmy Škoda Auto a.s., 2004. [ša7]

Andrlová, P., Antoš, M., Bušek, L., Gloser, F., Haburai, R., Pácalt, R.: Requirements Specification – Portal for Employees Škoda. Interní dokument firmy Škoda Auto a.s., 2006.

[ša8]

Škoda Auto a.s.: SEP - popis. Interní dokument firmy Škoda Auto a.s.

[ša9]

Škoda Auto a.s.: KLL Treffen. Interní dokument firmy Škoda Auto a.s., 2005.

[wikipedia]

Mnohojazyčná

webová

encyklopedie:

http://www.wikipedia.cz. [wikipedia_en]

Multilingual

web-based

http://www.wikipedia.org.

-83-

free

content

encyclopedia:

Klárka Hvězdová


Slovník použitých termínů a zkratek Administrátor

Administrátor je osoba zajišťující správu a provoz svěřených zařízení a aplikací (počítačů, informačních systémů, počítačových sítí a dalších). [autor]

Alert

Upozornění, varování, oznámení závažné nebo nebezpečné situace. [autor]

Aplikace

Využívaný software uživatelem, jím zpracovávaná data, poskytované funkce a podporované procesy a současně s aplikací spojené potřebné technologie. [cssi]

Atribut

Atribut je vlastnost entity nebo sloupec/pole u databázové tabulky nebo položka v datovém souboru. [cssi]

Autentizace

Autentizace znamená ověřování proklamované identity subjektu. Autentizace znamená ověřování pravosti, autentický znamená původní, pravý, hodnověrný. Autentizace patří k bezpečnostním opatřením a zajišťuje ochranu před falšováním identity (angl. impersonation, maskarade), kdy se subjekt vydává za někoho, kým není. Rozlišujeme autentizaci entity (osoby, programu) a autentizaci zprávy. [cssi]

Autorizace

Autorizace znamená oprávněnost, autorizovat znamená povolit, schválit, zmocnit, oprávnit. O autorizaci hovoříme, pokud určitá entita (uživatel, program) chce přistupovat k určitým zdrojům (např. serveru, souboru). Aby mohla entita ke zdrojům přistoupit, musí být k tomu autorizována – oprávněna (musí mít přístupová práva). Předpokladem autorizace entity je úspěšná autentizace. [cssi]

B2B

(Business-to-Business) Zahrnuje všechny komerční transakce mezi dvěma firmami, které jsou prováděny pomocí elektronických prostředků. Významným rysem modelu B2B je větší důraz na logistiku a zajištění samotného obchodu, oproti důrazu na získání

-84-

Klárka Hvězdová


zákazníka, jako je tomu v případě obchodů B2C. [cssi]

B2E

(Business-to-Employee) Vztahy mezi podnikem a zaměstnancem především na bázi interních webových aplikací a intranetu. [cssi]

Change

Řízení změn. Pevně stanovená procedura, která řeší způsob zadávání

Management

a vyřizování požadavků na změnu systému v průběhu projektu, ale i při jeho provozu. [autor]

CRT

(Current Reality Tree) viz Strom současné reality.

Databáze

Data, která jsou využívána ve více aplikacích. V databázi jsou minimalizovány redundance dat a existuje vhodně organizovaná správa těchto dat. Cílem databázového systému je uspořádat datové zdroje (datovou základnu) na počítači tak, aby tyto zdroje mohly být využívány více uživateli a mohly být využity na různých počítačích zapojených do sítě. Základní komponentou databázové koncepce je programový systém umožňující práci s databází – SŘBD (Systém řízení báze dat, angl. DBMS – Data Base Management System). [cssi]

DMS

(Document Management System) Systém pro správu dokumentů poskytuje centralizovanou správu dokumentů. Dokumenty lze snadno a rychle vyhledat, uživatelé se nemusejí bát, že upravují dokument, který současně upravuje někdo jiný, nebo že pracují s jeho neaktuální verzí. Dokumenty jsou chráněny několikaúrovňovými přístupovými právy, lze sledovat historii jejich použití. Systémy jsou úzce propojeny s běžnými kancelářskými aplikacemi a umožňují fulltextové vyhledávání jak ve strukturovaných informacích o dokumentu, tak v jeho textu. [cssi]

Doba odezvy

Doba odezvy informačního systému představuje čas, který uplyne mezi okamžikem zadání požadavku na zpracování a okamžikem přijetí výsledku zpracování zadavatelem. Při dávkovém zpracování není doba odezvy primárním kritériem a může činit minuty či hodiny.

-85-

Klárka Hvězdová


Při interaktivním zpracování musí být doba odezvy srovnatelná s dobou reakce člověka (sekundy). U systémů pracujících v reálném čase musí doba odezvy odpovídat času řízených procesů. [cssi] Firewall

Firewall je síťové zařízení, které slouží k řízení a zabezpečování síťového provozu mezi sítěmi s různou úrovní důvěryhodnosti a/nebo zabezpečení. [wikipedia]

Hardware

Technické prostředky, součást informačních technologií, které zahrnují zejména počítače, přídavná, komunikační a rozšiřující zařízení. [cssi]

HelpDesk

Informační a asistenční služba, která se stará o odstraňování závad a problémů s počítačovým zařízením a další ICT technikou. [wikipedia_en]

HomePage

Domovská stránka. Úvodní stránka, která se uživateli zobrazí při spuštění aplikace či prohlížeče Internetu. [autor]

HW

viz Hardware.

ICT

(Informační a komunikační technologie) Hardwarové a softwarové prostředky pro sběr, přenos, ukládání, zpracování a distribuci dat. Mezi hardwarové (technické) prostředky patří - servery, stacionární a přenosné personální počítače, tiskárny, komunikační a síťová zařízení (vysílače, směrovače, přepínače) a specializovaná koncová zařízení (myš, tablet, scanner, kamera, PDA, mobilní telefon apod.). Mezi softwarové (programové) prostředky patří základní software (operační systém, databázový systém, komunikační systém), aplikační software a software pro modelování a vývoj informačních systémů. [cssi]

Informační systém Informační systém je systém, jehož prvky jsou informační a komunikační technologie, data a lidé. Cílem informačního systému je efektivní podpora informačních a rozhodovacích procesů na všech úrovních řízení organizace (podniku). [cssi]

-86-

Klárka Hvězdová

Infrastruktura


Infrastruktura je v nejobecnějším smyslu slova množina propojených strukturálních prvků, které pak udržují celou strukturu pohromadě. Obvykle se používá pouze pro struktury, které jsou uměle vytvořené. Termín infrastruktura se používá v různém smyslu v řadě odvětví. [wikipedia]

Inkrementální

Inkrementální neboli přírůstkový vývoj je jedním z přístupů k tvorbě

vývoj IS

informačního systému. Celý systém je v průběhu projektu rozdělen na jednotlivé samostatně realizovatelné části a poté je vyvíjen po těchto částech (přírůstcích). Každý přírůstek prochází jednotlivými fázemi vývoje (analýza přírůstku, návrh, implementace) relativně samostatně (kontrolují se vazby na ostatní přírůstky). Každá verze přírůstkově vytvářeného systému musí být provozuschopná. Cílem je co nejrychlejší dosažení přínosů systému a snížení rizik jeho vývoje. [cssi]

Intranet

Specifický případ aplikace mechanismů, přístupů a protokolů uplatňovaných v Internetu na privátní prostředí organizace, tj. počítačové sítě ohraničené vlastnictvím organizace. Za oprávněné uživatele Intranetu jsou považováni pracovníci organizace. Ve vybraných případech (např. když organizace je geograficky dislokována nebo když pracovníci pracují mimo lokalitu organizace) jsou využívány i veřejné sítě (počítačové, telefonní), přičemž přenosy v takovýchto sítích jsou chráněny tak, aby byla zajištěna důvěrnost a neporušenost přenášených dat a prokázána identita komunikujících stran. Mluvíme pak o virtuálních privátních sítích. Důraz v aplikacích je kladen na zajištění přístupu k informacím, podporu rozhodování (decision support), podporu spolupráce (collaboration), řízení znalostí (knowledge management) atd. [cssi]

IS

viz Informační systém.

Iterace

Slovo iterace může být použito ve stejném významu jako opakování. Základním principem iterace je opakování určitého procesu v

-87-

Klárka Hvězdová


měnícím se kontextu. Uplatňuje se především v dynamických jevech. [wikipedia] Klient/server

Architektura softwarových systémů, kde se jeden program chová jako klient a posílá požadavky druhému programu (serveru), který tyto požadavky vyřizuje. [Buchalcevová, 2005]

Kompozitní

Kompozitní aplikace vyjadřuje takový přístup návrhu informačních

aplikace

systémů, kdy jsou jednotlivé aplikace skládány z mnoha dalších samostatných služeb. Kompozitní aplikace v sobě obsahuje funkčnost různých služeb obvykle v rámci SOA architektury. Komponentami kompozitní aplikace mohou být například samostatné webové služby, vybraná funkčnost některých jiných aplikací nebo výstup celého IS, který je kompozitní aplikaci předán ve formě webové služby. [wikipedia_en]

Koncern

Koncern (holding) je sdružení obchodních společností, z nichž jedna společnost ostatní společnosti řídí. Charakteristické je to, že jedna obchodní společnost prostřednictvím vlastnictví rozhodujícího kapitálového podílu (např. nadpoloviční většiny akcií) nebo na základě jiných skutečností ovládá a usměrňuje jednu společnost nebo více společností. Všechny obchodní společnosti, které tvoří koncern, jsou právně samostatnými subjekty. Koncern sám právní subjektivitu nemá, ale je sdružením (konsorciem) bez právní subjektivity. [wikipedia]

Kontextový

Výchozí diagram funkčního modelu. Popisuje vytvářený systém jako

diagram

jeden proces (černou skříňku) a strukturalizuje okolí systému na terminátory (aktéry), které si se systémem vyměňují data. Kontextový diagram představuje základní obrázek IS. [cssi]

Middleware

V počítačovém průmyslu je termín middleware používán pro označení jakéhokoli programu, který slouží pro spojení jiných, zpravidla už existujících programů, a nebo jako prostředník mezi nimi. Typicky jde o propojení na různé databázové systémy nebo

-88-

Klárka Hvězdová


komunikaci mezi komponentami. Systematické propojování aplikací pomocí middleware se označuje jako integrace podnikových aplikací (Enterprise Application Integration, EAI). Úloha middleware neustále roste tak, jak roste úloha integrace od integrace aplikací v rámci podniku, přes integraci podniků až po integraci služeb. [cssi] Míra přiměřenosti Míra poměru externích pracovníků ku interním zaměstnancům. Je externích

důležité se zamyslet, jaký poměr je pro podnik nejvhodnější. Příliš

pracovníků

mnoho interních zaměstnanců vede k malé flexibilitě počtu pracovníků a interní zaměstnanci jsou obvykle dražší. Příliš mnoho externích zaměstnanců zase naopak hrozí únikem informací a nízkou loajalitou pracovníků. [autor]

Multiprojektové

Prostředí, ve kterém běží více projektů najednou. Kromě otázek

prostředí

řízení v multiprojektovém prostředí vyvstávají i otázky správy tohoto prostředí. Především přehledná agenda dokončených, běžících i plánovaných projektů včetně jejich strukturované anotace s hlavními charakteristikami jednotlivých projektů. [autor]

Operační systém

Množina programových modulů, které slouží jako rozhranní mezi uživateli a jejich aplikačními programy a technickými prostředky počítačového systému, s primárním cílem vytvořit efektivní, bezpečný a snadno využitelný počítačový systém. [cssi]

Personalizace

Osobní nastavení a přizpůsobení vzhledem k potřebám a preferencím uživatele. [autor]

Pilotní fáze

Pilotní fáze, někdy zkráceně pilot, představuje etapu, ve které je implementovaný systém nasazen do provozu. V pilotní fázi ovšem implementované řešení neběží v plném plánovaném rozsahu. Systém je v provozu buď s omezenou funkčností a/nebo pro omezený počet uživatelů. Tato fáze má za úkol ověřit při omezeném provozu nasazované řešení v praxi. [autor]

Platforma

Definování platformy popisuje určitý druh rámce hardwarových nebo

-89-

Klárka Hvězdová


softwarových prostředků, které jsou nutné k běhu dané aplikace. [wikipedia_en] PM-Function Point Metoda k měření funkčního rozsahu informačního systému. Funkční rozsah mapuje funkční možnosti systému, které jsou pro uživatele z business sféry relevantní a dosažitelné. Funkční rozsah je nezávislý na implementované technologii. [wikipedia_en] Port

Vstup/výstup sítě. [autor]

Portál

Portál je sada aplikací, která zajišťuje uživateli přizpůsobený (personalizovaný) přístup k informacím a aplikacím prostřednictvím WWW prohlížeče. Portály lze klasifikovat dle typu uživatelů (všeobecné, podnikové), dle dominantní funkcionality (přístup k jiným

aplikacím,

podpora

rozhodování,

podpora

spolupráce

uživatelů, podpora práce se znalostmi). Specifickým případem jsou vertikální portály, které umožňují střetávání uživatelů z definovaného segmentu trhu (např. automobilový průmysl). [cssi] Portlet

Portlet je základní stavební kámen portálu. Je to objekt, který nese specifickou informaci nebo funkčnost. Může zobrazovat jak statické informace, tak výstupy z různých aplikací. [autor]

Procesní přístup

Přístup, kdy fungování firmy není vnímáno jako souhrn činností jednotlivých oddělení podniku, ale veškeré dění ve firmě probíhá v rámci jednotlivých procesů, které mohou jít vertikálně i horizontálně napříč více odděleními i celou firmou. [autor]

Projektové okolí

Projektové okolí je suma veličin vyskytujících se v bezprostřední blízkosti projektu, a tudíž velmi silně ovlivňujících celý projekt. Především jde o velikost firmy, ve které projekt běží, počet budoucích uživatelů, počet stávajících (ale i nových) hardwarových a softwarových prostředků, počet lidí zasahujících do projektu shora (představenstvo, finanční ředitelé, vlastníci a další). [autor]

Projektový

Paradox, kdy část projektu musí být rozběhnuta ještě předtím, než je

-90-

Klárka Hvězdová


Paradox

projekt odsouhlasen vedením a než jsou projektu přiděleny určitě finanční zdroje. [autor]

Prototyp

Vytvořená část nebo neúplná verze informačního systému založená na předběžném designu. Prototyp demonstruje především navržené funkce a způsob komunikace s částí informačního systému, aniž by byly zatím plně realizovány. [cssi]

Přenosová linka

Datově-komunikační linka určená k přenosu a výměně dat mezi jednotlivými počítači či celými sítěmi. Základní charakteristikou přenosové linky je přenosová rychlost daná objemem dat přenesených za časovou jednotku. [autor]

Přípravná projektu

fáze Ta část projektu (může zahrnovat i více fází životního cyklu projektu podle MMDIS [Buchalcevová, 2005], která běží ještě před tím, než je projekt odsouhlasen vedením a než jsou projektu přiděleny určité finanční prostředky. V této části jsou připravovány podklady pro následné předstoupení před řídící komisi. [autor]

Relace

Označením relace (z latinského relatio - zpráva, vztah) je myšleno trvající spojení v počítačové síti (session). [wikipedia]

Report

Report je výstup z koncových nástrojů pro uživatele s výsledky hodnot ukazatelů pro dané dimenze. Může být vyjádřen tabulkou, grafem, atd. Může být prezentován např. i v internetovém prohlížeči, může být obsažen v internetových portálech. [cssi]

Rozhraní

Rozhraní mezi programovými moduly. [cssi]

Server

Samostatný program, který je trvale spuštěn a který očekává požadavky jiného programu (klienta). Úkolem serveru je vedle přijímání

požadavku,

vykonání

činností,

které

jsou

mu

naprogramovány, a formulace odpovědi programu, který požadavek vznesl. [cssi]

-91-

Klárka Hvězdová

SLA


(Service Level Agreement) Dohoda o úrovni služeb. V řízení podnikových informačních systémů (IS): smlouva s provozovatelem IS (s dodavatelem v případě outsourcingu nebo v případě interního provozu vnitropodniková oddělení) nebo její součást, která vymezuje parametry provozu (metriky IS) aplikačního software (ASW) a hodnoty těchto parametrů, které mají být provozovatelem IS splněny (úroveň služby, Service Level). Pokud provozovatel nesplní sjednanou úroveň služby, bývá penalizován, způsob penalizace však musí být přesně sjednán. SLA jsou sjednány obvykle ve formě strukturovaných dokumentů. Úroveň služby bývá sjednána pro jednotky užití ASW: pro aplikace IS a pro kategorie uživatelů jednotlivých aplikací. Úroveň služby je tak rozdílná pro různé potřeby užití ASW. [cssi]

SOA

Service Oriented Architecture - Servisně orientovaná architektura je architektura, která k uspokojení požadavků business procesů a uživatelů používá volně vázané služby. Zdroje v počítačové síti jsou koncipovány jako nezávislé a lehce dosažitelné služby, které mohou být použity bez znalostí konkrétní implementace a platformy dané služby. [wikipedia_en]

SSO

(Single Sign-On) Speciální forma softwarové autentizace, která uživateli umožňuje provést proces autentizace pouze jednou a získat tím přístup ke zdrojům rozličných systémů a aplikací. [wikipedia_en]

Standardy

Standardy jsou publikované dokumenty vytvořené na základě dohod a zahrnující technické specifikace nebo jiná přesná kritéria důsledně uplatňovaná jako pravidla, směrnice nebo charakteristické definice, které zaručují, že materiály, produkty, procesy a služby splní své poslání. [cssi]

Strom

současné Je naznačení výchozího základního problému a popis důsledků

reality

tohoto problému na celý systém případně na běh celé organizace. Strom mapuje sekvenci příčin a následků, u jejichž kořene leží onen

-92-

Klárka Hvězdová


základní problém, na který chce strom poukázat. Strom má uživatele dovést k přesvědčení, že odstraněním základního problému se zbavíme i problému následujících. [wikipedia_en] TCO (Total Cost Finanční odhad k určení přímých a nepřímých nákladů svázaných s of Ownership)

koupí kapitálových statků (především počítačů, ICT techniky, SW, HW a další). Tento odhad v ideálním případě poukáže ne pouze na přímé náklady týkající se koupě, ale i na budoucí náklady spojené s používáním, provozem, nutným školením a dalšími souvisejícími náklady. [wikipedia_en]

Teorie omezení

Teorie omezení je souhrnný přístup, který má za cíl průběžné zvyšování počtu dosažených vytyčených cílů (především z finančního pohledu firmy). Vychází z přesvědčení, že každá organizace má přinejmenším jedno omezující místo, které zabraňuje celku dosahovat vyšší výkonnosti. Úkolem je tedy toto místo identifikovat a náležitě jej ošetřit a využít. [wikipedia_en]

TOC UMS

(Theory of Constraints) viz Teorie omezení. (User Systém řídící životní cyklus procesů spojených s uživatelem a jeho

Management

autorizací. Správa uživatelských účtů. [autor]

System) Use case diagram Obsahuje jednak popis chování systému vzhledem k požadavkům (model)

zadavatele a také kontextové umístění sama sebe v rámci ostatních use case modelů (zbytku systému či celé organizace). [wikipedia_en]

Webová služba

Webová služba je softwarový systém identifikovaný URI. Jeho veřejné rozhraní a vazba na konkrétní implementaci je definována a popsána XML. Uvedené informace mohou být zjištěny jiným softwarovým systémem. Tyto systémy smí spolu komunikovat způsobem popsaným v definici a za využití XML zpráv přenášených protokoly internetu. [Austin, 2004]

-93-

Klárka Hvězdová

Workflow


Řízení pracovních toků. Workflow systémy poskytují automatizaci celého nebo části podnikového procesu, během kterého jsou dokumenty, informace nebo úkoly předávány od jednoho účastníka procesu ke druhému podle sady procedurálních pravidel. Tyto produkty

vedou ke

změně podnikových

procesů. Zavedení

standardních postupů zvyšuje efektivitu práce, zároveň pracovní postupy jsou uchovány v systému a ne v hlavách odcházejících pracovníků, noví pracovníci se mohou snadněji zapracovat. Na základě vyhodnocení zdokumentovaných pracovních postupů je možno lépe navrhovat změny procesů, v každém okamžiku je zjistitelný stav vyřizování konkrétního případu, všechny akce jsou autorizovány a zaznamenávány, manažeři získávají věrohodnější podklady pro hodnocení pracovníků. Workflow prochází celou organizací a propojuje jak uživatele, tak aplikace. [cssi] Životnost relace s Doba, po kterou se aplikace udržuje v aktivním stavu bez činnosti aplikací

uživatele. Po uplynutí této doby dojde při nečinnosti uživatele k automatickému odhlášení uživatele. [autor]

-94-

Klárka Hvězdová


Slovník zmiňovaných technologií a produktů .NET

.NET je zastřešující název pro soubor technologií v softwarových

produktech,

které

tvoří

celou

novou

platformu, která je dostupná pro Web, Windows i Pocket PC. Pro tvorbu aplikací splňujících tyto myšlenky vydal Microsoft Visual Studio .NET, které bylo oproti předchozí verzi rozšířeno o snadný návrh webových XML služeb .NET, a .NET Framework, zajišťující prostředí potřebné pro běh aplikací a nabízející jak spouštěcí rozhraní, tak potřebné knihovny, jako Java. Visual studio se skládá z jazyků VB, J#, C# a Managed C++. Těmito jazyky napsanou aplikaci pak můžete bez problémů převést do ASP.NET(Web) nebo pro pocket PC (.NET Compact Framework). [wikipedia] IBM Tivoli Access Manager IBM TAM poskytuje komplexní zabezpečení včetně jediného přihlášení na WWW, distribuované webové administrace a zabezpečení na bázi zásad. [ibm] IMB

Tivoli

Manager

Storage IBM TSM je softwarový nástroj určený k zálohování (backup) a obnovování (recovery) dat. Software uživatelům umožňuje zálohovat a archivovat a znovu obnovovat data z hierarchické struktury datových úložišť. Datová úložiště, nazývaná pooly, mohou být disková, optická nebo pásková média. [wikipedia_en]

J2EE

Java Enterprise Edition je součást platformy Java určená pro vývoj a provoz podnikových aplikací a informačních systémů. [wikipedia]

Java 2 Security

Java

2

Security

je

mechanismus

pro

vytváření

zabezpečených javovských metod. Zabezpečené metody mohou být dokončeny pouze těmi vlákny, která mají

-95-

Klárka Hvězdová


dostatečná oprávnění k dokončení akce dané metody. [Maso, 2001] MS FrontPage

Program pro tvorbu webových stránek. Program typu WYSIWYG (What You See Is What You Get). [autor]

SAP

SAP je jméno firmy se sídlem ve Walldorfu v Německu. Její produkty jsou z oblasti ERP. Její jméno vzniklo ze zkratky

„Systeme,

Anwendungen,

Produkte

in

der

Datenverarbeitung“, což je analogicky anglicky „Systems Applications - Products in data processing“. [wikipedia] SAP HR

(Human Resources) - modul produktu SAP R/3 určený pro lidské zdroje. Skládá se ze dvou dalších modulů: PD, PA. [autor]

SAP HR BSP

Nástroj pro vytváření webových aplikací v prostředí SAP. [autor]

SAP HR PA

(Personal

Administration)

-

data

o

zaměstnancích,

jednotkou - klíčem je člověk (zaměstnanec nebo uchazeč). [autor] SAP HR PD

(Personal Development) - data o organizační struktuře, jednotkou - klíčem je oddělení. [autor]

SAP R/3

SAP R/3 je softwarovým produktem společnosti SAP, který slouží pro řízení podniku (Enterprise resources planning – ERP). SAP R/3 se skládá z následujících modulů: FI (Financial

Accounting)

(Controlling) Evidence

Kontroling;

majetku;

PS

Finanční AM (Project

účetnictví;

(Asset

CO

Management)

systém)

Plánování

dlouhodobých projektů; WF (Workflow) Řízení oběhu dokumentů; IS (Industry Solutions) Specifická řešení různých odvětví; HR (Human Resources) Řízení lidských zdrojů; PM (Plant Maintenance) Údržba; MM (Materials

-96-

Klárka Hvězdová


Management) Skladové hospodářství a logistika; QM (Quality

Management)

Management

kvality;

PP

(Production Planning) Plánování výroby; SD (Sales and Distribution) Podpora prodeje. [wikipedia] TAM

viz IBM Tivoli Access Manager

-97-

Klárka Hvězdová


Příloha 1 – Specifikace činnosti zmíněných oddělení EO (Informační systémy a organizace) • • •

Modelování komplexních procesů Podpora moderní struktury organizace Zaměření na projektové řízení a spolupráci přesahující různé oblasti

EOE (Procesní a systémová integrace – Řídící a podpůrné procesy) •

Softwarová podpora administrativním procesům

EOE/1 (Procesní a systémová integrace – Řídící a podpůrné procesy – Lidské zdroje) •

Kompletní řešení personálních a mzdových procesů

EOE/3 (Procesní a systémová integrace –Řídící a podpůrné procesy – Finanční účetnictví) • •

Podpora finančního účetnictví ve smyslu zákonných předpisů Provádění finančních operací bezhotovostního a hotovostního typu

EOE/4 (Procesní a systémová integrace – Řídící a podpůrné procesy – Cross Application) • • • • • •

Přehled systému Metodika vývoje Optimalizace SAP Change management Archivace Customer Competence Center

EOI/6 (ICT služby – Solution Building Blocks) •

Správa, plánování a rozvoj middleware systémů

EOM (Procesní a systémová integrace – Prodej a marketing) •

Systémová podpora procesů v oblasti prodeje a marketingu|

EOM/4 (Procesní a systémová integrace – Importér) • •

Systémová podpora importérů Portálová řešení

EOM/5 (Procesní a systémová integrace – Zákazník) • • •

WWW prezentace firmy ŠKODA AUTO a.s. WWW prezentace pro autorizované obchodníky v ČR WWW prezentace celosvětové importérské sítě

-98-

Klárka Hvězdová

•


Provoz intranetu

EOP (Procesní a organizační management) • •

Metodické řízení pracovních procesů Podpora procesně orientované organizační struktury

EOS (IT Governance a řízení servisu) • • •

Usměrňování IT aktivit v souladu s obchodními cíli Odpovědné využívání IT zdrojů Management IT rizik

EOS/1 (IT Governance a řízení servisu – Řízení IT služeb) • •

Koordinace a řízení IT služeb pro interní i externí zákazníky Řízení poskytování služeb v rámci koncernu

EOS/3 (IT Governance a řízení servisu), hlavní architekt IT • • • • •

Určování strategického rozvoje všech oblastí IS/IT Zpracování IT standardů Spolupráce na projektech z hlediska používaných technologií Posuzování požadavků na IT technologie Využívání synergických efektů v rámci ŠKODA AUTO a.s.

EOT/2 (Procesní a systémová integrace – Management zakázek a výroba) • •

Správa výrobních dat Podpora bezproblémového chodu systémů pracujících s výrobními daty

GK (Optimalizace výrobních nákladů) • •

Sběr a vytváření optimalizačních návrhů Podpora optimalizace výrobních nákladů v celém procesu

ZP (Personální ekonomie a sociální služby) • • • •

Plánování personálu a personálních nákladů Tvorba analýz personálu Správa dat v oblasti personálních informačních systémů Sociální politika firmy

ZP/1 (Personální statistika a analýzy) • • • •

Personální statistiky a analýzy Projekty SAP/HR Správa SAP/HR Poradenství uživatelům výpočetní techniky v oblasti Z

-99-

Klárka Hvězdová


Příloha 2 – Plánování jednotlivých fází projektu

Obrázek 23: Aktuální varianta. [ša7]

-100-

Klárka Hvězdová

10.10.2005 Ukončení KLL projektu


XI 2005 I 2006 II 2006 Definice garanta Odsouhlasení Odsouhlasení za odbornou oblast představenstvem Investice

I-X X 2005 - III 2006 Identifikace požadavků Business Blueprint odborných útvarů Technická a provozní Návrh konceptu řešení specifikace Harmonizace s portálovou strategií v rámci koncernu VW AG Obrázek 24: Původní plán Projektu B2E. [ša9]

-101-

IV 2006 - XII 2006 Realizace

XII 2006 Uvolnění do pilotní fáze

I 2007 - III 2007 Pilot

Klárka Hvězdová


-102-

Vysoká škola ekonomická v Praze

Recommend Documents