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. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8.

CÍLE PROJEKTU .............................................................................................................................. 3 FÁZE PROJEKTU ............................................................................................................................. 3 ROZSAH PROJEKTU ........................................................................................................................ 5 PŘEDPOKLADY .............................................................................................................................. 5 KONCEPT ARCHITEKTURY ............................................................................................................. 6 OVLIVNĚNÉ SYSTÉMY (APLIKACE) ................................................................................................ 6 VÝSTUPNÍ PRODUKTY PROJEKTU ................................................................................................... 6 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. 5.2.

6.

ANALÝZA PROJEKTOVÝCH NÁKLADŮ .......................................................................................... 10 ANALÝZA NÁKLADŮ/PŘÍNOSŮ ..................................................................................................... 10

ANALÝZA RIZIK............................................................................................................................ 11 6.1. 6.2.

RIZIKA PROJEKTU ........................................................................................................................ 11 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


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


4 (celkem 14)

2.3.

Rozsah projektu

2.4. Předpoklady 1. 2. 3. 4. 5. 6.

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


5 (celkem 14)

7. 8. 9.

Vyhodnocení podmínek pro přidělení bonusu a určení částky bonusu je řešeno logikou v ECR. Personalizace umožňuje "balíčkování" karet a jejich označení 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.

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.

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


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


7 (celkem 14)

3. ORGANIZACE PROJEKTU Členové projektového týmu ROLE Sponzor projektu Projektový manažer

POPIS Garant projektu, představuje nejvyšší eskalační stupeň v hierarchii projektu. 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).

OBSAZENÍ Petr Novák Tomáš Dospěl

Zodpovědné osoby za oblast: Vývoj IT

Bezpečnost

Obchodní požadavky Provozní požadavky

POS vývoj Vývoj serveru Analýza Testování a akceptace Obchod Marketing Provoz

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.

Zodpovídá za proveditelnost projektu z hlediska POS. Zodpovídá za proveditelnost projektu z hlediska POS.

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) J. Smutný J. Zelenka

Zajišťuje vypracování analýzy a zohlednění požadavků. Zodpovídá za testování.

Robert Šrámek

Zodpovídá za zajištění obchodních nabídek a zajištění smluvních vztahů PR a marketingová podpora produktu Zodpovědný za nastavení a popis provozních procesů

Karolína Urbanová


D. Musílek

J. Holtan Jaroslav Holý

8 (celkem 14)

4. ČASOVÝ HARMONOGRAM PROJEKTU ID

Název

Práce

1

Gift Cards release 1.0

Doba trvání

Dokončeníkvěten 2007 1. květen

Zahájení

0 hodin

71 dny?

1.6. 07

7.9. 07

2

Dokum entace rozhraní FO GC - POS terminál

0 hodin

1 den?

7.6. 07

7.6. 07

3

Dokum entace 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í rozs ahu projektu - ods ouhlas ení 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í tes tová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 tes tování celého sys tému - ECR+POS+POTOP 0 hodin FO 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

Nas azení aplikace do produkčního provozu

0 hodin

1 den?

17.8. 07

17.8. 07

31

Spuštění m onitoringu 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 Globus u

0 hodin

1 den?

31.8. 07

31.8. 07

0 hodin

51 dny?

29.6. 07

7.9. 07

26.7. 07

24.8. 07

34

Obchod

35

Obchodní nabídka

0 hodin

21,5 dny?

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

0 hodin

25,5 dny?

1.6. 07

6.7. 07

39

Provozní m odel

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

5.6. 07

5.6. 07

5.6. 07

5.6. 07

38

43

Nastavení provozu

Změna POTOP m odelu?


0 hodin

1 den? 1 den?

9 (celkem 14)

5. ODHAD PROJEKTOVÝCH NÁKLADŮ A PŘÍNOSŮ PROJEKTU 5.1.

Analýza projektových nákladů

Náklady Lidské zdroje

Nákup HW Nákup SW

5.2.

Celkový odhad projektových nákladů Částka (tisíce Kč)/MD Předpoklady 27 Čl./Měs. 7 ČM vývoj POS, 20ČM vývoj serveru (počítáno pouze pro 1.fázi) 0 0

Lze využít HW pro POTOP Pouze interní vývoj

Analýza nákladů/přínosů


10 (celkem 14)

6. ANALÝZA RIZIK 6.1.

Rizika projektu

Označení

Míra rizika

Chybějící solution architekt Chybějící produktový manažer Chybějící provoz

6.2.

Popis

Opatření k omezení rizika

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ů

Rizika produktu

Riziko

Omezení

Rizika spojená s osobními údaji

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.

− 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)

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


− 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.

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 – v nesprávný okamžit o Únik čísel dárkových karet o 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.

V první fázi analýzy rizik není nutné tato rizika Jedná se o běžná technologická rizika spojená specificky definovat a analyzovat, protože pro provoz bude využita již zavedená technologie. s provozem infrastruktury pro provoz Viva karet.

Technologická rizika


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 komplexní 1

Realizace

Popis typických druhů

požadavek bude realizován v rámci stávajícího projektu

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.

2

rozhoduje sponzor projektu

3

požadavek realizován v další verzi


Velký rozsah, střední či nízká obchodní priorita

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í

8.1.2.

Místo uložení http://mswproject/obchodrozvoj/projekty/Vivacards /default.aspx

Zainteresované role

Osoby uvedené níže obdrží kopii tohoto dokumentu. Tento seznam je platný ke dni {uveďte datum}. Zainteresované role Organizace


Jméno

14 (celkem 14)

RDB a.s. Projekt VIVA

Recommend Documents