SW nástroje pro podporu řízení projektu

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

SW nástroje pro podporu řízení projektu Bakalářská práce

Autor:

Jan Macháček Informační technologie

Vedoucí práce:

Praha

Ing. Václav Šebek, CSc.

Duben, 2012

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

V Písku, dne 30. 4. 2012

…..………………………………… Jan Macháček

Poděkování: Tímto bych rád poděkoval Ing. Václavu Šebkovi, CSc., za odborné vedení, poskytnutí cenných

rad

a

pomoci

při

psaní

této

práce

a

dále

také

doc. Ing. Bohumilu Minibergerovi, CSc., za poskytnutí informací týkající metodiky ASAP.

Anotace: Tématem této bakalářské práce jsou sw nástroje pro podporu řízení projektu. V první kapitole jsou definovány pojmy týkající se projektů a jejich řízení. Další kapitola se zabývá pak samotnými sw nástroji, především pak jejich rozdělením. Třetí kapitola je pak zaměřena na konkrétní sw nástroj. Tímto nástrojem je ASAP, který si popíšeme více do hloubky. V poslední kapitole se dozvíme více o poslední fázi tohoto nástroje a jednu z úlohu této fáze aplikujeme na konkrétním pilotním projektu. Klíčová slova: Projekt, projektové řízení, sw nástroje pro podporu řízení projektů, ASAP Annotation: This bachelor thesis deal with sw tools to support project management. The first chapter defines the terms relating to projects and their management. The next chapter deals with the software tools and

their

categorised.

The

third chapter

is focused

on a

specific software tool. This tool is ASAP, which will be described in more depth. In the last chapter we learn more about the final stage of this tool and one of the task of this stage is applied to a specific pilot project. Key words: Project, project management, sw tools to support project management, ASAP

Obsah Úvod ........................................................................................................................................... 7 1

2

3

4

Problematika řízení projektů ............................................................................................... 9 1.1

Úvod do řízení projektů ............................................................................................... 9

1.2

Zájmové skupiny a jejich vztahy ............................................................................... 12

1.3

Organizační struktura projektu .................................................................................. 14

1.4

Manaţer projektu ....................................................................................................... 17

1.5

Projektový tým ........................................................................................................... 20

1.6

Ţivotní cyklus projektu a fáze projektu ..................................................................... 22

1.7

Projektové řízení ........................................................................................................ 27

1.8

Project Management Institute (PMI) ......................................................................... 30

Přehled významných SW nástrojů .................................................................................... 30 2.1

Nástroje niţší třídy ..................................................................................................... 31

2.2

Nástroje střední třídy.................................................................................................. 31

2.3

Nástroje vyšší třídy .................................................................................................... 31

2.4

Výběr softvarových nástrojů ...................................................................................... 32

2.5

Funkce sowtvarových nástrojů .................................................................................. 32

Metodika ASAP ................................................................................................................ 34 3.1

Metodologie ............................................................................................................... 35

3.2

Nástroje ...................................................................................................................... 36

3.3

Itinerář Implementace ................................................................................................ 37

3.4

Sluţby ........................................................................................................................ 44

Vyuţití metodiky ASAP ................................................................................................... 45 4.1

Zhodnocení stálého výkonu a implementace zdokonalení ........................................ 45

4.2

Uskutečnění školení koncových uţivatelů ................................................................. 46

4.3

Zajištění stále podpory a údrţby dokumentace školení a řízení zdělávání ................ 48

4.4

Konkrétní pilotní projekt............................................................................................ 49 5

Závěr ......................................................................................................................................... 54 Seznam pouţité literatury ......................................................................................................... 56 Bibliografie ........................................................................................................................... 56 Internetové zdroje ................................................................................................................. 56 CD-ROM .............................................................................................................................. 56 Seznam příloh ........................................................................................................................... 57

6

Úvod Jak uţ sám název této práce napovídá, hlavním tématem bude projekt a software pro jeho podporu. Pokud se odprostíme od technického pohledu na slovo projekt, dá se říct, ţe cokoli ve svém ţivotě děláme, je projekt. Projektem můţe být cokoli od uspořádání oslavy, přes stavbu domu aţ po vývoj nového softwaru. Projekty tedy lidstvo provázejí v podstatě od samotného začátku, a tak jak se mění lidstvo samotné, mění se i nástroje a techniky pro podporu řízení projektů. Dříve měli vedoucí projektů k ruce pouze papír a tuţku, v dnešní počítačové době jsou tyto nástroje nahrazeny sofistikovanými softwarovými nástroji. Cílem této práce je přehled sw nástrojů pto podporu řízení projektu. Řekneme si tedy definici projektu, budeme se zaobírat lidmi podílejícími se na projektu, zejména potom pozicí projektového manaţera, která je pro projekt a jeho samotné řízení velmi důleţitá. Dále si projekt rozdělíme do ţivotních cyklů a tyto jednotlivé cykly si popíšeme. Této kapitole jsem věnoval velkou část práce z důvodu, ţe je nutné znát dobře projekt a všechny jeho aspekty, abychom se mohly věnovat softwaru pro podporu řízení projektu. Také si řekneme něco blíţe o řízení projektů. Závěrem této kapitoly se zmíním o instituci PMI. Ve druhé kapitole se jiţ zaměříme na samotné softwarové nástroje. Řekneme si, co to vůbec takový softwarový nástroj je a k čemu slouţí. Uvidíme, ţe takovým nástrojem nemusí být jenom specifický software určený pro řízení projektů. Existuje totiţ velké mnoţství dalších jiných aplikací, které při realizaci projektu vyuţíváme uţ od komunikace mezi členy projektového týmu, aţ po případné úloţiště dokumentů tykajících se daného projektu. Rozdělíme si zde nástroje do jednotlivých tříd a uvedeme si jednotlivé hlavní zástupce softwarových nástrojů. Ukáţeme si také, ţe různé nástroje mohou v řízení projektu zastupovat odlišné funkce. Třetí kapitola je zaměřena jiţ na jeden konkrétní softwarový nástroj, kterým je ASAP a právě v této kapitole se dozvíme, ţe to vlastně ani není nástroj jako spíše komplexní implementační metodika. Tuto metodiku si tedy představíme a popíšeme si její účel. Ukáţeme si, z čeho všeho se tato metodika skládá a jaké fáze projektu podporuje. Tyto jednotlivé fáze si následně detailněji představíme. Další kapitolou je pak kapitola zabývající se poslední fází metodiky ASAP, a to „Zahájení produktivního provozu a podpora“. Toto téma proberu trochu více do hloubky,

7

jelikoţ jsem vybral i konkrétní pilotní projekt ze skupiny úkolů obsaţených v této fázi. Jedná se konkrétně o přípravu školení a jeho následné provedení.

8

1 Problematika řízení projektů 1.1

Úvod do řízení projektů

V samém začátku této práce je třeba říci si něco o historii i současnosti projektů. Dále je třeba objasnit si některé základní pojmy této problematiky, jako jsou projekt, jeho vlastnosti či řízení projektu a další. Historie Za počátek novodobého řízení projektů se povaţuje projekt pod názvem Manhattan, který vedla americká armáda a jehoţ cílem bylo vyvinout jadernou bombu. Do tohoto projektu bylo zapojeno mnoţství lidí různých profesí, kteří pracovali na různých místech. Také v něm bylo rozděleno řízení projektu jako celku. Vývoj metod pro řízení projektů se objevuje od druhé poloviny dvacátého stolení. Základy pouţívaných metod byly poloţeny Fredericem Taylorem a Henry Ganttem, který navrhl Ganttovy diagramy, které se staly uţitečným nástrojem pro plánování. Ganntův diagram je standartní formát pro zobrazení informací o časovém plánu projektu. Jsou v něm zahrnuty jednotlivé aktivity projektu a jim odpovídající datum zahájení a ukončení. Ganttovy diagramy jsou pouţívány dodnes, avšak jedinou změnou je, ţe místo kreslení těchto diagramů ručně jsou dnes modelovány sofistikovanými softwary. První softwarové produkty pro řízení projektů byly pouţity ve vojenském sektoru v sedmdesátých letech dvacátého století. Tyto první softwary byly ovšem drahé a pracovaly na střediskových počítačích. Postupem času se však počítače a komponenty minimalizovaly a díky novým softwarům se staly základní nástroje pro řízení projektů podstatně levnější a jejich tvorba snadnější. Co je to projekt? Projekt je „časově omezená pracovní činnost, jejímž cílem je vytvoření jednoznačného produktu, služby, nebo dosažením jiného výsledku“1. Operační neboli provozní činnosti jsou naopak práce, které organizace provádí pro udrţení běţného chodu firmy a jejího podnikání. Projekty se tedy od běţného provozu liší tím, ţe po splnění stanovených cílů nebo svém ukončení (zastavení) skončí.[1] Projekty se mohou lišit v mnoho faktorech. Mohou být malé i velké, týkat se jedné osoby, nebo naopak tisíců lidí. Tak stejně jsou i různě časově náročné, projekt lze zvládnout 1

SCHWALBE, K. Řízení projektů v IT s. 36

9

za jeden den, tak stejně můţe trvat i několik let. Do projektů v informačních technologiích je zapojen určitý hardware, software a sítě, jejímţ úkolem je vytvořit produkt, sluţbu, nebo dosaţení jiného výsledku. Vlastnosti projektu -

Projekt má jednoznačně určený cíl. Všechny projekty musejí mít jasně určený záměr, účel, nebo cíl. Výsledkem projektu je jedinečný výrobek, sluţba, nebo jiný výsledek.

-

Projekt je dočasný. Kaţdý projekt má jasně definovaný začátek i konec.

-

Postupné vypracovávání projektu. Zpočátku bývají projekty definovány velice ze široka a postupem čas je specifikován a odhalen detailněji. Proto je dobré řešit projekt postupně v krocích. Nejprve by projektovým týmem měly být sestaveny prvotní plány, postupně je aktualizovat a zanášet do nich nové, podrobnější informace.

-

Projekt vyţaduje určité zdroje, často z různých oblastí. Do řešení projektů je nutné zapojit lidi, hardware, software a jiná aktiva. Často se na projektu podílejí lidé z různých oddělení podniku. Dále si firma můţe najmout externí konzultanty a i ty zapojit do řešení projektu. Projektový tým ke skutečné implementaci navíc bude potřebovat hardwarové, softwarové a síťové prostředky. Dalšími prostředky se stávají i lidé z dodavatelských a poradenských firem, a budou přispívat k cílům projektu. Pozor ale na to, ţe prostředky, neboli zdroje, jsou omezené, proto s nimi musíme při plnění cílů projektu i firmy jako celku hospodařit účelně.

-

Projekt by měl mít nějakého hlavní zákazníka, nebo zadavatele. Do většiny projektů je zapojených mnoho účastníků, ale jeden z nich by měl mít hlavní roly zadavatele, neboli sponzora projektu. Zadavatel projektu zpravidla určuje směr řešení projektu a uvolňuje na něj finanční prostředky.

-

Součástí projektu je neurčitost. Protoţe všechny projekty jsou neurčité, je někdy těţké jasně definovat jejich cíle, odhadnout dobu potřebnou k jeho realizaci a určit potřebné náklady. Jednou z příčin neurčitosti jsou také vnější, neboli externí faktory, například onemocnění člena projektového týmu, krach dodavatelské firmy a jiné. Tyto faktory jsou jedním z hlavních důvodů, proč je řízení projektů náročné. Pro úspěšnost projektu jako celku je nezbytně nutná osoba projektového manaţera.

Projektový manaţer je odpovědný za spolupráci se zadavatelem projektu, projektovým týmem a dalšími lidmi zapojených do celého projektu a jeho úkolem je naplnit určené cíle projektu.

10

Pokud vezmeme v potaz vše co je psáno výše, můţeme říct, ţe projektem je jakýkoli jedinečný sled aktivit a úkolů, který má dán specifický cíl, určité časové omezení působnosti a má dané limity pro čerpání zdrojů pro uskutečnění. Tato definice zahrnuje tři hlavní charakteristiky – tři základny projektového managamentu, které určují prostor, v němţ se podle vytyčených cílů vytváří nová hodnota. Touto hodnotou je produkt projektu definovaný jako výstup, nebo výsledek projektu.[2] Těmito základnami jsou: -

čas, který je určující pro plánování sledu jednotlivých dílčích aktivit projektu,

-

dostupnost zdrojů, které jsou projektu připojeny a budou průběţně uţívány a čerpány

-

náklady, které jsou finančním projevem vyuţívání zdrojů v časovém rozloţení Tento dynamický systém by měl být udrţován v rovnováze, abychom dosáhly

úspěšného ukončení zahájeného projektu. K tomu, aby byl naplněn tento předpoklad, slouţí plán projektu, podle jejţ je sled prací řízen, se současným působením kontrolních systémů, které monitorují, jak jsou dodrţovány limity pro daný systém (viz obrázek 1.1).[2] Obrázek 1.1: Základy projektového managmentu Základy projektového managementu 1.1

Zdroj: Autor

Při ideálních okolnostech by s dobře připraveným plánem měly být šance na úspěšné ukončení projektu vysoké. V skutečném světě však na projekt působí vlivy vyvolávající rizikové situace a změny, které zapříčiňují výkyv systému z jeho rovnováţného stavu.

Produkt projektu Cílem veškerého projektového snaţení je vytvoření určitého jedinečného produktu – předmětu, sluţby nebo jiné kombinace, která naplní očekávání zadavatele projektu a přispěje 11

