RDB a.s. Projekt VIVA

PŘÍLOHA Č. 1 RDB a.s. Projekt VIVA Autor: Datum: Verze: Schváleno dne: Jméno: Podpis:

1. ÚVOD... 3 2. PROJEKTOVÝ PLÁN... 3 2.1. CÍLE PROJEKTU... 3 2.2. FÁZE PROJEKTU... 3 2.3. ROZSAH PROJEKTU... 5 2.4. PŘEDPOKLADY... 5 2.5. KONCEPT ARCHITEKTURY... 6 2.6. OVLIVNĚNÉ SYSTÉMY (APLIKACE)... 6 2.7. VÝSTUPNÍ PRODUKTY PROJEKTU... 6 2.8. OMEZENÍ PROJEKTU... 7 3. ORGANIZACE PROJEKTU... 8 4. ČASOVÝ HARMONOGRAM PROJEKTU... 9 5. ODHAD PROJEKTOVÝCH NÁKLADŮ A PŘÍNOSŮ PROJEKTU... 10 5.1. ANALÝZA PROJEKTOVÝCH NÁKLADŮ... 10 5.2. ANALÝZA NÁKLADŮ/PŘÍNOSŮ... 10 6. ANALÝZA RIZIK... 11 6.1. RIZIKA PROJEKTU... 11 6.2. RIZIKA PRODUKTU... 11 7. ŘÍDÍCÍ PROCEDURY... 13 8. PŘÍLOHY... 14 Dokument projektu VIVA 2 (celkem 14)

1. ÚVOD Tento dokument sumarizuje výsledky úvodní zahajovací etapy projektu, které obsahují zejména: projektový plán a harmonogram rozsah projektu organizační struktura projektu analýzu nákladů a přínosů projektu vč. rozpočtu projektu 2. PROJEKTOVÝ PLÁN 2.1. Cíle projektu Cílem projektu je vytvoření systému pro provoz dárkových karet a věrnostních systémů. Navrhované řešení musí být univerzální a použitelné pro klienty se standalone terminály, tak pro klienty, kteří používají POS terminály integrované s pokladnou. Stejně tak by řešení dárkových karet mělo být uplatnitelné i v jiných zemích. Charakteristika Viva Cards Dárkové karty Viva Cards je specifická skupina nebankovních platebních karet s předplaceným limitem, který se dá vyčerpat u příslušného obchodníka, pro kterého jsou tyto karty vydány. Předplacený limit se může používat postupně. Limit a design Viva Cards se může lišit, za jakým účelem jsou dárkové karty nabízeny (např. narozeninové, výroční, vánoční, a jiné příležitosti. Na těchto kartách zpravidla nejsou uvedeny identifikační údaje držitele karty (použití je anonymní) a není použit PIN. Viva Card slouží primárně jako dárek a alternativa k dárkovým poukázkám. Z obchodního hlediska RDB pouze eviduje pohyby a zůstatky na karetních účtech. Finanční vypořádání s držiteli karet provádí klient RDB. RDB bude pouze fakturovat za prodej karet a provedené transakce. Typy karet: - Fixní - nebudou dobíjitelné, jsou označeny příslušnou nominální hodnotou - Variabilní - dobíjitelné, bez označení Kategorizace karet: a) Dárkové zákaznické (určené pro retail a aktivací na pokladně) b) Dárkové firemní (určené pro firmy s hromadnou aktivací) c) Věrnostní - karty slouží ke sbírání "bodů" a odměna pro věrné zákazníky. 2.2. Fáze projektu 1. Fáze: Implementace řešení dárkových karet pro Viveco 6400 integrované s pokladnou. Navrhované řešení předpokládá vytvoření Viva serveru, který bude zajišťovat zejména: autorizaci transakcí vedení zůstatků na karetních účtech evidenci karet vytvářeni souboru pro personalizaci podklady pro reporting a fakturaci Dokument projektu VIVA 3 (celkem 14)

