Tento dokument je ukázkou toho, jak má vypadat dokument případové studie, který je výstupem práce na cvičení v našem předmětu. Neberte jej prosím ale jako dogma. Jeho smyslem je především ukázat kapitoly, které bývají obvykle součástí reálné případové studie. Pro účely výuky jsme si jej trochu uzpůsobili a některé části zjednodušili, vypustili nebo naopak doplnili. Nepřistupujte k němu způsobem copy-paste, ale berte jako zdroj inspirace toho, co musí vaše práce obsahovat. Naše komentáře a doporučení jsou uvedeny vždy na začátku každé kapitoly a všude tam, kde to považujeme za důležité. Komentáře poznáte podle toho, že jsou psány stejným písmem jako tento text. Co je smyslem případové studie? Poskytnout zákazníkovi podklady pro rozhodnutí o tom, zda popsané řešení jeho problému realizovat nebo ne. Ve většině případů je určen pro střední a vyšší management. Tomuto určení odpovídá také struktura dokumentu, který má 3 části: 1. Manažerské shrnutí – nejdůležitější část dokumentu, která je určena pro vrcholové vedení a ve většině případů je jedinou částí dokumentu, které vrcholové vedení čte. Obsahuje stručné a přehledné informace o „trojimperativu“ projektu. Jedná se o shrnutí detailů, které jsou podrobně rozepsány ve 2. a 3. části studie. 2. Business pohled na zákazníka – shrnutí aktuálního stavu, problémů a potřeb zákazníka. Ve druhé části obsahuje vizi, kterou by chtěl zákazník při svém podnikání realizovat a strategii, kterou ji chce naplnit. Tato část je určena spíše pro „netechnický“ management zákazníka a pomáhá ujasnit obecný koncept řešení. 3. Podmínky realizace navrženého řešení zákazníkova problému – všechny aspekty, které si musí zákazník při realizaci uvědomit. Obsahuje jak organizační, tak i technickou stránku projektu. Je určena spíše pro „technický“ management zákazníka, který rozumí navrženému řešení. Obsahuje především detailní rozpad „trojimperativu“ projektu, kterým jako dodavatel odůvodňujeme časovou a finanční stránku případné realizace projektu. Po formální stránce musí být dokument přehledný a čitelný, musí být jasná jeho struktura, text musí logicky navazovat a nesmí obsahovat gramatické chyby ani překlepy. Samozřejmostí jsou záhlaví a zápatí dokumentu, na začátku obsah a utor (odpovědná osoba) dokumentu. Při psaní doporučujeme používat jednoduché, krátké a výstižné věty, které pomáhají lépe pochopit popsanou problematiku. Po formální stránce se nebojte projevit také „rozumnou“ míru kreativity. Obecně platí pravidlo, že jeden přehledný a názorný obrázek vydá za několik stránek textu. Zvláště v případě vysokého managementu je těžké získat více času, než několik minut. Žádný manažer nebude číst více než jednu nebo dvě stránky textu. Kapitoly jsou uváděny tak, že „velké“ začínají vždy na nové stránce. Poznámka: Některé nadpisy jsme ponechali v anglickém jazyce, protože se tak často uvádějí i v realitě. V textu jsou většinou popsány česky. Jedná se především o pojmy:
Executive summary = manažerské shrnutí
Roadmapa projektu = postup realizace projektu.
IT Enterprises
Každý dokument má svou úvodní stránku, která identifikuje, o jaký dokument se jedná. Označení „final draft“ je interní informace, která identifikuje, zda je možné dokument předat zákazníkovi nebo se na něm ještě pracuje. Finální verze dokumentu, odevzdávaná zákazníkovi, již informaci o draftu neobsahuje. Bylo by to pro něj matoucí a zbytečné.
Q&X TRADING, s.r.o Rezervační systém zdrojů (RESYZ) Úvodní studie – final draft
Q&X trading, s.r.o. Rezervační systém zasedaček (RESYZ) Úvodní studie – final draft
2
IT Enterprises Pro interní účely je vhodné v textu uvádět historii změn, aby bylo možné dohledat, kdo jakou změnu provedl a je odpovědný za uvedený obsah. Ve finální verzi, odevzdávané zákazníkovi se tato část již neobjevuje.
Verze dokumentu 0.9 0.6 0.5 0.2
Datum 24.05.2010 13.05.2010 05.05.2010 23.04.2010
Autor Josef Petr Matěj Novák Josef Petr Matěj Novák
0.1
01.04.2010
Josef Petr
Q&X trading, s.r.o. Rezervační systém zasedaček (RESYZ) Úvodní studie – final draft
Popis změn Verze k akceptaci Zapracování CR Doplnění kapitoly Roadmapa Zapracovány připomínky projektového manažera Úvodní draft, osnova
3
IT Enterprises A. Executive summary Manažerské shrnutí je nejdůležitější část dokumentu. Je to jediná část, kterou čte vrcholový management zákazníka. Doporuč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 podstatné, co je pro pochopení uvedené částky nezbytné. Dobře sepsané manažerské shrnutí může výrazným způsobem ovlivnit rozhodování zákazníka a udělat dobrou reklamu dodavateli.
1) Zadání Originální zadání, které nám dal zákazník na začátku, aby bylo jasné, co vlastně chtěl a chce řešit. Víme, kde byl začátek projektu. Změny, které během práce nastaly je nutné výrazněji odlišit.
Najít řešení, které pomůže zvýšit efektivitu využívání interních firemních zasedacích prostor společnosti QXT. Klíčovým milníkem, do kdy je řešení nutné aplikovat, je konec roku 2011.
Na základě diskusí byla navržena implementace elektronického rezervačního systému.
Klíčové požadavky na systém: jednoduchá a rychlá dostupnost informací o rezervacích, informace o využití /nevyužití rezervací, reportovací nástroje, operativnost 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 jeho firmě po nasazení navrženého řešení. Nejedná se o technickou vizi, ale obecnou vizi. Ideálně doplněno jasným a výstižným obrázkem.
Na základě workshopů mezi QXT a ITE byla identifikována potřeba obecnějšího řešení správy zdrojů. Řešení je založeno na univerzálním systému pro rezervaci firemních zdrojů (RESYZ). Systém je pevně začleněn do firemní infrastruktury a umožňuje jednoduché využívání všemi zaměstnanci firmy. V případě potřeby rezervace zasedačky, firemního automobilu nebo jiného firemního zdroje, který je evidován v systému může běžný uživatel uvnitř nebo i vně firmy přihlášením do systému vybrat volný zdroj a ten si zarezervovat. Pokud jej nepotřebuje, může rezervaci zrušit. Součástí systému je robustní reportovací modul, který poskytuje informace podle potřeby.
Navrhované řešení je založené na principech třívrstvé architektury s ohledem na moderní principy SOA a jednoduchou propojitelnost s jinými systémy společnosti.
Řešení využívá technologické základny produktů Microsoft, které se QXT rozhodla používat
Q&X trading, s.r.o. Rezervační systém zasedaček (RESYZ) Úvodní studie – final draft
4
IT Enterprises User approach
User
Browser
Okolní aplikace
Aplications
RESYZ
RESYPA
...
MS Sharepoint
MS Exchange server RRF
Moduly
Vizuální komponenty
Nevizuální komponenty
Uživatelská práva
Definice procesů a workflow
DB
Datový sklad
LDAP
3) Roadmapa Krátké shrnutí časového rámce projektu a informace o klíčových výstupech. Pro rychlé vizuální pochopení Je vhodné popisný text omezit na nezbytné minimum a harmonogram popsat zjednodušeným Ganttovým diagramem.
Rozdělení projektu do tří etap o
Etapa 1 – vyřešení klíčových funkčností RRF (obecné funkce, grafické prostředí, ověřování), které mají dopad na implementaci aplikací nad RRF. Bude implementována první verze aplikace RESYZ (rezervace zasedacích místností a funkčnosti s tím spojené).
o
Etapa 2 – vyřešení integrace se systémy MS Exchange a MS Sharepoint. Dále budou řešeny podpůrné a „nice-to-have“ funkčnosti a změnové požadavky (např. napojení na čtečky vstupních karet). Bude implementována nová aplikace RESYPA (rezervace firemních automobilů a podpora managementu pro sledování jejich využívání).
o
Etapa 3 – budou identifikovány aplikace z existujícího aplikačního portfolia QXT, které jsou kandidáty na převedení nad RRF a business procesy QXT, které nejsou podporovány žádným systémem.
Q&X trading, s.r.o. Rezervační systém zasedaček (RESYZ) Úvodní studie – final draft
5
IT Enterprises 4) Harmonogram
1) Cena Nejdůležitější část celého manažerského shrnutí. Je třeba jasně uvést, kolik bude celé řešení stát a z čeho je cena složena. Je vhodné také uvést návratnost projektu. Čísla musí být jasná a zřejmá, nicméně vzhledem k možným nejasnostem je vhodné uvést i míru tolerance, s jakou je třeba k těmto číslům přistupovat. Klíčové čísla je vhodné zdůraznit, například tučným písmem. Náklady na pořízení systému jsou rozděleny podle realizačních etap. Ceny jsou počítány z průměrné hodinové sazby 1000 Kč/člh bez DPH. Počítány jsou jen náklady na realizaci. Ostatní HW a SW je na základě společné dohody pořizován QXT. Maximální odchylka odhadu je +/- 20%.
Cena Etapy 1: 1 470 000 Kč Cena Etapy 2: 2 200 000 Kč Cena Etapy 3: cena bude stanovena po vyhodnocení Etapy 1 a 2 a definici nových požadavků.
Návratnost investice (ROI) pro období 5 let byla na základě nákladů (bez součinnosti a využití frameworku společnosti ITE) a přínosů spočítána ve výši 2,4. Tzn. V tomto horizontu je implementace systémů zisková.
2) Součinnost Část, kterou je možné zahrnout i kapitoly cena. My ji uvádíme jako samostatnou kapitolu, abychom si uvědomili, že zákazník neplatí jen dodavateli, ale také investuje za interní a další zdroje projektu. Je také doporučené uvést všechny nezbytné podmínky pro korektní realizaci, které byly identifikované během analýzy. Například požadavky na nezbytnou infrastrukturní součinnost. Pro úspěšnou realizaci projektu bude vyžadována ze strany QXT následující součinnost:
Personální – dedikovaný vedoucí projektu, členové vrcholového managementu pro účast v řídící komisi, klíčoví uživatelé pro účely analýzy a návrhu systému, běžní uživatelé pro účely provedení funkčních a zátěžových testů. Minimální požadovaná součinnost je ve výši 365 člh pro 1. etapu projektu a 355 člh pro 2. etapu. Celkem 720 člh.
Q&X trading, s.r.o. Rezervační systém zasedaček (RESYZ) Úvodní studie – final draft
6
IT Enterprises
Infrastrukturní – společnost QXT zajistí připravenost prostředí pro nasazení systému, specifikuje způsob a parametry napojení na stávající systémy a poskytne kapacitu pro řešení problémů spojených s integrací systému do existujícího prostředí.
Q&X trading, s.r.o. Rezervační systém zasedaček (RESYZ) Úvodní studie – final draft
7
IT Enterprises B. Obsah Obsah celého dokumentu. Není nutné uvádět všechny kapitoly. Stačí uvést kapitoly do druhé úrovně. A.
EXECUTIVE SUMMARY ............................................................................................................................. 4 1) 2) 3) 4) 1) 2)
ZADÁNÍ ......................................................................................................................................................... 4 VIZE ............................................................................................................................................................. 4 ROADMAPA ................................................................................................................................................... 5 HARMONOGRAM ............................................................................................................................................ 6 CENA ............................................................................................................................................................ 6 SOUČINNOST.................................................................................................................................................. 6
B.
OBSAH ..................................................................................................................................................... 8
C.
SLOVNÍK ................................................................................................................................................. 10
D.
PŘÍLOHY ................................................................................................................................................. 11 1)
E.
HARMONOGRAM PROJEKTU ............................................................................................................................ 11 ZADÁNÍ ÚVODNÍ STUDIE ........................................................................................................................ 12
1) 2) 3) 4) 5) 6) F.
VSTUPNÍ ZADÁNÍ ........................................................................................................................................... 12 ZÁMĚR........................................................................................................................................................ 12 AKTUÁLNÍ PROBLÉMY (BUSINESS PROBLEMATIKA) ................................................................................................ 12 KLÍČOVÉ ICT POŽADAVKY ................................................................................................................................ 13 TECHNOLOGICKÁ A JINÁ OMEZENÍ..................................................................................................................... 13 CHANGE REQUESTS (POŽADAVKY NA ZMĚNU) ..................................................................................................... 14 SITUAČNÍ ANALÝZA ................................................................................................................................ 15
1) 2) 3) G.
SWOT ANALÝZA QXT ................................................................................................................................... 15 FURPS+ ANALÝZA RESYZ .............................................................................................................................. 15 PODPORA MANAGEMENTU QXT ...................................................................................................................... 17 VIZE ŘEŠENÍ ........................................................................................................................................... 18
1) 1) 2) H.
STRATEGIE NAPLNĚNÍ VIZE ŘEŠENÍ ..................................................................................................................... 18 KLÍČOVÉ BENEFITY NAVRHOVANÉHO ŘEŠENÍ PRO BUSINESS .................................................................................... 19 KLÍČOVÉ BENEFITY NAVRHOVANÉHO ŘEŠENÍ PRO IT .............................................................................................. 20 RIZIKA .................................................................................................................................................... 22
1) 2) I.
RIZIKA ZADAVATELE ....................................................................................................................................... 22 PROJEKTOVÁ RIZIKA ....................................................................................................................................... 23 ROADMAPA PROJEKTU .......................................................................................................................... 25
1) 2) 3) 4) 5)
PROJEKTOVÝ TÝM .......................................................................................................................................... 25 SOUČINNOSTI ............................................................................................................................................... 26 ETAPA 1 – RRF 1.0 A RESYZ 1.0 .................................................................................................................... 28 ETAPA 2 – RRF 1.5, RESYZ 1.5, RESYPA 1.0 .................................................................................................. 31 VIZE DALŠÍHO ROZVOJE – ETAPA 3 (RRF 2.0, RESYZ 2.0, RESYPA 1.5) ................................................................ 34
Q&X trading, s.r.o. Rezervační systém zasedaček (RESYZ) Úvodní studie – final draft
8
J.
FINANCE ................................................................................................................................................ 35
K.
ZÁVĚR .................................................................................................................................................... 37
C. Slovník Slovníček je, i když se to nezdá, jednou z nejdůležitějších částí, kterou je třeba vyřešit na začátku celého projektu. V případě špatného chápání pojmů ze strany zákazníka i dodavatele jsou důsledky, zvláště ve fázi akceptace, katastrofální. Ve slovníku se omezte na vysvětlení klíčových zkratek a pojmů, které jsou pro správné pochopení obsahu studie důležité. Zkratka CF CR ČR člh DCF Framework
FURPS+
HW ICT ITE ITEFWK LDAP Mitigace MS NPV QXT RESYPA RESYZ ROI RP## RRF RZ## SLA SW SWOT analýza UAT Workflow
Popis změn Cash Flow, peněžní tok Change Request Česká republika Člověkohodiny Discounted Cash Flow, diskontovaný peněžní tok Obecné softwarové prostředí pro jednoduchý vývoj aplikací Popis požadavků na systém z hlediska funkčností (Functionalities), použitelnosti (Usability), spolehlivosti (Reliability), výkonnosti (Performance), podporovatelnosti (Suportability) a dalších nefunkčních požadavků (+) Hardware Informační a komunikační technologie IT Enterprises ITE Framework pro podniková řešení Lightweight Directory Access Protocol je definovaný protokol pro ukládání a přístup k datům na adresářovém serveru Zmírnění, minimalizace Microsoft Net Present Value, čistá současná hodnota Q&X Trading, s.r.o. Rezervační systém firemních automobilů Rezervační systém zdrojů Return On Investment , návratnost investice Projektové riziko (číslo) Resources reservation framework (Framework pro systémy na rezervaci zdrojů) Riziko zadavatele (číslo) Service Level Agreement Software, programové vybavení Analýza silných (Strenghts) a slabých (Weaknesses) stránek spolu s příležitostmi (Opportunities) a hrozbami (Threats) Uživatelské akceptační testy Pracovní postup, postup zpracování položek v příslušné agendě (např. žádost o rezervaci).
D. Přílohy Pokud jsou součástí studie přílohy, uvedeme je zde seznamem (v případě, že jsou tištěné) nebo je sem můžeme rovnou vložit. V případě této ukázky je vložen dokument z programu MS Projekt, který obsahuje detailní harmonogram projektu. Tuto část necháváme jako volitelnou. Je na jednotlivých týmech, zda tuto část ve finální studii uvedou nebo neuvedou.
1) Harmonogram projektu
E. Zadání úvodní studie Zde začíná druhá, na business pohled orientovaná, část případové studie. Začíná se prvotním zadáním a jeho rozborem. Smyslem je shodnout se na tom, co chce zákazník vlastně řešit a co má být klíčovým přínosem (výstupem). Předejde se tím zbytečným diskusím při finální prezentaci a obhajobě navrženého řešení.
1) Vstupní zadání Sem vždy vkládáme originální zadání, které nám zákazník dal. Tedy jak to vše začalo, s čím zua námi zákazník přišel. Pokud došlo v průběhu analýzy ke změně, jsou tyto změny uvedeny a rozebrány později, v příslušné části změnového řízení. Hledáme řešení, které nám pomůže zvýšit efektivitu využívání našich interních zasedacích prostor. Klíčovým milníkem je konec roku 2011.
2) Záměr Zde popisujeme, jak jsme zadání během společných diskusí pochopili a co je jeho smyslem. Jedná se o detailnější a konkrétnější popis zadání, včetně nástřelu řešení. Není třeba psát dlouhý text, spíše klíčové myšlenky, podobně jako v dokumentu A4. V případě, že došlo k výrazné změně, je proveden odkaz do kapitoly změn.
Společnost QXT vydává na nákladech na externí prostory ročně až 2,8 mil. Kč. Cílem managementu QXT je omezit plýtvání zdrojů pro jednání. Pokud lze, všechna jednání a prezentace by měly proběhnout v interních prostorách, ve kterých je vybudováno potřebné zázemí.
Vhodným řešením se jeví implementace elektronického rezervačního systému pro zasedačky v sídle společnosti.
Základními požadavky na systém je jednoduchá a rychlá dostupnost informací o rezervovaných zasedačkách, informace o využití / nevyužití rezervací, reportovací nástroje pro management a jednoduchost rezervace/zrušení běžnými zaměstnanci.
3) Aktuální problémy (business problematika) V této části popisujeme aktuální problémy, které má zákazník z hlediska fungování společnosti, jejich dopad a důvody, které vedly k oslovení dodavatele a hledání řešení problémů.
Nevyužívání rezervací interních zasedaček (zasedačky a prezentační místnosti jsou dle názoru managementu pořád prázdné).
Evidence rezervací existuje jenom v papírové podobě na dveřích zasedaček.
Nemožnost kontroly využití rezervací, monitoringu rušení rezervací, nedostupnost informací pro rozhodování.
Malá motivaci zaměstnanců pro využívání interních prostor.
4) Klíčové ICT požadavky Technická omezení (požadavky), které jsou na systém kladeny z pohledu podpory. Vzhledem k tomu, že my řešíme informační systém, uvádíme a popisujeme specifika zákazníka z pohledu IT oddělení. Z těchto podmínek vychází navržené řešení. Pokud nemá například zákazník vlastní IT oddělení a ani jej nechce, musíme zvážit, jakým způsobem bude systém provozovaný a jaké bude jeho technické řešení. Detailní technické požadavky jsou uvedeny v následující kapitole. Zde se omezíme maximálně na konstatování, zda požaduje komerční nebo open-source produkty.
IT oddělení QXT má jenom 2 správce sítě a 2 správce systémů. V současné době jsou plně vytíženi a i v budoucnu se očekává, že jejich kapacity budou omezené. Rozšíření IT oddělení se neplánuje.
QXT používá v současné době výhradně volně dostupných technologií (openoffice, thunderbird, mozilla, linux).
HW a SW nutný pro nasazení systému, který přímo nesouvisí se systémem (např. server, licence serverového SW), bude pořízen přímo společností QXT od již existujících dodavatelů. Stejně tak bude pracovníky QXT zajištěna základní instalace a konfigurace těchto prostředků.
5) Technologická a jiná omezení Zde popíšeme detailní technologické požadavky na systém, které vyžaduje zákazník. Například jestli musí mít nový systém vazby na konkrétní existující systémy, počty uživatelů, obvyklé nástroje a další konkrétní, ve většině případů omezující, podmínky.
Výsledné řešení musí být integrováno s MS Sharepoint a MS Outlook (viz kapitola Change requests), což má za důsledek: o
Nutnost přizpůsobení firemních procesů balíkovému řešení.
o
Limity v možnosti zásahu do zdrojového kódu Microsoftu.
o
Potenciální riziko ztráty záruky a příslušného záručního servisu při nedodržení ujednání licenčních podmínek.
o
Nové technologie nejsou zažité a problémy s nimi mohou zkomplikovat nasazení systému.
Očekávaný počet uživatelů – QXT má v současné době 200 zaměstnanců a 50 obchodních zástupců. I s ohledem na budoucí růst společnosti je potřeba počítat s počtem uživatelů v řádu stovek.
QXT vlastní a používá 30 firemních vozů (náklady na splátku a provoz činí průměrně 200 tis./rok).
Uživatelé pracují primárně s webovým prohlížečem MS Internet Explorer (cca 28% tvoří IE9, dalších 25% starší verze IE8 a IE7) a s webovými prohlížeči Google Chrome (11%), Mozilla Firefox (35%) a Opera (1%).
6) Change requests (požadavky na změnu) V případě, že během hledání řešení a společných diskusí zjistíme, že dochází k významné změně zadání, uvedeme všechny významné změny v této kapitole. Uvádíme i stav, zda byl nebo nebyl požadavek oboustranně akceptován. Z těch akceptovaných plyne, proč došlo ke změně nebo bylo původní zadání rozšířeno. Neakceptované mohou minimalizovat diskusi při obhajobě, proč nebylo „něco“ řešeno nebo navrženo. Také to dokládá, že jsme na nic, co zákazník požadoval, nezapomněli. Akceptace je vždy oboustrannou dohodou a v textu uvádíme vždy výsledek spoelčných dohod. Ne to, co si myslí jen dodavatel nebo zákazník.
1
CR1: Jednoduchá rozšiřitelnost (univerzálnost) řešení pro využití systému i pro další firemní agendy. Např. pro rezervace firemních aut, rezervace lidí na úkoly/projekty, rezervace projektorů a další techniky, atd. – akceptováno.
CR2: Společnost QXT se rozhodla kompletně přejít na MS (Microsoft) technologie, požaduje integraci s MS Outlook a s MS Sharepoint Portal a podporu pro všechny internetové prohlížeče – částečně akceptováno (mimo univerzální podporu všech prohlížečů, budou podporovány jen aktuálně používané).
CR3: Dostupnost systému i z prostředí mimo interní doménu QXT – akceptováno.
CR4: Dostupnost z mobilních telefonů (mobilní technologie jako WAP) – po dohodě zamítnuto z důvodu nevýhodnosti (náročnosti) implementace před usazením systému. Požadavek bude znovu otevřen ve 3. etapě.
CR5: Řešení nebude postaveno plně na „zelené louce“, ale je požadováno, aby bylo postaveno na existujícím frameworku – akceptováno1.
Zadavatel si je vědom, že tímto omezuje možné dodavatele jen na firmy, které mají za sebou více projektů a delší existenci. Chce tím zvýšit pravděpodobnost úspěchu a snížit cenu. Aby bylo možné posuzovat kvalitu a cenu frameworku, je v dalším textu uváděn jako srovnávací Framework autora studie, společnost ITE. Ten byl během práce na studii představen jako ukázkový pracovníkům QXT a ti odsouhlasili jeho použití ve studii.
F. Situační analýza Také tato kapitola je součástí druhé části studie. Navazujeme na předchozí část, která rozebrala zadání a požadavky zákazníka. V této kapitole provedeme rozbor zákazníka pomocí standardních nástrojů, které se používají pro business a technickou analýzu požadavků zákazníka. Pomocí nich rozhodujeme na co se v řešení zaměřit a co konkrétně bude jeho součástí.
1) SWOT analýza QXT SWOT analýza je jednou z prvních analýz, kterou u zákazníka provádíme. Analyzujeme slabiny a silné stránky zevnitř firmy a dopady vnějších vlivů. Společně se zákazníkem se na základě parametrů určuje, na co se z hlediska vnitřního fungování firmy a vnějších vlivů v našem řešení zaměřujeme. Nejčastěji minimalizujeme slabé stránky firmy a současně eliminujeme negativní vnější vlivy. Při tvorbě SWOT analýzy je třeba dobře zvažovat, co je vnitřní problém a co je vnější vliv. Velmi často jsou tyto faktory provázané, a proto je nutné vždy zvažovat, kam který faktor z hlediska SWOT analýzy zapadá.
Strenghts (silné stránky)
Weaknesses (slabé stránky)
Opportunities (příležitosti)
Threats (hrozby)
Nízké náklady na údržbu systému (jenom papírová forma). Neexistence kontroly využívání zdrojů. Informace je k dispozici jenom na dveřích konkrétní zasedačky, často jsou neúplné a neaktuální. Malá flexibilita při plánování. Zefektivnění využívání nejenom zasedaček ale i jiných zdrojů společnosti. Podpora marketingu a PR firmy (ukazujeme naše prostory a ne cizí). Posílení jména firmy. Plýtvání zdroji má přímý dopad na hospodářský výsledek společnosti. Ztráta konkurenceschopnosti. Někteří zákazníci budou muset akceptovat změnu místa konání setkání. Demotivace zaměstnanců a jejich přechod ke konkurenci.
Na závěr je vždy nutné uvést, jakým způsobem se bude, na základě SWOT analýzy, pokračovat. Tj. jakou strategii volíme. V uvedeném dokumentu je to strategie MIN-MAX. Jedná se o případ, kdy minimalizujeme slabiny a posilujeme existující a přicházející vnější příležitosti. V rámci návrhu řešení se zaměříme na minimalizaci slabých stránek a maximalizace příležitostí. Aplikujeme strategii MIN-MAX.
2) FURPS+ analýza RESYZ FURPS+ analýza je analýza, která překlápí business požadavky do konkrétních technických požadavků. Není nutné psát detaily, ale je třeba popsat všechny klíčové parametry, které jsou
z pohledu technické realizace důležité. Analýza uvádí požadavky z různých aspektů, které mají vliv na složitost realizace. Požadavky reflektují výstupy SWOT analýzy.
a) Funkčnosti
Elektronická rezervace zasedaček. Evidence a správa zasedaček. Kalendář. Práva pro rezervaci jednotlivých zasedaček. Možnost zadat opakované rezervace. Suplementární služby k rezervacím (občerstvení, projektor…). Na rezervaci zasedačky musí mít pracovník práva (rozličná práva pro rozličné zasedačky). Práva budou řešena prostřednictvím skupinových rolí (prostřednictvím doménových skupin). Elektronický přístup do zasedaček na vstupní kartu (kdokoli z účastníků jednání). V případě, že rezervace není využita do 10min od začátku platnosti je zasedačka uvolněna pro kohokoli. Automatické předání informací o změně stavu rezervace prostřednictvím informačního mailu. Online rozhraní pro zadávání a monitorování stavu rezervací. Reporty pro management o využívání zdrojů, změnách a rušení rezervací. Podpora workflow pro naplánování údržby a obnovy zdrojů (např. servisní prohlídky u automobilů, vymalování zasedaček, výměna koberců apod.).
b) Použitelnost
Internetové prohlížeče, nejenom IE, ale také Firefox, Chrome a Opera.
c) Spolehlivost
Dostupnost 99% v době 5x12 (pondělí – pátek 7:00 - 19:00). Žádné kritické chyby, které by znemožňovaly použití systému.
d) Výkon
Desítky „kliků“ za minutu. Stovky uživatelů. Doba odezvy maximálně do 10s, průměrně do 5s při plném zatížení systému (stovky uživatelů).
e) Podporovatelnost
Kompletní zdokumentování systému ve vlastnictví zákazníka (administrátorská a programátorská dokumentace). Prostředí běží na serverech zákazníka. Existence testovacího prostředí. Garance řešení chyb dodavatelem (servisní smlouva).
f) Další nefunkční požadavky
Napojení na LDAP, jednotné přihlašování do systému. Vývojová platforma a prostředí Microsoft (.NET, MS SQL server, Windows server).
3) Podpora managementu QXT V našem případě jsme do business analýzy přidali samostatnou kapitolu, která zdůrazňuje požadavky managementu, které naše řešení bude obsahovat. V tomto konkrétním případě se jedná o reporting. Obecně platí, že pokud chceme některý z klíčových požadavků vyzdvihnout, uvedeme jej do samostatné kapitoly, jako v tomto případě. Například podpora logistiky, skladování, ale také IT atd. Podobně je možné tuto kapitolu využít pro zdůraznění benefitů řešení, které toto řešení přinese a které nebylo očekáváno, protože zákazník o něm nevěděl. Dodavatel ukazuje své schopnosti nejen najít řešení, ale najít i další benefity, které může zákazník vyřešením problému získat. Ze stávající situace je jasné, že základním problémem managementu je neexistence relevantních informací pro kontrolu nakládání se zdroji společnosti pro manažerská rozhodnutí. Mezi zásadní informace, které musí RESYZ poskytnout patří:
Fyzická (skutečná) obsazenost zasedaček v konkrétním čase.
Týdenní / měsíční přehledy o vytíženosti zasedaček.
Množství nevyužitých rezervací, s možností dohledání konkrétních pracovníků, kteří rezervaci nevyužili.
Počty změn rezervací.
Obsazenost rezervovaných místností (počet lidí na jednání vs. kapacita zasedačky).
Požadavky oddělení / pracovníků na rezervace.
G. Vize řešení Tuto kapitolu lze považovat za poslední část druhé části studie a přechod k třetí části. Obsahuje popis toho, jakým způsobem se navrhované řešení projeví ve fungování společnosti a jakou cestou se k němu dojde. Prvním krokem je popis vize. V našem případě znamená vize krátký popis stavu, který po nasazení řešení ve firmě nastane. Díváme se tedy jako vizionáři do budoucnosti a popisujeme tuto budoucnost. Krátce zákazníkovi popisujeme, jak funguje nově nasazení řešení v realitě. Zákazník se v ní musí vidět. Na základě workshopů mezi QXT a ITE byla identifikována potřeba obecnějšího řešení správy zdrojů. Řešení je založeno na univerzálním systému pro rezervaci firemních zdrojů (RESYZ). Systém je pevně začleněn do firemní infrastruktury a umožňuje jednoduché využívání všemi zaměstnanci firmy. V případě potřeby rezervace zasedačky, firemního automobilu nebo jiného firemního zdroje, který je evidován v systému může běžný uživatel uvnitř nebo i vně firmy přihlášením do systému vybrat volný zdroj a ten si zarezervovat. Pokud jej nepotřebuje, může rezervaci zrušit. Systém podporuje maximální automatizaci procesů. Např. potvrzení využití rezervované místnosti je provedeno automaticky při otevření místnosti kartou zaměstnance atd. Dohled nad rezervacemi zdrojů provádí určení odpovědní pracovníci (správce zasedaček, správce automobilů…). Ti jsou schopni provádět korekce v rezervacích. O všech změnách jsou uživatelé automaticky informování. Součástí systému je robustní reportovací modul, který poskytuje informace podle potřeby. Běžní zaměstnanci se mohou například podívat na své využívání zasedaček, správci mohou kontrolovat aktuální stav a management společnosti může strategicky plánovat efektivitu využívání zdrojů, včetně jejich rozšiřování.
1) Strategie naplnění vize řešení Po vizi následuje strategie, neboli postup, jakým toho dosáhneme. V našem případě je to prostřednictvím nasazení informačního systému. Kapitola strategie obsahuje klíčové parametry jeho nasazení a zprovoznění. Ideálně doplněno o vhodný obrázek architektury. Snažte se vyhnout UML diagramům a použijte vizuální podobu, kterou pochopí i „netechnický“ uživatel. Zde se dá hodně získat. Stejný obrázek je vhodné použít ve stejné nebo zkrácené podobě i v manažerském shrnutí. Proto musí být jasný a zřetelný. Na základě vytvořené vize bude navrhované řešení RESYZ založené na principech třívrstvé architektury s ohledem na principy SOA. Parciálním cílem projektu je v maximální možné míře využít technologickou základnu, kterou poskytují produkty společnosti Microsoft, které se QXT strategicky rozhodla používat. Zároveň je nevyhnutné implementované struktury komponovat do elementárně rozšiřitelného a flexibilního (univerzálního) celku, s ohledem na další rozvoj a využití systému. Na základě dohody mezi QXT a ITE byla stanovena priorita, fokus a rozsah oblastí, které budou řešeny a konsolidovány v horizontu nejbližších dvanácti měsíců:
Vytvoření jednotného univerzálního frameworku pro systémy na rezervaci zdrojů (RRF), který bude vytvořen na základech existujícího ITEFWK společnosti ITE. Využití již
existujícího řešení přináší velkou úsporu času, protože nebude nutné navrhnout a implementovat celý framework na zelené louce.
Vytvoření RESYZ nad tímto frameworkem.
Vytvoření systému pro rezervaci služebních firemních automobilů (RESYPA).
Nástroje pro vytváření reportů a monitoring využívání zdrojů.
Základní architekturu celého řešení zobrazuje následující obrázek. User approach
User
Browser
Okolní aplikace
Aplications
RESYZ
RESYPA
...
MS Sharepoint
MS Exchange server RRF
Moduly
Vizuální komponenty
Nevizuální komponenty
Uživatelská práva
Definice procesů a workflow
DB
Datový sklad
LDAP
Obrázek 1. Architektura systému společnosti QXT.
1) Klíčové benefity navrhovaného řešení pro business V této části popisujeme klíčové benefity našeho řešení z pohledu fungování zákazníka a běžných uživatelů. V krátkosti shrnujeme, jakým způsobem se technologické řešení projeví na fungování firmy a co to firmě přinese. Dá se konstatovat, že navazujeme na dřívější specifikaci požadavků business uživatelů. V podstatě potvrzujeme, že to co zákazník požadoval, to dostane + my mu to nabízíme v té nejlepší variantě. Využité principy SOA umožňují jednoduché propojení různých služeb (aplikací), využívajících rozličné platformy a technologie. Nad SOA může být jednoduše vytvořeno workflow (pracovní postup) na úrovni komponent (jednotlivých funkcí) využívaných v jednotlivých službách. Každý proces je pak od začátku až do konce jednoduše sledovatelný až na úroveň základních operací.
Nevyhnutným předpokladem implementace řešení je tedy identifikace business (funkčních) modulů a aplikací, poskytujících svoje služby okolním aplikacím jako je např. MS Sharepoint. Jednotlivé business moduly jsou transparentně definovány a musí operovat nad konkrétní částí firemních procesů. V současné době jsou identifikovány tyto funkční moduly:
Správa zasedaček.
Rezervace zasedaček.
Správa automobilů.
Rezervace firemních automobilů.
Reporting
Funkčnosti takto navržených business modulů jsou použitelné obecně napříč procesy QXT, co představuje jeden z nejdůležitějších benefitů použití SOA. Neméně významná je i možnost znovupoužití a elementární rozšiřitelnost při definici nových business modulů. Řešení založené na těchto technologických principech přinese QXT celou řadu klíčových benefitů:
Jednoduché uživatelské rozhraní pro zadávání rezervací.
Online přehled o obsazenosti a využití zasedaček.
Snížení nákladů na externí prostory.
Optimalizace procesů rezervací a použití zdrojů.
Rozšiřitelnost řešení pro další sdílené zdroje.
Zdokumentované řešení nezávislé na dodavateli.
Eliminace potenciálních problémů.
Garance reakčních časů pro opravy chyb na základě servisní smlouvy.
Možnost outsourcování provozu a rozvoje celého řešení.
2) Klíčové benefity navrhovaného řešení pro IT Podobně jako v předchozí kapitole shrnujeme klíčové přínosy navrženého řešení, v tomto případě z pohledu IT oddělení. Navazujeme na požadavky a technická omezení, které jsme specifikovali v jedné z kapitol zadání a požadavků. V podstatě opět potvrzujeme, tentokrát z jiné stránky, že to co zákazník požadoval, to dostane + my mu to nabízíme v té nejlepší variantě. Definice základní technologické platformy .NET, MS SQL server vede k eliminaci zastaralých (nevyhovujících platforem) a je základem dlouhodobé využitelnosti a podporovatelnosti. Vytvořením jednotného aplikačního frameworku RRF zajistíme jednotnou architekturu a unifikovaný způsob vývoje aplikací nad tímto frameworkem jak v době realizace systému, tak i v době podpory systému. Klíčovými benefity jsou:
Architektura – Etablování frameworku a architektury (SOA).
LDAP – kontrola přístupových a uživatelských práv.
Infrastruktura – Vybudování infrastruktury s potřebnou dostupností a výkonem.
Integrace – Využití jednotného rozhraní pro transparentní a standardizovaný způsob integrace.
Microsoft compliant – framework i aplikace musí být MS compliant. Platforma MS je strategická pro QXT .
QXT dále očekává v cílovém stavu:
Maximální možné využití stávajících IT prostředků/aplikací/služeb, kterými disponuje.
Vybudování architektury založené na moderních přístupech a flexibilních službách tak, aby bylo možné pružně reagovat na měnící se požadavky a zajistit významnou znovupoužitelnost (technologický framework) jak na technologické, tak zejména na úrovni firemních procesů (klíčová logika je implementována jako samostatné aplikace s jasně definovaným rozsahem a službami, které poskytuje okolí).
Identifikovat ve spolupráci s ostatními odděleními firmy oblasti, které jsou podporovány technologiemi, které v horizontu tří let nemají v IT strategii a architektuře QXT perspektivu a je nutné zvážit jejich náhradu, ideálně na frameworku RRF a tento framework připravit i pro tyto aplikace.
H. Rizika Kapitola rizik je na pomezí druhé a třetí části případové studie. V našem případě ji zahrnujeme již do třetí části, protože obsahuje část, která se týká konkrétních rizik projektu nasazení informačního systému. Vypisujeme zde klíčové rizika, které mohou projekt nasazení navrženého řešení ohrozit a díky tomu se projekt může prodražit nebo protáhnout. Těchto hrozeb si jako zákazník musíme být vědomi a dle vlastního zvážení je buď před projektem elimininovat, minimalizovat nebo v krajním případě projekt raději nerealizovat. Neřešením rizik by projekt nemusel dopadnout dobře a výrazným způsobem ovlivnit fungování zákazníka. V krajním případě vést ke krachu. U rizik vždy evidujeme stav, kdo je jeho vlastník (je odpovědný za jeho sledování), pravděpodobnost výskytu (udává, zda má smysl se jím zabývat), dopad (co se stane), mitigaci (jakým způsobem se jej snažíme předem i průběžně minimalizovat) a krizový plán, který udává konkrétní kroky, které budeme dělat v případě, že riziko nastane.
1) Rizika zadavatele První kategorií jsou rizika samotného zákazníka. Reflektují stav zákazníka a to jak z aktuálního pohledu, tak i budoucího. Neboli musíme zvážit riziko toho, že systém nemáme (aktuální stav) a máme (co nám hrozí při a po jeho nasazení).
a) RZ01 – Plýtvání zdrojů Stav Vlastník Pravděpodobnost výskytu Dopad Plán pro mitigaci rizika Krizový plán
Nastalo QXT 100% Zvýšené náklady (zasedačky jsou prázdné a jednání probíhají v pronajatých prostorách). Kontrola skutečně využívaných rezervací. Nasazení systému pro správu rezervací zasedaček a opatření proti těm, kteří své rezervace nevyužívají.
b) RZ02 – Nasazení systému po plánovaném termínu Stav Vlastník Pravděpodobnost výskytu Dopad
Plán pro mitigaci rizika
Potenciální QXT 20% Prodloužení aktuálního stavu plýtvání s dalším navýšením nákladů na IT řešení. Nutnost prodloužení smlouvy o pronájmu externích prostorů. Vytvoření úvodní studie pro podporu rozhodování renomovanou společností ITE. Rozdělení projektu do etap. Smluvní opatření (sankce) v realizační smlouvě.
Krizový plán
Uplatnění sankcí vůči dodavateli řešení.
c) RZ03 – Nedostupnost implementovaného systému po nasazení Stav Vlastník Pravděpodobnost výskytu Dopad
Plán pro mitigaci rizika
Krizový plán
Potenciální QXT 5% Nedostupnost informací o rezervacích zdrojů. Varianta 1: Přenesení rizika na dodavatele prostřednictvím smlouvy o provoze a servisu pro řešení nedostupnosti funkčností RESYZ. Definice odpovídající SLA. Varianta 2: Funkčnosti RESYZ jsou poskytovány jako služba (použití systému, který nebude ve vlastnictví QXT). Definice odpovídající SLA. Uplatnění sankcí vůči poskytovateli služeb.
2) Projektová rizika Druhým typem rizik, která popisujeme, jsou rizika projektu nasazení navrženého řešení. Týkají se toho, na co bychom si jak z pohledu zákazníka, tak i dodavatele, měli dát pozor. Například, když zpracovatel studie zjistí, že budou problémy v komunikaci se zaměstnanci, je třeba uvést riziko malé a špatné součinnosti zákazníka. Ta může vést k navýšení rozpočtu, prodloužení času nasazení nebo krachu celého projektu. Obdobně je vhodné být připravený na riziko problematického dodavatele řešení. Tím říkáme zákazníkovi, aby se sledování a řízení projektu věnoval s maximální pozorností.
a) RP01 – Nasazení systému po plánovaném termínu Stav Vlastník Pravděpodobnost výskytu Dopad
Plán pro mitigaci rizika
Krizový plán
Potenciální Dodavatel 20% Prodloužení status quo. Poškození dobrého jména dodavatele. Penále za nenasazení v termínu. Naplánování projektu do několika etap a iterativní přístup k projektu. Průběžné dodávky výstupů a jejich připomínkování a schvalování zákazníkem. Pravidelné reportování stavu projektu. Zvýšené úsilí projektového týmu. Svolání řídící komise.
b) RP02 – Nedostatečná kapacita a kvalita projektového týmu Stav
Potenciální
Vlastník Pravděpodobnost výskytu Dopad
Plán pro mitigaci rizika
Krizový plán
Dodavatel 5% Dopad na kvalitu, kvantitu a termín dodání výstupů projektu. Včasné sestavení stabilního projektového týmu, který plně pokryje potřebnou pracnost a kvalitu na projektu svou kapacitou. Průběžná kontrola. Nutné přesčasy sestaveného projektového týmu. Svolání řídící komise.
c) RP03 – Nedostatečná součinnost zákazníka Stav Vlastník Pravděpodobnost výskytu Dopad Plán pro mitigaci rizika Krizový plán
Potenciální Dodavatel 35% Dopad na kvalitu, kvantitu a termín dodání výstupů projektu. Včasná eskalace problému na řídící komisi. Průběžné reportování. Dohoda se zákazníkem o posunu termínu. Svolání řídící komise.
d) RP04 – Problémy s integrací systému Stav Vlastník Pravděpodobnost výskytu Dopad
Plán pro mitigaci rizika
Krizový plán
Potenciální Dodavatel 25% Omezená nebo minimální funkčnost systému. Neschopnost plánovat rezervace. Finanční ztráty Vysoký důraz na technický projekt. Naplánování integračních testů v dostatečném předstihu před nasazením. Úzká spolupráce s IT oddělením. Průběžná kontrola. Dohoda se zákazníkem o posunu termínu. Svolání řídící komise.
I. Roadmapa projektu Detailní popis postupu realizace řešení je jádrem třetí části případové studie. Obsahuje detailní rozpis „trojimperativu“ projektu. Začíná se krátkým shrnutím postupu projektu (obdoba manažerského shrnutí) a následně jsou popsány detaily jednotlivých etap. Každý část obsahuje sumarizaci, která je promítnuta do manažerského shrnutí. Tato kapitola popisuje v jakých krocích a jakým způsobem bude dosaženo cílového stavu. Dále obsahuje organizační strukturu a vyžadovanou součinnost, harmonogram a milníky. Na závěr jsou uvedeny oblasti následného rozvoje za horizontem roku 2011. Předchozí kapitoly definovaly cílový stav projektu, kterého bude dosaženo v horizontu konce roku 2011. Vzhledem na požadovaný rozsah řešení a nutnost co nejrychlejšího přínosu používání aplikace RESYZ je vhodné rozdělit projekt do tří realizačních etap (každá etapa je plánována na cca 6 měsíců):
Etapa 1: návrh a implementace RRF (základní funkčnosti pro integraci s okolím, klíčové reportovací a monitorovací nástroje) a RESYZ 1.0. Definice procesů a metodiky pro kontinuální rozvoj RRF a aplikací nad RRF.
Etapa 2: rozšíření RRF o další funkčnosti (napojení na MS Sharepoint) a nástroje, RESYZ 1.5, RESYPA 1.0.
Etapa 3: RESYZ 2.0, RESYPA 1.5.
Na následujícím obrázku je vidět rámcová roadmapa etap 1 – 3. Plán jednotlivých etap je upřesněný v následujících kapitolách.
V průběhu všech etap bude probíhat technologický rozvoj architektury a aplikačního frameworku.
1) Projektový tým V úvodu je uvedena charakteristika a složení týmu, který je nutné pro úspěšnou realizaci řešení sestavit. Není třeba psát konkrétní jména, ale jen role, které se budou projektu účastnit jak ze strany zákazníka, tak dodavatele. Je třeba zdůraznit také roli vedení firmy v podobě řídící komise a projektového vedoucího. Tam, kde je to vhodné, krátce popíšeme konkrétní náplň práce. Především u rolí zákazníka. Tyto role jsou pak součástí finančních kalkulací, uvedených v kapitolách s detailních popisem jednotlivých etap. Pro implementaci řešení tohoto významu a potenciálu je z pohledu QXT nutné vytvořit potřebné předpoklady pro realizaci projektu po stránce organizační. Vedle dodávky komponent
frameworku, funkčních komponent a metodiky pro práci s nimi je nutné vytvořit i organizační struktury, které budou budování tohoto systému řídit. Tyto struktury budou zajišťovat využití dodaných komponent v i dalších oblastech.
Řídící komise – nejvyšší projektová řídící struktura projektu. Schvaluje a koordinuje klíčové plánované dodávky a milníky. Je nadřízená Architektonické komisi a Projektovému řízení. Členy jsou nominováni z vrcholového managementu QXT a ITE. Jedná se o dozorný orgán nad projektem.
Komise pro architekturu systému – udržuje a rozvíjí celkovou vizi rozvoje RRF a souvisejících aplikací. Zajišťuje, aby všechny rozvojové aktivity byly v souladu s touto vizí. Členy jsou nominováni:
o
Hlavní softwarový architekt (QXT).
o
Business architekt (QXT).
o
Business analytik (ITE).
o
Software architekt (ITE).
Projektový tým QXT – zajišťuje a poskytuje součinnosti za business i IT QXT. Je odpovědný za kontrolu termínů a výstupů ITE (i průběžných). Projektový manažer je odpovědný za kontrolu kvality a případnou eskalaci nedodržování termínů a kvality na řídící komisi. o
Projektový manažer.
o
QA manažer (klíčový uživatel systému / metodik).
Projektový tým za ITE – je odpovědný za dodání výstupů ve stanovených termínech, kvalitě, kvantitě a dohodnutém rozpočtu. Projektový manažer je odpovědný za řešení rizik, a jejich případnou eskalaci na Řídící komisi. o
Projektový manažer.
o
Business analytik.
o
Software architekt.
o
Konfigurační manažer.
o
Test manažer / test architekt.
o
Vývojář.
o
Tester.
2) Součinnosti Žádný projekt neprobíhá izolovaně. Proto je v úvodu zmíněna také nezbytná součinnost, kterou musí zákazník realizátorovi řešení poskytnout. A to nejen v podobě lidských zdrojů, ale třeba také součinností a spoluprací s jinými projekty, které mohou probíhat současně a mít vliv na realizaci.
Popřípadě nutnou infrastrukturní podporu pro případ požadavku na propojení s jinými systémy. Špatná součinnost je velmi často důvodem (nepřímým) neúsěšné realizace projektů. Potřebnou součinnost lze rozdělit na 3 typy: Zdroje, Projekty a Infrastruktura.
a) Zdroje
Projektový manažer - stanovení kompetentního zástupce a jeho vybavení příslušnými pravomocemi. Ideálně osoba ze středního managementu. V průběhu projektu budou definovány detailní požadavky na součinnost dovnitř QXT (dodání specifických testovacích dat, vyplnění číselníků apod.). Pro jejich zprostředkování a hlavně následnou konsolidaci před předáním ITE je nutné zajistit dostatečnou kapacitu dedikovaných pracovníků QXT.
Business a software architekti - zajistit dostatečnou kapacitu odpovědných architektů ze strany QXT. Ti pak budou během projektu průběžně podle předem definovaného plánu revidovat a akceptovat výstupy projektu a účastnit se plánovaných workshopů a schůzek. Do role architektů je nutné vybrat zkušenější (klíčové) uživatele a vybrané zástupce managementu, kteří budou mít dostatečnou kvalifikaci a časovou kapacitu pro návrh systému v Technickém projektu.
Testeři – pro přípravu a provedení UAT je potřeba dedikovat dostatečně velký tým testerů, kteří budou schopni ve spolupráci s testovacím týmem ITE a v rámci předem definovaného plánu, kvalitně připravit a otestovat výstupy projektu. Testeři by měli být vybráni jak z oblasti klíčových uživatelů, tak i běžných, aby byly testy komplexní a věrohodné.
Členové řídícího výboru – nominovat do řídící ho výboru členy vrcholového managementu, kteří budou moci věnovat projektu dostatečnou pozornost. Během projektu budou pravidelně informováni o stavu, budou provádět klíčová rozhodnutí a provádět finální akceptace.
b) Projekty a okolní systémy
Projekty – v QXT probíhá paralelní projekt implementace MS technologií, který má přímý dopad na projekty RRF / RESYZ. V rámci Technického Projektu budou detailně popsány kroky na obou stranách, které povedou k vyřešení všech konfliktů. Bude potřeba zajistit v definovaném čase provedení těch kroků, které budou mimo rámec projektu RRF / RESYZ.
Okolní systémy – u předem definovaných systémů QXT jde zejména o včasné dodání potřebné dokumentace, zajištění případných schválených úprav v těchto systémech v definovaném termínu a vyhrazení jejich dostupnosti pro vývoj, trénink a testování integrace projektu RRF / RESYZ s těmito systémy.
c) Infrastruktura
Připravenost všech prostředí (vývojové, testovací, tréninkové, deployment a provozní) v potřebné struktuře a požadované kapacitě tak, jak budou popsány v Technickém projektu v kapitolách Infrastruktura a Nefunkční požadavky.
Potřebné nástroje pro podporu celého životního cyklu projektu zajistí ITE.
3) Etapa 1 – RRF 1.0 a RESYZ 1.0 Nyní následuje detailní popis jednotlivých etap realizace. Co se dělá, kdo a kdy to dělá a v neposlední řadě v jakém rozsahu.
a) Rozsah a zaměření etapy Nejprve krátce popíšeme funkce, činnosti, výstupy, které budou v rámci dané etapy realizovány. V této etapě budou vyřešeny klíčové technické rizika RRF, které mají dopad na implementaci aplikací nad RRF. Jako „proof-of-concept“ bude implementována první verze aplikace RESYZ:
RFF o
Vyhodnocování uživatelských práv (komunikace s LDAP).
o
Podpora workflow.
o
Definice klíčových procesů.
o
Vizuální komponenty pro RESYZ.
o
Nevizuální komponenty pro RESYZ.
o
Moduly
Správa zdrojů (Evidence a správa zasedaček). Kalendář. Reporty pro management o využívání zdrojů, změnách a rušení rezervací.
RESYZ o
Elektronická rezervace zasedaček.
o
Práva pro rezervaci jednotlivých zasedaček.
o
Možnost zadat opakované rezervace.
o
Online rozhraní pro zadávání a monitorování stavu rezervací.
b) Součinnosti Následují požadavky na konkrétní součinnost zákazníka. U požadavků na lidské zdroje je nutné uvést alespoň odhad hodin a jejich předběžné rozložení v průběhu etapy, aby si je mohl zákazník naplánovat a vyčíslit, kolik jej to bude stát. Na konci následuje suma požadovaných hodin, která se přenáší do manažerského shrnutí. V rámci této etapy bude nutné ze strany zákazníka QXT zajistit intenzivní součinnost následujících typů uživatelů:
Pracovníci odpovědní za plánování zasedaček a znalosti firemních procesů spojených s jejich rezervací. Především pro účely návrhu koordinaci řešení (klíčoví uživatelé). o
Během tvorby technického projektu.
o
Kapacita cca. 60 člověkohodin.
Zástupci managementu pro účely vydefinování a následně otestování požadovaných manažerských výstupů. o
Během tvorby technického projektu.
o
Kapacita cca. 30 člověkohodin.
Uživatelé budoucího systému pro testování a zaškolení systému. o
Během testů systému.
o
Kapacita cca. 120 člověkohodin.
Uživatelé budoucího systému pro prvotní konfiguraci a nastavení systému. o
Během nasazení systému.
o
Kapacita cca. 90 člověkohodin.
Projektový vedoucí (koordinátor) ze strany QXT. o
Během celé fáze.
o
Kapacita cca. 50 člověkohodin.
Členové řídícího výboru ze strany QXT. o
1x za měsíc.
o
Kapacita cca. 15 člověkohodin.
Očekávaná celková minimální součinnost ze strany Q&X: 365 člh.
c) Harmonogram Harmonogram je vhodné uvést v podobě Ganttova diagramu. Volte kompromis mezi čitelností a mírou detailu. Je vhodnější velký detail vložit do dokumentu jako přílohu a zde jen uvést shrnující informace, ze kterých půjde vyčíst kdy se co bude realizovat a jak na sebe jednotlivé části navazují.
d) Odhad nákladů na realizaci etapy V poslední části popisu dané etapy jsou vyčísleny odhadované náklady na nasazení řešení z pohledu dodavatele. Začíná se uvedením sazby, která se obvykle pro realizaci používá. Dodavatel může klidně uvést své sazby a pro zákazníka tato sazba může být vodítkem pro výběrové řízení. Následně jsou v tabulce sečteny všechny náklady dodavatele. Pokud se pořizuje technické vybavení, uvádí se do samostatné tabulky, popřípadě můžeme rozpis uvést v samostatné kapitole. V tomto případě je nutné ale v této části uvést alespoň sumu nákladů na pořízení. Na konci je uvedena celková suma za etapu, která se přenáší do manažerského shrnutí. V úvodu kapitoly je vhodné také uvést toleranci, s jakou byl odhad sestaven. Odhad nákladů na realizaci je počítán při průměrné sazbě 1 000Kč / člh bez DPH. Realizace se může odchylovat od tohoto odhadu o +/- 20%. Do ceny není zahrnut cena za pořízení dalšího HW a SW, které bude nutné pro zprovoznění systému pořídit. Společnost QXT si je na základě stanovení parametrů dodavatele pořídí u svých dodavatelů. Nasazení je vyčísleno v kapitole „Finance“ Systém / část Funkčnosti RFF Vyhodnocování uživatelských práv (komunikace s LDAP) Podpora workflow (existuje v rámci ITEFWK) Definice klíčových procesů Vizuální komponenty pro RESYZ Nevizuální komponenty pro RESYZ Správa zdrojů (Evidence a správa zasedaček) Kalendář Reporty pro management o využívání zdrojů, změnách a rušení rezervací RESYZ Elektronická rezervace zasedaček Práva pro rezervaci jednotlivých zasedaček Možnost zadat opakované rezervace Online rozhraní pro zadávání a monitorování stavu rezervací
Celková cena za Etapu 1
člh 970 100 0 100 250 250 100 20 150 500 250 100 100 50
1 470
Cena v Kč bez DPH 970 000
500 000
1 470 000
4) Etapa 2 – RRF 1.5, RESYZ 1.5, RESYPA 1.0 Obdoba předchozí kapitoly.
a) Rozsah a zaměření etapy V této etapě bude řešena zejména integrace s MS Exchange a MS Sharepoint. Dále budou řešeny podpůrné a „nice-to-have“ funkčnosti a změnové požadavky na RRF a RESYZ. Zároveň bude implementována nová aplikace RESYPA. V současné době lze identifikovat jenom požadavky na funkčnosti RESYZ, které nebylo možné zařadit do Etapy 1 a požadavky na aplikaci RESYPA. Ostatní požadavky budou identifikovány v průběhu první fáze Etapy 2.
RRF o
Integrace s MS Exchange.
o
Integrace s MS Sharepoint.
o
Vytvoření rozhraní pro datový sklad.
o
Integrace se sytémem pro fyzické přístupy do místností na kartu.
o
Automatické předání informací o změně stavu rezervace prostřednictvím informačního mailu.
o
Podpora workflow pro naplánování údržby a obnovy zdrojů (např. servisní prohlídky u automobilů, vymalování zasedaček, výměna koberců apod.).
RESYZ 1.5 o Podpora suplementárních služeb k rezervacím (občerstvení, projektor…). o
Elektronický přístup do zasedaček na vstupní kartu (kdokoli z účastníků jednání).
o
V případě, že rezervace není využita do 10min od začátku platnosti je zasedačka uvolněna pro kohokoli.
RESYPA 1.0 o Elektronická rezervace firemních automobilů. o
Práva pro rezervaci jednotlivých automobilů.
o
Možnost zadat opakované rezervace.
o
Online rozhraní pro zadávání a monitorování stavu rezervací.
b) Součinnosti V rámci této etapy bude nutné ze strany zákazníka Q&X zajistit intenzivní součinnost následujících typů uživatelů:
Pracovníci odpovědní za technickou infrastrukturu pro účely integrace s existujícími firemními nástroji (produkty Microsoft, karetní systém…). o
Během celého projektu.
o
Kapacita cca. 50 člověkohodin.
Pracovníci odpovědní za rezervace a půjčování firemních automobilů se znalostí firemních procesů spojených s jejich rezervací. Především pro účely návrhu koordinaci řešení (klíčoví uživatelé). o
Během tvorby technického projektu.
o
Kapacita cca. 60 člověkohodin.
Uživatelé budoucího systému pro testování a zaškolení systému. o
Během testů systému.
o
Kapacita cca. 120 člověkohodin.
Uživatelé budoucího systému pro konfiguraci a nastavení nových funkčností systému. o
Během nasazení systému.
o
Kapacita cca. 70 člověkohodin.
Projektový vedoucí (koordinátor) ze strany QXT. o
Během celé fáze.
o
Kapacita cca. 40 člověkohodin.
Členové řídícího výboru ze strany QXT. o
1x za měsíc.
o
Kapacita cca. 15 člověkohodin.
Očekávaná celková minimální součinnost ze strany Q&X: 355 člh.
c) Harmonogram
d) Odhad nákladů na realizaci etapy Odhad nákladů na realizaci je počítán při průměrné sazbě 1 000Kč / člh bez DPH. Realizace se může odchylovat od tohoto odhadu o +/- 20%. Do ceny není zahrnut cena za pořízení dalšího HW a SW, které bude nutné pro zprovoznění systému pořídit. Společnost QXT si je na základě
stanovení parametrů dodavatele pořídí u svých dodavatelů. Nasazení je vyčísleno v kapitole „Finance“ Systém / část RRF 1.5 Integrace s MS Outlook Integrace s MS Sharepoint Vytvoření rozhraní pro datový sklad Integrace se sytémem pro fyzické přístupy do místností na kartu Automatické mailové notifikace Podpora workflow pro naplánování údržby a obnovy zdrojů RESYZ 1.5 Podpora suplementárních služeb k rezervacím Elektronický přístup do zasedaček na vstupní kartu (účastníci jednání) Automatické uvolňování zasedaček v případě jejich nevyužití RESYPA 1.0 Elektronická rezervace automobilů Práva pro rezervaci jednotlivých automobilů Možnost zadat opakované rezervace Online rozhraní pro zadávání a monitorování stavu rezervací
Celková cena za Etapu 2
člh 1430 300 300 300 300 80 150 470 80 240 150 300 120 80 80 20 2 200
Cena v Kč bez DPH 1 430 000
470 000
300 000
2 200 000
5) Vize dalšího rozvoje – Etapa 3 (RRF 2.0, RESYZ 2.0, RESYPA 1.5) V každém projektu je vhodné uvést a popsat, co se bude dít po jeho dokončení, respektivě co dalšího je vhodné udělat. V našem případě a v případě nasazení jakéhokoliv technického řešení se obvykle jedná o dlouhodobou podporu. Není na škodu, když se uvede také zpětné vyhodnocení provozu sytému s odstupem například půl roku a návrh dalšího rozvoje. Vždy je třeba ale zákazníkovi zdůraznit, že dokončením nasazení by spolupráce neměla končit a zkušenost dodavatele ukazuje, že podpora má smysl. V současné době je předčasné diskutovat obsah a zaměření třetí etapy projektu. Je velmi pravděpodobné, že v této etapě budou řešeny zejména podpůrné a rozšiřující funkčnosti, spolu se změnovými požadavky na RRF, RESYZ a RESYPA. Ty budou vycházet z provozu systému a jeho využívání uživateli. Jednou z nových funkčností, která byla již identifikována a zatím odložena, je podpora mobilních zařízení. Zároveň budou identifikovány aplikace z existujícího aplikačního portfolia QXT, které jsou vhodnými kandidáty na převedení svých funkčností nad RRF a podporu firemních procesů QXT, které zatím nejsou podporovány žádným systémem / aplikací. Předpokládá se, že třetí etapa bude zahájena po pilotu druhé etapy (trvání cca. 1 – 2 měsíce) a ukončena před koncem roku 2011. Další rozvoj systému po roce 2011 bude řešen v rámci samostatné servisní smlouvy s dodavatelem. Parametry smlouvy budou nastaveny před jejím podepsáním. Pro aktuální stav, známý na konci případové studie, je vyžadována podpora v rozsahu minimálně 4 člh/týden.
J. Finance V reálných projektech je klíčovou informací informace o návratnosti investice do nasazení řešení. Obvykle je to kapitola, která srovnává náklady a navržené přínosy řešení. Dobré a kvalitní zpracování této kapitoly může rozhodnout o tom, zda se do řešení vyplatí nebo nevyplatí jít. Finální výstup se přenáší do manažerského shrnutí. Obvyklé způsoby vyčíslení jsou ROI a NPV. Jakýkoliv další způsob vyčíslení může být plusem pro zpracovatele případové studie a reklamou pro případ, že chce být i realizátorem. Předpokládáme, že díky RESYZ bude možné vést všechna jednání a prezentace v interních prostorách a společnost QXT tak ušetří roční náklady na externí prostory 2,8 mil. Kč. Také dojde k úspoře využívání firemních automobilů. V současnosti si QXT pronajímá 30 firemních aut (náklady činí 200 tis. Kč ročně na jeden vůz). Očekáváme, že při využití systému RESYPA bude možné auta využít efektivněji a společnost QXT tak bude moct snížit vozový park na 15 aut. Při větším vytížení stoupnou roční náklady na 1 vůz na 230 tis. Kč. V nákladech vycházíme z předchozích výpočtů:
Cena Etapy 1: 1 470 000 Kč
Cena Etapy 2: 2 200 000 Kč
Cena Etapy 3: předběžný odhad 3 mil. Kč
K těmto nákladům je nutno přičíst:
Cenu za zavedení (nastavení, migraci) IS: (80 tis. Kč)
Zaškolení zaměstnanců: 100 člh (20 skupin x 5 hod.), tj. 100 tis. Kč
Support 4 člh/ týdně, tj. 200 tis. Kč / ročně
Náklady a úspory znázorňuje tabulka níže. Minimální předpokládaná životnost činí 5 let, dá se očekávat celková životnost systému až 10 let. Uvažujeme diskont 6%. Do nákladů není započítána cena za součinnost zaměstnanců QXT. Rok Etapa 1 Etapa 2 Etapa 3 Nastavení Školení Podpora Úspory CF DCF Úspory celkem Náklady celkem NPV ROI*
0 -1 470 -2 200
1
2
3
4
5
-200 5 350 5 150 4 583
-200 5 350 5 150 4 324
-200 5 350 5 150 4 079
-200 5 350 5 150 3 848
-3 000 -80 -100
-3 850 -3 850
-200 5 350 2 150 2 028
26 750 000 Kč 7 850 000 Kč 15 013 000 Kč 2,4
*ROI = (26 750 000 - 7 850 000) / 7 850 000
Vysoká hodnota čisté současné hodnoty a ROI ukazují finanční výhodnost investice. Avšak do investice není zahrnuta cena HW a ostatního SW (MS Server, Sharepoint, …), která by celkovou výhodnost snížila. Vypočítané hodnoty jsou pouze orientační. Celková výnosnost se může pohybovat do 15% od vypočítaných hodnot. I přes odchylku je zaručena výhodnost investice. Pokud se do systému povede zaintegrovat i další funkčnosti, budou přínosy ještě vyšší.
K. Závěr Na konci každého dokumentu následuje závěr. Ten hodnotí obsah dokumentu a snaží se zdůraznit vše klíčové. Měl by také být zhodnocením spolupráce a reklamou pro další pokračování. Ať již v tomto nebo dalších projektech. Musí z něj plynout, že jsme se jako dodavatelé snažili udělat pro zákazníka maximum a umíme toho udělat i víc. Tento dokument úvodní studie vznikl na základě potřeby efektivnější práce s interními zasedačkami ve společnosti QXT. Obsahuje analýzu aktuálního stavu situace ve společnosti a návrh nového řešení, které splňuje všechny požadavky na něj kladené. A to včetně dodržení klíčového termínu nasazení (konec roku 2011) a vypočtení předpokládané návratnosti investice. Při tvorbě dokumentu byly zvažovány různé varianty řešení tak, aby byly v souladu s firemní strategií a vizí. V průběhu tvorby úvodní studie byly identifikovány další business oblasti, které je možné nasazením obecnějšího řešení nad rámec původních požadavků Q&X také zefektivnit. Po dohodě s Q&X bylo proto původní zadání modifikováno tak, aby tuto skutečnost reflektovalo. Toto obecné řešení přinese společnosti QXT finanční úspory a vysokou přidanou hodnotu nejen z hlediska práce se zdroji, ale zároveň i z hlediska vytvoření moderní platformy pro rozvoj dalších aplikací. Cílem práce, mimo požadavky zákazníka, bylo také ukázat schopnosti a možnosti společnosti IT Enterprises jako zkušeného komplexního integrátora IT řešení. Věříme, že kvalita odvedená práce a tohoto dokumentu jsou začátkem dlouhodobé spolupráce mezi společnostmi IT Enterprises a Q&X. Pro účely předmětu musí být závěr doplněn i hodnocením předmětu, přístupu vyučujících a podnětů, které mohou vést ke zlepšení nebo změně průběhu cvičení nebo i přednášek. Hodnocení lze provést za celý tým jednotně nebo po jednotlivých členech týmu. Toto hodnocení je povinné, ale nemá žádný vliv na závěrečné hodnocení práce studentů v semestru a jejich výslednou známku. Za každou objektivní zpětnou vazbu děkujeme a rádi ji se studenty prodiskutujeme. Nebojte se i kritických komentářů, jako tomu bylo u kolegů z předchozích let.
