Tent dkument je ukázku th, jak má vypadat dkument případvé studie, který je výstupem práce na cvičení v našem předmětu. Neberte jej prsím ale jak dgma. Jeh smyslem je především ukázat kapitly, které bývají bvykle sučástí reálné případvé studie. Pr účely výuky jsme si jej trchu uzpůsbili a některé části zjedndušili, vypustili neb napak dplnili. Nepřistupujte k němu způsbem cpy-paste, ale berte jak zdrj inspirace th, c musí vaše práce bsahvat. Naše kmentáře a dpručení jsu uvedeny vždy na začátku každé kapitly a všude tam, kde t pvažujeme za důležité. Kmentáře pznáte pdle th, že jsu psány stejným písmem jak tent text. C je smyslem případvé studie? Pskytnut zákazníkvi pdklady pr rzhdnutí tm, zda ppsané řešení jeh prblému realizvat neb ne. Ve většině případů je určen pr střední a vyšší management. Tmut určení dpvídá také struktura dkumentu, který má 3 části: 1. Manažerské shrnutí nejdůležitější část dkumentu, která je určena pr vrchlvé vedení a ve většině případů je jedinu částí dkumentu, které vrchlvé vedení čte. Obsahuje stručné a přehledné infrmace trjimperativu prjektu. Jedná se shrnutí detailů, které jsu pdrbně rzepsány ve 2. a 3. části studie. 2. Business phled na zákazníka shrnutí aktuálníh stavu, prblémů a ptřeb zákazníka. Ve druhé části bsahuje vizi, kteru by chtěl zákazník při svém pdnikání realizvat a strategii, kteru ji chce naplnit. Tat část je určena spíše pr netechnický management zákazníka a pmáhá ujasnit becný kncept řešení. 3. Pdmínky realizace navrženéh řešení zákazníkva prblému všechny aspekty, které si musí zákazník při realizaci uvědmit. Obsahuje jak rganizační, tak i technicku stránku prjektu. Je určena spíše pr technický management zákazníka, který rzumí navrženému řešení. Obsahuje především detailní rzpad trjimperativu prjektu, kterým jak ddavatel důvdňujeme časvu a finanční stránku případné realizace prjektu. P frmální stránce musí být dkument přehledný a čitelný, musí být jasná jeh struktura, text musí lgicky navazvat a nesmí bsahvat gramatické chyby ani překlepy. Samzřejmstí jsu záhlaví a zápatí dkumentu, na začátku bsah a utr (dpvědná sba) dkumentu. Při psaní dpručujeme pužívat jednduché, krátké a výstižné věty, které pmáhají lépe pchpit ppsanu prblematiku. P frmální stránce se nebjte prjevit také rzumnu míru kreativity. Obecně platí pravidl, že jeden přehledný a názrný brázek vydá za něklik stránek textu. Zvláště v případě vyskéh managementu je těžké získat více času, než něklik minut. Žádný manažer nebude číst více než jednu neb dvě stránky textu. Kapitly jsu uváděny tak, že velké začínají vždy na nvé stránce. Pznámka: Některé nadpisy jsme pnechali v anglickém jazyce, prtže se tak čast uvádějí i v realitě. V textu jsu většinu ppsány česky. Jedná se především pjmy: Executive summary = manažerské shrnutí Radmapa prjektu = pstup realizace prjektu.
IT Enterprises Každý dkument má svu úvdní stránku, která identifikuje, jaký dkument se jedná. Označení final draft je interní infrmace, která identifikuje, zda je mžné dkument předat zákazníkvi neb se na něm ještě pracuje. Finální verze dkumentu, devzdávaná zákazníkvi, již infrmaci draftu nebsahuje. Byl by t pr něj matucí a zbytečné. Q&X TRADING, s.r. Rezervační systém zdrjů (RESYZ) Úvdní studie final draft Q&X trading, s.r.. 2 Rezervační systém zasedaček (RESYZ) Úvdní studie final draft
IT Enterprises Pr interní účely je vhdné v textu uvádět histrii změn, aby byl mžné dhledat, kd jaku změnu prvedl a je dpvědný za uvedený bsah. Ve finální verzi, devzdávané zákazníkvi se tat část již nebjevuje. Verze dkumentu Datum Autr Ppis změn 0.9 24.05.2010 Jsef Petr Verze k akceptaci 0.6 13.05.2010 Matěj Nvák Zapracvání CR 0.5 05.05.2010 Jsef Petr Dplnění kapitly Radmapa 0.2 23.04.2010 Matěj Nvák Zapracvány připmínky prjektvéh manažera 0.1 01.04.2010 Jsef Petr Úvdní draft, snva Q&X trading, s.r.. 3 Rezervační systém zasedaček (RESYZ) Úvdní studie final draft
IT Enterprises A. Executive summary Manažerské shrnutí je nejdůležitější část dkumentu. Je t jediná část, kteru čte vrchlvý management zákazníka. Dpručená délka textu je 1 2 stránky. Musí z něj jasně vyplývat cena za navržené řešení a vše pdstatné, c je pr pchpení uvedené částky nezbytné. Dbře sepsané manažerské shrnutí může výrazným způsbem vlivnit rzhdvání zákazníka a udělat dbru reklamu ddavateli. 1) Zadání Originální zadání, které nám dal zákazník na začátku, aby byl jasné, c vlastně chtěl a chce řešit. Víme, kde byl začátek prjektu. Změny, které během práce nastaly je nutné výrazněji dlišit. Najít řešení, které pmůže zvýšit efektivitu využívání interních firemních zasedacích prstr splečnsti QXT. Klíčvým milníkem, d kdy je řešení nutné aplikvat, je knec rku 2011. Na základě diskusí byla navržena implementace elektrnickéh rezervačníh systému. Klíčvé pžadavky na systém: jednduchá a rychlá dstupnst infrmací rezervacích, infrmace využití /nevyužití rezervací, reprtvací nástrje, perativnst změn v rezervaci. 2) Vize Krátké shrnutí vize, k čemu navržené řešení směřuje. Zákazník musí jasně vidět stav, který bude v jeh firmě p nasazení navrženéh řešení. Nejedná se technicku vizi, ale becnu vizi. Ideálně dplněn jasným a výstižným brázkem. Na základě wrkshpů mezi QXT a ITE byla identifikvána ptřeba becnějšíh řešení správy zdrjů. Řešení je zalžen na univerzálním systému pr rezervaci firemních zdrjů (RESYZ). Systém je pevně začleněn d firemní infrastruktury a umžňuje jednduché využívání všemi zaměstnanci firmy. V případě ptřeby rezervace zasedačky, firemníh autmbilu neb jinéh firemníh zdrje, který je evidván v systému může běžný uživatel uvnitř neb i vně firmy přihlášením d systému vybrat vlný zdrj a ten si zarezervvat. Pkud jej neptřebuje, může rezervaci zrušit. Sučástí systému je rbustní reprtvací mdul, který pskytuje infrmace pdle ptřeby. Navrhvané řešení je zalžené na principech třívrstvé architektury s hledem na mderní principy SOA a jednduchu prpjitelnst s jinými systémy splečnsti. Řešení využívá technlgické základny prduktů Micrsft, které se QXT rzhdla pužívat Q&X trading, s.r.. 4 Rezervační systém zasedaček (RESYZ) Úvdní studie final draft
IT Enterprises User apprach User Brwser Aplicatins Oklní aplikace RESYZ RESYPA... MS Sharepint RRF MS Exchange server Mduly Vizuální kmpnenty Nevizuální kmpnenty Datvý sklad Uživatelská práva Definice prcesů a wrkflw DB LDAP 3) Radmapa Krátké shrnutí časvéh rámce prjektu a infrmace klíčvých výstupech. Pr rychlé vizuální pchpení Je vhdné ppisný text mezit na nezbytné minimum a harmngram ppsat zjedndušeným Ganttvým diagramem. Rzdělení prjektu d tří etap Etapa 1 vyřešení klíčvých funkčnstí RRF (becné funkce, grafické prstředí, věřvání), které mají dpad na implementaci aplikací nad RRF. Bude implementvána první verze aplikace RESYZ (rezervace zasedacích místnstí a funkčnsti s tím spjené). Etapa 2 vyřešení integrace se systémy MS Exchange a MS Sharepint. Dále budu řešeny pdpůrné a nice-t-have funkčnsti a změnvé pžadavky (např. napjení na čtečky vstupních karet). Bude implementvána nvá aplikace RESYPA (rezervace firemních autmbilů a pdpra managementu pr sledvání jejich využívání). Etapa 3 budu identifikvány aplikace z existujícíh aplikačníh prtflia QXT, které jsu kandidáty na převedení nad RRF a business prcesy QXT, které nejsu pdprvány žádným systémem. Q&X trading, s.r.. 5 Rezervační systém zasedaček (RESYZ) Úvdní studie final draft
IT Enterprises 4) Harmngram 1) Cena Nejdůležitější část celéh manažerskéh shrnutí. Je třeba jasně uvést, klik bude celé řešení stát a z čeh je cena slžena. Je vhdné také uvést návratnst prjektu. Čísla musí být jasná a zřejmá, nicméně vzhledem k mžným nejasnstem je vhdné uvést i míru tlerance, s jaku je třeba k těmt číslům přistupvat. Klíčvé čísla je vhdné zdůraznit, například tučným písmem. Náklady na přízení systému jsu rzděleny pdle realizačních etap. Ceny jsu pčítány z průměrné hdinvé sazby 1000 Kč/člh bez DPH. Pčítány jsu jen náklady na realizaci. Ostatní HW a SW je na základě splečné dhdy přizván QXT. Maximální dchylka dhadu je +/- 20%. Cena Etapy 1: 1 470 000 Kč Cena Etapy 2: 2 200 000 Kč Cena Etapy 3: cena bude stanvena p vyhdncení Etapy 1 a 2 a definici nvých pžadavků. Návratnst investice (ROI) pr bdbí 5 let byla na základě nákladů (bez sučinnsti a využití framewrku splečnsti ITE) a přínsů spčítána ve výši 2,4. Tzn. V tmt hrizntu je implementace systémů ziskvá. 2) Sučinnst Část, kteru je mžné zahrnut i kapitly cena. My ji uvádíme jak samstatnu kapitlu, abychm si uvědmili, že zákazník neplatí jen ddavateli, ale také investuje za interní a další zdrje prjektu. Je také dpručené uvést všechny nezbytné pdmínky pr krektní realizaci, které byly identifikvané během analýzy. Například pžadavky na nezbytnu infrastrukturní sučinnst. Pr úspěšnu realizaci prjektu bude vyžadvána ze strany QXT následující sučinnst: Persnální dedikvaný veducí prjektu, členvé vrchlvéh managementu pr účast v řídící kmisi, klíčví uživatelé pr účely analýzy a návrhu systému, běžní uživatelé pr účely prvedení funkčních a zátěžvých testů. Minimální pžadvaná sučinnst je ve výši 365 člh pr 1. etapu prjektu a 355 člh pr 2. etapu. Celkem 720 člh. Q&X trading, s.r.. 6 Rezervační systém zasedaček (RESYZ) Úvdní studie final draft
IT Enterprises Infrastrukturní splečnst QXT zajistí připravenst prstředí pr nasazení systému, specifikuje způsb a parametry napjení na stávající systémy a pskytne kapacitu pr řešení prblémů spjených s integrací systému d existujícíh prstředí. Q&X trading, s.r.. 7 Rezervační systém zasedaček (RESYZ) Úvdní studie final draft
IT Enterprises B. Obsah Obsah celéh dkumentu. Není nutné uvádět všechny kapitly. Stačí uvést kapitly d druhé úrvně. A. EXECUTIVE SUMMARY... 4 1) ZADÁNÍ... 4 2) VIZE... 4 3) ROADMAPA... 5 4) HARMONOGRAM... 6 1) CENA... 6 2) SOUČINNOST... 6 B. OBSAH... 8 C. SLOVNÍK... 10 D. PŘÍLOHY... 11 1) HARMONOGRAM PROJEKTU... 11 E. ZADÁNÍ ÚVODNÍ STUDIE... 12 1) VSTUPNÍ ZADÁNÍ... 12 2) ZÁMĚR... 12 3) AKTUÁLNÍ PROBLÉMY (BUSINESS PROBLEMATIKA)... 12 4) KLÍČOVÉ ICT POŽADAVKY... 13 5) TECHNOLOGICKÁ A JINÁ OMEZENÍ... 13 6) CHANGE REQUESTS (POŽADAVKY NA ZMĚNU)... 14 F. SITUAČNÍ ANALÝZA... 15 1) SWOT ANALÝZA QXT... 15 2) FURPS+ ANALÝZA RESYZ... 15 3) PODPORA MANAGEMENTU QXT... 17 G. VIZE ŘEŠENÍ... 18 1) STRATEGIE NAPLNĚNÍ VIZE ŘEŠENÍ... 18 1) KLÍČOVÉ BENEFITY NAVRHOVANÉHO ŘEŠENÍ PRO BUSINESS... 19 2) KLÍČOVÉ BENEFITY NAVRHOVANÉHO ŘEŠENÍ PRO IT... 20 H. RIZIKA... 22 1) RIZIKA ZADAVATELE... 22 2) PROJEKTOVÁ RIZIKA... 23 I. ROADMAPA PROJEKTU... 25 1) PROJEKTOVÝ TÝM... 25 2) SOUČINNOSTI... 26 3) ETAPA 1 RRF 1.0 A RESYZ 1.0... 28 4) ETAPA 2 RRF 1.5, RESYZ 1.5, RESYPA 1.0... 31 5) VIZE DALŠÍHO ROZVOJE ETAPA 3 (RRF 2.0, RESYZ 2.0, RESYPA 1.5)... 34 Q&X trading, s.r.. 8 Rezervační systém zasedaček (RESYZ) Úvdní studie final draft
J. FINANCE... 35 K. ZÁVĚR... 37
C. Slvník Slvníček je, i když se t nezdá, jednu z nejdůležitějších částí, kteru je třeba vyřešit na začátku celéh prjektu. V případě špatnéh chápání pjmů ze strany zákazníka i ddavatele jsu důsledky, zvláště ve fázi akceptace, katastrfální. Ve slvníku se mezte na vysvětlení klíčvých zkratek a pjmů, které jsu pr správné pchpení bsahu studie důležité. Zkratka CF CR ČR člh DCF Framewrk FURPS+ HW ICT ITE ITEFWK LDAP Mitigace MS NPV QXT RESYPA RESYZ ROI RP## RRF RZ## SLA SW SWOT analýza UAT Wrkflw Ppis změn Cash Flw, peněžní tk Change Request Česká republika Člvěkhdiny Discunted Cash Flw, diskntvaný peněžní tk Obecné sftwarvé prstředí pr jednduchý vývj aplikací Ppis pžadavků na systém z hlediska funkčnstí (Functinalities), pužitelnsti (Usability), splehlivsti (Reliability), výknnsti (Perfrmance), pdprvatelnsti (Suprtability) a dalších nefunkčních pžadavků (+) Hardware Infrmační a kmunikační technlgie IT Enterprises ITE Framewrk pr pdnikvá řešení Lightweight Directry Access Prtcl je definvaný prtkl pr ukládání a přístup k datům na adresářvém serveru Zmírnění, minimalizace Micrsft Net Present Value, čistá sučasná hdnta Q&X Trading, s.r.. Rezervační systém firemních autmbilů Rezervační systém zdrjů Return On Investment, návratnst investice Prjektvé rizik (čísl) Resurces reservatin framewrk (Framewrk pr systémy na rezervaci zdrjů) Rizik zadavatele (čísl) Service Level Agreement Sftware, prgramvé vybavení Analýza silných (Strenghts) a slabých (Weaknesses) stránek splu s příležitstmi (Opprtunities) a hrzbami (Threats) Uživatelské akceptační testy Pracvní pstup, pstup zpracvání plžek v příslušné agendě (např. žádst rezervaci).
D. Přílhy Pkud jsu sučástí studie přílhy, uvedeme je zde seznamem (v případě, že jsu tištěné) neb je sem můžeme rvnu vlžit. V případě tét ukázky je vlžen dkument z prgramu MS Prjekt, který bsahuje detailní harmngram prjektu. Tut část necháváme jak vlitelnu. Je na jedntlivých týmech, zda tut část ve finální studii uvedu neb neuvedu. 1) Harmngram prjektu
E. Zadání úvdní studie Zde začíná druhá, na business phled rientvaná, část případvé studie. Začíná se prvtním zadáním a jeh rzbrem. Smyslem je shdnut se na tm, c chce zákazník vlastně řešit a c má být klíčvým přínsem (výstupem). Předejde se tím zbytečným diskusím při finální prezentaci a bhajbě navrženéh řešení. 1) Vstupní zadání Sem vždy vkládáme riginální zadání, které nám zákazník dal. Tedy jak t vše začal, s čím zua námi zákazník přišel. Pkud dšl v průběhu analýzy ke změně, jsu tyt změny uvedeny a rzebrány pzději, v příslušné části změnvéh řízení. Hledáme řešení, které nám pmůže zvýšit efektivitu využívání našich interních zasedacích prstr. Klíčvým milníkem je knec rku 2011. 2) Záměr Zde ppisujeme, jak jsme zadání během splečných diskusí pchpili a c je jeh smyslem. Jedná se detailnější a knkrétnější ppis zadání, včetně nástřelu řešení. Není třeba psát dluhý text, spíše klíčvé myšlenky, pdbně jak v dkumentu A4. V případě, že dšl k výrazné změně, je prveden dkaz d kapitly změn. Splečnst QXT vydává na nákladech na externí prstry rčně až 2,8 mil. Kč. Cílem managementu QXT je mezit plýtvání zdrjů pr jednání. Pkud lze, všechna jednání a prezentace by měly prběhnut v interních prstrách, ve kterých je vybudván ptřebné zázemí. Vhdným řešením se jeví implementace elektrnickéh rezervačníh systému pr zasedačky v sídle splečnsti. Základními pžadavky na systém je jednduchá a rychlá dstupnst infrmací rezervvaných zasedačkách, infrmace využití / nevyužití rezervací, reprtvací nástrje pr management a jednduchst rezervace/zrušení běžnými zaměstnanci. 3) Aktuální prblémy (business prblematika) V tét části ppisujeme aktuální prblémy, které má zákazník z hlediska fungvání splečnsti, jejich dpad a důvdy, které vedly k slvení ddavatele a hledání řešení prblémů. Nevyužívání rezervací interních zasedaček (zasedačky a prezentační místnsti jsu dle názru managementu přád prázdné). Evidence rezervací existuje jenm v papírvé pdbě na dveřích zasedaček. Nemžnst kntrly využití rezervací, mnitringu rušení rezervací, nedstupnst infrmací pr rzhdvání. Malá mtivaci zaměstnanců pr využívání interních prstr.
4) Klíčvé ICT pžadavky Technická mezení (pžadavky), které jsu na systém kladeny z phledu pdpry. Vzhledem k tmu, že my řešíme infrmační systém, uvádíme a ppisujeme specifika zákazníka z phledu IT ddělení. Z těcht pdmínek vychází navržené řešení. Pkud nemá například zákazník vlastní IT ddělení a ani jej nechce, musíme zvážit, jakým způsbem bude systém prvzvaný a jaké bude jeh technické řešení. Detailní technické pžadavky jsu uvedeny v následující kapitle. Zde se mezíme maximálně na knstatvání, zda pžaduje kmerční neb pen-surce prdukty. IT ddělení QXT má jenm 2 správce sítě a 2 správce systémů. V sučasné dbě jsu plně vytíženi a i v buducnu se čekává, že jejich kapacity budu mezené. Rzšíření IT ddělení se neplánuje. QXT pužívá v sučasné dbě výhradně vlně dstupných technlgií (penffice, thunderbird, mzilla, linux). HW a SW nutný pr nasazení systému, který přím nesuvisí se systémem (např. server, licence servervéh SW), bude přízen přím splečnstí QXT d již existujících ddavatelů. Stejně tak bude pracvníky QXT zajištěna základní instalace a knfigurace těcht prstředků. 5) Technlgická a jiná mezení Zde ppíšeme detailní technlgické pžadavky na systém, které vyžaduje zákazník. Například jestli musí mít nvý systém vazby na knkrétní existující systémy, pčty uživatelů, bvyklé nástrje a další knkrétní, ve většině případů mezující, pdmínky. Výsledné řešení musí být integrván s MS Sharepint a MS Outlk (viz kapitla Change requests), cž má za důsledek: Nutnst přizpůsbení firemních prcesů balíkvému řešení. Limity v mžnsti zásahu d zdrjvéh kódu Micrsftu. Ptenciální rizik ztráty záruky a příslušnéh záručníh servisu při neddržení ujednání licenčních pdmínek. Nvé technlgie nejsu zažité a prblémy s nimi mhu zkmplikvat nasazení systému. Očekávaný pčet uživatelů QXT má v sučasné dbě 200 zaměstnanců a 50 bchdních zástupců. I s hledem na buducí růst splečnsti je ptřeba pčítat s pčtem uživatelů v řádu stvek. QXT vlastní a pužívá 30 firemních vzů (náklady na splátku a prvz činí průměrně 200 tis./rk). Uživatelé pracují primárně s webvým prhlížečem MS Internet Explrer (cca 28% tvří IE9, dalších 25% starší verze IE8 a IE7) a s webvými prhlížeči Ggle Chrme (11%), Mzilla Firefx (35%) a Opera (1%).
6) Change requests (pžadavky na změnu) V případě, že během hledání řešení a splečných diskusí zjistíme, že dchází k významné změně zadání, uvedeme všechny významné změny v tét kapitle. Uvádíme i stav, zda byl neb nebyl pžadavek bustranně akceptván. Z těch akceptvaných plyne, prč dšl ke změně neb byl půvdní zadání rzšířen. Neakceptvané mhu minimalizvat diskusi při bhajbě, prč nebyl něc řešen neb navržen. Také t dkládá, že jsme na nic, c zákazník pžadval, nezapmněli. Akceptace je vždy bustrannu dhdu a v textu uvádíme vždy výsledek spelčných dhd. Ne t, c si myslí jen ddavatel neb zákazník. CR1: Jednduchá rzšiřitelnst (univerzálnst) řešení pr využití systému i pr další firemní agendy. Např. pr rezervace firemních aut, rezervace lidí na úkly/prjekty, rezervace prjektrů a další techniky, atd. akceptván. CR2: Splečnst QXT se rzhdla kmpletně přejít na MS (Micrsft) technlgie, pžaduje integraci s MS Outlk a s MS Sharepint Prtal a pdpru pr všechny internetvé prhlížeče částečně akceptván (mim univerzální pdpru všech prhlížečů, budu pdprvány jen aktuálně pužívané). CR3: Dstupnst systému i z prstředí mim interní dménu QXT akceptván. CR4: Dstupnst z mbilních telefnů (mbilní technlgie jak WAP) p dhdě zamítnut z důvdu nevýhdnsti (nárčnsti) implementace před usazením systému. Pžadavek bude znvu tevřen ve 3. etapě. CR5: Řešení nebude pstaven plně na zelené luce, ale je pžadván, aby byl pstaven na existujícím framewrku akceptván 1. 1 Zadavatel si je vědm, že tímt mezuje mžné ddavatele jen na firmy, které mají za sebu více prjektů a delší existenci. Chce tím zvýšit pravděpdbnst úspěchu a snížit cenu. Aby byl mžné psuzvat kvalitu a cenu framewrku, je v dalším textu uváděn jak srvnávací Framewrk autra studie, splečnst ITE. Ten byl během práce na studii představen jak ukázkvý pracvníkům QXT a ti dsuhlasili jeh pužití ve studii.
F. Situační analýza Také tat kapitla je sučástí druhé části studie. Navazujeme na předchzí část, která rzebrala zadání a pžadavky zákazníka. V tét kapitle prvedeme rzbr zákazníka pmcí standardních nástrjů, které se pužívají pr business a technicku analýzu pžadavků zákazníka. Pmcí nich rzhdujeme na c se v řešení zaměřit a c knkrétně bude jeh sučástí. 1) SWOT analýza QXT SWOT analýza je jednu z prvních analýz, kteru u zákazníka prvádíme. Analyzujeme slabiny a silné stránky zevnitř firmy a dpady vnějších vlivů. Splečně se zákazníkem se na základě parametrů určuje, na c se z hlediska vnitřníh fungvání firmy a vnějších vlivů v našem řešení zaměřujeme. Nejčastěji minimalizujeme slabé stránky firmy a sučasně eliminujeme negativní vnější vlivy. Při tvrbě SWOT analýzy je třeba dbře zvažvat, c je vnitřní prblém a c je vnější vliv. Velmi čast jsu tyt faktry prvázané, a prt je nutné vždy zvažvat, kam který faktr z hlediska SWOT analýzy zapadá. Strenghts (silné stránky) Weaknesses (slabé stránky) Opprtunities (příležitsti) Threats (hrzby) Nízké náklady na údržbu systému (jenm papírvá frma). Neexistence kntrly využívání zdrjů. Infrmace je k dispzici jenm na dveřích knkrétní zasedačky, čast jsu neúplné a neaktuální. Malá flexibilita při plánvání. Zefektivnění využívání nejenm zasedaček ale i jiných zdrjů splečnsti. Pdpra marketingu a PR firmy (ukazujeme naše prstry a ne cizí). Psílení jména firmy. Plýtvání zdrji má přímý dpad na hspdářský výsledek splečnsti. Ztráta knkurenceschpnsti. Někteří zákazníci budu muset akceptvat změnu místa knání setkání. Demtivace zaměstnanců a jejich přechd ke knkurenci. Na závěr je vždy nutné uvést, jakým způsbem se bude, na základě SWOT analýzy, pkračvat. Tj. jaku strategii vlíme. V uvedeném dkumentu je t strategie MIN-MAX. Jedná se případ, kdy minimalizujeme slabiny a psilujeme existující a přicházející vnější příležitsti. V rámci návrhu řešení se zaměříme na minimalizaci slabých stránek a maximalizace příležitstí. Aplikujeme strategii MIN-MAX. 2) FURPS+ analýza RESYZ FURPS+ analýza je analýza, která překlápí business pžadavky d knkrétních technických pžadavků. Není nutné psát detaily, ale je třeba ppsat všechny klíčvé parametry, které jsu
z phledu technické realizace důležité. Analýza uvádí pžadavky z různých aspektů, které mají vliv na slžitst realizace. Pžadavky reflektují výstupy SWOT analýzy. a) Funkčnsti Elektrnická rezervace zasedaček. Evidence a správa zasedaček. Kalendář. Práva pr rezervaci jedntlivých zasedaček. Mžnst zadat pakvané rezervace. Suplementární služby k rezervacím (bčerstvení, prjektr ). Na rezervaci zasedačky musí mít pracvník práva (rzličná práva pr rzličné zasedačky). Práva budu řešena prstřednictvím skupinvých rlí (prstřednictvím dménvých skupin). Elektrnický přístup d zasedaček na vstupní kartu (kdkli z účastníků jednání). V případě, že rezervace není využita d 10min d začátku platnsti je zasedačka uvlněna pr khkli. Autmatické předání infrmací změně stavu rezervace prstřednictvím infrmačníh mailu. Online rzhraní pr zadávání a mnitrvání stavu rezervací. Reprty pr management využívání zdrjů, změnách a rušení rezervací. Pdpra wrkflw pr naplánvání údržby a bnvy zdrjů (např. servisní prhlídky u autmbilů, vymalvání zasedaček, výměna kberců apd.). b) Pužitelnst Internetvé prhlížeče, nejenm IE, ale také Firefx, Chrme a Opera. c) Splehlivst Dstupnst 99% v dbě 5x12 (pndělí pátek 7:00-19:00). Žádné kritické chyby, které by znemžňvaly pužití systému. d) Výkn Desítky kliků za minutu. Stvky uživatelů. Dba dezvy maximálně d 10s, průměrně d 5s při plném zatížení systému (stvky uživatelů). e) Pdprvatelnst Kmpletní zdkumentvání systému ve vlastnictví zákazníka (administrátrská a prgramátrská dkumentace). Prstředí běží na serverech zákazníka. Existence testvacíh prstředí. Garance řešení chyb ddavatelem (servisní smluva). f) Další nefunkční pžadavky Napjení na LDAP, jedntné přihlašvání d systému. Vývjvá platfrma a prstředí Micrsft (.NET, MS SQL server, Windws server).
3) Pdpra managementu QXT V našem případě jsme d business analýzy přidali samstatnu kapitlu, která zdůrazňuje pžadavky managementu, které naše řešení bude bsahvat. V tmt knkrétním případě se jedná reprting. Obecně platí, že pkud chceme některý z klíčvých pžadavků vyzdvihnut, uvedeme jej d samstatné kapitly, jak v tmt případě. Například pdpra lgistiky, skladvání, ale také IT atd. Pdbně je mžné tut kapitlu využít pr zdůraznění benefitů řešení, které tt řešení přinese a které nebyl čekáván, prtže zákazník něm nevěděl. Ddavatel ukazuje své schpnsti nejen najít řešení, ale najít i další benefity, které může zákazník vyřešením prblému získat. Ze stávající situace je jasné, že základním prblémem managementu je neexistence relevantních infrmací pr kntrlu nakládání se zdrji splečnsti pr manažerská rzhdnutí. Mezi zásadní infrmace, které musí RESYZ pskytnut patří: Fyzická (skutečná) bsazenst zasedaček v knkrétním čase. Týdenní / měsíční přehledy vytížensti zasedaček. Mnžství nevyužitých rezervací, s mžnstí dhledání knkrétních pracvníků, kteří rezervaci nevyužili. Pčty změn rezervací. Obsazenst rezervvaných místnstí (pčet lidí na jednání vs. kapacita zasedačky). Pžadavky ddělení / pracvníků na rezervace.
G. Vize řešení Tut kapitlu lze pvažvat za pslední část druhé části studie a přechd k třetí části. Obsahuje ppis th, jakým způsbem se navrhvané řešení prjeví ve fungvání splečnsti a jaku cestu se k němu djde. Prvním krkem je ppis vize. V našem případě znamená vize krátký ppis stavu, který p nasazení řešení ve firmě nastane. Díváme se tedy jak vizináři d buducnsti a ppisujeme tut buducnst. Krátce zákazníkvi ppisujeme, jak funguje nvě nasazení řešení v realitě. Zákazník se v ní musí vidět. Na základě wrkshpů mezi QXT a ITE byla identifikvána ptřeba becnějšíh řešení správy zdrjů. Řešení je zalžen na univerzálním systému pr rezervaci firemních zdrjů (RESYZ). Systém je pevně začleněn d firemní infrastruktury a umžňuje jednduché využívání všemi zaměstnanci firmy. V případě ptřeby rezervace zasedačky, firemníh autmbilu neb jinéh firemníh zdrje, který je evidván v systému může běžný uživatel uvnitř neb i vně firmy přihlášením d systému vybrat vlný zdrj a ten si zarezervvat. Pkud jej neptřebuje, může rezervaci zrušit. Systém pdpruje maximální autmatizaci prcesů. Např. ptvrzení využití rezervvané místnsti je prveden autmaticky při tevření místnsti kartu zaměstnance atd. Dhled nad rezervacemi zdrjů prvádí určení dpvědní pracvníci (správce zasedaček, správce autmbilů ). Ti jsu schpni prvádět krekce v rezervacích. O všech změnách jsu uživatelé autmaticky infrmvání. Sučástí systému je rbustní reprtvací mdul, který pskytuje infrmace pdle ptřeby. Běžní zaměstnanci se mhu například pdívat na své využívání zasedaček, správci mhu kntrlvat aktuální stav a management splečnsti může strategicky plánvat efektivitu využívání zdrjů, včetně jejich rzšiřvání. 1) Strategie naplnění vize řešení P vizi následuje strategie, nebli pstup, jakým th dsáhneme. V našem případě je t prstřednictvím nasazení infrmačníh systému. Kapitla strategie bsahuje klíčvé parametry jeh nasazení a zprvznění. Ideálně dplněn vhdný brázek architektury. Snažte se vyhnut UML diagramům a pužijte vizuální pdbu, kteru pchpí i netechnický uživatel. Zde se dá hdně získat. Stejný brázek je vhdné pužít ve stejné neb zkrácené pdbě i v manažerském shrnutí. Prt musí být jasný a zřetelný. Na základě vytvřené vize bude navrhvané řešení RESYZ zalžené na principech třívrstvé architektury s hledem na principy SOA. Parciálním cílem prjektu je v maximální mžné míře využít technlgicku základnu, kteru pskytují prdukty splečnsti Micrsft, které se QXT strategicky rzhdla pužívat. Zárveň je nevyhnutné implementvané struktury kmpnvat d elementárně rzšiřitelnéh a flexibilníh (univerzálníh) celku, s hledem na další rzvj a využití systému. Na základě dhdy mezi QXT a ITE byla stanvena pririta, fkus a rzsah blastí, které budu řešeny a knslidvány v hrizntu nejbližších dvanácti měsíců: Vytvření jedntnéh univerzálníh framewrku pr systémy na rezervaci zdrjů (RRF), který bude vytvřen na základech existujícíh ITEFWK splečnsti ITE. Využití již
existujícíh řešení přináší velku úspru času, prtže nebude nutné navrhnut a implementvat celý framewrk na zelené luce. Vytvření RESYZ nad tímt framewrkem. Vytvření systému pr rezervaci služebních firemních autmbilů (RESYPA). Nástrje pr vytváření reprtů a mnitring využívání zdrjů. Základní architekturu celéh řešení zbrazuje následující brázek. User apprach User Brwser Aplicatins Oklní aplikace RESYZ RESYPA... MS Sharepint RRF MS Exchange server Mduly Vizuální kmpnenty Nevizuální kmpnenty Datvý sklad Uživatelská práva Definice prcesů a wrkflw DB LDAP Obrázek 1. Architektura systému splečnsti QXT. 1) Klíčvé benefity navrhvanéh řešení pr business V tét části ppisujeme klíčvé benefity našeh řešení z phledu fungvání zákazníka a běžných uživatelů. V krátksti shrnujeme, jakým způsbem se technlgické řešení prjeví na fungvání firmy a c t firmě přinese. Dá se knstatvat, že navazujeme na dřívější specifikaci pžadavků business uživatelů. V pdstatě ptvrzujeme, že t c zákazník pžadval, t dstane + my mu t nabízíme v té nejlepší variantě. Využité principy SOA umžňují jednduché prpjení různých služeb (aplikací), využívajících rzličné platfrmy a technlgie. Nad SOA může být jednduše vytvřen wrkflw (pracvní pstup) na úrvni kmpnent (jedntlivých funkcí) využívaných v jedntlivých službách. Každý prces je pak d začátku až d knce jednduše sledvatelný až na úrveň základních perací.
Nevyhnutným předpkladem implementace řešení je tedy identifikace business (funkčních) mdulů a aplikací, pskytujících svje služby klním aplikacím jak je např. MS Sharepint. Jedntlivé business mduly jsu transparentně definvány a musí pervat nad knkrétní částí firemních prcesů. V sučasné dbě jsu identifikvány tyt funkční mduly: Správa zasedaček. Rezervace zasedaček. Správa autmbilů. Rezervace firemních autmbilů. Reprting Funkčnsti takt navržených business mdulů jsu pužitelné becně napříč prcesy QXT, c představuje jeden z nejdůležitějších benefitů pužití SOA. Neméně významná je i mžnst znvupužití a elementární rzšiřitelnst při definici nvých business mdulů. Řešení zalžené na těcht technlgických principech přinese QXT celu řadu klíčvých benefitů: Jednduché uživatelské rzhraní pr zadávání rezervací. Online přehled bsazensti a využití zasedaček. Snížení nákladů na externí prstry. Optimalizace prcesů rezervací a pužití zdrjů. Rzšiřitelnst řešení pr další sdílené zdrje. Zdkumentvané řešení nezávislé na ddavateli. Eliminace ptenciálních prblémů. Garance reakčních časů pr pravy chyb na základě servisní smluvy. Mžnst utsurcvání prvzu a rzvje celéh řešení. 2) Klíčvé benefity navrhvanéh řešení pr IT Pdbně jak v předchzí kapitle shrnujeme klíčvé přínsy navrženéh řešení, v tmt případě z phledu IT ddělení. Navazujeme na pžadavky a technická mezení, které jsme specifikvali v jedné z kapitl zadání a pžadavků. V pdstatě pět ptvrzujeme, tentkrát z jiné stránky, že t c zákazník pžadval, t dstane + my mu t nabízíme v té nejlepší variantě. Definice základní technlgické platfrmy.net, MS SQL server vede k eliminaci zastaralých (nevyhvujících platfrem) a je základem dluhdbé využitelnsti a pdprvatelnsti. Vytvřením jedntnéh aplikačníh framewrku RRF zajistíme jedntnu architekturu a unifikvaný způsb vývje aplikací nad tímt framewrkem jak v dbě realizace systému, tak i v dbě pdpry systému. Klíčvými benefity jsu: Architektura Etablvání framewrku a architektury (SOA). LDAP kntrla přístupvých a uživatelských práv.
Infrastruktura Vybudvání infrastruktury s ptřebnu dstupnstí a výknem. Integrace Využití jedntnéh rzhraní pr transparentní a standardizvaný způsb integrace. Micrsft cmpliant framewrk i aplikace musí být MS cmpliant. Platfrma MS je strategická pr QXT. QXT dále čekává v cílvém stavu: Maximální mžné využití stávajících IT prstředků/aplikací/služeb, kterými dispnuje. Vybudvání architektury zalžené na mderních přístupech a flexibilních službách tak, aby byl mžné pružně reagvat na měnící se pžadavky a zajistit významnu znvupužitelnst (technlgický framewrk) jak na technlgické, tak zejména na úrvni firemních prcesů (klíčvá lgika je implementvána jak samstatné aplikace s jasně definvaným rzsahem a službami, které pskytuje klí). Identifikvat ve splupráci s statními dděleními firmy blasti, které jsu pdprvány technlgiemi, které v hrizntu tří let nemají v IT strategii a architektuře QXT perspektivu a je nutné zvážit jejich náhradu, ideálně na framewrku RRF a tent framewrk připravit i pr tyt aplikace.
H. Rizika Kapitla rizik je na pmezí druhé a třetí části případvé studie. V našem případě ji zahrnujeme již d třetí části, prtže bsahuje část, která se týká knkrétních rizik prjektu nasazení infrmačníh systému. Vypisujeme zde klíčvé rizika, které mhu prjekt nasazení navrženéh řešení hrzit a díky tmu se prjekt může prdražit neb prtáhnut. Těcht hrzeb si jak zákazník musíme být vědmi a dle vlastníh zvážení je buď před prjektem elimininvat, minimalizvat neb v krajním případě prjekt raději nerealizvat. Neřešením rizik by prjekt nemusel dpadnut dbře a výrazným způsbem vlivnit fungvání zákazníka. V krajním případě vést ke krachu. U rizik vždy evidujeme stav, kd je jeh vlastník (je dpvědný za jeh sledvání), pravděpdbnst výskytu (udává, zda má smysl se jím zabývat), dpad (c se stane), mitigaci (jakým způsbem se jej snažíme předem i průběžně minimalizvat) a krizvý plán, který udává knkrétní krky, které budeme dělat v případě, že rizik nastane. 1) Rizika zadavatele První kategrií jsu rizika samtnéh zákazníka. Reflektují stav zákazníka a t jak z aktuálníh phledu, tak i buducíh. Nebli musíme zvážit rizik th, že systém nemáme (aktuální stav) a máme (c nám hrzí při a p jeh nasazení). a) RZ01 Plýtvání zdrjů Stav Nastal Vlastník QXT Pravděpdbnst výskytu 100% Dpad Zvýšené náklady (zasedačky jsu prázdné a jednání prbíhají v prnajatých prstrách). Plán pr mitigaci rizika Kntrla skutečně využívaných rezervací. Nasazení systému pr správu rezervací Krizvý plán zasedaček a patření prti těm, kteří své rezervace nevyužívají. b) RZ02 Nasazení systému p plánvaném termínu Stav Ptenciální Vlastník QXT Pravděpdbnst výskytu 20% Prdlužení aktuálníh stavu plýtvání s dalším navýšením nákladů na IT řešení. Dpad Nutnst prdlužení smluvy prnájmu externích prstrů. Vytvření úvdní studie pr pdpru rzhdvání renmvanu splečnstí ITE. Plán pr mitigaci rizika Rzdělení prjektu d etap. Smluvní patření (sankce) v realizační smluvě.
Krizvý plán Uplatnění sankcí vůči ddavateli řešení. c) RZ03 Nedstupnst implementvanéh systému p nasazení Stav Ptenciální Vlastník QXT Pravděpdbnst výskytu 5% Dpad Nedstupnst infrmací rezervacích zdrjů. Varianta 1: Přenesení rizika na ddavatele prstřednictvím smluvy prvze a servisu pr řešení nedstupnsti funkčnstí RESYZ. Definice dpvídající SLA. Plán pr mitigaci rizika Varianta 2: Funkčnsti RESYZ jsu pskytvány jak služba (pužití systému, který nebude ve vlastnictví QXT). Definice dpvídající SLA. Krizvý plán Uplatnění sankcí vůči pskytvateli služeb. 2) Prjektvá rizika Druhým typem rizik, která ppisujeme, jsu rizika prjektu nasazení navrženéh řešení. Týkají se th, na c bychm si jak z phledu zákazníka, tak i ddavatele, měli dát pzr. Například, když zpracvatel studie zjistí, že budu prblémy v kmunikaci se zaměstnanci, je třeba uvést rizik malé a špatné sučinnsti zákazníka. Ta může vést k navýšení rzpčtu, prdlužení času nasazení neb krachu celéh prjektu. Obdbně je vhdné být připravený na rizik prblematickéh ddavatele řešení. Tím říkáme zákazníkvi, aby se sledvání a řízení prjektu věnval s maximální pzrnstí. a) RP01 Nasazení systému p plánvaném termínu Stav Ptenciální Vlastník Ddavatel Pravděpdbnst výskytu 20% Prdlužení status qu. Dpad Pškzení dbréh jména ddavatele. Penále za nenasazení v termínu. Naplánvání prjektu d něklika etap a iterativní přístup k prjektu. Plán pr mitigaci rizika Průběžné ddávky výstupů a jejich připmínkvání a schvalvání zákazníkem. Pravidelné reprtvání stavu prjektu. Krizvý plán Zvýšené úsilí prjektvéh týmu. Svlání řídící kmise. Stav b) RP02 Nedstatečná kapacita a kvalita prjektvéh týmu Ptenciální
Vlastník Ddavatel Pravděpdbnst výskytu 5% Dpad na kvalitu, kvantitu a termín ddání Dpad výstupů prjektu. Včasné sestavení stabilníh prjektvéh týmu, který plně pkryje ptřebnu pracnst Plán pr mitigaci rizika a kvalitu na prjektu svu kapacitu. Průběžná kntrla. Nutné přesčasy sestavenéh prjektvéh Krizvý plán týmu. Svlání řídící kmise. c) RP03 Nedstatečná sučinnst zákazníka Stav Ptenciální Vlastník Ddavatel Pravděpdbnst výskytu 35% Dpad na kvalitu, kvantitu a termín ddání Dpad výstupů prjektu. Včasná eskalace prblému na řídící kmisi. Plán pr mitigaci rizika Průběžné reprtvání. Dhda se zákazníkem psunu termínu. Krizvý plán Svlání řídící kmise. d) RP04 Prblémy s integrací systému Stav Ptenciální Vlastník Ddavatel Pravděpdbnst výskytu 25% Omezená neb minimální funkčnst systému. Dpad Neschpnst plánvat rezervace. Finanční ztráty Vyský důraz na technický prjekt. Naplánvání integračních testů Plán pr mitigaci rizika v dstatečném předstihu před nasazením. Úzká splupráce s IT ddělením. Průběžná kntrla. Dhda se zákazníkem psunu termínu. Krizvý plán Svlání řídící kmise.
I. Radmapa prjektu Detailní ppis pstupu realizace řešení je jádrem třetí části případvé studie. Obsahuje detailní rzpis trjimperativu prjektu. Začíná se krátkým shrnutím pstupu prjektu (bdba manažerskéh shrnutí) a následně jsu ppsány detaily jedntlivých etap. Každý část bsahuje sumarizaci, která je prmítnuta d manažerskéh shrnutí. Tat kapitla ppisuje v jakých krcích a jakým způsbem bude dsažen cílvéh stavu. Dále bsahuje rganizační strukturu a vyžadvanu sučinnst, harmngram a milníky. Na závěr jsu uvedeny blasti následnéh rzvje za hrizntem rku 2011. Předchzí kapitly definvaly cílvý stav prjektu, kteréh bude dsažen v hrizntu knce rku 2011. Vzhledem na pžadvaný rzsah řešení a nutnst c nejrychlejšíh přínsu pužívání aplikace RESYZ je vhdné rzdělit prjekt d tří realizačních etap (každá etapa je plánvána na cca 6 měsíců): Etapa 1: návrh a implementace RRF (základní funkčnsti pr integraci s klím, klíčvé reprtvací a mnitrvací nástrje) a RESYZ 1.0. Definice prcesů a metdiky pr kntinuální rzvj RRF a aplikací nad RRF. Etapa 2: rzšíření RRF další funkčnsti (napjení na MS Sharepint) a nástrje, RESYZ 1.5, RESYPA 1.0. Etapa 3: RESYZ 2.0, RESYPA 1.5. Na následujícím brázku je vidět rámcvá radmapa etap 1 3. Plán jedntlivých etap je upřesněný v následujících kapitlách. V průběhu všech etap bude prbíhat technlgický rzvj architektury a aplikačníh framewrku. 1) Prjektvý tým V úvdu je uvedena charakteristika a slžení týmu, který je nutné pr úspěšnu realizaci řešení sestavit. Není třeba psát knkrétní jména, ale jen rle, které se budu prjektu účastnit jak ze strany zákazníka, tak ddavatele. Je třeba zdůraznit také rli vedení firmy v pdbě řídící kmise a prjektvéh veducíh. Tam, kde je t vhdné, krátce ppíšeme knkrétní náplň práce. Především u rlí zákazníka. Tyt rle jsu pak sučástí finančních kalkulací, uvedených v kapitlách s detailních ppisem jedntlivých etap. Pr implementaci řešení tht významu a ptenciálu je z phledu QXT nutné vytvřit ptřebné předpklady pr realizaci prjektu p stránce rganizační. Vedle ddávky kmpnent
framewrku, funkčních kmpnent a metdiky pr práci s nimi je nutné vytvřit i rganizační struktury, které budu budvání tht systému řídit. Tyt struktury budu zajišťvat využití ddaných kmpnent v i dalších blastech. Řídící kmise nejvyšší prjektvá řídící struktura prjektu. Schvaluje a krdinuje klíčvé plánvané ddávky a milníky. Je nadřízená Architektnické kmisi a Prjektvému řízení. Členy jsu nminváni z vrchlvéh managementu QXT a ITE. Jedná se dzrný rgán nad prjektem. Kmise pr architekturu systému udržuje a rzvíjí celkvu vizi rzvje RRF a suvisejících aplikací. Zajišťuje, aby všechny rzvjvé aktivity byly v suladu s tut vizí. Členy jsu nminváni: Hlavní sftwarvý architekt (QXT). Business architekt (QXT). Business analytik (ITE). Sftware architekt (ITE). Prjektvý tým QXT zajišťuje a pskytuje sučinnsti za business i IT QXT. Je dpvědný za kntrlu termínů a výstupů ITE (i průběžných). Prjektvý manažer je dpvědný za kntrlu kvality a případnu eskalaci neddržvání termínů a kvality na řídící kmisi. Prjektvý manažer. QA manažer (klíčvý uživatel systému / metdik). Prjektvý tým za ITE je dpvědný za ddání výstupů ve stanvených termínech, kvalitě, kvantitě a dhdnutém rzpčtu. Prjektvý manažer je dpvědný za řešení rizik, a jejich případnu eskalaci na Řídící kmisi. Prjektvý manažer. Business analytik. Sftware architekt. Knfigurační manažer. Test manažer / test architekt. Vývjář. Tester. 2) Sučinnsti Žádný prjekt neprbíhá izlvaně. Prt je v úvdu zmíněna také nezbytná sučinnst, kteru musí zákazník realizátrvi řešení pskytnut. A t nejen v pdbě lidských zdrjů, ale třeba také sučinnstí a spluprací s jinými prjekty, které mhu prbíhat sučasně a mít vliv na realizaci.
Ppřípadě nutnu infrastrukturní pdpru pr případ pžadavku na prpjení s jinými systémy. Špatná sučinnst je velmi čast důvdem (nepřímým) neúsěšné realizace prjektů. Ptřebnu sučinnst lze rzdělit na 3 typy: Zdrje, Prjekty a Infrastruktura. a) Zdrje Prjektvý manažer - stanvení kmpetentníh zástupce a jeh vybavení příslušnými pravmcemi. Ideálně sba ze středníh managementu. V průběhu prjektu budu definvány detailní pžadavky na sučinnst dvnitř QXT (ddání specifických testvacích dat, vyplnění číselníků apd.). Pr jejich zprstředkvání a hlavně následnu knslidaci před předáním ITE je nutné zajistit dstatečnu kapacitu dedikvaných pracvníků QXT. Business a sftware architekti - zajistit dstatečnu kapacitu dpvědných architektů ze strany QXT. Ti pak budu během prjektu průběžně pdle předem definvanéh plánu revidvat a akceptvat výstupy prjektu a účastnit se plánvaných wrkshpů a schůzek. D rle architektů je nutné vybrat zkušenější (klíčvé) uživatele a vybrané zástupce managementu, kteří budu mít dstatečnu kvalifikaci a časvu kapacitu pr návrh systému v Technickém prjektu. Testeři pr přípravu a prvedení UAT je ptřeba dedikvat dstatečně velký tým testerů, kteří budu schpni ve splupráci s testvacím týmem ITE a v rámci předem definvanéh plánu, kvalitně připravit a testvat výstupy prjektu. Testeři by měli být vybráni jak z blasti klíčvých uživatelů, tak i běžných, aby byly testy kmplexní a věrhdné. Členvé řídícíh výbru nminvat d řídící h výbru členy vrchlvéh managementu, kteří budu mci věnvat prjektu dstatečnu pzrnst. Během prjektu budu pravidelně infrmváni stavu, budu prvádět klíčvá rzhdnutí a prvádět finální akceptace. b) Prjekty a klní systémy Prjekty v QXT prbíhá paralelní prjekt implementace MS technlgií, který má přímý dpad na prjekty RRF / RESYZ. V rámci Technickéh Prjektu budu detailně ppsány krky na bu stranách, které pvedu k vyřešení všech knfliktů. Bude ptřeba zajistit v definvaném čase prvedení těch krků, které budu mim rámec prjektu RRF / RESYZ. Oklní systémy u předem definvaných systémů QXT jde zejména včasné ddání ptřebné dkumentace, zajištění případných schválených úprav v těcht systémech v definvaném termínu a vyhrazení jejich dstupnsti pr vývj, trénink a testvání integrace prjektu RRF / RESYZ s těmit systémy. c) Infrastruktura Připravenst všech prstředí (vývjvé, testvací, tréninkvé, deplyment a prvzní) v ptřebné struktuře a pžadvané kapacitě tak, jak budu ppsány v Technickém prjektu v kapitlách Infrastruktura a Nefunkční pžadavky.
Ptřebné nástrje pr pdpru celéh živtníh cyklu prjektu zajistí ITE. 3) Etapa 1 RRF 1.0 a RESYZ 1.0 Nyní následuje detailní ppis jedntlivých etap realizace. C se dělá, kd a kdy t dělá a v nepslední řadě v jakém rzsahu. a) Rzsah a zaměření etapy Nejprve krátce ppíšeme funkce, činnsti, výstupy, které budu v rámci dané etapy realizvány. V tét etapě budu vyřešeny klíčvé technické rizika RRF, které mají dpad na implementaci aplikací nad RRF. Jak prf-f-cncept bude implementvána první verze aplikace RESYZ: RFF Vyhdncvání uživatelských práv (kmunikace s LDAP). Pdpra wrkflw. Definice klíčvých prcesů. Vizuální kmpnenty pr RESYZ. Nevizuální kmpnenty pr RESYZ. Mduly RESYZ Správa zdrjů (Evidence a správa zasedaček). Kalendář. Reprty pr management využívání zdrjů, změnách a rušení rezervací. Elektrnická rezervace zasedaček. Práva pr rezervaci jedntlivých zasedaček. Mžnst zadat pakvané rezervace. Online rzhraní pr zadávání a mnitrvání stavu rezervací. b) Sučinnsti Následují pžadavky na knkrétní sučinnst zákazníka. U pžadavků na lidské zdrje je nutné uvést alespň dhad hdin a jejich předběžné rzlžení v průběhu etapy, aby si je mhl zákazník naplánvat a vyčíslit, klik jej t bude stát. Na knci následuje suma pžadvaných hdin, která se přenáší d manažerskéh shrnutí. V rámci tét etapy bude nutné ze strany zákazníka QXT zajistit intenzivní sučinnst následujících typů uživatelů: Pracvníci dpvědní za plánvání zasedaček a znalsti firemních prcesů spjených s jejich rezervací. Především pr účely návrhu krdinaci řešení (klíčví uživatelé). Během tvrby technickéh prjektu. Kapacita cca. 60 člvěkhdin.
Zástupci managementu pr účely vydefinvání a následně testvání pžadvaných manažerských výstupů. Během tvrby technickéh prjektu. Kapacita cca. 30 člvěkhdin. Uživatelé buducíh systému pr testvání a zašklení systému. Během testů systému. Kapacita cca. 120 člvěkhdin. Uživatelé buducíh systému pr prvtní knfiguraci a nastavení systému. Během nasazení systému. Kapacita cca. 90 člvěkhdin. Prjektvý veducí (krdinátr) ze strany QXT. Během celé fáze. Kapacita cca. 50 člvěkhdin. Členvé řídícíh výbru ze strany QXT. 1x za měsíc. Kapacita cca. 15 člvěkhdin. Očekávaná celkvá minimální sučinnst ze strany Q&X: 365 člh. c) Harmngram Harmngram je vhdné uvést v pdbě Ganttva diagramu. Vlte kmprmis mezi čitelnstí a míru detailu. Je vhdnější velký detail vlžit d dkumentu jak přílhu a zde jen uvést shrnující infrmace, ze kterých půjde vyčíst kdy se c bude realizvat a jak na sebe jedntlivé části navazují.
d) Odhad nákladů na realizaci etapy V pslední části ppisu dané etapy jsu vyčísleny dhadvané náklady na nasazení řešení z phledu ddavatele. Začíná se uvedením sazby, která se bvykle pr realizaci pužívá. Ddavatel může klidně uvést své sazby a pr zákazníka tat sazba může být vdítkem pr výběrvé řízení. Následně jsu v tabulce sečteny všechny náklady ddavatele. Pkud se přizuje technické vybavení, uvádí se d samstatné tabulky, ppřípadě můžeme rzpis uvést v samstatné kapitle. V tmt případě je nutné ale v tét části uvést alespň sumu nákladů na přízení. Na knci je uvedena celkvá suma za etapu, která se přenáší d manažerskéh shrnutí. V úvdu kapitly je vhdné také uvést tleranci, s jaku byl dhad sestaven. Odhad nákladů na realizaci je pčítán při průměrné sazbě 1 000Kč / člh bez DPH. Realizace se může dchylvat d tht dhadu +/- 20%. D ceny není zahrnut cena za přízení dalšíh HW a SW, které bude nutné pr zprvznění systému přídit. Splečnst QXT si je na základě stanvení parametrů ddavatele přídí u svých ddavatelů. Nasazení je vyčíslen v kapitle Finance Systém / část člh Cena v Kč bez DPH Funkčnsti RFF 970 970 000 Vyhdncvání uživatelských práv (kmunikace s LDAP) 100 Pdpra wrkflw (existuje v rámci ITEFWK) 0 Definice klíčvých prcesů 100 Vizuální kmpnenty pr RESYZ 250 Nevizuální kmpnenty pr RESYZ 250 Správa zdrjů (Evidence a správa zasedaček) 100 Kalendář 20 Reprty pr management využívání zdrjů, změnách a rušení rezervací 150 RESYZ 500 500 000 Elektrnická rezervace zasedaček 250 Práva pr rezervaci jedntlivých zasedaček 100 Mžnst zadat pakvané rezervace 100 Online rzhraní pr zadávání a mnitrvání stavu rezervací 50 Celkvá cena za Etapu 1 1 470 1 470 000
4) Etapa 2 RRF 1.5, RESYZ 1.5, RESYPA 1.0 Obdba předchzí kapitly. a) Rzsah a zaměření etapy V tét etapě bude řešena zejména integrace s MS Exchange a MS Sharepint. Dále budu řešeny pdpůrné a nice-t-have funkčnsti a změnvé pžadavky na RRF a RESYZ. Zárveň bude implementvána nvá aplikace RESYPA. V sučasné dbě lze identifikvat jenm pžadavky na funkčnsti RESYZ, které nebyl mžné zařadit d Etapy 1 a pžadavky na aplikaci RESYPA. Ostatní pžadavky budu identifikvány v průběhu první fáze Etapy 2. RRF Integrace s MS Exchange. Integrace s MS Sharepint. Vytvření rzhraní pr datvý sklad. Integrace se sytémem pr fyzické přístupy d místnstí na kartu. Autmatické předání infrmací změně stavu rezervace prstřednictvím infrmačníh mailu. Pdpra wrkflw pr naplánvání údržby a bnvy zdrjů (např. servisní prhlídky u autmbilů, vymalvání zasedaček, výměna kberců apd.). RESYZ 1.5 Pdpra suplementárních služeb k rezervacím (bčerstvení, prjektr ). Elektrnický přístup d zasedaček na vstupní kartu (kdkli z účastníků jednání). V případě, že rezervace není využita d 10min d začátku platnsti je zasedačka uvlněna pr khkli. RESYPA 1.0 Elektrnická rezervace firemních autmbilů. Práva pr rezervaci jedntlivých autmbilů. Mžnst zadat pakvané rezervace. Online rzhraní pr zadávání a mnitrvání stavu rezervací. b) Sučinnsti V rámci tét etapy bude nutné ze strany zákazníka Q&X zajistit intenzivní sučinnst následujících typů uživatelů: Pracvníci dpvědní za technicku infrastrukturu pr účely integrace s existujícími firemními nástrji (prdukty Micrsft, karetní systém ). Během celéh prjektu. Kapacita cca. 50 člvěkhdin.
Pracvníci dpvědní za rezervace a půjčvání firemních autmbilů se znalstí firemních prcesů spjených s jejich rezervací. Především pr účely návrhu krdinaci řešení (klíčví uživatelé). Během tvrby technickéh prjektu. Kapacita cca. 60 člvěkhdin. Uživatelé buducíh systému pr testvání a zašklení systému. Během testů systému. Kapacita cca. 120 člvěkhdin. Uživatelé buducíh systému pr knfiguraci a nastavení nvých funkčnstí systému. Během nasazení systému. Kapacita cca. 70 člvěkhdin. Prjektvý veducí (krdinátr) ze strany QXT. Během celé fáze. Kapacita cca. 40 člvěkhdin. Členvé řídícíh výbru ze strany QXT. 1x za měsíc. Kapacita cca. 15 člvěkhdin. Očekávaná celkvá minimální sučinnst ze strany Q&X: 355 člh. c) Harmngram d) Odhad nákladů na realizaci etapy Odhad nákladů na realizaci je pčítán při průměrné sazbě 1 000Kč / člh bez DPH. Realizace se může dchylvat d tht dhadu +/- 20%. D ceny není zahrnut cena za přízení dalšíh HW a SW, které bude nutné pr zprvznění systému přídit. Splečnst QXT si je na základě
stanvení parametrů ddavatele přídí u svých ddavatelů. Nasazení je vyčíslen v kapitle Finance Systém / část člh Cena v Kč bez DPH RRF 1.5 1430 1 430 000 Integrace s MS Outlk 300 Integrace s MS Sharepint 300 Vytvření rzhraní pr datvý sklad 300 Integrace se sytémem pr fyzické přístupy d místnstí na kartu 300 Autmatické mailvé ntifikace 80 Pdpra wrkflw pr naplánvání údržby a bnvy zdrjů 150 RESYZ 1.5 470 470 000 Pdpra suplementárních služeb k rezervacím 80 Elektrnický přístup d zasedaček na vstupní kartu (účastníci jednání) 240 Autmatické uvlňvání zasedaček v případě jejich nevyužití 150 RESYPA 1.0 300 300 000 Elektrnická rezervace autmbilů 120 Práva pr rezervaci jedntlivých autmbilů 80 Mžnst zadat pakvané rezervace 80 Online rzhraní pr zadávání a mnitrvání stavu rezervací 20 Celkvá cena za Etapu 2 2 200 2 200 000
5) Vize dalšíh rzvje Etapa 3 (RRF 2.0, RESYZ 2.0, RESYPA 1.5) V každém prjektu je vhdné uvést a ppsat, c se bude dít p jeh dknčení, respektivě c dalšíh je vhdné udělat. V našem případě a v případě nasazení jakéhkliv technickéh řešení se bvykle jedná dluhdbu pdpru. Není na škdu, když se uvede také zpětné vyhdncení prvzu sytému s dstupem například půl rku a návrh dalšíh rzvje. Vždy je třeba ale zákazníkvi zdůraznit, že dknčením nasazení by splupráce neměla knčit a zkušenst ddavatele ukazuje, že pdpra má smysl. V sučasné dbě je předčasné diskutvat bsah a zaměření třetí etapy prjektu. Je velmi pravděpdbné, že v tét etapě budu řešeny zejména pdpůrné a rzšiřující funkčnsti, splu se změnvými pžadavky na RRF, RESYZ a RESYPA. Ty budu vycházet z prvzu systému a jeh využívání uživateli. Jednu z nvých funkčnstí, která byla již identifikvána a zatím dlžena, je pdpra mbilních zařízení. Zárveň budu identifikvány aplikace z existujícíh aplikačníh prtflia QXT, které jsu vhdnými kandidáty na převedení svých funkčnstí nad RRF a pdpru firemních prcesů QXT, které zatím nejsu pdprvány žádným systémem / aplikací. Předpkládá se, že třetí etapa bude zahájena p piltu druhé etapy (trvání cca. 1 2 měsíce) a uknčena před kncem rku 2011. Další rzvj systému p rce 2011 bude řešen v rámci samstatné servisní smluvy s ddavatelem. Parametry smluvy budu nastaveny před jejím pdepsáním. Pr aktuální stav, známý na knci případvé studie, je vyžadvána pdpra v rzsahu minimálně 4 člh/týden.