k dosaţení jeho strategického nebo taktického cíle, jeţ souvisí s jeho vlastními aktivitami. Pro produkt pak platí jedn z následujících moţností nebo jejich kombinace: -

je kvantifikovatelný a můţe reprezentovat ucelený fyzický objekt nebo jeho část,

-

vytváří určitou sluţbu, například zlepšení výkonnosti podnikového procesu,

-

vytváří výsledek, který se stává vstupem pro jiné externí nebo interní procesy, například dokument jako výsledek výzkumného projektu.

1.2

Zájmové skupiny a jejich vztahy

Zájmové skupiny projektů třídí jednotlivé interní účastníky projektu, dále také jednotlivce a skupiny z vnějšího prostředí se vztahem k projektu podle rozloţení jejich individuálních nebo skupinových cílů. Jedním z prvních úkolů spojených s přípravou a plánováním projektu je identifikace zájmových skupin.[2] Zájmové skupiny projektu jsou jednotlivci a organizace aktivně se zapojující do realizace projektu nebo jejichţ zájmy mohou být pozitivně či negativně výsledkem nebo průběhem projektu.[1] Zájmové skupiny projektu (stakeholders) reprezentují osoby nebo skupiny mající různou úroveň odpovědnosti a rozhodovací autority vzhledem ke konkrétnímu projektu. Zákazníci projektu Kaţdý projekt má svého zákazníka, který je jeho investorem nebo zadavatelem a má zájem na realizaci projektu – zpravidla se jedná o budoucího uţivatele výstupů produktu projektu nebo o investora, pro nějţ realizace projektu znamená zvýšení potenciální úspěšnosti na trhu prostřednictvím nového produktu nebo sluţby, která je předmětem projektu. Zákazník projektu je společnost nebo její část, která je zadavatelem projektu a pro ní budou výsledky projektu slouţit pro naplnění strategického záměru nebo změny. Klíčovou osobou ve skupině zákazníka projektu je sponzor, který je formálním nositelem většinou nejvyšší rozhodovací úrovně v projektu. [2] Sponzor projektu. Sponzor projektu je většinou funkčním manaţerem Zákazníka projektu – organizační jednotky, která bude výsledek projektu pouţívat. Obecně lze říci ţe Sponzor projekt můţe být

12

jakákoli osoba s pověřením k výkonu potřebných rozhodnutí, jako jsou předmět projektu, rozpočet a časový rámec projektu. Dodavatel/realizátor projektu Dodavatelem je společnost nebo její část přímo se účastnící se kontraktu a z něho plynoucí odpovědnosti za vlastní realizaci projektu. Úkolem dodavatele projektu je splnit podmínky obsaţené v kontraktu a získání s ním spojené odměny. Dodavatel mohou být: -

externí společnost,

-

jiná organizační jednotka zadavatele projektu (speciální projekty),

-

organizační jednotka, která je zároveň zadavatelem projektu (individuální a týmové projekty). Spektrum zájmových skupin je široké – od osob občasně poskytujících informace přeš

manaţery poskytující finanční nebo politickou podporu, aţ po ty, kteří mohou ovlivnit sponzorování projektu. Podle vztahu k projektu mohou tito vzdálení účastníci projektu mít určité odpovědnosti, jejichţ nesplněním či případným zneuţitím mohou negativně ovlivnit průběh i úspěšné ukončení projektu. Také dílčí zájmy některých skupin (někdy téţ nazýváme negativní zájmové skupiny), které jsou v rozporu s projektem, mohou ovlivnit projekt k jeho neprospěchu.[1] Pro úspěšné řízení projektu je tedy důleţité: -

identifikovat všechny zájmové skupiny,

-

porozumět rozsahu jejich autority a odpovědnosti,

-

popsat jejich poţadavky a očekávání,

-

dokázat odhadnout rizika, která jejich individuální cíle mohou pro projekt představovat,

-

vhodně komunikovat potřeby a stavy projektu v jeho průběhu, a chránit tak projekt před případnými negativními vlivy. Klíčové skupiny projektu jsou:

-

představitelé zákazníka projektu: 13

sponzor projektu, investor nebo vlastník podniku, který projekt realizaci projektu poţaduje, uţivatelé budoucího produktu projektu, zaměstnanci zákazníka projektu působící v bezprostřední blízkosti projektu -

představitelé dodavatele projektu: manaţeři podílející se na řízení projektu ve všech jeho řídících úrovních, manaţer projektu, členové projektového týmu, subdodavatelé a subkontraktoři,

-

jiné skupiny s vlivem na projekt (zastupitelské úřady, politická lobby, konkurence apod.),

-

veřejnost a sdělovací prostředky[1]

Kromě těchto hlavních skupin existuje celá řada dalších interních a externích subjektů mající vliv na projekt, jako například rodiny členů projektového týmu, ochránci ţivotního prostředí a další.

1.3 Organizační struktura projektu Projektový management, také jako i jiné druhy řízení, je zaloţen na uplatňování vlivů řídících subjektů na řízené. Podle profesora Kerznera se člení na základní a nedílné principy řídících vlivů na: -

pověření (Authority) – moc

přidělena jednotlivci tak, aby mohl uskutečňovat

rozhodnutí, která jsou respektována jedinci, -

odpovědnost (Responsibility) – morální povinnost přijatá jednotlivcem spočívající v efektivním splnění uloţeného úkolu,

-

závaznost (Accountability) – schopnost plnění pověření – stav, kdyţ jednotlivec dokáţe naplnit očekávání a uspokojujícím způsobem završit určité pověření tím, ţe má dostatek autority i schopností a zodpovědnosti ke splnění tohoto očekávání. [2]

14

Vztahy znázorněné profesorem Kerznerem mezi těmito kategoriemi: Accountability = Autority + Responsibility Pro přijmutí závazku projektového manaţera za plánování a realizaci projektu s ţádaným výsledkem ve všech posuzovaných rovinách, je nutné, aby disponoval jak pracovními zdroji, které skrz kaţdého zúčastněného jednotlivce nesou morální závazky za vykonání přiděleného úkolu v rozsahu stanovených měřítek a to jak kvantitativních, tak i kvalitativních, ale i manaţerskou autoritu k delegování a ţádání splnění úkolů. V češtině se velmi často pletou, zaměňují a nejasně pouţívají pojmy „odpovědnost“ a „zodpovědnost“ bez jasné vazby k závazkům a kvalitě vlastní práce nebo jako výrazu k ručení za práci jiných. Jednoduchá pomůcka při rozlišování závazku můţe být to, ţe odpovědnost (Responsibility) znamená, co má kaţdý jednotlivec v popisu práce, či specifikaci – resp. Co má osobně udělat, jakého výsledku se má dobrat. Zodpovědnost a závaznost (Accountability) se týká výsledku, za který ručí, aniţ by se musel účastnit na jeho provedení osobně. Pověření (Autority) je vymezením oprávnění, jehoţ deleguje vlastní provedení úkolu.[1] Prostředí, ve kterém probíhá největší mnoţství interakcí mezi jednotlivými účastníky projektu nazýváme Organizační struktura projektu. Tyto interakce se dějí za účelem: -

Koordinace a řízení projektových prací

-

Monitorování a kontroly procesů projektu

-

Veškeré odborné, řídící a doprovodné projektové komunikace Komunikace v této struktuře je velice proměnlivá, proto je důleţité správné nastavení

vztahů, rozloţení autority a formalizace vztahů a komunikačních toků. Organizační struktura projektu je navrţena tak, aby splňovala: -

Potřeby a principy řízení, rozdělení autorit a odpovědností stanovených při iniciaci projektu

-

Profesionální a související komunikační potřeby projektu podle plánu projektu

Organizační struktura projektu je formalizována: -

Zakládací listinou projektu (Project Chapter) 15

-

Plánem projektu

-

Sadou pověření k realizaci projektových prací opatřenou podpisem ověřujícím přijetí závazku takto formulované zadání splnit Kvalita úrovně projektového managementu je i při uţití detailně vypracovaných

metodologií a pravidel je vţdy plně závislá na lidech tvořící organizační strukturu konkrétního projektu. Přestoţe, ţe se zdá nejdůleţitějším plnění jednotlivých dílčích úkolů jednotlivců nebo skupin, celkový úspěch vytyčeného cíle projektu je výrazně závislý na celkové spolupráci projektového týmu. Ve většině případů se projektový tým skládá se specialistů příslušným k jiným oddělením podniku, kteří dříve mohli pracovat na odlišných projektech nebo se nesetkat vůbec. Také jedinečnost projektu jako jeho originálních procesů, klade důraz na jednoznačné přidělení manaţerské autority a schopnosti rozhodování. V tomto prostředí nabývá na důleţitosti role manaţera projektu.[1] Z těchto důvodů má kaţdý projekt, stejně jako kaţdé jiné podnikatelské uskupení svou vlastní organizační strukturu, pravidla rozhodování, nadřízenost a podřízenost, pravidla vyjednávání a způsobu pověření k výkonu úkolů a hierarchický systém sdílení odpovědnosti za jednotlivé výsledky aţ po globální cíl projektu. Základními subjekty projektového managementu jsou: -

Manaţer projektu

-

Asistent manaţera projektu, vyţaduje-li to rozsah projektu

-

Projektová kancelář, vyzraje-li to rozsah projektu

-

Projektový tým Zde je uveden jako samotný řídící orgán pouze manaţer projektu. Pokud je však

projekt součástí nějakého širšího programu, pak do rozdělení ještě patří manaţer programu, nebo ředitel programu. Na obrázku 1.2 je znázorněno rozloţení odpovědnosti jednotlivých úrovní projektového managementu.

16

Obrázek 1.2: Rozložení odpovědnsoti úrovní projektového managementu

Zdroj: Svozilová, A. Projektový management. s. 30

1.4 Manaţer projektu Klíčovou postavou celého projektového managementu je manaţer projektu. Jak jiţ bylo zmíněno, projektový manaţer úzce spolupracuje s ostatními účastníky projektu, zvláště pak se zadavatelem projektu a se samotným projektovým týmem. Pod jeho přímým vlivem je veškeré projektové dění od vytvoření projektového plánu, obsazení jednotlivých pozic v projektovém týmu, koordinaci úkolů, finální fázi a předání výstupů projektu zákazníkovi aţ po jeho ukončení. Manaţer projektu je také zodpovědný za splnění cílů projektu při dodrţení všech stanovených charakteristik projektu. Do role manaţera projektu by měl být vybrán člověk i

s komplexními

znalostmi

zahrnující

obchodně

–

ekonomický,

odborný

metodicko – procesní pohled na vytvoření nového produktu nebo sluţby. Z toho co

jsme si uţ popsaly lze říci, ţe mezi hlavní úkoly projektového manaţera patří:[2] -

zajistit vytvoření produktu projektu, coţ můţe být předmět, sluţba, jejich kombinace nebo jiný výstup projektu s pouţitím dostupných zdrojů, v předpokládaném čase, s daným limitem nákladů a za pouţití dostupných technologií,

-

dodrţet určené limity spotřeby zdrojů a dosáhnout plánovaného profitu projektu,

-

najít alternativní postupu a rozhodovat o nich v rozsahu pověření, 17

-

zastupovat zájmy zákazníka, a to zároveň a v souladu se zájmy společnosti, která ho řízením projektu určila.[2] Z těchto globálních cílu určující odpovědnosti jakéhokoli manaţera, můţeme odvodit

konkrétní odpovědnosti manaţera projektu: -

Řízení zdrojů projektu, především: Času, prostřednictvím řízení harmonogramu, Pracovní síly tvořící z projektového týmu, Finančních prostředků určených projektu, Hmotných prostředků – materiálů, budov a zařízení, Informačních technologií.

-

Plánování a kontrola postupu projektu ve smyslu: Efektivního vyuţití zařízení a optimálního výkonu subjektů účastnících se na projektu, Koordinace a integrace dodávek, Sníţení projektových rizik a optimalizace řešení problémových situací, Předcházení neţádoucích konfliktů nebo řešení těch nevyhnutelných ve prospěch projektu.

-

Řízení ostatních subjektů a procesů, to znamená: Produktu, který má být projektem vytvořen, a to z pohledu schopnosti i vlastnosti spolupráce s okolními systémy, pokud to zadání poţaduje, Vztahů mezi projektem a jeho okolím, včetně vztahů k managementu společnosti a vztahů se zákazníkem, Všech informačních toků s vazbou na projekt.[2] Jaký by manaţer projektu měl být?

Dobrý projektový manaţer by měl mít celou řadu schopností, zkušeností a dovedností. Pokud se zaměříme na obor IT, tak by měly být následující: -

základní okruh znalostí poznatků pro řízení projektu,

-

poznatky, standardy a předpisy pro příslušnou oblast

-

poznatky ohledně prostředí projektu, 18

-

obecné poznatky a dovednosti řízení

-

sociální dovednosti (soft skills) neboli umění vycházet s lidmi. Projektové prostředí se liší nejen mezi organizacemi, ale dokonce i mezi projekty