Součástí celého řešení bude i POS aplikace pro Viveco 6400(ve variantě integrované s pokladnou) umožňující dobíjení a aktivaci karet na POS terminálu. Řešení umožní dobíjení a aktivaci předplacených karet na POS terminálu a hromadnou aktivaci karet na serveru. V této fázi jsou řešeny pouze fixní nedobijitelné dárkové karty a variabilní dárkové karty dobijitelné na POS terminálu. Detailní rozsah projektu je dán seznamem řešených požadavků (viz příloha). 2. Fáze: Implementace řešení dárkových karet pro Viveco 6400 bez integrace s pokladnou. Tato fáze představuje úpravu aplikace POS pro Viveco 6400, která není integrovaná s pokladnou. Podporované funkcionality budou stejné jako u fáze 1. 3. Fáze: Rozšíření funkcionalit serveru a POS aplikace. Úprava aplikace POS pro další terminály. Fáze 3 bude upřesněna po dokončení fáze 1. Seznam požadavků je uveden v příloze 1 - Požadavky Dokument projektu VIVA 4 (celkem 14)

2.3. Rozsah projektu 2.4. Předpoklady 1. V první a druhé fázi budou použity pouze POS terminály Ingenico 5100. 2. Bude použit hardware z projektu POTOP. 3. Lze provést remote download aplikace na POS, t.j. není třeba plánovat manuální instalace a výjezdy techniků. 4. V první fázi: POST propojen s ECR, start z POST, maximální počet GC v balíčku 10.+ 5. Zúčtování nominálních hodnot si provádí klient sám (RDB neúčtuje o nominálních hodnotách). 6. RDB nebo klient má právo měnit aplikaci terminálu. Dokument projektu VIVA 5 (celkem 14)

7. Vyhodnocení podmínek pro přidělení bonusu a určení částky bonusu je řešeno logikou v ECR. 8. Personalizace umožňuje "balíčkování" karet a jejich označení 9. V RDB se nebude provádět skladování karet, karty jsou distribuovány rovnou příjemci 2.5. Koncept architektury 2.6. Ovlivněné systémy (aplikace) Systém/aplikace POS Front Controller Viva Cards Server 2.7. Výstupní produkty projektu 1. Aplikace dárkových karet Aplikace pro řešení karet (Viva server) Aplikace front controller Aplikace POS pro dárkové karty Dopad Vývoj aplikace Viva Cards Vývoj aplikace front controller Vývoj aplikace pro evidenci karet a autorizaci transakcí Vývoj aplikace pro správu transakcí (webové rozhraní) Vývoj aplikace pro správu objednávek (webové rozhraní) Mechanismus uploadu emboss souboru na AS/400. Dokument projektu VIVA 6 (celkem 14)

2. Dokumentace: Detailní funkční analýza FO a BO Detailní funkční analýza POS Deployment manuál Obecný popis architektury Popis nasazení aplikace Testovací scénáře Sada testovacích dat Projektová dokumentace (Základní dokument projektu, Projektový plán, Seznam požadavků) Uživatelský manuál pro Viva server Provozní model a popis rolí/odpovědností 3. Projekt dále zajistí: Instalaci systémového a aplikačního SW (POTOP aplikace) Školení Konfiguraci sítě, serverů, aktivních prvků Provedení funkčních, integračních, zátěžových, bezpečnostních (volitelně dle bezpečnostních požadavků) a akceptačních testů Přípravu a spuštění všech produkčních procesů 2.8. Omezení projektu Dokument projektu VIVA 7 (celkem 14)

