Poptávkový dokument na IS společnosti ibanked, a.s. dokument vytvořen na základě týmové seminární práce předmětu 4IT215 na VŠE v r. 2012/2013
Obsah OBSAH... 2 1. MANAŽERSKÉ SHRNUTÍ... 3 1.1. POŽADAVKY ZADAVATELE... 3 1.2. NÁVRH DALŠÍHO POSTUPU... 3 2. ANALÝZA SOUČASNÉHO STAVU IS/ICT... 4 2.1. KONTEXTOVÝ DIAGRAM... 4 2.2. ZHODNOCENÍ PRŮBĚHU PODNIKOVÝCH PROCESŮ... 5 2.2.1. ZALOŽENÍ ÚČTU... 5 2.2.2. VÝBĚR Z BĚŽNÉHO ÚČTU... 5 2.2.3. ZRUŠENÍ ÚČTU... 5 2.2.4. ŽÁDOST O ÚVĚR... 5 2.2.5. ČERPÁNÍ ÚVĚRU... 6 2.2.6. SPLÁCENÍ ÚVĚRU... 6 2.2.7. UKONČENÍ ÚVĚRU... 6 2.2.8. VÝBĚR Z TERMÍNOVANÉHO ÚČTU... 6 2.2.9. VYSTAVENÍ KREDITNÍ KARTY... 6 2.2.10. VYTVOŘENÍ SPOŘICÍHO ÚČTU... 6 2.2.11. ZRUŠENÍ SPOŘICÍHO ÚČTU... 6 2.3. TECHNOLOGICKÁ INFRASTRUKTURA... 7 2.3.1. HARDWARE... 7 2.3.2. SOFTWARE... 7
1. Manažerské shrnutí Hlavním účelem je zefektivnit podnikové procesy společnosti ibanked, a.s. prostřednictvím IS/ICT. Navrhované řešení zahrnuje nový komplexní informační systém, který pokývá následující oblasti: Vedení Správa klientů Správa produktů Personální Pobočka Komunikace 1.1. Požadavky zadavatele Společnost ibanked, a.s. klade velký důraz na online bankovnictví, jelikož byla založena na základě moderního stylu bankovnictví se zaměřením na internet banking. V současné době se však potýká s podstatným nárůstem klientů, což podmiňuje otevření nových poboček a přijetí nových zaměstnanců. Z toho vyplývá i nárůst počtu operací a zpracovaných dat, na které ovšem současný IS není navržen. Co se týká podnikových procesů a požadavků uživatelů, společnost ibanked, a.s. potřebuje sledovat obrat a další finanční ukazatele jednotlivých poboček, aby mohla hodnotit finanční výkonnost firmy. Dále si žádá možnost vstoupit do databáze zaměstnanců, klientů a účetnictví za účelem vypsání reportů. Společnost ibanked, a.s. klade důraz na správu klientů v informačním systému a jejich jednotlivé produkty, taktéž na správu produktů samotných. Tyto údaje si představuje uchovávat v přehledné formě, kdy pracovníci jednotlivých oddělení budou mít možnost tyto databáze spravovat. Také informace o svých zaměstnancích potřebuje ukládat do databáze včetně správy ID karet a přístupu zaměstnanců do sítě. Dále je nutné, aby na pobočkách společnosti i BANKed, a.s. měl systém přístup do správy klientů, aby mohly proběhnout požadované transakce klientem (například výběr z účtu, zadání platby atd.). Společnost i BANKed, a.s. by také ráda zavedla online komunikace mezi vedením a pobočkami, mezi jednotlivými odděleními a mezi jednotlivými zaměstnanci pro zjednodušení a zefektivnění spolupráce. Mělo by se jednat především o videokonference, školení, porady, upozornění, atd. 1.2. Návrh dalšího postupu Jelikož současný IS má nekomplexní strukturu a skládá se z několika modulů, které mezi sebou nejsou z větší části provázány, jeví se jako nejefektivnější řešení vytvořit zcela nový jednotný IS, který nejenže vyřeší problémy stávajícího IS, ale zároveň i firmě nabídne možné řešení vzhledem k jejímu budoucímu růstu. Navrhovaný IS pokrývá šest klíčových podnikových oblastí společnosti ibanked, a.s., a to vedení, správa klientů, správa produktů, personální, pobočka a komunikace. Ovšem vzhledem k tomu, že současné řešení IS je neefektivní především z důvodu nekomplexní struktury a zároveň s přihlédnutím k ekonomické stránce řešení, bude velmi výhodné použít v novém IS mzdový a účetní modul ze stávajícího IS. Jejich plná integrace v novém IS zajistí maximální využití, které bude dostačující jak pro současnou situaci, tak i pro budoucí stav. Zbylé moduly budou zcela nahrazeny novým IS.
2. Analýza současného stavu IS/ICT Největší slabinou současného IS je jeho nekomplexní struktura. Skládá se z několika modulů, které mezi sebou nejsou z větší části provázány. Především neprovázanost účetního (Pohoda 2010), mzdového (Okmzdy) a personálního (Target2100) systému vedou k neefektivní práci a prodlužovaní procesů uvnitř firmy. Ani systém pro správa klientu (icube) už nevyhovuje stále se rozšiřujícímu portfoliu služeb firmy. 2.1. Kontextový diagram
2.2. Zhodnocení průběhu podnikových procesů 2.2.1. Založení účtu Proces založení účtu začíná žádostí o založení účtu. Jako prvním podprocesem zde je Ověření náležitosti dokumentů, kde kromě kontroly totožnosti klienta probíhá i kontrola jeho podpisových vzorů a formuláře pro založení účtu. Kontrolu podpisových vzorů by bylo vhodnější provádět až při samotném založení účtu, protože při neúspěšné identifikaci klienta či špatně vyplněném formuláři k založení účtu vůbec nedojde a kontrola podpisových vzoru, tak zbytečně zatíží proces. Dále v případě, že žadatel o účet ještě není klientem banky, proces končí, v jiném procesu dojde k založení klienta a proces založení účtu startuje znovu od začátku, což vede nejen k prodloužení doby trvání procesu, ale především dlouho čekající zákazník je nespokojený zákazník. Z toho důvodu je nutné do procesu zakomponovat podproces vytvoření klienta, který pak přímo naváže na založení účtu, jako je tomu v případě, že validace klienta a formuláře proběhne úspěšně. Samotné založení účtu pak obsahuje procesy založení účtu, vytvoření smlouvy, podepsaní smlouvy klientem a vytvoření účtu v systému, které jsou spolu velmi úzce spojeny a daly se spojit v jeden, což opět povede jak k rychlejšímu průběhu procesu, tak i k většímu pohodlí klienta. 2.2.2. Výběr z běžného účtu Proces výběru z běžného účtu probíhá na základě obdržení příkazu k jednorázové platbě. Proces probíhá správně bez zbytečných průtahů, které by vedly ke zpomalování průběhu procesu. Po kontrole správnosti údajů se proces buďto ukončí, jestliže byly zjištěny nějaké nevalidní údaje nebo se přejde k další kontrole týkající se zůstatku na účtu klienta. Pokud má klient zůstatek odpovídající příkazu k platbě, je platba přijata, v opačném je klient upozorněn na nedostatek finančních prostředku k provedení platebního příkazu. 2.2.3. Zrušení účtu Proces zrušení účtu probíhá od přijetí žádosti o zrušení účtu. Samotný proces přijetí žádosti, by bylo vzhledem k zefektivnění a zrychlení procesu vynechat, protože celý tento proces vlastně startuje přijetí žádosti. Kromě záporného výstupu kontroly totožnosti klienta, která správně probíhá jako první a ukončuje proces v případě neidentifikace klienta, by i zde na základě procesu Kontroly zůstatku měl existovat záporný výstup ukončující proces v případě, že klient bude na svém účtu v debetu. Rušení samotného účtu pak ještě obsahuje procesy smazání účtu ze systému, vytvoření dokladu o zrušení účtu a předání dokumentů klientovi, které v případě spojení v jeden proces, se stanou efektivnějším především z hlediska délky trvání procesu. 2.2.4. Žádost o úvěr Při žádosti o úvěr je třeba vědět poměrně podrobné údaje o klientovi. Je tedy třeba vést DB klientů, ve které budou zjištěné osobní údaje, údaje o příjmu apod. Zároveň je třeba zvážit rizika spojená s dluhy klienta, proto navrhujeme držet údaj o zadluženosti ve stejné DB, popř. pro zamezení duplikace si je stahovat z DB dlužníků. Též je třeba vědět, zda již klient využívá služeb banky, neboť úvěr lze čerpat pouze na účet u ibanked a.s. V systému je zároveň třeba mít předpřipravené návrhy následujících dokumentů, jež nám poskytnout konzultant IS: Návrh úvěru, vzory smluv k založení úvěru, smluvní podmínky úvěru. Z našeho pohledu je úzkým místem procesu fakt, že bez ohledu na
způsobilost klienta pro obdržení úvěru je mu nabízen účet, na což může být nahlíženo klienty negativně. ibanked, a.s. ovšem náš návrh zamítli. 2.2.5. Čerpání úvěru Při čerpání úvěru je třeba čerpat ze smluvních podmínek termíny splátek a klienta upozornit. Úzké místo jsme nalezli v kontrole využití úvěru, která při jakémkoliv využití úvěru průběh schválila. Byla tak přidána další větev procesu, který ve firmě probíhá. Klientovi jsou odeslány postupně 3 upomínky k doložení korektních dokladů o správném využití úvěru, při nedodání je pak podána žádost o exekuční řízení. 2.2.6. Splácení úvěru Proces splácení úvěru je v současnosti velmi dobře optimalizován, v systému bude třeba kontrolovat proběhlé platby a podat možnosti k žádosti o změnu/prolongaci úvěru. 2.2.7. Ukončení úvěru Proces ukončení úvěru je též z našeho pohledu zoptimalizován, systémově je oproti již implementované funkcionalitě nutné ukládat data o vyplácení do registru klientů. 2.2.8. Výběr z termínovaného účtu Ve srovnání se současným systémem se technicky výběr z termínovaného účtu příliš neliší od výběru z běžného účtu. Vznikají ovšem zbytečné průtahy z důvodu neprovázanosti systému icube a personálního systému. V kontextu rozšíření portfolia společnosti ibanked je třeba zajistit nový systém, který bude zajišťovat plnou provázanost mezi databázemi. 2.2.9. Vystavení kreditní karty Současný systém neposkytuje možnost vydávání kreditních karet, což veškerý průběh procesu zpomaluje a zneefektivňuje. Je třeba tedy v rámci IS vytvořit modul ke správě kreditních karet, který bude propojen s daty běžných účtů. Podobně jako hesla i údaje o kreditní kartě je pro minimalizaci bezpečnostních rizik třeba šifrovat. 2.2.10. Vytvoření spořicího účtu Vytvoření spořicího účtu probíhá na základě podání žádosti pro zřízení. Po ověření totožnosti klienta následuje na základě žádosti proces definování požadavku na spořicí účet. V případě, že identifikace uživatele neproběhne úspěšně, procesu definování požadavku předchází ještě proces vytvoření klienta. Po definování parametrů pro spořicí účet, následují procesy příprava smlouvy, podepsání smlouvy a zaevidovaní účtu v systému, které se dají shrnout do jediného procesu (např. uzavření smlouvy), a tím urychlit vyřízení požadavku, což povede ke spokojenosti obou stran. 2.2.11. Zrušení spořicího účtu Zrušení spořicího účtu probíhá na základě podání žádostí o zrušení. Zrušení dále pokračuje ověřením, zda-li uživatel, který žádost podal, je klientem banky a vlastní-li vůbec spořicí účet. Pokud ano, je nutné ověřit, jestli uživatel nemá nějaké nesplněné závazky vůči bance. Při nesplnění, některých z těchto požadavků chybí upozornění/zpráva pro klienta/uživatele, která by jej informovala o zamítnutí žádosti a o důvodech, které k zamítnutí vedly. Při splněných podmínkách, následují procesy
podepsání smlouvy a zrušení účtu, které se dají shrnout do jediného procesu a tím urychlit vyřízení požadavku, což povede ke spokojenosti obou stran. 2.3. Technologická infrastruktura 2.3.1. Hardware Systém bude vyvíjen na bázi tenkého klienta a požadavky na HW se proto dají rozdělit do následujících kategorií: Databázový server Webový server Klientská zařízení Hardwaru, který má již zákazník k dispozici: Notebook Lenovo ThinkPad X1 Carbon 3448-24G Desktopové počítače (Intel DualCore E4200, 1GB RAM, GeForce 5500FX, Win XP Professional) Server DELL PowerEdge T310 Vzhledem k použití tenkého klienta nebude problém s využitím stávajících osobních počítačů. Naopak, k aplikaci bude možné přistupovat také z mobilních telefonů či tabletů. Problém nastává se servery DELL, kterých má zákazník 50 kusů. Jejich konfigurace bude dostatečná pro využití jako webový server, ovšem využije se jen několik kusů. Zbytek se může využít jako záložní zdroje. Pro databázový server bude třeba pořídit zcela nové řešení s důrazem na škálovatelnost. Ideální by byla racková forma serveru, například platforma Blade, v kombinaci s diskovým polem. Zákazník uvádí, že očekává významný růst klientů, který bude nutně spojen s nárůstem vytížení databázového serveru jakožto zdroje dat. Proto je škálovatelnost maximálně důležitá. Druhou možností pro databázový server je využít cloudových služeb třetích stran, například Microsoft Azure. Zde je úroveň flexibility ještě o úroveň vyšší, než u blade serverů. Zvýšit výkon je možné prakticky okamžitě a daly by se takto vyřešit jak špičky ve využívání systému, tak rychlý nárůst klientů. Další výhodou je záruka dostupnosti, kdy se o celý systém stará dodavatel a má odpovědnost za bezvadný chod. Nevýhodou může být paušální forma financování, kdy zákazník platí každý měsíc částku za využitý výkon. Jako ideální řešení bychom zvolili využití obou výše zmíněných. V počáteční fázi, kdy se očekává významný nárůst jak funkcí a služeb systému, tak klientů využívající tyto služby, by se využili PaaS třetí strany. Po zavedení a uklidnění situace se zařídí vlastní datové centrum. 2.3.2. Software Obecně pro celé řešení budou použity technologie od firmy Microsoft. Webový server poběží na MS Server 2012 a IIS 7.5. Databázový server se bude nejdříve outsourcovat a poté poběží na MS SQL Server 2012. Konečná aplikace bude testovaná pro Internet Explorer, ale měla by být kompatibilní i s ostatními prohlížeči, včetně mobilních pro Android a ios.