v jedné organizaci, přesto ale existuje jistý okruh dovedností důleţitých ve většině prostředí. Jednou z těchto dovedností je schopnost porozumět změnám a způsobu činnosti organizace v rámci daného sociálního, politického a fyzického prostředí. Manaţer projektů by měl tyto změny vézt a zvládat, protoţe velké mnoţství projektů zavadí v organizaci nějaké změny, také samotné řešení projektů je samo o sobě plné změn. Projektoví manaţer by měl porozumět organizaci, ve které pracuje a musí vědět jakým způsobem se v ní vyrábějí výrobky nebo produkují sluţby. Také musí pochopit obecné pojetí prostředí. Rozdílné vlastnosti a chování bude mít projektový manaţer v mezinárodní organizaci neţ projektový manaţer malé lokální firmy. [1,2] Další důleţité znalosti a dovednosti by měl mít z oblasti řízení. Rozumět by tedy měl nejdůleţitějším tématům souvisejících s finančním řízením, účetnictvím, obstaráváním, prodejem, marketingem, smlouvami, výrobou, distribucí, logistikou, dodavatelskými řetězci, strategickým plánováním, taktickým plánováním, provozním řízením, organizačními strukturami a chováním, řízení zaměstnanců, odměňováním, kariérním postupem a s ochranou zdraví a bezpečnosti práce. U některých projektů jsou velké znalosti a zkušenosti jedné, či více oblastí pro projektového manaţera ţivotně důleţité. V některých projektech však můţe delegovat těmito povinnostmi nějakého člena projektového týmu nebo externího dodavatele. Ale i v tomto případě musí být manaţer natolik inteligentní a schopný, aby věděl komu můţe tuto odpovědnost dát. Musí také učinit všechna důleţitá rozhodnuti nebo za ně převzít plnou odpovědnost. Pokud chce manaţer projektu dosáhnout vysoké efektivnosti při řízení projektů je nezbytné ovládat taká sociální dovednosti (soft skills) neboli umění vycházet s lidmi. Do těchto schopností lze zařadit efektivní komunikaci, ovlivňování organizace směrem ke splnění úkolu, motivace, vůdčí schopnosti, zvládaní konfliktů, vyjednávání a řešení problémů. Proč vlastně by manaţer projektu měl mít tyto vlastnosti a dovednosti? Jeden z důvodu je, ţe by měl porozumět očekáváním a potřebám jednotlivých účastníků, orientovat se v nich a plnit je a právě z těchto důvodů musí vést, komunikovat, řešit problémy a ovlivňovat organizaci jako celek. Dalším úkolem projektového manaţera týkající je umět lidem naslouchat, napomáhat vzniku nových přístupů k řešení problémů a všechny ostatní přesvědčit, aby 19

společně spolupracovali ve prospěch dosaţení cíle, dokončení projektu. Projektoví manaţery musejí umět vést svůj tým a také umět delegovat lidi uvnitř týmu. Důleţité také je vytvoření dobrého, energického pracovního prostředí a být dobrým příkladem. Projektový manaţer se musí umět zaměřit také na dovednosti týmové práce, aby dokázal vyuţít individuálních schopností jedinců ve prospěch týmu. Nezbytnou součástí jeho práce je motivace typově odlišných

lidí

a docílit toho, aby se kaţdý člověk cítil jako důleţitá součást projektového týmu. Člověk ve funkci projektového manaţera musí zvládat stres, stejně tak i kritiku a rychle se vypořádávat se změnami. Mezi jejich vlastnosti by také měli patřit kreativita, přizpůsobivost, dochvilnost a zejména zodpovědnost. Jak jsme zjistili výše, projektový manaţer je jedním z nejdůleţitějších článků celého projektu. Také jsme si řekli ţe vede projektový tým, proto si o něm něco povíme v následujících řádcích.

1.5

Projektový tým

Projektový tým je skupina osob, které se podílejí na splnění cílů projektů a dobu projektu jsou pod vedením projektového manaţera a to jak v přiděleném čase, nebo pracovní kapacity a v rámci přidělených oprávnění a odpovědností. Projektový tým je hlavním realizačních článkem projektu. Náplní osob v tomto týmu je realizovat určitou jednotku práce s jasně určeným zadáním, poţadovaným výsledkem, v definovaném časovém úseku a s určeným předpokladem pracnosti.[2] Rozloţení odpovědnosti projektového týmu: -

Projektový tým je seskupení jednotlivců do pracovního týmu s platností po dobu existence projektu.

-

Pracovní vytíţení jednotlivce můţe být vyčleněno na práci v projektovém týmu aţ do 100% jeho kapacity. Následné vyšší nároky mohou nastat pouze se souhlasem jeho liniového manaţera a manaţera projektu, a to v souladu s rozpočtem projektu.

-

V době vyhrazené pro realizaci konkrétního projektu podléhá tento jednotlivec řízení manaţera projektu.

-

V případě kdy není jednotlivec přidělen na plnění projektového úkolu na svou plné pracovní vytíţení, pak ve zbývajícím čase podléhá řízení svého liniového manaţera, nebo manaţera jiného projektu. Pokud dojde ke konfliktu potřeby času na výkon jednotlivých úkonů a ohroţení termínu splnění úkolu, pak toto dotyčný oznámí 20

manaţerovi projektu, který situaci projedná s příslušným liniovým manaţerem nebo manaţerem konkurujícího projektu. -

Za odbornost a kvalitu pracovního výkonu jednotlivce v čase přiděleném na realizaci konkrétního projektového úkolu odpovídá liniový manaţer.

-

V případě obsazení jednotlivce po dohodě manaţera projektu a liniového manaţera pro realizaci určitého pracovního úkolu projektu, stává se členem projektového týmu a musí být seznámen s předmětem úkolu a s jeho předpokládaným rozsahem z pohledu vynaloţeného času.

-

Případné dotazy, připomínky, upřesnění, poţadované změny nebo úpravy předpokládané pracnosti projednává člen projektového týmu s manaţerem projektu, a to v okamţiku, kdy tyto skutečnosti nastanou.

Výše uvedená pravidla jsou obecná, a proto se mohou lišit v různých společnostech podle jejich zvyklostí a interních metodik. Na obrázku 1.3 lze vidět zjednodušenou organizační strukturu projektu bez konkrétních odpovědností, profesí nebo jmen.

Obrázek 1.3: Příklad obecné organizační struktury projektu

Zdroj: Svozilová, A. Projektový management. s. 34

Při obsazováním jednotlivých pozic v projektovém týmu jsou důleţité následující skutečnosti: 21

-

odbornost,

-

dostupnost v čase vzhledem k harmonogramu,

-

náklady na výkon činnosti podle popisu vzhledem k rozpočtu,

Jedna z výhod projektového řízení je, ţe nasazení členové projektového týmu jsou přiděleni jen po dobu trvání projektu a poté jsou uvolněny na jiné projekty, coţ umoţňuje větší flexibilitu a efektivitu při jejich vyuţívaní. V projektovém týmu se po určitou dobu setkávají specialisté z různých odborných úseků společnosti, provedou svůj díl práce a poté se vracejí na své oddělení nebo jsou vyuţiti na jiném projektu. Po dubu nasazení do projektového týmu stále přetrvává slabá řídící vazba mezi dotyčným jedincem a jeho mateřským oddělením. Toto oddělení je odpovědné za: -

kvalitu a odbornou úroveň výkonů člena projektového týmu,

-

kvalifikační poţadavky, pokud nejsou součástí náplně projektu

-

provozní úkony spojené s pracovní příslušností jednotlivce ke společnosti – zajištění úkonů, jako je evidence pracovní doby, mzdové účetnictví, zdravotní pojištění, spoření atd.

1.6 Ţivotní cyklus projektu a fáze projektu Projekt je svým charakterem podobný procesu, coţ znamená, ţe v době své existence se vyvíjí a nachází se v různých stadiích, které nazýváme ţivotním cyklem projektu. Existuje celá řada definic, co je ţivotní cyklus projektu, ale neexistuje ţádná shoda ani mezi teoretiky, hospodářskými sektory a ani mezi jednotlivými společnostmi. Pokud bychom na projekt aplikovali teorii systému podle Aleny Svozilové2, pak lze definovat základní rozdělení na následující fáze:[1] -

Konceptuální návrh – formulace základních záměrů, hodnocení dopadů a přínosů, realizace projektu, odhady času a nákladů potřebných na vlastní realizaci, předběţná analýza rizik

-

Definice projektu – podstatě se jedná o zpřesnění výstupů první fáze – rozdělení cílů, příprava metodik a dostupných znalostí a dovedností, nasazení realistického časového rámce a přepočet nákladů, určení rizik a předpokládaných dopadů, příprava detailních plánů na realizaci projektu

2

Strana 37

22

-

Produkce – vlastní realizace projektu. Do této fáze spadá řízení prací a dodávek, kontrola postupu podle harmonogramu, kontrola kvality a dosaţeních jednotlivých dílčích cílu.

-

Operační období – vlastní uţívání předmětu projektu. Jedná se o integraci projektu do existující struktury podniku. Také zde dochází k hodnocení dopadů na jednotlivé aspekty organizace.

-

Vyřazení projektu – převedení předmětu projektu do stadia podpory, převedení zdrojů na jiné projekty, zpracování poučení a získaných zkušeností z řízení daného projektu. Rozdělením jednotlivých realizačních aktivit do logického sledu nám pomůţe

zlepšit podmínky pro kontrolu jednotlivých procesů. Dále to usnadní orientaci všem účastníkům projektu a tím zvýší pravděpodobnost celkového úspěchu.[2] Obecně lze říci, ţe fáze ţivotního cyklu projektu definují: -

jaký typ práce má být vykonán v příslušném stádiu rozvoje projektu,

-

jaké konkrétní výstupy jsou v jednotlivých fázích generovány, jak jsou ověřovány a hodnoceny,

-

kdo se zapojuje do aktivit projektu v jeho jednotlivých úsecích. Fáze ţivotního cyklu jsou úseky, jimţ v daném časovém období odpovídá stav

projektu. Přechod z jedné fáze do druhé je uskutečněn poté, co je dosaţeno předem definovaného stavu projektu, případně souboru plánovaných dílčích výsledků. Přechod je zpravidla proveden na základě schvalovacího procesu, který konstatuje připravenost pro přechod do další fáze. Na obrázku 1.4 lze vidět, jak v jednotlivých fázích projektu dochází k zapojování různých zdrojů projektu od ideologických myšlenek aţ po plné vyuţití zdrojů projektu. Naproti tomu jsou postupně generovány výstupy projektu. Tyto výstupu mají charakter výsledků výkonu řízení a vlastního produktu projektu. Můţe se stát, ţe rozsah a charakter projektu bude vyţadovat rozčlení střední fáze na dílčí etapy, jejichţ výsledky jsou definovány mezivýstupy projektu.[2]

23

Obrázek 1.4: Typické rozložení fází životního cyklu projektu

Zdroj: Svozilová, A. Projektový management. s. 38

Jak uţ jsme si řekli, přechod mezi jednotlivými fázemi, je realizován pomocí schvalovacího procesu, na jehoţ základě je rozhodnuto, zda-li bude projekt pokračovat podle planu nebo dojde k aplikaci opatření. V případě zjištění velkých rozdílu mezi skutečným a plánovaným stavem, nebo při zvýšeném výskytu a působení rizik se můţe stát, ţe je rozhodnuto o přerušení či předčasném zrušení projektu.

24

Obrázek 1.5: Typický průběh čerpání nákladů v průběhu životního cyklu

Zdroj: Svozilová, A. Projektový management. s. 39

Obrázek 1.6: Typický průběh nasazení lidských zdrojů v průběhu životního cyklu

Zdroj: Svozilová, A. Projektový management. s. 40

U některých projektů se lze setkat s velkou mírou neurčitosti. V tomto případě není volen přístup plánu pokrývající celý projekt od začátku do konce, ale o realizaci dalších fází

25

je rozhodnuto aţ po vypracování studie proveditelnosti v přímé návaznosti na splnění předešlých podmínek.

Projekt v průběhu svého ţivotního cyklu mění celou řadu svých charakteristik: -

postupně čerpá zdroje, viz obrázky 1.5 a 1.6,

-

mění svojí odolnost proti dodatečným změnám, viz obrázek 1.7,

-

mění svojí citlivost vůči riziku z neurčitosti – postupně odstraňuje důvody jejich vzniku.

Vše co jsem se výše uvedl, platilo pro obecné fáze projektu. Jelikoţ jsou projekty různorodé i jejich fáze se mohou lišit nebo jak uţ bylo zmínění mohou se dále členit do dalších částí.[2]

Obrázek 1.7 Vliv zájmových skupin v průběhu cyklu projektu

Zdroj: Svozilová, A. Projektový management. s. 40

26

1.7 Projektové řízení Pokud bychom chtěly charakterizovat projektové řízení definicí, jedná se o „uplatnění veškerých poznatků, dovedností, nástrojů a technik na aktivity (činnosti) projektu takovým způsobem, aby byly splněny na projektu“3. Jednoduše tedy lze říci, ţe jde o způsob, jakým dosáhneme cílu projektu. Projektové řízení by nám tedy mělo pomoct ke zvýšení efektivity jednotlivých procesů v průběhu projektu, proto je často uplatňováno společnostmi, které si uvědomili, ţe na realizaci projektu promrhaly mnoho prostředků a udělali spousty chyb. Kvalitním projektovým řízením lze většinu těchto chyb odstranit. Projektové řízení lze tedy pojmout jako jakýsi projektový rámec zobrazený na obrázku 1.8. Klíčové prvky tohoto rámce zastupují účastnící projektu, oblasti poznatků pro řízení projektů, nástroje a techniky pro řízení projektů a přínosy úspěšných projektů pro podnik.[1]

Obrázek 1.8: Základní rámec řízení projektů

Zdroj: SCHWALBE, K. Řízení projektů v IT. s. 42