3. ORGANIZACE PROJEKTU Členové projektového týmu ROLE POPIS OBSAZENÍ Sponzor Garant projektu, představuje nejvyšší eskalační stupeň Petr Novák projektu v hierarchii projektu. Projektový manažer Zodpovídá za řízení projektu (termíny, dokumentace, svolává a vede status meetingy) a za dodávku výstupů projektu v požadované kvalitě a v požadovaném termínu (zodpovídá za validaci dokumentů, vede projektový web). Tomáš Dospěl Zodpovědné osoby za oblast: Vývoj IT Bezpečnost Obchodní požadavky Provozní požadavky Supervizor pro analýzu, vývoj a testování. Zodpovědný za organizaci vývoje a testování. Koordinuje činnosti v oblasti IT, je odpovědný za předávání informací v rámci svého úseku, aktivně upozorňuje na možná úskalí projektu z hlediska svého úseku, zodpovědnost za dokumentaci IT infrastruktury. Formuluje požadavky na systém z hlediska bezpečnosti, vyhodnocuje dokumenty z hlediska bezpečnosti, aktivně upozorňuje na možná úskalí projektu z hlediska svého úseku. Zodpovídá za úplnost a správnou interpretaci požadavků z hlediska obchodu, konzultační role. Zodpovídá za úplnost a správnou interpretaci požadavků z hlediska provozu, konzultační role. Pavel Svoboda Petr Antoš Jaroslav Holý Karolína Urbanová K. Pašek (provoz aplikace), J. Pelán (fakturace), R. Jarolímek (personalizace), S. Procházka (produkty) POS vývoj Zodpovídá za proveditelnost projektu z hlediska POS. J. Smutný Vývoj Zodpovídá za proveditelnost projektu z hlediska POS. J. Zelenka serveru Analýza Zajišťuje vypracování analýzy a zohlednění Robert Šrámek požadavků. Testování a Zodpovídá za testování. D. Musílek akceptace Obchod Zodpovídá za zajištění obchodních nabídek a zajištění Karolína Urbanová smluvních vztahů Marketing PR a marketingová podpora produktu J. Holtan Provoz Zodpovědný za nastavení a popis provozních procesů Jaroslav Holý Dokument projektu VIVA 8 (celkem 14)

4. ČASOVÝ HARMONOGRAM PROJEKTU ID Název Práce Doba trvání Zahájení Dokončení květen 2007 1. květen 1 Gift Cards release 1.0 0 hodin 71 dny? 1.6. 07 7.9. 07 2 Dokumentace rozhraní FO GC - POS terminál 0 hodin 1 den? 7.6. 07 7.6. 07 3 Dokumentace rozhraní POS - ECR a předání do Globus 0 hodin 1 den? 8.6. 07 8.6. 07 4 Zapracování připomínek ze strany Globus 0 hodin 5 dny 11.6. 07 15.6. 07 5 Zafixování rozsahu projektu - odsouhlasení interně v GPE 0 hodin 1 den? 14.6. 07 14.6. 07 6? Front Office 0 hodin 45 dny? 5.6. 07 6.8. 07 22? BO 0 hodin 12 dny? 13.7. 07 30.7. 07 27 Ukončení testování POS s ECR Globus - integrační testy, akceptace 0 hodin pokladny 1 den? 20.8. 07 20.8. 07 28 Ukončení akceptačního testování celého systému - ECR+POS+POTOP 0 hodinfo a BO 1 den? 27.8. 07 27.8. 07 29 Produkční prostředí 0 hodin 11 dny? 17.8. 07 31.8. 07 30 Nasazení aplikace do produkčního provozu 0 hodin 1 den? 17.8. 07 17.8. 07 31 Spuštění monitoringu aplikace 0 hodin 1 den? 20.8. 07 20.8. 07 32 Dokončená instalace POS v Globusu 0 hodin 1 den? 24.8. 07 24.8. 07 33 Start pilotu v Globusu 0 hodin 1 den? 31.8. 07 31.8. 07 34 Obchod 0 hodin 51 dny? 29.6. 07 7.9. 07 35 Obchodní nabídka 0 hodin 21,5 dny? 26.7. 07 24.8. 07 36 Smlouva 0 hodin 28 dny? 1.8. 07 7.9. 07 37 Marketingový plán 0 hodin 1 den? 29.6. 07 29.6. 07 38 Nastavení provozu 0 hodin 25,5 dny? 1.6. 07 6.7. 07 39 Provozní model 0 hodin 21 dny? 1.6. 07 29.6. 07 40 Výběr dodavatele karet 0 hodin 23,5 dny? 5.6. 07 6.7. 07 41 Smlouvy s dodavatelem 0 hodin 1 den? 5.6. 07 5.6. 07 42 Dopady do dalších projektů 0 hodin 1 den? 5.6. 07 5.6. 07 43 Změna POTOP modelu? 0 hodin 1 den? 5.6. 07 5.6. 07 Dokument projektu VIVA 9 (celkem 14)

5. ODHAD PROJEKTOVÝCH NÁKLADŮ A PŘÍNOSŮ PROJEKTU 5.1. Analýza projektových nákladů Celkový odhad projektových nákladů Částka (tisíce Náklady Kč)/MD Předpoklady Lidské zdroje 27 Čl./Měs. 7 ČM vývoj POS, 20ČM vývoj serveru (počítáno pouze pro 1.fázi) Nákup HW 0 Lze využít HW pro POTOP Nákup SW 0 Pouze interní vývoj 5.2. Analýza nákladů/přínosů Dokument projektu VIVA 10 (celkem 14)

