Příloha č.3 – Detailní rozpis požadavků na funkcionalitu systému a průběh realizace ERP systému pro zajištění globálních plateb II
Zadavatel:
Westcom, s.r.o., U Vodárny 2, 616 00, Brno
Detailní rozpis požadavků na systém a průběh realizace projektu Pro dodání kompletního informačního systému dle Zadávací dokumentace výše uvedeného výběrového řízení, a dále také z důvodu detailního pochopení celé problematiky, musí dodavatel realizovat úkony dle následujícího plánu prací.
(1)
Vytvoření studie „Analýza používaných platebních metod pro platby za online nákupy v jednotlivých zemích“.
(2)
Vytvoření studie „Analýza procesů v online platebních systémech“.
(3)
Vytvoření studie „Analýza služeb Centra včetně popisu core-procesů“.
(4)
Vytvoření studie „Analýza administrativních a manažerských procesů Centra“.
(5)
Vytvoření studie „Integrační API a zabezpečení citlivých datových přenosů“.
(6)
Vytvoření studie „HW koncepce Centra a zajištění bezvýpadkového provozu“.
(7)
Vytvoření studie „Šablony v systému a grafický návrh jednotlivých obrazovek v systému“.
(8)
Vytvoření studie „Mezinárodní účetnictví jako služba pro zákazníky Centra“.
(9)
Vytvoření studie „Napojení informačního systému na stávající účetní systém zadavatele“.
(10) Syntéza informačního systému. (11) Implementace informačního systému. (12) Lokalizace informačního systému do 11 jazyků. (13) Vyhodnocení výkonu implementovaného systému pomocí simulace. (14) Předání systému do zkušebního provozu. (15) Zahájení testovacího provozu help-desku. (16) Oprava chyb a úpravy chování systému na základě zpětné vazby od uživatelů. (17) Akceptační testy. (18) Uvedení systému do ostrého provozu. (19) Zahájení ostrého provozu help-desku. (20) Školení uživatelů systému Zpracování uvedených studií je nutné zahrnout do nabídkové ceny. Studie budou připravovány dodavatelem v součinnosti se zadavatelem a každá studie bude zadavatelem
schvalována zvlášť. Tento dokument definuje minimální požadovaný rozsah prací. Při realizaci studií a implementaci není možné jakkoliv tento rozsah omezovat nebo krátit. Schválení a akceptace vyhotovených studií a předaných výsledků implementačních prací bude vždy zadavatelem stvrzeno a podepsáno v akceptačním protokolu. Tzv. Komplexní analýza IS (viz Zadávací dokumentace a Smlouva o dílo) je tvořena realizací bodů 1 – 10. Implementace systému bude moci být zahájena až po schválení Komplexní analýzy IS zadavatelem, přičemž vyhotovené podklady budou pro implementaci závazné. V průběhu implementace a po dokončení implementačních prací budou realizovány kroky č. 11 – 19. Zadavatel bude akceptovat systém do zkušebního provozu po realizaci kroků 1 – 13. Do ostrého provozu bude systém uveden splněním a schválením všech uvedených kroků, kdy systém bude uveden do bezchybného rutinního provozu, jak je definováno ve smlouvě o dílo.
(1) Analýza používaných platebních metod pro platby za online nákupy v jednotlivých zemích Účelem studie je zjistit výčet karetních, mikroplatebních a integrovaných systémů pro realizaci online plateb, a také výčet populárních lokálních bank, které používá obyvatelstvo jednotlivých zemí ke správě hotovosti. Výstupy: tabulka se sloupci: o Stát – název země, členěno po jednotlivých státech:
Německo, Španělsko, Velká Británie, Francie, Nizozemsko, Norsko, USA, Kanada, Austrálie, Izrael, Japonsko, Rusko, Brazílie.
o Karetní platební systémy – seznam používaných karetních platebních systémů seřazený podle objemu karetních transakcí realizovaných online za rok 2011. o Mikroplatební systémy – seznam používaných elektronických peněženek včetně lokálních specifických systémů seřazených podle objemu realizovaných transakcí za rok 2011. Např. Paypal, AliPay, DinneroMail aj. o Banky – seznam bank, ve kterých má obyvatelstvo země vedeny bankovní účty, řazeno podle popularity vč. informace o možnostech integrace bankovních systémů pro online platby. Stačí 3 v daném státě nejpopulárnější banky.
o Nejpoužívanější typy plateb za online nákupy – seznam nejčastějších metod plateb používaných obyvatelstvem online. Např. v ČR při nákupu online služeb přes Internet využívá 78% zákazníků bankovní převod, 12% platbu kartou a 10% použilo jiný mikroplatební systémy (např.Paypal). o Použité zdroje – linky na použité informační zdroje. Informace musí být podložené a důvěryhodné.
(2) Analýza procesů v online platebních systémech Studie má za cíl detailně popsat jednotlivé platební systémy (vycházející z bodu 1), procesy v nich, nashromáždit snímky platebních a administračních obrazovek, a detailně popsat možnosti jejich integračních API. Bude se jednat o 30 – 40 systémů, jejichž seznam bude upřesněn zadavatelem po vyhodnocení bodu 1. Příkladem uvedených služeb jsou PayPal, AliPay, Smart2Pay, DinneroMail, Pagseguro, Wirecard, IDeal, SIBS a řada dalších. Výstupy: -
Seznam všech dostupných platebních systémů pro platby kartami (např. Wirecard, SWREG a Stripe), mikroplatebních systémů (např. PayPal, PaySec) a integrovaných systémů (např. Smart2Pay).
-
U každé jednotlivé platební metody následně: o Detailní popis všech poskytovaných služeb. o Detailní popis procesu platby, ideálně v podobě procesní mapy o Popis způsobu grafické integrace i komunikační integrace (API) těchto systémů do webových obchodních systémů online prodejců. o Detailní popis všech kroků a toků platebních procesů při nákupu zboží/služeb a následné platbě z hlediska kupujícího, a z hlediska prodejce. Popis řešení chybových stavů. o Popis způsobů vyúčtování úhrad a způsobu toku peněz mezi platebním systémem a online prodejcem. o Popis administračního rozhraní systému vč. screenshotů. o Ceny služeb, transakční podíly, vstupní poplatky, výstupní poplatky a všechny další případné poplatky. o Dostupnost služeb v jednotlivých zemích.
(3) Analýza služeb Centra včetně popisu core-procesů Studie bude obsahovat popis hlavních činností Centra, které budou implementovány, a které musí být zároveň plně automatizovány. Jedná se zejména o vystavování výzev k úhradě, faktur a dobropisů, zpracování plateb a refundací, zaúčtování dokladů a časového rozlišení víceletých služeb, importy bankovních výpisů, příprava příkazů k úhradě, zpřístupnění zaplacených služeb, administrativní sledování plateb, objednávek a služeb. Cílem studie je vypracovat podrobný rozbor všech variant a alternativ jednotlivých procesů a subprocesů, které zde mohou nastat. Součástí musí být návrh způsobu řešení všech potenciálně problematických situací (nespárované platby, dodatečné úpravy faktur apod.). Výstupy: (1) Analýza fyzické realizace plateb a integrace platebního procesu do webového rozhraní zákazníků Centra Jedná se o rozbor a detailní popis platebního procesu. Bude zpracována procesní mapa a následně konkrétní návrh GUI systému až na úroveň jednotlivých obrazovek a kroků platebního procesu (viz 3.8 Rozbor způsobu použití služeb Centra zákazníky v příloze č. 1.). Bude provedena detailní analýza objednávkového a platebního procesu, která se skládá zejména z následujících okruhů:
Automatická nabídka vhodných platebních metod podle lokality kupujícího (brazilskému kupujícímu se zobrazí sada platebních metod typická pro Brazílii, českému kupujícímu se zobrazí typické platební metody pro ČR apod.).
Vystavení výzvy k úhradě v jazyce kupujícího s ohledem na lokální daňová specifika a požadavky na doklady. Výzva k úhradě musí zohledňovat
správné
účtování
DPH
v případě
domácích
a
přeshraničních prodejů v EU a mimo EU.
Po autorizaci platby nebo přijetí úhrady bankovním převodem se provede automatizované vystavení faktury podle údajů ve výzvě k úhradě a následně se uvolní zakoupené služby, nebo se vydá pokyn1 prodávajícímu ke zpřístupnění služeb nebo odeslání zakoupeného zboží.
1
Přes API Centra, které je řešeno ve studii „Integrační API a zabezpečení citlivých datových přenosů“; viz níže.
Rozbor a popis procesu automatického zaúčtování výnosového dokladu pro prodávajícího.
Automatické zaúčtování podílu na transakci jako výnosu na straně Centra.
Řešení rekurentních plateb (automatické obnovování předplatného po jeho vypršení; musí být odsouhlaseno kupujícím, každá rekurentní platba musí být předem oznamována kupujícímu). Nutno analyzovat rekurentní platby z hlediska jejich podpory v rámci jednotlivých platebních systémů.
Platby budou prováděny na lokální bankovní účty Centra v zemi kupujícího, nebo na karetní či mikroplatební účty Centra u příslušných operátorů. Centrum bude následně prostředky náležející zákazníkům Centra (online prodávajícím) dávkově (tzn. např. 1x za týden atp.) převádět na bankovní účty.
Řešení chybových stavů, které mohou nastat kdykoliv v průběhu transakce. Nesmí dojít ke ztrátě finančních prostředků, nebo k neoprávněnému zpřístupnění služeb.
Návrh způsobu integrace platebního subsystému Centra do webových stránek zákazníka Centra včetně detailního popisu jednotlivých principů.
(2) Administrační centrum zákazníků (internetových prodejců) Jedná se o popis a návrh administrační části systému, která bude přístupná zákazníkům Centra po přihlášení se. Bude obsahovat všechny potřebné funkce ke správě systému ze strany zákazníků Centra. Nutno detailně zpracovat následující okruhy:
Proces vyřizování objednávky, stavy objednávky (např. „objednáno“, „čeká se na platbu“, „platba přijata“, „dodáno“, „nedodáno“, „chyba při zpracování platby“, „chyba při zpřístupnění zakoupených služeb“ apod.). Kroky vývoje objednávky od stavu „objednáno“ až do stavu „dodáno“ včetně všech možných chybových stavů a návrhu způsobu jejich řešení.
Zadávání kupónů/voucherů pro použití kupujícími. Voucher na jedno použití / na konkrétní počet použití / bez limitu. Vouchery na konkrétní
služby / obecné vouchery. Voucher je na konkrétní částku nebo na procentuální slevu nebo na služby zdarma po určitou dobu.
Objednávky, stav, vyřízené/nevyřízené, storno objednávek, statistiky objednávek ve členění podle kupujícího, města, státu, pohlaví, věku. Detailní soupis objednávek (datum, čas, souhrn objednávek, detail každé objednávky).
Statistiky skutečně realizovaných prodejů, nejprodávanější zboží, analýza prodejů podle kupujícího, města, státu, pohlaví, věku. Detailní soupis realizovaných prodejů. Segmentace kupujících a jejich rozdělování do různých skupin pomocí různých kritérií, zobrazení souhrnů prodejů podle uživatelsky definovaných segmentů.
Proces expirace zakoupených služeb, upozorňování kupujících i prodejců na blížící se termín expirace, automatizované zasílání notifikací mailem, uživatelem definovatelné texty notifikačních zpráv, zablokování přístupu kupujícího ke službě po vypršení předplatného.
Bezplatný/zpoplatněný transfer zakoupených služeb na jiný subjekt. Zákazník A chce převést své zakoupené služby na zákazníka B. Data v účetnictví se nemění, ale změní se identifikace zákazníka u zakoupených služeb. Služby jsou zpřístupněny novému zákazníkovi.
Finanční bilance, zúčtování a hromadná úhrada zákazníkům Centra za vyfakturované a zaplacené zboží a služby. S tímto souvisí nutnost konverze měn, platba transakčních poplatků za mezinárodní bankovní převody, údržba příslušných kurzovních lístků.
Centrum bude svým zákazníkům účtovat podíl z realizovaného obratu za prodeje. Procento podílu se bude lišit pro každého zákazníka Centra zvlášť. Centrum bude pravidelně fakturovat tento podíl zákazníkovi a automaticky si jej odečte před transferem peněz na bankovní účet zákazníka. Vyúčtování bude přílohou faktury Centra a bude obsahovat informace o realizovaných transakcích a podílech. Centrum bude kromě podílů na transakcích fakturovat zákazníkům konkrétní položky placených služeb.
Správa, vystavování a tisk daňových dokladů, evidence daňových dokladů, možnosti dodatečné úpravy daňových dokladů na základě požadavků kupujících (budou chtít změnit kupujícího apod.).
Automatické zaúčtování příjmů za prodané služby/zboží, včetně automatizovaného zúčtování časového rozlišení v případě víceletých předplatných. Storno vystavených faktur. Možnost dodatečné editace položek na zaúčtované faktuře.
Evidence zákazníků a vztahů se zákazníky (CRM). Provázanost s ostatními moduly (např. při zobrazení detailu zákazníka je možné dostat se na detail jeho objednávek, apod.).
Katalog používaných placených služeb Centra – zákazník si vybere z portfolia různých doplňkových služeb Centra, které chce využívat, a předplatí si je. Ceny budou odstupňovány podle různých variant uvedených služeb. Portfolio placených služeb bude dynamické a nastavitelné správou Centra.
(3) Interní administrační centrum pro support zaměstnance Centra Personál zaměstnanců Centra, kteří budou poskytovat podporu zákazníkům, bude pro svoji práci s uživatelskými projekty používat Interní administrační centrum. Tento subsystém umožní zjistit detaily o jednotlivých zákaznících Centra, jejich projektech, prodejích, doménách, zálohách, bilanci finančních prostředků atd. Také umožní realizovat administrativní úkony nezbytné pro chod Centra samotného – zpracování bankovních výpisů, ruční párování plateb, provádění refundací, atd. Interní
administrační
centrum
bude
obsahovat
všechny
možnosti
administračního centra pro zákazníky (popsáno výše v bodě 2) a navíc přidá následující okruhy témat:
Evidence výpisů a potvrzení o platbách (bankovní výpisy, notifikace karetních a mikroplatebních systémů o provedení či selhání plateb).
Automatizované párování plateb podle informací na Výpisech (párování platba – zboží – obchodník) včetně automatického uvolňování služeb,
Rozbor a návrh procesu automatizovaného řešení nespárovaných a neidentifikovaných plateb, včetně vazby na interakci se zaměstnanci Centra (support).
Refundace kupujícím a refundace zákazníkům Centra, řízení refundací, dynamické podmínky refundací, evidence refundací, stav jednotlivých
refundací, statistika refundací podle jednotlivých prodejců. Provázání refundací do účetnictví.
Možnost bezplatně povolit kupujícím přístup ke službám, nastavit časová omezení přístupu, blokace přístupu, zakazování zákaznických účtů a účtů kupujících, prohlížení logů aktivity uživatele a kupujícího, sledování přístupů zákazníků do systému. Transfer celého účtu prodejce
na
jiný subjekt,
včetně
bezpečnostních
ověřovacích
mechanismů a právně validních potvrzovacích dokumentů.
Subsystém pro správu zákazníků (zavedení, rušení, evidence).
Subsystém pro správu zaměstnanců Centra (zavedení zrušení, evidence, role, přístupová oprávnění).
Další nezbytné administrační nástroje jako dešifrátor šifrovaných systémových zpráv zasílaných mezi servery a jiných zabezpečených dat vytvořených nebo zasílaných systémem,
správa šifrovacích klíčů,
apod. Toto je nutné zejména z důvodu, kdy selže některý z procesů a např. bude nutné z logů rekonstruovat zasílaná data, která se v logu ale objeví v šifrovaném tvaru (např. v URL).
Ve studii také bude řešen popis způsobu nasazování nových verzí systému a popis testovacího prostředí pro vyhodnocování nových verzí systému před nasazením do ostrého provozu. Spuštění synchronizace nových verzí systému na ostré servery bude mít v kompetenci tým vývojářů Centra a příslušné ovládací GUI bude součástí Interního administračního centra, přičemž přístupné bude jen oprávněným osobám.
Studie také vyřeší způsob logování aktivity uživatelů a zaměstnanců Centra, aby bylo vždy možné zpětně dohledat zodpovědnost konkrétních pracovníků či uživatelů za konkrétní operace.
Ve studii bude také navržen mechanismus optimalizace hromadného transferu finančních prostředků zákazníkům Centra. Účelem bude minimalizace nákladů Centra na tyto poplatky pomocí vhodného plánování realokace prostředků v různých zemích.
Modelovým příkladem může být situace, kdy Centrum má 10 zákazníků ze Španělska a 10 z Německa. Těchto 20 zákazníků
realizovalo prodeje ve všech členských státech EU z nichž 50% bylo zaplaceno kartou a jsou tak připsány na účet Centra v rámci karetního operátora. Ostatní úhrady byly provedeny bankovním převodem na bankovní účty Centra vedené v jednotlivých zemích. Cílem je hromadný převod peněžních prostředků všech těchto zákazníků ze všech různých zdrojů do španělské a německé banky tak, aby transakční poplatky byly minimální. Přitom je nutné co nejvíce využít zdrojů v lokálních bankách – např. německý prodejce prodává španělským zákazníkům, kteří platí bankovním převodem do španělské banky, a naopak španělský prodejce prodává německým zákazníkům, kteří platí do německé banky. Účelem je neprovádět zbytečné bankovní transakce a interně zajistit v maximální možné míře realokaci peněžních prostředků v jednotlivých státech.
(4) Analýza administrativních a manažerských procesů Centra Cílem studie je popsat procesy, které mají administrativní charakter vzhledem k business procesu Centra. Studie bude tvořena čtyřmi okruhy: účetnictví, CRM, MIS, Workflow. (1) Požadavky na účetní subsystém pro samostatné účtování operací samotného Centra: o Slouží jen pro potřeby účetnictví Centra (tj. účetnictví zadavatele). o Plnění zákonných požadavků na účetní systém, dostupnost různých světových účetních standardů a osnov, vč. IFRS a US GAAP. o Tvorba daňových přiznání a dalších účetních výkazů. o Napojení účetního subsystému na procesy v rámci Centra pro automatické zaúčtování účetních dokladů a operací, které vzniknou v souvislosti s realizací business procesů Centra. Zejména jde o automatické účtování výnosů a automatické vystavování a zasílání faktur zákazníkům za služby Centra. o Systém musí umožňovat sestavení konsolidovaných reportů a závěrek. o Napojení na současný účetní systém zadavatele (SAP).
(2) Požadavky na CRM o Popis realizace CRM systému, provázanost CRM s ostatními částmi systému. o Helpdesk – návrh systému, návrh obrazovek, automatizované hlídání povinností zaměstnanců plynoucích z SLA (service level agreement podepsaný mezi Centrem a zákazníkem Centra) včetně příslušného upozorňování zaměstnanců samotných a jejich nadřízených pracovníků v případě včasného nesplnění povinností. Správa ticketů s historií komunikace. Ke každému ticketu možnost zapsat poznámky. Možnost předávání ticketů mezi pracovníky podpory. Fulltextové a vícekriteriální vyhledávání v ticketech. Možnost definic uživatelských podpisů. Automatické třídění ticketů do různých departmentů podle cílové e-mail adresy. Statistiky stavu řešených / neřešených ticketů, zpoždění, členěno po departmentech. Předdefinované odpovědi včetně inteligentní nabídky výběru předdefinovaných odpovědí na základě kategorií a hledaných frází. Dashboard s informacemi pro pracovníky (informace, novinky, statistiky, počty přiřazených ticketů ke zpracování). Knowledgebase s informacemi známých postupů řešení různých typů problémů a situací. FAQ. o Online diskuzní fórum – návrh systému, návrh obrazovek, validace vstupních dat, captcha, notifikace systémové podpory o nových zprávách ve fóru, grafické oddělení příspěvků zaměstnanců Centra od běžných uživatelů, různé druhy zobrazení, zamykání vláken, mazání příspěvků i celých vláken, „rozcestník“ diskusí – stránka se seznamem diskusních kategorií a odkazy na ně. o Online chat – návrh systému, návrh obrazovek, validace vstupních dat, captcha, notifikace systémové podpory o nových zprávách v chatu, různé druhy zobrazení. (3) Požadavky na manažerský informační systém Centra: o Jedná se o manažerské subsystémy, které umožní vyhodnocování ekonomické výkonnosti Centra včetně hodnocení ekonomické efektivnosti investic. Musí umožňovat sestavení různých pohledů na data, provázání různých datových zdrojů vizuální formou pomocí návrháře formulářů, sestav a grafů. Jedná se zejména o následující okruhy témat:
Požadavky na modul Business inteligence:
Popis analytických nástrojů BI,
Návrh konfigurace konkrétních BI ukazatelů, statistik a grafů.
Uživatelsky definované BI ukazatele,
Uživatelsky definované reporty a výkazy, návrhář sestav pomocí drag&drop přístupu,
Nastavení provázanosti různých datových zdrojů a tvorba vlastních pohledů na data.
Grafické znázornění trendů, poměrů a podílů.
Využití datových kostek.
Data-mining,
Segmentace kupujících a jejich rozdělování do různých skupin pomocí různých kritérií,
Plánování a simulace – systém na základě dostupných dat a analýzy jejich trendů provede odhad budoucího vývoje různých ekonomických a jiných parametrů společnosti. Predikce budoucího vývoje bude parametrizovaná a manažer bude schopen s pomocí tohoto nástroje modelovat různé varianty budoucího vývoje firmy na základě různých scénářů vývoje. Např. jak se projeví na budoucích příjmech společnosti dvojnásobné zvýšení počtu uživatelů, jak se toto projeví na růstu nákladů vč. jejich pyramidálního rozkladu apod.
Statistiky prodejů podle lokalit, prodejců, měsíční, kvartální a roční statistiky,
Sledování a analýza nákladů, pyramidální rozklady podle různých hledisek (oddělení, zaměstnanci, majetek atp.)
Hodnocení ekonomické efektivnosti investic.
(4) Požadavky na Workflow. Definice, správa a změny workflow. Uživatelsky definovatelné workflow. o Možnost změnit tok a průběh administrativních procesů, přidat/odebrat schvalovací kroky, definovat cestu oběhu dokumentů firmou. o Možnost uživatelsky definovat zcela nové procesy pomocí interaktivních návrhářů workflow.
(5) Integrační API a zabezpečení citlivých datových přenosů Ve studii bude zpracován návrh koncepce integrace API různých platebních bran a mikroplatebních systémů v rámci informačního systému. Cílem je zpřístupnění různých platebních systémů transparentně zákazníkům Centra přes jediné zastřešující API. Ve studii bude proveden návrh a popis zabezpečení datových toků mezi systémy, zajištění důvěryhodnosti, nepopiratelnosti, autenticity. Výstupy: o Návrh a popis univerzálního platebního aplikačního programového rozhraní (API), které budou implementovat zákazníci Centra do svých systémů. API bude pokrývat celý platební proces a bude zajišťovat důvěryhodnost, nepopiratelnost a autenticitu realizovaných transakcí. o Popis integrace a implementace API různých platebních systémů. Bude se jednat o 30 – 40 systémů, jejichž seznam bude upřesněn zadavatelem na základě výsledků studie č. 1. Příkladem jsou PayPal, AliPay, Smart2Pay, DinneroMail, Pagseguro, Wirecard, IDeal, SIBS a řada dalších. o Pro každý platební systém realizace detailního rozboru jeho integračního API, zajištění přístupu k vývojářskému sand-boxu, ověření API, vyhodnocení API. Syntéza společných rysů a návrh vnitřní objektové struktury systému Centra pro integraci všech aplikačních rozhraní různých systémů s ohledem na budoucí rozšiřitelnost. o Návrh a detailní popis mechanismu kryptografického zabezpečení datové komunikace. Návrh a popis jednotlivých zpráv a datových toků mezi servery Centra a servery zákazníků Centra (online prodejců). Spolehlivé dvojstranné stvrzování platnosti transakcí. o Koncepce proaktivního fraud-detection mechanismu. Hledání podezřelých transakcí, ochrana proti zneužití ukradených platebních údajů (platba s ukradeným číslem platební karty apod.). Tuto funkci je nutné velmi pečlivě promyslet a navrhnout, protože banky a karetní společnosti nechávají úhradu fraudů na straně obchodníků, tedy na straně Centra. Mechanismy fraud detekce, které nabízí API karetních společností a poskytovatelů platebních bran není dostatečně spolehlivé. Na straně operátorů ani není snaha tento problém nějak zásadně řešit, protože náklady jsou přesunuty na stranu obchodníka.
o Koncepce ochrany proti útokům man-in-the-middle a brute-force útokům na symetrickou šifru. Koncepce správy, ochrany a obnovy klíčů pro asymetrickou kryptografii. Krizové scénáře při napadení systému Centra a kompromitace tajného klíče. o Návrh koncepce periodických vyhodnocování bezpečnosti implementovaného API pro zákazníky Centra (pravidelné penetrační testy, jejich náplň, a způsoby vyhodnocení). Rozbor známých typů útoků na webové systémy a metody ochrany proti nim. Techniky a metody preventivní ochrany.
(6) HW koncepce Centra a zajištění bezvýpadkového provozu Dodavatel informačního systému stanoví HW architekturu, která bude zajišťovat fyzický bezvýpadkový provoz systémů Centra s odolností proti výpadkům elektrické energie a síťového připojení. Cílem této studie je tuto architekturu definovat, popsat a specifikovat možné problematické situace a navrhnout krizové scénáře. Studie musí počítat s obrovskými datovými objemy uloženými na serverech a v databázích. Očekává se více než 100 milionů záznamů v jednotlivých tabulkách. Systém musí být dostatečně dimenzován, aby při takovém objemu dat zvládl spolehlivě pracovat a odpovídat na požadavky v přiměřeně krátké době. Výstupy:
Koncepce HW architektury systému, ve smyslu aplikačního určení jednotlivých serverů (jaké budou typy serverů a jaké na nich poběží systémy, např. databázový server, aplikační server, souborový server, zálohovací server atp.). Kooperace a datové toky mezi servery. Popis koncepce zvyšování výkonu pomocí horizontálního škálování. Při návrhu HW řešení bude dodavatel počítat se servery v následující výkonnostní třídě: o AMD Opteron 2,6 GHz, 8core (nebo adekvátní procesor Intel), o 32 GB RAM 1600 MHz DDR 3, o 2x sATA2 RAID 0,1, o 3x HDD 1TB 7500RPM/4,2ms/64MB, o 2U.
Dodavatel musí architekturu systému navrhnout tak, aby systém byl schopen zpracovat minimálně 500 transakcí za sekundu na server. o Transakcí se míní jeden úkon zpracování požadavku a vygenerování příslušné odpovědi, např. vytvoření účtenky, faktury, objednávky, přidání
nebo odebrání položek z objednávky, zaplacení, včetně příslušných datových operací zápisu a čtení.
Datové centrum a jeho systém musí podporovat formu realizace pomocí geografického clusteru, kde jednotlivé lokace jsou vzájemně ekvivalentní.
Studie také musí řešit problematiku monitoringu dostupnosti služeb Centra z celého
světa.
V případě
výpadků
musí
být
tyto
výpadky
hlášeny
administrátorům. Administrátoři musí mít k dispozici systém graficky monitorující stav serverů po jednotlivých parametrech s minutovou přesností (průměrné využití CPU, konzumace paměti, počet provedených SQL dotazů, počet vláken web serveru s rozlišením na vlákna čekající, pracující, zasílající data atd., počet odeslaných mailových zpráv a stav volného místa na discích serveru. Monitorována bude také odezva na frontendu systému na různé požadavky. Při nárůstu průměrné doby odezvy musí systém podat o tomto zprávu. Monitorovány budou také databázové tabulky, zda nedošlo k poškození a není nutná oprava. Klíčové databáze a jiné subsystémy musí být v architektuře systému redundantně rozmístěné, aby v případě výpadku jednoho z uzlů převzaly jeho provoz další uzly.
Koncepce HW řešení serverovny (routery, přepínače, firewally, kabeláž, záloha napájení, schéma zapojení, chlazení atd.), podrobná specifikace konfigurace serverů,
koncepce
ukládání
dat,
koncepce
garantovaného
redundantního
zálohování dat, mechanismus rozkládání zátěže, dlouhodobý data storage, využití cloud řešení.
Krizové scénáře při výpadku serveru, směrovačů, přepínačů, datové linky (připojení centra bude zálohováno dvěma různými linkami a providery => každý provider má jiný prostor IP adres).
Koncepce serverovny pro situace při výpadku proudu; nutnost zajistit dostupnost systémů při výpadcích proudu trvajících neomezeně dlouho – zařazení diesel agregátu a jeho redundance.
Proces periodického zálohování a automatizované kontroly kvality záloh.
Návrh procesu periodického transferu zálohovaných dat do jiné lokality. Nutno brát ohled na obrovské datové objemy.
Analýza nákladů na realizaci HW zázemí a serverovny vč. výhledu nákladů na údržbu a obnovování HW do budoucna.
(7) Šablony v systému a grafický návrh jednotlivých obrazovek v systému Studie grafické koncepce systému a grafický návrh jednotlivých obrazovek. Při návrhu je nutné respektovat tok textu z leva doprava i zprava doleva (např. arabština), vč. symbolických písem (japonština, korejština). Součástí návrhu musí být systém šablon pro dynamické přidávání dalších grafických vzhledů (import šablon). Systém z pohledu zákazníků i zaměstnanců Centra bude provozován ve webovém prohlížeči. „Tlustý klient“ není dovolen a nikde se nebude instalovat. Výstupy:
Návrh koncepce šablon, formát zdrojových souborů pro popis grafického vzhledu, popis jednotlivých značek včetně uvedení příkladů použití.
Jednotlivé grafické návrhy jednotlivých subsystémů a obrazovek tak, jak vyplynou ze syntézy informačního systému.
(8) Mezinárodní účetnictví jako služba pro zákazníky Centra Vedení účetnictví bude jednou z placených služeb, které budou nabízeny zákazníkům Centra. Informační systém bude tuto službu plně realizovat ve spolupráci s kvalifikovanou obsluhou. Tato služba bude nabízena ve dvou variantách: -
účtování pouze výnosových operací za prodané zboží a služby,
-
komplexní vedení účetnictví.
Studie musí popsat způsob napojení účetního systému do portfolia služeb Centra tak, aby veškeré výnosové operace za prodeje byly zaúčtovány automaticky. Uživatelé si budou moci exportovat data do svých vlastních účetních systémů v XML formátu. XML formát bude dynamický a uživatelem nastavitelný. Pro zákazníky s předplaceným komplexním vedením účetnictví bude účetní systém generovat daňová přiznání a další zákonné výkazy a sestavy. Studie musí navrhnout způsob zpřístupnění modulu účetnictví a způsob interakce zákazníka s účetním, který ho bude mít na starost. Osobní účast pracovníků Centra je nutné koncipovat tak, aby fyzické práce účetního na celém procesu bylo minimum. Systém musí být v co nejvyšší míře automatizovaný. Nezbytné je také zpřístupnění dat účetního systému
zákazníkovi Centra, který tak bude mít možnost kontroly stavu svého účetnictví, realizace exportu dat, zálohování a tisk PDF sestav. Služba komplexního vedení účetnictví bude provozována jen pro následující země: o Velká Británie, o Francie, o Německo, o USA, o Česká republika. Výstupy: o Popis
provázání
účetního
systému
s implementovaných
informačním
systémem. o Návrhy obrazovek pro ruční zaúčtování dokladů, změny dokladů, generování souhrnných sestav, tisk daňových přiznaní a jiných povinných výkazů dle jednotlivých národních specifik. o Popis způsobu exportu souhrnných výnosových dokladů za všechny prodeje a dané období. o Systém musí podporovat uživatelsky definovaný XML formát dat pro hromadný export výnosových dokladů. Součástí systému (v administraci v internetovém prohlížeči) bude interaktivní návrhář exportního XML formuláře. o Systém musí být plně kompatibilní se světovými účetními standardy a osnovami, vč. IFRS a US GAAP a musí splňovat povinnosti vyplývající z platné účetní legislativy v uvedených zemích. o Studie zohlední dvě varianty služeb, které bude Centrum nabízet svým zákazníkům:
Varianta 1: účetnictví bude účtovat pouze výnosové operace a exportovat souhrnný výnosový doklad za operace, které prošly přes Centrum, a to v XML formátu pro účetní systém zákazníka Centra.
Varianta 2: komplexní vedení účetnictví, tzn. výnosy i náklady, zaměstnanci, mzdy, majetek, zásoby, daňová přiznání, zákonné výkaznictví státním institucím atd.
(9) Napojení informačního systému na stávající účetní systém zadavatele Studie popíše mechanismy automatického hromadného vkládání dokladů do účetního systému zadavatele. Bude se jednat zejména o souhrnné účtování výnosových a nákladových operací. Zadavatel zajistí nezbytnou součinnost s dodavatelem jeho účetního systému, dodá popis API, testovací sandbox aplikaci pro vývoj importního rozhraní.
(10) Syntéza informačního systému Na základě splnění kroků 1 – 9 bude možné přistoupit k syntéze informačního systému. Výstupy:
Návrh jednotlivých obrazovek GUI všech plánovaných subsystémů – koncepční. Detailní návrh GUI je řešen v samostatné studii č. (7).
Detailní plán implementace informačního systému, milníky.
V databázích se očekává více než 100 milionů záznamů v jednotlivých tabulkách. Systém musí být dostatečně dimenzován a výkonnostně optimalizován, aby při takovém objemu dat zvládl spolehlivě pracovat a odpovídat na požadavky uživatelů a kupujících v přiměřeně krátké době.
Z hlediska výkonnosti je naprosto kritická realizace platebního procesu z pohledu kupujícího, který nesmí pozorovat dlouhé časové prodlevy způsobené na straně systémů Centra. Maximální doba generování jedné stránky v rámci platebního procesu z pohledu kupujících je 0,5 sekundy.
(11) Implementace informačního systému Po splnění a schválení kroků 1 – 10 (Komplexní analýza) bude možné přistoupit k samotné implementaci informačního systému, a to na základě výše uvedených studií. Dodavatel zpracuje dokumentaci datových toků v rámci systému a detailně popíše datová úložiště tak, jak budou skutečně vytvořena. Po dokončení implementace budou prováděny dílčí integrační testy, kdy Westcom provede testování a vyhodnocení implementovaného systému a oznámí dodavateli zjištěné
nedostatky. Dodavatel nedostatky neprodleně odstraní. Westcom po odstranění všech nalezených vad vystaví zadavateli akceptační protokol, který je nezbytný pro postoupení projektu do další fáze (lokalizace).
(12) Lokalizace informačního systému do 11 jazyků Lokalizace systému může být zahájena až v okamžiku, kdy Westcom vystaví dodavateli akceptační protokol podle bodu 11 tohoto dokumentu. Dodávaný informační systém musí být připraven v 11 jazykových mutacích: -
čeština,
-
angličtina,
-
polština,
-
slovenština,
-
holandština,
-
španělština,
-
francouzština,
-
brazilská portugalština,
-
němčina,
-
italština,
-
japonština.
Dodavatel musí zajistit překlad do uvedených jazyků rodilými mluvčími, kteří musí živě vidět systém, pracovat s ním a překládat přesně to, co v systému právě dělají (tzv. kontextový překlad). Je naprosto nepřípustné řešit tuto problematiku pouze formou exportu hlášek systému do textového souboru, a jeho zaslání na překlad agentuře. Zadavatel dbá na velmi vysokou kvalitu překladu, která musí být na takové úrovni, aby rodilý mluvčí nedokázal rozpoznat, že systém nepochází z jeho země. Proto si zadavatel vyhrazuje právo aktivní účasti svých pracovníků při realizaci překladu. Překládat bude nezbytné pouze ty části systému, se kterými přijde do styku zákazník Centra a případně kupující. Překládat se také budou systémy technické podpory pro komunikaci se zákazníky (chat, diskusní fórum).
(13) Vyhodnocení výkonu implementovaného systému pomocí simulace Realizace zátěžových testů, které jsou nezbytné pro finální akceptaci implementovaného systému zadavatelem bude krokem, ke kterému se přistoupí po dokončení implementace dodavatelem. Dodavatel připraví informační systém na servery a zhotoví simulační úlohu, která bude simulovat reálnou zátěž celého systému. Databáze musí být naplněna testovacími daty v objemu stovek milionů záznamů v kritických tabulkách.
Simulační úloha musí
obsahovat a vyhodnocovat očekávaný datový provoz, který bude muset Centrum obsluhovat (vše běží paralelně a je spouštěno ve frekvencích adekvátních reálnému provozu), jako například: -
nákupy kupujících, včetně nárazových velmi vysokých špiček v počtu nákupů (30x vyšší než očekávaný denní průměr).
-
vystavování výzev k úhradě,
-
vystavování daňových dokladů,
-
zpracování bankovních, karetních a mikroplatebních výpisů pomocí sandboxů,
-
párování plateb,
-
anti-fraud mechanismus pro ověřování transakcí,
-
registrace nových zákazníků Centra,
-
účtování dokladů do účetnictví,
-
aktualizace daňových dokladů, po vystavení a zaúčtování,
-
výpisy a změny záznamů o zákaznících v CRM systému,
-
hromadný příchod zpráv na podporu (support),
-
zálohy dat,
-
další kroky, které budou upřesněny v průběhu přípravy simulace ve spolupráci se zadavatelem. Veškeré konkrétní měřené hodnoty budou taktéž upřesněny zadavatelem v průběhu přípravy simulace.
(14) Předání systému do zkušebního provozu Dodavatel předá zadavateli systém implementovaný podle výše uvedených a oboustranně schválených studií, připravený v požadovaných jazykových mutacích. O předání systému do zkušebního provozu bude vyhotoven předávací protokol, kde zadavatel musí písemně stvrdit, že systém do zkušebního provozu přebírá. Toto převzetí je možné jen tehdy, pokud systém při
testování nevykazuje žádné zjevné vady. Uvedením systému do zkušebního provozu zároveň zadavatel zahájí provoz Centra a začne ve vybraných zemích nabízet své služby. Současně s předáním systému do zkušebního provozu zajistí dodavatel provedení školení uživatelů systému v následujícím členění: o Školení TOP managementu – principy systému, organizace systému, použití systému z manažerského hlediska, důraz na business inteligenci, o Školení uživatelů – zaměstnanci zadavatele, principy systému, ovládání, řešení problémů, jednotlivé moduly systému detailně, o Školení správců systému – zaměstnanci zadavatele, správa systému, administrace databáze, zálohování, krizové scénáře, komunikace s HelpDeskem dodavatele.
(15) Zahájení testovacího provozu help-desku Dodavatel předá zadavateli kontaktní údaje na vícejazyčný help-desk, který je definován v sekci 3.6 CRM a Helpdesk v příloze č. 1. Vícejazyčný helpdesk bude plně zajišťován dodavatelem, který zajistí realizaci 24/7 zákaznické podpory v jazycích čeština, angličtina.
(16) Oprava chyb a úpravy chování systému na základě zpětné vazby od uživatelů. V průběhu zkušebního provozu bude zadavatel dostávat zprávy od uživatelů systému, kteří budou zadavatele informovat o chybách a požadovaných změnách v aplikační struktuře a chování. Zadavatel tyto informace bude analyzovat, filtrovat a sám zhodnotí, které připomínky uživatelů budou zapracovány do změn v systému. Tyto požadavky bude zadavatel periodicky předávat dodavateli, který zajistí jejich implementaci v rámci systému. Tyto požadavky zaslané na dodavatele v rámci zkušebního provozu se nepovažují za vícepráce. Dodavatel se zavazuje požadavky bezodkladně zapracovat.
(17) Akceptační testy Zadavatel vyhodnotí ve spolupráci s dodavatelem zkušební provoz systému. Po zapracování všech potřebných změn (viz bod 16) bude systém připraven k nasazení do ostrého provozu.
V tomto okamžiku vystaví zadavatel dodavateli písemně akceptační protokol, v němž vyjádří stav přebíraného díla, souhrn případných nedodělků, které budou dodavatelem zapracovány bezplatně a bezodkladně. Zadavatel i dodavatel tento protokol odsouhlasí a podepíší. Tímto se informační systém považuje za předaný a akceptovaný.
(18) Uvedení systému do ostrého provozu Po akceptaci systému bude systém uveden do ostrého provozu. Pokud v průběhu ostrého provozu budou zjištěny chyby, nedodělky nebo jiné závady, provede dodavatel neprodleně jejich odstranění, na základě výzvy zadavatele.
(19) Zahájení ostrého provozu help-desku V průběhu testovacího provozu help-desku bude zadavatel průběžně vyhodnocovat poskytované
služby
a
bude
periodicky
informovat
dodavatele
o
požadovaných
změnách/zlepšení služeb. Dodavatel se zavazuje bezodkladně změny provést či promítnout do procesů v rámci poskytovaného help-desku. V okamžiku spouštění ostrého provozu helpdesku bude sepsán akceptační protokol, kde bude uveden soupis neodstraněných nedostatků, které se dodavatel zaváže bezplatně odstranit.