Účastníci projektu jsou zde zastoupeni osobami, které jsou zapojeny do projektu. Mezi ně patří

zadavatel projektu, projektový tým, podpůrný personál, zákazníci, uţivatelé

a i oponenti projektu. Jednotlivým účastníků uţ jsme se věnovali výše. Oblasti poznatků pro řízení projektu popisují nejvýznamnější schopnosti či kvalifikace, které by měl projektový manaţer ovládat. Uprostřed obrázku 1.8 můţeme vidět 3

Řízeni projektů v IT strana 41

27

všech 9 oblastí poznatků, přitom mezi hlavní můţeme zařadit řízení rozsahu projektu, řízení času, řízení nákladů a řízení kvality projektu. Můţeme o nich mluvit jako o základních oblastech poznatků, protoţe všechny vedou k naplnění projektu. Nyní se stručně popíšeme tyto hlavní oblasti: -

Řízení rozsahu projektu lze popsat jako definování a řízení veškerých prací, nezbytných k úspěšnému dokončení projektu

-

Řízení času v projektu představuje návrh časového plánu projektu, odhad doby nutné k dokončení prací a zajištění včasného dokončení projektu.

-

Řízení nákladů obsahuje přípravu rozpočtu projektu a jeho řízení.

-

Řízení kvality zaručuje, ţe projekt splní stanovené nebo předpokládané poţadavky. Další čtyři oblasti označujeme jako podpůrné – konkrétně se jedná o řízení lidských

zdrojů, řízení komunikací, řízení rizik a řízení obstarávání v projektu. Podpůrnými proto, protoţe definují procesy, jejichţ prostřednictvím dosahujeme cíle projektu. Tyto konkrétní oblasti jsou: -

Řízení lidských zdrojů se zabývá efektivním vyuţití lidí zapojených do projektu.

-

Řízení komunikací lze charakterizovat jako generování, shromaţďování, distribucí a uloţením informací o projektu.

-

Řízení rizik zahrnuje rozpoznání rizik, jejich analýzu a reakci na rizika týkající se projektu.

-

Řízení obstarávání obsahuje obstarávání zboţí a sluţeb pouţitých pro řešení projektu, pocházející z vnějších organizací. Poslední devátou oblastí je řízení integrace projektu. Tato oblast se prolíná všemi

předchozími oblastmi poznatků. Nástroje a techniky pro řízení projektů pomáhají účastníků projektu v práci ve všech devíti oblastech poznatků. Mezi nejrozšířenější nástroj v oblasti řízení času například Ganttovy diagramy, síťové diagramy a analýza kritické cesty4. V tabulce 1.1 nalezneme některé běţné pouţívané nástroje a techniky podle jedle jednotlivých oblastí.[1]

4

Kritická cesta je matematický algoritmus plánování průběhu mnoţiny činností projektu

28

Tabulka 1.1: Nejběžnější nástroje a techniky pro řízení projektů, podle oblasti poznatků Oblast (kategorie)

poznatků Nástroje a techniky Metody výběru projektu, metodologie řízení projektů, analýza účastníků, charta projektu,plán řízení projektu, software pro řízení projektů, výbor pro řízení změn, řízení konfigurace, kontrolní porady projektu, systémy pro autorizaci práce

Řízení integrace

Řízení rozsahu

Stanovení rozsahu projektu, struktura rozpisu prací, pracovní příkazy, plán řízení rozsahu, analýza požadavků, řízení změn rozsahu

Řízení času

Ganttovy diagramy, síťové diagramy (grafy) projektu, analýza kritické cesty, metoda PERT (Program Evaluation and Reviw Technique), plánování kritického řetězu,crashing, rychlé sledování (fast tracking), revize milníků

Řízení nákladů

Čistou současná hodnota, návratnost investic, analýza doby návratnosti, řízení portfolia projektů, odhady nákladů, plán řízení nákladů, finanční software

Řízení kvality

Six Sigma, diagramy řízení kvality, Paretovy diagramy, Ishikawovy diagramy, audity kvality, modely vyspělosti, statistické metody

Řízení lidských zdrojů

Motivační techniky, empatické naslouchání, týmové smlouvy, matice přidělení odpovědnosti, histogramy zdrojů, vyrovnání zdrojů, cvičení při budování týmu

Řízení komunikací

Plán řízení komunikací, řízení konfliktů, výběr komunikačních médií, komunikační infrastruktura, zpráva o stavu, virtuální komunikace, šablony, weby projektů

Řízení obstarávání

Analýza ,,make-or-buy“, smlouvy, žádosti o návrh nebo o nabídku, výběr zdroje, vyjednávání o smlouvě, elektronické obstarávání

Řízení rizik

Plán řízení rizik, matice pravděpodobnosti a důsledků, hodnocení rizik, simulace (metoda) Monte Carlo, sledování deseti nejrizikovějších položek Zdroj: SCHWALBE, K. Řízení projektů v IT. s. 45

Úkolem manaţera projektů a klíčových účastníků, je definovat, co bude představovat úspěch konkrétního projektu a za vyuţití vhodných nástrojů a technik úspěšně dokončit projekt. V dnešní době v mnoho organizacích tito manaţeři také podporují nově vznikající obchodní strategii takzvaného řízení portfolia projektů, uvnitř kterého organizace seskupuje a řídí projekty jako portfolio investic, které přispívá k celkovému úspěchu společnosti.

29

1.8 Project Management Institute (PMI) Project Management Institute (dále uţ jen PMI) je „mezinárodní profesionální sdruţení projektových manaţerů.“5 Toto sdruţení bylo zaloţeno v roce 1969 a stéle nabírá více členů, kterých bylo k květnu 2004 více neţ 133 000. Velké mnoţství členů PMI pracuje v oboru IT a více neţ 15 000 tvoří další skupinu plnící povinnosti v zájmové skupině Information System Specific Interest Group. Z důvodu, ţe na projektech pracují lidé z různých oborech, byly v PMI vytvořeny speciální zájmové skupiny (Specific Interest Groups, SIC), ve kterých si členové vyměňují informace, zkušenosti a nápady s řízení projektů v daném konkrétním oboru. V tomto rámci PMI pak tedy existují zájmové skupiny pro oblast letectví a obrany, pro finanční sluţby, zdravotní péči a mnohé jiné. Tato organizace je uţ zastoupena i ČR. [2]

2 Přehled významných SW nástrojů Jak uţ bylo řečeno v úvodu, dnes se k realizaci projektů pouţívají různé sowtvarové nástroje, které by nám především měli ulehčit práci. V dnešní době je na trhu dostupné nepřeberné mnoţství těchto nástrojů. Poslední dobou se pak zejména rozšiřuje počet webově orientovaných aplikací pro podporu řízení projektů. Vybrat proto jeden z tohoto nepřeberného mnoţství, který nám bude vyhovovat je projekt sám o sobě. V této části si tedy shrneme základní typy dostupných softwarových nástrojů pro řízení projektu.[2] Řada lidí stále pouţívá k různým úkolům při řízení projektů jen základní kancelářské aplikace, pomocí kterých například stanovují rozsah projektu, rozpočet, časový plán, nebo přiřazují jednotlivé zdroje. Jsou pouţívány namísto specializovaných nástrojů zejména pro to, ţe je lidé mají ve většině případů ve svém osobním počítači a umějí s nimi pracovat. Jak uţ jsme ale zmínili, existuje velké mnoţství speciálních softwarových nástrojů právě pro řízení projektu, ty pak lze rozdělit podle úrovně funkcí a ceny do tří kategorií:[2]

5

-

Nástroje niţší třídy

-

Nástroje střední třídy

-

Nástroje vyšší třídy

Řízení projektů v IT strana 60

30

2.1 Nástroje niţší třídy Nabízené funkce těchto nástrojů jsou jen základní a cena by neměla přesáhnout 200 dolarů na jednoho uţivatele. Tyto nástroje zpravidla neumoţňují skupinovou spolupráci. Dále také v mnoha případech umějí vytvářet Ganttovy diagramy, které jsou v běţných kancelářských aplikacích kreslí velice obtíţně. Jako zástupce této kategorie si můţeme uvést produkt Milestones Simplicity od společnosti KIDASA Software, Inc., jenţ nabízí uţivateli vytvoření Ganttova diagramu v sérii jednoduchých kroků. Tento nástroj je moţné pořídit za cenu niţší neţ 50 dolarů pro jednoho uţivatele. Dalšími zástupci v této třídě jsou různé doplňky pro Microsoft Excel nebo Micsrosoft Aceess od různých společností, které umoţňují základní funkcionalitu řízení projektu v známých kancelářských aplikacích.[1]

2.2 Nástroje střední třídy O jednu úroveň výše jsou pak nástroje střední třídy, které jiţ zvládají rozsáhlejší projekty a zároveň práci více uţivatelů na více projektech. Všechny tyto nástroje také umějí vytvářet Ganttovi diagramy a síťové diagramy, navíc také pomáhají s analýzou kritické cesty, alokací zdrojů, sledováním postupu prací na projektu, vytváření zpráv o stavu projektu a jiné. Cena těchto nástrojů se pohybuje od 200 do 500 dolarů na jednoho uţivatele. Nejvýznamnějším nástrojem této třídy je zejména Microsoft Project. Mezi další společnosti zasahující svými nástroji do této třídy patří například Artemis, PlanView, Primavera a Welcom.[1]

2.3 Nástroje vyšší třídy Poslední třídou softwarových nástrojů pro řízení projektů tvoří vrcholové produkty, které jsou občas označovány jako software pro řízení podnikových projektů. V těchto nástrojích jsou obsaţeny robustní funkce, pomocí kterých zvládají i velmi velké projekty, umoţňující práci skupin, a nabízejí speciální funkce podnikové úrovně, které sdruţují informace z jednotlivých projektů celé organizace. Licencování těchto nástrojů je ve většině případě zaloţeno na počtu uţivatelů daného produktu. Také bývají integrovány s databázovým softwarem na podnikové úrovni a jsou dostupné přes internet. Jedním z produktů od společnosti Microsoft je Enterprice Project Management vydaný v roce 2002, který byl v roce 2003 nahrazen novým řešením Microsoft Enterprice Project Managment Solution. Jedním z příkladů webového nástroje z této třídy je VPMi Enterprice Online, který stojí pouhých 12 dolaru na jednoho aktivního uţivatele měsíčně.[1]

31

2.4 Výběr softvarových nástrojů Jak uţ bylo napsáno výše, na trhu je obrovské mnoţství softwarových nástrojů a proto při vybíraní konkrétního produktu je třeba brát v potaz celou řadu podmínek, vlastností a funkcí, které budou odpovídat potřebám pouţití v konkrétních hospodářských odvětví, strategickým záměrům a technologickým moţnostem společnosti. Analýzou z které můţeme identifikovat potřeby, je prověření rozsahu a metod projektového managementu v podniku. Určitě jiné potřeby bude mít podnik, který bude dodávat implementaci rozsáhlých informačních systémů, neţ podnik, který formou projektů bude realizovat občasný interní rozvoj.

2.5 Funkce sowtvarových nástrojů Jak uţ jsme si popsali v předchozí kapitole, řízení projektů zahrnuje devět rámců, a proto i softwarové nástroje pro podporu řízení projektů mají různé funkce. Dokonce by se dalo říci, ţe některé tyto aplikace nejsou ani určeny k řízení projektů. Některé tyto aplikace jsou primárně určeny pro jiné účely, ale jejich uplatnění se najde i v tomto oboru. Funkce aplikací pro podporu řízení projektů tedy jsou:[5] -

Sdílení a správa dokumentů

-

Elektronická komunikace

-

Správa úkolů

-

Podpora projektového řízení

-

Vizualizace Sdílení a správa dokumentů Je důleţité umoţnit přístup členům projektového týmu k jednotlivým dokumentům

na základě přístupových práv a to z důvodu, ţe projektu se účastní mnoho lidí, kteří potřebují různé informace. Nastavení přístupových práv má dobře zvládnutý systém Microsoft Server, stejně pak lze tento systém zastoupit freewarovým6 Linux Serveru. Dále je moţné vyuţít moţné některé webové systémy. Dalším systémem, který lze vyuţít i ze vzdáleného místa, pokud je zde připojení k internetu je pomocí FTP protokolu7.

6 7

Freeware je sowtware distrubuovaný bezplatně. FTP (File Transport Protokol) je protokol je v informatice protolol pro přenos souborů v počítačové síti.

32

Elektronická komunikace Nezbytnou součástí řízení je také komunikace. Tato část je v celku dobře vyřešena, protoţe standardních mailových řešeni je hned několik. Mezi nejznámější zástupce patří Microsoft Outlook a Exchange Server. I mezi freewarovýmí aplikacemi zle nalézt několik kvalitních zástupců jako jsou Thunderbird a Mutt. Dále na trhu jsou další aplikace určené ke komunikaci, jako je například Skype, nabízející také videokonferenci, ICQ, Microsoft Live Messenger a jiné. Správa úkolů Kvalitních „taskových“ nástrojů mnoho není. Například úkolovník Microsoft Outlook mezi ne počítat nelze. Základními funkcemi takového systému by mělo být přiřazování priorit, moţnost přiřadit jednotlivé úkoly částem projektu a také jednotlivý účastníkům projektu, export aktuálních denních úkolů přiřazené konkrétní osobě a zároveň napojení těchto expertů na komunikační systém, přidávání poznámek a sledování stavů úkolů. Mezi tyto nástroje by s určitým omezením šel zařadit freewarový nástroj BugZilla. Podpora projektového řízení Nástroje obsahující tuto funkci umí vést informace o jednotlivých činnostech, ukazovat vzájemné vazby mezi jednotlivými činnostmi a seskupovat činnosti patřící k sobě do skupin. Důleţitou částí je, ţe tyto nástroje dokáţou najít kritickou cestu projektu a zobrazit Ganttův diagram s příslušnými informacemi o činnostech a zdrojích poţadovaných pro provedení této činnosti. Nejlépe by pak měli být napojeny na systémy správy úkolů, z důvodů přiřazení úkolů jednotlivý účastníkům projektu a k získaní jejich zpětné vazby a stavu. Do této kategorie můţeme zařadit Microsoft Project, z freewarových nástrojů je to potom Open WorkBench. Vizualizace Tyto nástroje usnadňují přípravu schémat, data flow diagramů, datových modelů a procesů. Zástupce této kategorie je pak Microsoft Visio