6. ANALÝZA RIZIK 6.1. Rizika projektu Označení Chybějící solution architekt Chybějící produktový manažer Chybějící provoz Míra rizika Popis Chybí osoba, která by zajistila komplexní architekturu celého řešení Chybí osoba, která bude odpovídat za strategii a rozvoj produktu do budoucna a bude zodpovídat za nastavení provozních procesů Zavedení produktu bude mít dopad na nastavení nových provozních procesů Opatření k omezení rizika 6.2. Rizika produktu Riziko Rizika spojená s osobními údaji Omezení Viva karta neobsahuje osobní údaje, proto tato třída rizik není relevantní Rizika zcizení dárkových karet Výroba kopie karty - nemá význam u držitele karty (karta je vázána pořád na stejný účet), ale možné u třetích osob při krádeži karty v obchodě nebo při personalizaci a následném okopírovaní Odcizení vyrobených karet před distribucí příjemcům, nebo během distribuce. Odcizení vyrobených karet koncovým příjemcům. Rizika odcizení finančních prostředků na kartě Jedná se o skupinu rizik, kdy dojde k vyčerpání finančních prostředků z Viva karty neoprávněnou osobou. Dojde tak k poškození držitele karty bez toho, že by mu byla karta odcizena. Výroba padělku karty bez fyzické přítomnosti kopírované karty. Může se jednat o hádání nebo jinou formu sociální manipulace, na jejímž základě pachatel dokáže vytvořit kopii funkční kartu bez toho, aby získal fyzicky přístup k originální kartě. Riziko narušení integrity dat. Mohlo by dojít k chybě, která poškodí data o zůstatcích jednotlivých Viva karet na Viva serveru. Alternativou je úmyslná manipulace s těmito daty za účelem získání prospěchu. RDB spravuje karetní účty, na kterých jsou zůstatky, které mohou dosáhnout objemu v řádech milionů korun omezením je neznalost doby aktivace, omezené použití pouze v jednom obchodě, relativně malé částky Zneužití odcizení karet je omezeno nutností aktivace. Karty se distribuují neaktivované K zjištění chybějících karet je nutné provádět přepočítání karet při přejímce. Za ztrátu odebraných karet odpovídá odběratel. Za odcizení karet konečným držitelům odpovídá držitel (nemá nárok na náhradu) Výroba padělku karty bez fyzické přítomnosti kopírované karty musí být omezena CVV kódem nebo podobnou ochranou Riziko narušení integrity dat musí být omezeno online replikací dat a jejich zálohováním Každá změna (aktivace, dobití, změna zůstatku) musí být auditovatelná a přiřaditelná konkrétnímu uživateli Podvodné transakce budou omezeny kontrolou TIID, uživatelského jména a hesla obsluhy, která se bude k aplikaci přihlašovat. Dokument projektu VIVA 11 (celkem 14)

Odeslání podvržených podvodných transakcí o platbě. Toto riziko může být provedeno i jako žert, ze kterého nebude mít jeho pachatel přímý finančních prospěch, ale může prostřednictvím podvržených transakcí vybít cizí dárkové karty. Rizika podvodných transakcí Podvody provedené pokladním. Může se jednat o aktivaci karty. Zejména nebezpečná by byla kombinace s aktivace s výrobou padělku. Alternativním podvodem je dobití karty bez zaplacení. Podvod provedený obsluhou Viva serveru. Mohlo by se jednat o následující typy rizik o Navýšení kreditu na konkrétní dárkové kartě o Aktivace/deaktivace dárkové karty o o v nesprávný okamžit Únik čísel dárkových karet Smazání, nebo modifikace transakcí provedených dárkovou kartou o Neoprávněná/nesprávná reklamace transakce Podvod provedené pokladním musí být omezen přihlašováním pokladních pod uživatelským jménem nebo heslem a možností zpětného dohledání transakce Podvod provedený obsluhou Viva serveru bude omezen zavedením správy uživatelů a možností dohledání transakce. Správa uživatelů bude odpovědností odběratele. Technologická rizika Jedná se o běžná technologická rizika spojená s provozem infrastruktury pro provoz Viva karet. V první fázi analýzy rizik není nutné tato rizika specificky definovat a analyzovat, protože pro provoz bude využita již zavedená technologie. Dokument projektu VIVA 12 (celkem 14)