33

3 Metodika ASAP Abychom mohly říct k čemu nebo kde je metodika ASAP vyuţita, je třeba si nejdříve říct co je to SAP. SAP8 je firma zabývající se vývojem ERP systému. Tyto systémy jsou velice komplexní a jsou poţívány většinou středních a velkých firem. Jelikoţ implementace takto velkých a rozsáhlých systémů byla sloţitá a časově náročná, z čehoţ plynuly i vyšší náklady, SAP vyvinula implementační řešení Accelerated SAP (dále uţ jen ASAP), které se v roce 1997 stalo firemním standardem. Podnícení vývoje ASAP proběhlo v roce 1995 ve Spojených státech amerických, kdy sytém SAP R/3 byl velice úspěšný u velkých společností, ale na straně druhé byl odmítán trhem s velkým potenciálem růstu a to středními a malými společnostmi. Důvodem nebyla chybějící funkcionalita systému ani cena, ale právě náročnost implementace tohoto systému. Jak uţ název této práce napovídá, měla by se věnovat softwarovým prostředkům, proto je moţné ţe název metodika trochu klame. Pro ASAP lze totiţ velmi těţké najít stručné a vytíţené pojmenování, neboť se jedná a soubor sloţený z řady různorodých komponent, jejich sjednocující prvek je metodika, které dohromady umoţňují efektivní a rychlou implementaci systému SAP R/3. Struktura ASAPu je patrná z obrázku 3.1, kde lze vidět, ţe ASAP podporuje celý ţivotní cyklus projektu v uzavřeném cyklu. Z hlediska projektového řízení lze implementační postup rozdělit do pěti fází. Kde v kaţdé fázi jsou jasně definované vstupy, obsah a výstupy. Tyto fáze se nazývají: -

Příprava projektu (Project preparation)

-

Cílový koncept (Business Blueprint)

-

Realizace (Realization)

-

Příprava produktivního provozu (Final Preparation)

-

Produktivní provoz (Go Live and Support)

8

SAP je jméno firmy, která má sídlo ve Walldorfu v Německu. Její jméno vzniklo na základě zkratky

S = systeme, A = anwendugen, P = produkte in der Datenverarbeitung a v angličtině znamená Systém applications produkt in data processing.

34

Obrázek 3.1: Struktura ASAP

Zdroj: Implementační metodika ASAP

Z těchto pěti fází se skládá jedna etapa projektu. V případě rozsáhlých projektů se můţe skládat z více etap například v první etapě, budou implementovány moduly logistické a v druhé fázi moduly účetnictví. Jednotlivým fázím se budeme věnovat v této kapitole o trochu později. Jak jiţ bylo zmíněno ASAP se skládá z růţných komponent a ty jde rozdělit na tři hlavní skupiny: -

metodologie

-

nástroje

-

sluţby

3.1 Metodologie Stavebník kamenem metodologie obsaţené v způsobu implementace ASAP je Implementační asistent a v něm především Itinerář (Roadmap) zobrazený na obrázku 3.2 popisující jednotlivé aktivity procesu výstavby informačního systému rozčleněného do pěti fází. Zahájením produktivního provozu však tato „cesta“ nekončí. Jako další itineráře jsou k dispozici itinerář pro trvalou podporu zákazníka a itinerář upgrade systému na vyšší verzi apod.

35

Obrázek 3.2: Itinerář

Zdroj: CD ASAP

3.2 Nástroje Nástroji rozumíme dokumenty a programy soustředěné v počítači jako Implementační asistent (Implementation Assistant), integrující dokumenty, techniky a nástroje pouţívané v průběhu implementace podle itineráře, z nich mezi nejvýznamnější patří: -

Q&Adb (Question & Ansfer Databáze) – databáze otázek a odpovědí na ně. Pomocí tohoto nástroje jsou schopny společnosti implementující nový systém získat odpovědi takovým způsobem jak jsou definovány ve vnitřní struktuře systému R/3.

-

Implementační itinerář (Implementation Roadmap)

- popis implementace systému

R/3 bod po bodu. Popisuje postup implementace strukturovaně ve čtyřech úrovních – fáze, skupina úloh, úloha, aktivita. -

Změnový itinerář (Continous Change Roadmap) – doplňuje implementační itinerář o aktivity v průběhu produktivního provozu. Obsahuje průběţnou podporu uţivatelů systému, zlepšování provozních vlastností a rozvoje funkcionality i při archivaci dat a správě systému.

-

Upgrade itinerář (Upgrade Roadmap) popis přechodu systému na vyšší verzi. Je začleněn to stejných pěti fází jako implementační itinerář.

-

BPM (Bussines Process Masterlist) – definice rozsahu projektu. Rozsah projektu je určen na základě scénářů a transakcí systému R/3, které budou v průběhu implementovány.

36

-

Knihovna návodů (Knowledge Corner) – znalostní databáze zahrnující detailní popis procesů a funkci systému R/ 3 spolu implementačními příručkami k dané oblasti. Pro národní verze se zavádí Country Corner s lokálně platnými informacemi.

-

Akcelátory (Accelerators) – řada předem připravených dokumentů a nástrojů obsaţených v implementačním asistentovi podporující do kterých stačí pouze doplnit správně informace. Výsledkem toho je přehledná a ucelená dokumentace projektu.

-

Databáze poţadavků (Issue Database) – slouţí k evidenci poţadavků na vlastnosti informačního systému a problémů vzniklých během implementace a k následnému řešení těchto problémů.

-

CCT (Concept Check Tool) - sada formulářů ověřující správnost pouţitých postupů

3.3 Itinerář Implementace Fáze 1. Příprava projektu Obecně můţeme říci, ţe pro kaţdý projekt ať uţ se týká čehokoli, je velmi důleţitá příprava. Základem předpokladem pro úspěšné dokončení projektu je podpora od vedení společnosti zákazníka. Pokud projekt implementace bude aţ druhořadým zájmem, není moţné zaručit jeho úspěšnost. A to z toho důvodu, ţe dnes informační systémy zasahují do všech částí podniku. V této fázi jsou ze strany zákazníka i ze strany implementující firmy vybrány osoby, které budou po dobu implementace tvořit projektový tým. Jejich úkolem je systém nastavit včas a ve 100% kvalitě. Celý projektový tým absolvuje sérií školení o implementační metodologii ASAP a o systému SAP R/3. Všichni členové týmu musí velice dobře rozumět jednotlivým oblastem, protoţe na nich potom bude záleţet jejich správné nastavení. Největší zodpovědnost v této fázi má vedoucí a sponzoru projektu. Jejich společným úkolem je stanovit hrubý rozsah projektu (jaké moduly budou implementovat, popř. jaké části těchto modulů). Toto velice zjednodušuje interní nástroj SAP – Project Estimator. Experti ze SAP na základě vstupů od zákazníka vyčíslí předpokládané náklady na projekt, potřebu lidských zdrojů a přibliţný časový harmonogram. Tyto údaje jsou pak pouţity jako vstupy pro plánování projektu implementace systému SAP R/3. Vedení projektu je komplexní úkol. Na ţádnou z částí se nesmí zapomenout, vţdy musí být jasné, kdo je za co zodpovědný a jaký je termín pro splnění úkolu. Popis standardů 37

projektu (dokumentace, organizace projektového týmu, porady, atd.) jsou obsaţeny v komplexním dokumentu – „Definice projektu“. Nedílnou součástí je i hrubý plán projektu. Detailní plánování je provedeno vţdy aţ na počátku nové fáze. Kaţdý projekt musí mít určeny hlavní postupy implementace, mezi něţ patří konfigurace procesů, testování, nastavení autorizací pro jednotlivé skupiny uţivatelů a způsob řešení případných chyb. Při oficiální zahájení projektu dojde k formálnímu seznámení všech zúčastněných stran s cíly projektu. Účastníci tohoto zahájení jsou členové týmu zákazníka, implementačního partnera a firmy SAP. Úkolem techniků projektového týmu je určit základní poţadavky na hardware a objednat jeho dodání od hardwarového dodavatele. Na konci této fáze dojde ještě k prověření postupů a výstupů pomocí nástroje Concept Check Tool. Tento nástroj za pomocí jednoduchý otázek vede přes jednotlivé oblasti a na závěr Vám podá souhrnnou informaci, včetně doporučení pro odstranění problémů a to jak potenciální tak i skutečných. Tato činnost by měla být prováděna vedoucím projektu, jedná se o interní kontrolu kvality. Po dokončení fáze přichází expert SAP a provede kontrolu této fáze, která probíhá v jedno aţ třídenním sezení, podle metodologie kontroly kvality Review projektu. Poté je o všem vyhotoven podrobný zápis zdůrazňující případné problémové a rizikové oblasti, včetně doporučení pro jejich odstranění. Fáze2 – Cílový koncept Z důvodu aby implementovaný informační systém co nejpřesněji odpovídal představám podniku, je nezbytné přesně definovat vnitropodnikové procesy a interakci podniku s jeho okolím. Identifikací těchto vzájemných vazeb lze procesy optimalizovat a automatizovat. Detailním plánováním všech aktivit pro danou fázi zahajujeme tvorbu cílového konceptu. Úkolem vedoucí projektu je seznámí projekčního týmu a řídící výboru s novým plánem. Případné připomínky, či změny opět zaznamená do plánu projektu. Z důvodů, ţe popis struktury podniku musí být proveden s ohledem na strukturu informačního systému SAP R/3, je velmi důleţité důkladně proškolit členy projektového týmu v daných oblastech. 38

V této fázi mají techničtí pracovníci dostatek času na přípravu vývojového systému. Jejich úkolem je návrh technické infrastruktury její důkladná dokumentace. Následným krokem je postupná příprava celého systému (instalace vývojového systému, připojení a instalace koncových stanic, infrastruktura tisků, zřízení vzdáleného připojení, atd.). Pro rychlé zřízení vzdáleného připojení na systém podpory SAP partneři nabízejí standardní balík rcPack. Dále je třeba vytvořit systém klientů a nastavit k nim oprávnění v samotném systému SAP R/3. Úkolem projektového týmu je popsat organizační strukturu podniku. Jedná se o rozsáhlý úkol. Funkčnost budoucího informačního systému do značné míry závisí na jeho kvalitě. ASAP obsahuje akcelerátor „Dokument rozsahu projektové funkčnosti“, který odpovídá svou strukturou procesům v R/3.

Relevantním projektovým procesům jsou

přiřazeny zdroje a oblasti podniku, do nichţ proces zasahuje. Výsledek potom je hrubá koncepce pro implementaci. V momentě, kdy je popsána struktura podniku, lze postoupit k popisu jednotlivých procesů. SAP pro toto má specializovaný nástroj Questions&Answers Database (Q&Adb) pro snadnou údrţbu všech informací. Projektový týmu spolu s experty z implementující firmy zodpovídají sadu otázek ke kaţdému procesu a tím ho přesně definují. Kaţdému procesu odpovídá sada transakcí, které popisují jeho reálné zobrazení v R/3. Kaţdou transakci lze pomocí Q&Adb přímo spustit jak lze vidět na obrázku 3.3. Obrázek 3.3: Ukázka z metodiky ASAP

Zdroj: Výstup z metodiky ASAP(CD)

Výstupem této fáze jsou dva velice nezbytné dokumenty. Dokument „Cílový koncept“ obsahující všechny detailní popisy pro jednotlivé procesy, je tedy jakousi „příručkou organizace“. Kdokoli potřebuje vědět, jak podnik v dané oblasti pracuje, se můţe přímo 39

odkázat na relevantní část dokumentu. Proto je tento dokument neocenitelný zdroj informací a přeneseného know-how. Další dokument se nazývá „Základní seznam obchodních procesů“ a slouţí projektovému týmu při nastavování procesů v systému R/3. Jeho struktura je stejná se strukturou referenčního modelu R/3. Stejně jako po ukončení první fáze opět přijde expert SAP a v jednom aţ třídenním sezení proběhne kontrola právě končené fáze podle metodologie kontroly kvality Review projektu. O všem bude také proveden detailní zápis se zdůrazněním problémových a rizikových oblastí, včetně doporučení na jejich odstranění. Fáze 3 – Realizace Vedoucí projektu opět nejdříve stanoví detailní plán pro fázi realizace. Struktura plánování je stejná jako v ostatních fázích, plán musí být projednán s projektovým týmem a s řídícím výborem. Je třeba klást velký důraz na paralelní průběh všech akcí. Během této fáze členové projektového týmu absolvují školení 3. stupně a osvojí si detailní znalosti pro jejich oblast. Obsahem těchto školení je detailní osvětlení problematiky a jejím nastavení v systému R/3. Pomocí získanými znalostmi jiţ mohou začít s nastavováním základních funkčností systému. Jsou to hlavní procesy, na kterých je zaloţeno veškeré firemní podnikání. Procesy jsou většinou standardizované a jde pouţít standardních procesů R/3 bez velkých změn. Při nastavování základních funkčností platí pravidlo 80:20 (80% funkčnosti je nastaveno ve 20% času). Nakonec jsou všechny tyto funkčnosti detailně otestovány. Pro zpřehlednění, zjednodušení, nastavování a testování je vyuţíván dokument „Základní seznam obchodních procesů“ (BPML). Vybrané procesy jsou seřazeny do tabulky v programu Excel. Pomocí automatizace s vyuţitím maker je moţná procesní implementace jednotlivých procesů. Pouţitím Excelu lze z celého referenčního modelu podniku vyfiltrovány pouze ty transakce, jejichţ nastavením umoţníme vyuţití daného procesu v podnikovém informačním systému. Zároveň jsou vybrány i související oblasti v jiných modulech, protoţe velký důraz je kladen na vzájemnou provázanost procesů. V tuto dobu se technický tým zabývá strukturou a přípravou produktivního systému. Postup je stejný, jako u přípravy systému vývojového.

40

Zbývající funkčnosti sou navrhovány v tzv. cyklech. Nejprve jsou nastaveny procesy, na nichţ závisí procesy ostatní. K integraci dříve nastavených procesů dochází vyšších cyklech. Kaţdý cyklus je vţdy po svém ukončení důkladně otestován, k zajištění odpovídající kvality implementace. Nyní je vývojový systém nastaven a jsou v něm zaneseny všechny procesy definované ve 2.fázi, ale neobsahuje ţádná data, která podnik bude potřebovat, proto je nutné přistoupit k migraci dat ze stávajícího informačního systému do systému R/3. Pro moţnost komunikovat systému s produkty třetích stran, jsou přizpůsobována nebo vytvářena komunikační rozhraní. Ve většině případů implementace se stává, ţe standardní funkčnost systému R/3 přesně nevyhovuje potřebám podniku a proto se přistupuje k tvorbě rozšíření stávající funkčnosti. Toto rozšíření se realizuje pomocí programováním v objektově orientovaném programovacím jazyce ABAP/4. Čím více nestandardních funkcí budete vyţadovat, tím větší potenciální komplikace mohou nastat při upgrade systému na vyšší verzi.Všechna tato rozšíření budou muset být s kaţdou novou verzí systému opět testovány a upravovány. V nově nastaveném systému bude pracovat mnoţství uţivatelů. Abychom zajistili bezpečnost zpracování dat je nezbytné vytvořit tzv. autorizační koncepty. Za pomoci těchto konceptů zpřístupníme kaţdé skupině uţivatelů pouze pro ně určené části systému, včetně tvorby uţivatelského menu (pomocí programu Profile Generator). Uţivatelé tak nemusí sloţitě procházet celou rozvětvenou strukturu menu, ale mohou si vybrat jen z autorizací, jim určených. Jelikoţ firma SAP klade velký důraz na provázanost jednotlivých procesů ,musí vedoucí projektu vytvořit plán integračního testování systému. Toto testování probíhá opět v cyklech, kde první cyklus prověří vazby uvnitř modulu a druhý následné vazby mezi moduly. Důleţitým úkolem projektového týmu v této fázi implementace je vytvoření jednotné uţivatelské dokumentace detailně popisující zpracování jednotlivých procesů. Toto je nezbytné z důvodu, ţe pro většinu uţivatelů bude nový informační systém velkou neznámou. Dokumentace by měla obsahovat slovní popis s přiloţenými kopiemi obrazovek pro větší přehlednost. Jakoţ to i ve dvou předchozích fází na závěr přichází expert SAP a opět v jedno aţ tří denním sezení provede kontrolu této fáze podle metodologie kontroly kvality Review 41

projektu. O všem je zřízen zápis a jsou zdůrazněny případné rizikové a problémové oblasti i jejich případné odstranění. Fáze 4 – Příprava produktivního provozu Úkolem vedoucí projektu je stanovit detailní plán pro fázi realizace. Struktura plánování se nemění a je stejná jako pro ostatní fáze, plán je projednán s projektovým týmem a s řídícím výborem. Protoţe uţ je nový systém připraven k produktivnímu provozu je třeba zaškolit jeho uţivatele. Pro provádění zaškolení vyuţijeme dokumentace pro koncové uţivatel, vytvořené v minulé fázi. Školení je nezbytné věnovat velká pozornost, protoţe právě na schopnosti koncových uţivatelů bezchybně ovládat informační systém závisí bezproblémový chod organizace po přechodu do produktivního provozu. Dále je třeba důkladně otestovat budoucí produktivní systém, zda vydrţí nápor pracujících uţivatelů. Toto lze zjisti provedením dvou testů – zátěţový a objemový. Puštěním Zátěţového test simulujeme přihlášení velkého mnoţství uţivatelů a tím ověříme jeho vliv na dobu odezvy systému na poţadavek. Průchodnost velkého mnoţství dat systémem otestujeme Objemovým testem. V případě, ţe vše aţ doposud proběhlo hladce, systém by měl být připraven na přechod do produktivního provozu. Zde je nutné detailní naplánování a poté provedení dle daného plánu. Jakoţ to i předchozích fází přichází expert SAP, který provede kontrolu kvality. Opět je o všem pořízen podrobný pořízen zápis a zdůrazněny problémové oblasti pokud jsou. Fáze 5 – Zahájení produktivního provozu a podpora Během několika následujících týdnů po přechodu systému do produktivního provozu je třeba zajistit nepřetrţitou podporu pro koncové uţivatele ze stranu Local Supportu zákazníka. Z velkou pravděpodobností se bude jednat o mnoho velice podobných otázek, které postupem času zmizí. Často jsou to otázky z důvodu uţivatelovo neznalosti nového systému. V této fázi také administrátoři systému sledují jeho výkon a případně ho dále optimalizují.

42

Na závěr vedoucí týmu sestaví hodnocení projektu. Je třeba se soustředit na zhodnocení dosaţení cílů projektu stanovených v počáteční fázi. Za formální ukončení projektu ze povaţuje podpis dokumentu o ukončení projektu mezi zákazníkem a implementující firmou. Obě strany zde odsouhlasí, ţe s výsledky projektu souhlasí a ţe projekt dosáhl předem vytyčených cílů. Metodologie ASAP se zaměřuje na celý ţivotní cyklus systému R/3 a ne jenom pouze na jeho implementaci. Proto jsou připraveny další dva itineráře. Itinerář trvalé podpory zákazníka Tento itinerář lze díky speciálním poţadavkům zákazníků, kteří uţ uţívají systém v produktivním provozu rozdělit na čtyři samostatné body: -

Dodatečná školení – Z důvodu příchodu nových zaměstnanců je třeba provádět důkladná školení.

-

Optimalizace běhu systému – Kaţdý systém se vyvíjí, a to jak z pohledu mnoţství uţivatelů, tak z pohledu mnoţství přenesených dat.

-

Upgrade – Systém SAP R/3 se nepřetrţitě vyvíjí a tak poskytuje lepší rozsáhlejší funkčnost. V mnoho případech se stane, ţe dříve specifické funkce jsou jiţ zahrnuty v standardně v nově poskytované verzi. Metodologie ASAP má pro to svůj specifický itinerář, zmíněný níţe.

-

Archivace

- Jelikoţ systém je nepřetrţitě v provozu, časem dojde ke zpomalení

operací a diskový prostor se bude blíţit svému maximu. Proto je třeba archivovat stará data a zachovat integritu dat, aby data nebyla narušena. Itinerář upgrade Podobně jako samotná implementace systému, tak i upgrade je veden jako projekt. Stejně jako v případě implementace je rozdělen do pěti fází. Jelikoţ uţ jsme si celkem detailně vypsali fáze implementace a fáze upgrade systému jsou téměř totoţné jen si zmíníme jaké jsou a popíšeme jen základní rysy těchto fází. -

Fáze 1 – Příprava projektu upgrade – Přechod na navou verzi nebývá sloţitý. Detailní plánování je podmínkou úspěšného dokončení. Dochází zde k určení nákladů a určení členů projektového týmu. Je třeba dát si pozor, zda nebude potřeba nový hardware. 43

-

Fáze 2 – Cílový koncept – Tato fáze je při upgrade systému vynechána. Struktura organizace jiţ byla popsána při implementaci systému.

-

Fáze 3 – Upgrade testovacího systému a systému pro ověření kvality – Nejdříve je proveden upgrade testovacího systému na novou verzi. Systém sám upozorní kde je třeba manuálního zásahu. 4lenové projektového týmu zkontrolují a případně upraví nastavení oprávnění, rozhraní a zákaznických programů. Pokud se zdá být vše v pořádku dojde k přenosu do systému pro ověření kvality, kde dojde k detailnímu otestování, pro zajištěná bezchybné funkčnosti.

-

Fáze 4 – Upgrade produktivního systému – Je třeba upravit stávající dokumentaci z důvodů nových funkcí, s kterými budou muset uţivatelé pracovat. Koncoví uţivatelé by měli být seznámení s novými funkcemi prostřednictvím školení.

-

Fáze 5 – Zahájení produktivního provozu a podpora – po uvedení nové verze je třeba zajistit podporu koncových uţivatelů. Jeho ukončení je stvrzeno podpisem dokumentu o ukončení projektu, v němţ stvrzují, ţe obě strany jsou s výsledkem spokojeny a ţe projekt proběhl dle plánů.

3.4 Sluţby SAP, nebo partneři této společnosti nabízí jako součást procesu implementace rozsáhlou nabídku standardizovaných sluţeb nabízených všem uţivatelů systémů SAP R/3 nabízející: -

školení a vzdělávání – rozsáhlý systém vzdělávání o InfoDB – databáze informací, zabezpečuje celosvětově přístup ke všem školícím materiálům (na základě licence produktu)

-

Online Service System – on-line do systému OSS firmy SAP, nabízející informace jako jsou informace o novinkách firmy SAP, tvorba a odeslání dotazů při problémech se systémem, nahrávání změn v systému (Hot Package) a přístup k dalším sluţbám

-

Quality Checks – prostřednictvím programu Project Review lze nezávisle přezkoumat kvalitu implementačního procesu. Provádí se, jak bylo zmíněno na konci kaţdé fáze.

44

4 Vyuţití metodiky ASAP V této kapitole se budu věnovat konkrétnímu pilotnímu projektu a pouţít na něj metodiku ASAP. Jelikoţ tato metodika je nesmírně obsáhlá a komplexní, vybral jsem si jednu část z 5. fáze. Jedná se o úlohu „Uskutečnění školení koncový uţivatelů po zahájení provozu“. Tuto část jsem si vybral záměrně, protoţe ve své práci pracuji jako SAP Administrátor. Jedná se právě především o práci s uţivateli, jejich školení, či případné řešení problémů. Na následujících řádcích si blíţe popíšeme návody a rady i Itineráře. Poté v příloze bude ukázka jedno reálného školicího dokumentu. Hlavním cílem této úlohy je vyhodnotit výkon při provozu, a jaká další podpora v podobě školení je potřebná. V tomto případě dochází ke školení koncových uţivatelů, kteří jiţ byli školeni před zahájením produktivního provozu, ale bylo zjištěno, ţe je třeba dalších školení. Tyto školení je třeba vyhodnotit a vyvodit s nich závěry. Také je nezbytné stálá údrţba dokumentace a pro školení a plánů řízení vzdělávání. Tyta činnost je vykonávána po celou dobu ţivota systému SAP. Tato úloha má následující tři aktivity: -

Zhodnocení stálého výkonu a implementace zdokonalení

-

Uskutečnění školení koncových uţivatelů

-

Zajištění stálé podpory údrţby dokumentace a školení a řízeni know-how

4.1 Zhodnocení stálého výkonu a implementace zdokonalení Úkolem této aktivity je zhodnotit výkon školení koncový uţivatelů při provozu a implementovat proces zlepšení, který se definuje během fáze 3. Dochází zde k vyhodnocení výkonu koncových uţivatelů, posouzením školeních, která proběhla před produktivním provozem. Zle také provézt například pomocí formuláře vyplněného koncovými uţivateli, který by obsahoval otázky, v čem by potřebovali zlepšit, nebo co plně nechápou. Existují i jiné zpětné vazby neţ jen formulář. Poté by mělo dojít k analýze a identifikovat oblasti pro zlepšení. Je třeba promyslet zda-li můţe být školení nějak zlepšeno, aby koncoví uţivatelé splňovali výkonnostní měřítka. Za zváţení stojí také jestli by nebylo výhodnější místo školení na místo problémů dosadit koncového uţivatele experta, který by pomáhal při řešení problémů. Na závěr podle uváţení buď vytvoříme nové kurzy, ty existující upravíme poţadavkům, nebo vytvoříme programy podpory, abychom jsme zajistili vyšší výkonnost 45

koncových uţivatelů. Vţdy je třeba hledat důvody, proč koncoví uţivatelé nedosahují poţadované výkonnosti. Pokud je těchto uţivatelů více je třeba hledat důvody v kvalitě školících materiálů, v instruktorovi. Neměli bychom předpokládat, ţe vinu nese koncový uţivatel.