7. ŘÍDÍCÍ PROCEDURY 7.1.1. Hlášení problémů a požadavků Požadavky Požadavky na systém, které nejsou součástí vstupních požadavků, budou ukládány na projektovém webu v sekci SEZNAMY- Issue Log. Za uložení požadavku odpovídá ten, kdo jej vznesl, za jeho další správutj. vyhodnocení, distribuci odpovědným osobám zodpovídá PM, po konzultaci se supervizorem projektu, případně analytikem, produktovým zastřešením a dalšími zainteresovanými lidmi. Pokud bude požadavek vyhodnocen jako změnový, jeho životní cyklus bude odpovídat procesu řízení změn popsaném v další kapitole. Problémy Hlášení problémů se řídí eskalačními kritérii definovanými výše. Od úrovně problému předaného PM je za jeho sledování, zápis, aktualizaci a řešení zodpovědný PM. Problém také dokumentuje a aktualizuje na projektovém webu v sekci SEZNAMY- Issue Log. Popis problému obsahuje i jeho prioritu, jméno osoby odpovědné za jeho vyřešení, datum, kdy byl problém identifikován a stav řešení. 7.1.2. Změnové požadavky Iniciátor požadavku na změnu (tj. ten kdo požadavek, který byl PM vyhodnocen jako změnový viz. předcházející kapitola, vznesl) určí prioritu požadavku dle svého pohledu (obchodní hledisko, bezpečnostní hledisko atp.)-parciální priorita. PM nechá vypracovat hrubý odhad pracnosti a seznam dotčených systému (analýza, vývoj) a po konzultaci se supervizorem projektu určí prioritu v rámci projektu- komplexní priorita (nutnost, přínos, náklady). S požadavkem potom bude nakládáno podle míry komplexní priority (viz. následující tabulka). PM informuje iniciátora požadavku, ten má právo v případě nesouhlasu trvat na přezkoumání požadavku sponzorem projektu. Ten poté rozhodne definitivně. Priorita Realizace komplexní 1 požadavek bude realizován v rámci stávajícího projektu 2 rozhoduje sponzor projektu 3 požadavek realizován v další verzi Popis typických druhů Změnový požadavek malého rozsahu a střední obchodní priority, změnový požadavek většího rozsahu a velké obchodní priority, bezpodmínečný bezpečnostní požadavek akceptačního rázu Střední rozsah, střední obchodní či bezpečnostní priorita, velký rozsah a velké obchodní přínosy apd. Velký rozsah, střední či nízká obchodní priorita Dokument projektu VIVA 13 (celkem 14)

PM zodpovídá za předání požadavku s komplexní prioritou 1 zainteresovaným členům týmu. U požadavku s prioritou 2 je oprávněn požádat o mimořádnou schůzku sponzora projektu a po překategorizaci priority spravuje požadavek dále dle jeho nového statusu. U požadavků priority 3 zakonzervuje požadavek pro další verzi aplikace. O změnových požadavcích bude sponzor projektu pravidelně informován na schůzkách executive committee. 7.1.3. Procedury pro sledování postupu projektu Projekt bude sledován: - vykazováním práce v rámci dohadu času na mcprojectu - reportem skutečného stavu splnění úkolů O stavu projektu budou členové projektového týmu pravidelně informování na pravidelných status meetinzích, sponzor projektu pak na executive committee. 8. PŘÍLOHY 8.1.1. Související dokumenty Tabulka obsahuje seznam zdrojů, kterých bylo využito při vytváření tohoto dokumentu, nebo na které se dokument odkazuje. Dokument/produkt Příloha 1 - Požadavky Příloha 2 - Zajištění kvality a testování Místo uložení http://mswproject/obchodrozvoj/projekty/vivacards /default.aspx 8.1.2. Zainteresované role Osoby uvedené níže obdrží kopii tohoto dokumentu. Tento seznam je platný ke dni {uveďte datum}. Zainteresované role Organizace Jméno Dokument projektu VIVA 14 (celkem 14)