4.2 Uskutečnění školení koncových uţivatelů Cílem této úlohy je provést vlastní cvičení zaloţené na výsledcích předchozí kapitoly. Uţivatelé by v této fázi měli základní znalost systémových úloh a obchodních procesů, které potřebují k provádění jejich práce. Toto doplňující školení by se mělo zaměřit na oblasti, kde koncoví uţivatelé dělají chyby a je tedy proto nutné podrobnější školení. Je taky moţné ţe některé oblasti potřebné k jejich prací nebyly zahrnuty ve školení před zahájením produktivního provozu. Proto je třeba od koncových uţivatelů získat zpětnou vazbu jak jsme si popsali v kapitole výše. Nejlépe pak s nimi uspořádat neformální schůzku k stanovení oblasti, kde nejsou s pouţíváním spokojeni. Je třeba také myslet na to, ţe na kurzu mohou být uţivatelé, jeţ nemají základní kurz a proto od nich nelze očekávat dosaţení maximálního přínosu kurzu. Jestliţe kurz nebyl doposud vytvořen nebo navrţen a je třeba jej po zahájení produktivního provozu dodat, opakuje se vývojoví proces počínaje Vytvořením návrhu školení z fáze 3. Na následujících řádcích si představíme návrh nejdůleţitějších tipů, které je třeba mít na paměti jak před, tak i během provedení školení. Vyuţije jich jak zkušený tak relativně nový školitel. Mnohé tipy jsou všeobecně známé, a proto přejde velmi rychle do podvědomí. Techniky školitele -

Školitel by měl celé školení zahájit tím, ţe se představí, uvede se pravomoci a přednosti (zkušenosti se systémem SAP, délku práce na projektu apod.)

-

Definujte účel a podstatu školení, které bude provedeno.

-

Zajistěte, aby účastníci pochopili, z jakých důvodů se nachází ve školící místnosti a co můţou od školení očekávat.

-

Program a cíle výuky by měly být jasně podány a vysvětleny na začátku kaţdého kurzu.

-

Školitel by se měl vyvarovat trhavých/nervózních pohybů.

-

Měl by upravit spád slov, aby jeho projev nebyl monotónní.

-

Neměl by mluvit příliš rychle

46

-

Měl by rozpoznat, kdy je třeba mimořádná přestávka, aby účastnící byli schopni stále vnímat.

-

Školitel by se neměl obávat inovací.

-

Zajistit, aby výklad byl veden v logickém sledu. Postup podle programu, ale je moţné se od něj odchýlit, z důvodů probraní všech bodů.

-

V případě, ţe školitel nezná odpověď na nějakou poloţenou otázku, zapíše si jí do bloku a domluví se, jakou formou odpoví.

-

Pokud nějaká transakce nepracuje správně, neměl by se pokoušet o vyřešení tohoto problému, pokud se nejedná o nějakou formalitu a říct posluchačům jak by vše proběhlo za normální situace.

-

Všichni posluchači by se měli aktivně zapojit.

-

Je třeba být trpělivý i s méně chápavými posluchači, vyzvěte posluchače, aby si vzájemně pomáhali.

-

Noste pohodlné boty, školení bývají dlouhá a celou dobu při nich školitel stojí.

-

Školitel by měl znát obsah. Jeho důvěra v systém se přenáší na účastníky.

-

Vţdy mějte na pamětí oční kontakt. Volte vhodná slova, místo „obtíţný“ říkejte „náročnější“ apod.

-

Školitele by práce měla bavit, coţ se pak projeví i na dobrém rozpoloţení účastníků. Školící materiály

-

Školitel je seznámen s transakcemi/ systémovými úlohami.

-

Školitel je obeznámen se strukturou školení.

-

Existují data pro školení, jak pro samotnou prezentaci výuky, tak pro cvičení scénáře.

-

Zajistěte, aby cvičení/scénáře byly platné pro třídu.

-

Nenechávejte tisknutí školících materiálů na poslední chvíli

-

Při demonstraci transakci dbejte na následující: o určete klíčovou cestu transakcí. Pokud dáme uţivatelů více moţností, je moţné, ţe se snadno zahltí, o rozhodněte se, o kterých polích se zmíníte u kaţdé jednotlivé obrazovky, o při ukázce transakcí uveďte souhrnným způsobem dat, potřebná pro zadání. Příkladná ukázka je dobrým příkladem, o

určete informace, zvláště významné pro účastníky,

o zdůrazněte akce, které jsou pro SAP velmi typické, 47

o nenavrhujte alternativní cesty při prvním seznámení s transakcí, o nezapomeňte na diskuzi příkladů, o klaďte důraz na základní průchod trakcí, aby se uţivatelé netopili v detailech. -

Při provádění cvičení pamatujte na: o zkontrolujte cvičení a vyberte ta, která jsou pro třídu vhodná, o

zkontrolujte připravená dat, jestli jsou přiměřená,

o určete doplňková cvičení, pro získání praktických zkušeností, o buďte nápomocní, o obcházejte účastníky, aby jste byli jisti, ţe dělají správné cvičení, o berte v potaz návrhy.

Provozní zařízení/vybavení -

Zkontrolujte školící místnost před provedením školení.

-

Buďte v místnosti alespoň 30 min před zahájením školení.

-

Ověřte, zda je dostatek ţidli a PC.

-

Ověřte, ţe všechna PC jsou funkční.

-

Ověřte zda je moţné se na všech PC přihlásit do SAP

-

Podle moţností zapište program výuky a její cíle na prezenční listinu a připevněte jí na zeď.

-

Ověřte, zda jsou všechny školící místnosti správně popsány. Pro zpětnou vazbu ze školení nám slouţí dokumenty:

-

Zhodnocení školitele,

-

Zhodnocení školení,

-

Zhodnocení účastníků školení. Na základě těchto dokumentů můţeme připravit další školení, nebo upravit stávající.

4.3 Zajištění stále podpory a údrţby dokumentace školení a řízení zdělávání Cílem je dokončit a zkompletovat přenos znalostí ze školicího týmu a týmu vyvíjejícího dokumentaci k osobám, jeţ jsou označeny jako odpovědné za obsah stálého 48

školení a za údrţbu dokumentace. Pokračuje se vytváření dlouhodobého plánu řízení vzdělávání. Je třeba zhodnotit a posoudit aktuální stav stálé údrţby, aktualizace plánu a údrţby dokumentace z fáze 2. Dále je nezbytné ověřit zda existuje vhodná dokumentace, pokud ne, je třeba jí nahradit. Stále se pokračuje v práci s klíčovými osobami a vedoucím projektu, abychom zajistili sestavení dlouhodobého plánu řízení vzdělávání. Jedná se o naplánování dalších školení atd.

4.4 Konkrétní pilotní projekt Proto, abychom si mohli řící co znamená pilotní projekt, je třeba si obsajnit slovo „pilotní“. Pilotní znamená zkušební, zaváděcí, průzkumný. Pilotní projekt je tedy takový projekt, po jehoţ ukončení nebo v jeho průběhu dojte k analýze , testování výsledků, zjišťovaní nedostatků atd. Za konkrétní pilotního projekt jsem se zvolil trénink uţivatelů týkající se vytváření speciálních prodejních příkazů. Jedná se o prodejní příkazy vedené přes „Consignment Stock“. Cílem tedy je provést toto školení a následně ho zhodnotit. Tento konkrétní případ jsem si vybral z toho důvodu, ţe v Naší společnosti, jsem za tyto školení zodpovědný, bylo mnou skutečně provedeno. K rozhodnutí o provedení tohoto školení bylo poţádáno uţivatelem z týmu, který má na starosti prodej součástí a dílu týkajícícdh se „automotive průmyslu“9 a to především z důvodu, ţe jeden z hlavních zákazníků vyţadoval pouţití toho speciálního skladu. Jedná se o sklad, který je umístěn na straně zákazníka, avšak majetek, tedy zboţí umístěné v tomto skladu, je stále majetkem prodávající společnosti. Jaké z toho plynnou výhody? Výhody zde plynnou pro obě strany provádějící obchod. Jak pro stranu prodávající společnosti, tak i pro stranu kupující. Pro stranu dodávající zboţí je výhoda ta, ţe zboţí je jiţ u zákazníka a nedochází kde k prodlení vyplývající z doby potřebné k přepravě. Výhodou zákazníka je v tomto případě, ţe materiál zaplatí aţ v případě jeho skutečného vyuţití, nemá tedy bytečně uloţeny finanční prostředky v rezervách materiálu. Jelikoţ jsem s tímto typem prodejních příkazů neměl ţádnou zkušenost, poţádal jsem o radu a pomoc nadřízené osoby, která vedla celou implementaci SAP v naší společnosti. Zde vznikl malý komunikační problém týkající se časového pásma a vytíţenosti této osoby, protoţe společnost sídlí v Singapuru a momentálně probíhala implementace SAP 9

Automotiv průmysl, je průmysl zabývající se výrobou součástek pro automobilový průmysl

49

další pobočky v Malajsii. Veškerou komunikaci jsem tedy řešil prostřednictví emailu a pomocí aplikace Windows Live Messenger. Po získání informací o procesu tohoto prodeje, jsem vše otestoval na testovacím serveru SAP. Pokud se jedná o samotný proces tohoto druhu prodeje, více lze pochopit z obrázku 4.1. Obrázek 4.1: Proces prodeje

Zdroj: Školící materiál společnosti

Jak je vidět jiţ z obrázku tento prodej má dvě fáze. První fáze je vystavení prodejního příkazu do speciálního skladu. Druhá fáze je pak samotný prodej zákazníkovi v případě pouţití materiálu. V praxi to tedy znamená, ţe nejdříve se vytvoří prodejní příkaz do speciálního skladu, které musí následovat vytvoření dodacího dokumentu. Tento první proces nemá ţádný finanční dopad, protoţe jak uţ bylo zmíněno, zboţí je stále majetkem prodávající společnosti. K jediné změně ke které v systému dojde je, ţe zboţí uţ nevidíme na skladě, kde byl předtím, ale je moţné ho vidět na konkrétním speciálním skladu. K druhé fázi dochází po oznámení zákazníka, ţe došlo k pouţití materiálu ze speciálního skladu. V tomto případě je vytvořen prodejní příkaz z konkrétního speciálního skladu k zákazníkovi. I v tomto případě dochází k vytvoření dodacího listu a následného vyskladnění, ovšem na základě této operace, dochází i k operaci vzniku faktury, materiál totiţ změnil majitele. Toto lze ověřit i v systému po shlédnutí zásob na skladě, kde jiţ byl odečten materiál ze speciálního skladu. Pokud by došlo k vrácení materiálu od zákazníka zpět prodávající společnosti, dochází k opačnému procesu jeţ můţeme vidět na obrázku 4.2.

50

Obrázek 4.2 : Proces vrácení materiálu

Zdroj:Školicí materiál společnosti

Zaměříme-li se na tento proces má opět dva kroky, prvním je vrácení zboţí od zákazníka do speciálního skladu a následně vydání zboţí ze speciálního skladu zpět do skladu umístěného v prodávající společnosti. Opět se vše provádí pomocí určených prodejních poţadavků v SAP. První krok musí vyjma vystavení tohoto prodejního příkazu a následného vytvoření dodacího dokumentu obsahovat i krok vystavení dobropisu, protoţe v této fázi se z majetku kupující společnosti stává majetek Naší společnosti a je třeba se finančně vypořádat. Po pochopení všech procesu a jejich otestování v „QAS“10 bylo nezbytné zjistit kdo vše se školení bude účastnit a to z důvodu, abych věděl jakým způsobem školení připravit, zejména z důvodů uţivatelské dovednosti se systémem SAP. Dalším důvodem bylo jak rozsáhlé školení má být a zda–li by nebylo výhodnější ho rozdělit na více skupin, jak z důvodu mnoţství uţivatelů, tak i z důvodu, ţe je zde více operací z různých oddělení. Nakonec jsem uváţil, ţe je moţné udělat trénink najednou. Školení se tedy účastnili zástupci finančního oddělení, prodejního oddělení a odděleni logistiky. Další částí přípravy bylo zajištění materiálů pro trénink. Jelikoţ společnost ve které pracuji je mezinárodní, podmínkou bylo připravit materiály a školit v anglickém jazyce. Pro přípravu školící prezentace, jsem pouţil část materiálů, které jsem obdrţel uţ dříve od svého 10

QAS server je název testovacího serveru SAP v Naší společnosti

51

nadřízeného. Některé informace jsem také našel na internetu a k neposlední řadě jsem vyuţil obrázků pořízených během testování v „QAS“. Z těchto všech zdrojů jsem pak vytvořil prezentaci v anglickém jazyce, která byla pouţita pro toto konkrétní školení a je přiloţena v příloze jako příloha 1. Nezbytným úkolem také bylo zajistit výukovou místnost. Pro tento účel jsem zvolil jednu z našich zasedacích místností, kterou bylo třeba rezervovat pomocí firemního intranetu11.

Nejdříve bylo proto nutné zajistit vhodný termín. Z mé strany nebyl ţádný

problém, jelikoţ si svou práci mohu časově přizpůsobit. Zbylo tedy jen navrhnout termín a pomocí aplikace Microsoft Outlook rozeslal pozvánky k účasti. Po potvrzení všech uţivatelů jsem tedy uţ jen zamluvil zasedací místnost. Jelikoţ se školení mělo účastnit více jak 15 uţivatelů, zvolil jsem jednu z největších místností, kde uţ je nainstalovaný projektor. V samotný den školení jsem dorazil do zasedací místnosti o něco dříve, abych zkontroloval zda-li je v místnosti dostatek ţidlí, připojil notebook k projektoru, a prověřil jak prezentace bude vypadat při promítání. Poté co dorazili všichni uţivatelé, jsem si jako školitel vzal slovo. Jelikoţ mě jiţ všichni uţivatelé znali, představení mé osoby mi přišlo jako zbytečné, tudíţ došlo rovnou na informace, čeho se školení bude týkat a jak bude probíhat. Předem při rozesílání pozvánek byli uţivatelé informováni o předběţné délce školení. Naplánováno bylo okolo 30 minut pro samotné vysvětlení daného procesu a dalších 30 minut na případné otázky a diskuzi. Jelikoţ si myslím, ţe hodina není příliš, nebyla naplánována ţádná přestávka a pro odpočinek, či případné občerstvení. Po stanovení rozsahu školení, jsem uţivatele upozornil, aby si všechny případné nejasnosti a dotazy zapisovali a po skončení školení je přednesli. Nejdříve jsem se tedy věnoval samotnému vysvětlení procesu, k čemu slouţí a jaké výhody nám přináší. Následovali jednotlivé ukázky operací. Po mém přednesu došlo na otázky. Jelikoţ tato tématika nebyla příliš sloţitá, byl jsem schopen na všechny dotazy odpověď bez dalšího nutného studování daného problému. Jelikoţ ne všichni uţivatelé jsou schopni pochopit vše najednou, došlo i k praktické ukázce v „QAS“. Po ukončení školení jsem uţivatele poprosil o vyplnění příslušných formulářů. Jednalo se o formulář „Zhodnoceni školení“ a „Zhodnocení školitele“. Sám sem pak vyplnil formulář 11

Termín intranet můţe označovat interní webové, ale i rozsáhlejší informační nebo výpočetní počítačovou infrastrukturu. Například privátní internetové stránky, které slouţí jako infrastruktura pro interní komunikaci a spolupráci uvnitř firmy. Intranet pouţívá známé internetové protokoly jako jsou například HTTP, SMTP a FTP.

52

„Zhodnocení účastníků školení“. Jelikoţ všechny tyto formuláře jsou v českém jazyce, poprosil jsem česky mluvící účastníky, aby pomohli svým kolegům, kteří česky nehovoří, vyplnit formulář. Na tento problém jsme v přípravě školení zapomněl a do příště jsem se poučil a poskytl formuláře v obou jazycích, jak v anglickém tak i českém. Tato chyba byla také uvedena většinou uţivatelů nemluvících česky. Uţivatelé také byly informováni, kde je moţné najít školící materiály. Také po ukončení byly rozeslány dle listu účastníků školení na příslušné emailové adresy. Po zhodnocení formulářů vyplynulo, ţe uţivatelé tento nový proces pochopili a s mým výkladem byli v celku spokojeni. I přes toto kladné zhodnocení se našel jeden uţivatel, který problematice moc nepozoruměl a tomotu uţivateli jsem se pak věnoval individuálně při vysvětlování konkrétních případů. Co se týče samotného pilotního projektu, ten byl zhodnocen pozitivně a školení dále budou probíhat podle metodiky ASAP. Samotní uţivatelé jsou tomuto přístupu nakloněny také. Uţivatelé tedy budou informováni a plánu dalších školení. Velkým přínosem je zpětná vazba od uţivatelů, pomocí které, jsem byl schopen analazyvat kdo ještě potřebuje individuální přístup. Pomocí tohoto pilotního projektu bylo také zjištěno, ţe poskytnuté formuláře byly poue v českém jazyce, coţ se během jejich vyplňování ukázalo jako nedostatečné z důvodu, ţe školení se zúčastnili i uţivatelé nehovořící česky. Pro příští školení budou tedy formuláře připraveny v českém a anglickém jazyce. Celkově byl tedy pilotní projekt úspěšný.

53

Závěr Cílem této práce byl přehled významných sw nástrohů pro podporu řízení projektů. Prostřednictvím této práce, jsem si uvědomil, jak moc je v dnešní době plné změn, důleţitá disciplína řízení projektů, a jak důleţitou roly zde hraje osoba v podání manaţera projektu. Poté co jsem se zaměřil na softwarové nástroje pro podporu řízení projektu, a zjistil, ţe na současném trhu existuje nepřeberné mnoţství a druhů těchto nástrojů, jsem dospěl k názoru, ţe v první řadě je nejdůleţitějším úkolem vybrat ten správný nástroj, a to jak z hlediska ceny, náročnosti na uţívaní, hardwarovou náročností tak i vzhledem ke komptabilitě s jinými softwarovými aplikacemi a to především s nástroji sady MS Office, jakoţ to nevyskytovanější sadou kancelářských aplikací. Právě sloţitost výběru bych viděl jako jednu z nevýhod. Jedna z dalších nevýhod je komptabilita mezi jednotlivými nástroji, které

je

zapotřebí

z důvodu,

ţe jeden nástroj neobsahuje všechny funkce, které jsou pro řízení projektů zapotřebí. Pokud bych měl zhodnotit metodiku ASAP, byla pro mě na začátku velkou neznámou, i přes to, ţe pracuji jako SAP administrátor. Proto pro mě zpracování této práce bylo velmi naučné a přineslo mi mnoho poznatků. Myslím si, ţe tato metodika je velkým přínosem při implementaci informačního systému SAP. Největším problémem pro mě byla obsáhlost a pochopení samotného principu této metodiky. Nešlo se tedy detailně zaměřit na všechny aspekty této metodiky, a proto jsem se zaměřil pouze na poslední fázi samotné implementace, a to především z důvodu, ţe veškerá školení ve společnosi v které pracuji jsou prováděna mnou. Zaměřím-li se na své pracoviště a postupy, které jsou v Naší společnosti zavedeny, došel jsem k závěru, ţe u Nás metodika ASAP nebyla téměř vyuţita co se týče poslední fáze, zejména pak následných školení. Nemohu posoudit zda-li tato medotodika byla vyuţita při samotné implementaci SAP, jelikoţ jsem v této době ještě nebyl zaměstnám v této společnosti. Protoţe jsem za veškeré záleţitosti týkající se SAP zodpovědný, pomalu se snaţím této metodiky vyuţít. Pokud bych měl být konkrétnější dříve nebyla evidována školení ani neexistoval ţádný dokument o těchto školeních. Dále pak také neexistovalo jedno společné místo, kde by uţivatelé mohly najít různé materiály týkající se procesů v SAP. Neexistovala ani ţádná zpětná vazba od uţivatelů. Dokud tedy uţivatel nepřišel a nepoţádal o školení, ţádné se nekonalo. Proto se pomalu snaţím tyto zavedené „pořádky“ měnit. Co se týče vedení samotných školení je třeba se více zabývat jednotlivými znalostmi uţivatelů. Dále 54

také ne kaţdý uţivatel má kladný vztah k informační technice, zejména s těmito uţivateli je třeba mít trpělivost. Co se týče celkového pohledu na sw nástroje pro podporu řízení projektu, domnívám se, ţe největší překáţkou je neznalost těchto aplikací. Mým názorem tedy je, ţe pokud můţe být na středních školách věnován čas různým vývojovím aplikacím a následným cvičením zaměřených na tyto aplikace, bylo by vhodné studenty seznámit i s sw nástroji pro podporu řízení projeků. Pokud bych měl vybrat jeden nástroj vybral bych ten nejznámější a to MS Project. Uvědomuji si finanční náročnost týkající se zakoupení licencí pro případnou výuku, ale jiné aplikace, které se na školách vyučují nejsou o přiliš levnější, zda-li vůbec levnější jsou. Zejména bych toto uvítal na vyšších odborných školách, kde je více času věnováno praktických cvičením a zárovneň je zde větší předpokládat, ţe studenti budou v budoucnu zastávat pozice, kde by tyto zkušenosti uplatnili.

55

Seznam pouţité literatury Bibliografie [1]

SCHWALBE, Kathy. Řízení projektů v IT: Kompletní průvodce. Vydání první. Brno: Computer press, a.s., 2007. ISBN 978-80-251-1526-8.

[2]

SVOZILOVÁ, Alena. Projektový managment. 2., aktualizované a doplněné vydání. Praha: Grada Publishing, 2011. ISBN 978-80-247-3611-2.

Internetové zdroje [3]

OŠMERA, Jiří. Accelerated SAP: Implementační řešení pro malé a střední podniky. [online]. [cit. 2012-04-26]. Dostupné z: http://si.vse.cz/archive/proceedings/1999/accelerated-sap-implementacni-reseni-promale-a-stredni-podniky.pdf

[4]

Řízení projektů. [online]. [cit. 2012-04-26]. Dostupné z: http://www.rizeniprojektu.cz/

[5]

KALINA, Petra. Bakalářská práce: Řízení SW projektů. [online]. [cit. 2012-04-26]. Dostupné z: https://dip.felk.cvut.cz/browse/pdfcache/glumbp1_2009bach.pdf

[6]

Implementační metodika ASAP. [online]. [cit. 2012-04-26]. Dostupné z: http://www.sntcz.cz/solutions_services/67572.cz.php

[7]

Softwaroví podpora a public relations při projektové činnosti. [online]. [cit. 2012-0426]. Dostupné z: http://www.ccvj.cz/UserFiles/File/euprolek/M5/softwarova-podporaa-public-relations-pri-projektove-cinnosti-studijni-text.pdf

[8]

Pilotní projekt BPM. [online]. [cit. 2012-04-26]. Dostupné z: http://bpmtema.blogspot.com/2007/04/pilotn-projekt-bpm.html

[9]

Project Management Institute. [online]. [cit. 2012-04-27]. Dostupné z: http://www.pmi.org/

CD-ROM [10]

AcceleratedSAP – ASAP, ASAP for 4.6B, 2 CD, Červen 2000

56

Seznam příloh Příloha 1.....SAP tréninkový materiál

57

Příloha 1 SAP trénink – Consignment Stock Snímek 1

Consignment Stock training

Jan Macháček

Snímek 2

Purpose Consignment goods are goods which are stored at the customer location but which are owned by your company. The customer is not obliged to pay for these goods until they remove them from consignment stock. Otherwise, the customer can usually return consignment goods which are not required.

Jan Macháček

1

Příloha 1 SAP trénink – Consignment Stock Snímek 3

Jan Macháček

Snímek 4

STEPS

Consignment fill-up Consignment pick-up Consignment issue Consignment return

Jan Macháček

2

Příloha 1 SAP trénink – Consignment Stock Snímek 5

CONSIGNMENT FILL-UP

When you ship consignment stock to the customer, you record the transaction by creating a consignment fill-up order (order type KB). As a result, the system carries out the following actions: The relevant quantity is removed from regular inventory in your plant and is added to the special stock for the customer. The total valuated stock for the plant remains the same. The transaction is not relevant for pricing since the consignment stock remains the property of your company. Jan Macháček

Snímek 6

Consignment PICK-UP • If the customer returns consignment stock to you, you record the transaction in the system by creating a consignment pick-up order (order type KA). As a result, the system carries out the following actions: • When goods issue is posted, the relevant quantity is deducted from the customer’s special stock and is added back into your regular stock at the plant where the goods are returned. Your total valuated stock remains the same since the returned stock was regarded as part of your own inventory even while it was at the customer’s premises. • This transaction is not relevant for billing. Jan Macháček

3

Příloha 1 SAP trénink – Consignment Stock Snímek 7

Consignment ISSUE • Consignment issue enables the customer to take consignment goods from the special stock for their use or to sell. When the customer removes consignment stock to use or sell, you record the transaction in the system by creating a consignment issue order (order type KE). As a result, the system carries out the following actions: • When goods issue is posted, the relevant quantity is deducted from both the customer’s special stock and your own total valuated stock • The transaction is relevant for pricing since the goods now become the property of the customer.

Jan Macháček

Snímek 8

Consignment RETURN • Consignment returns are used for when your customer wants to return goods to the consignment stock. If the customer wishes to claim on consignment goods which have already been issued, you can record this transaction by creating a consignment return order (order type KR). As a result, the system carries out the following actions: • When goods issue is posted, the relevant quantity is added to the customer’s special stock at the plant where the goods are returned. • Since the ownership of the goods is passed from the customer back to your company, the transaction is relevant for billing. In this case, the customer receives a credit memo for the returned goods.

Jan Macháček

4

Příloha 1 SAP trénink – Consignment Stock Snímek 9

Jan Macháček

Snímek 10

Jan Macháček

5

Příloha 1 SAP trénink – Consignment Stock Snímek 11

SAP Side • Initial status

Jan Macháček

Snímek 12

Create Consignment Fill-up

Jan Macháček

6

Příloha 1 SAP trénink – Consignment Stock Snímek 13

Stock after PGI

Jan Macháček

Snímek 14

Create Consignment Issue

Jan Macháček

7

Příloha 1 SAP trénink – Consignment Stock Snímek 15

Stock after PGI

Document flow

Jan Macháček

Snímek 16

Consignment Return

Jan Macháček

8

Příloha 1 SAP trénink – Consignment Stock Snímek 17

Stock after PGI

Jan Macháček

Snímek 18

Consignment Pick-Up

Jan Macháček

9

Příloha 1 SAP trénink – Consignment Stock Snímek 19

Stock after PGI

Jan Macháček

Snímek 20

Thank you

Jan Macháček

10