ebanka a co Případová studie ebanky

eBanka a co dál…? Případová studie eBanky

Program: 1. Úvod Představení přednášejícího Struktura přednášky

2. eBanka (dříve Expandia Banka, dnes eKonto) případová studie 3. Role IT v (elektronické) bance 4. Budoucnost bankovních IS 5. Závěr

1. Představení přednášejícího • Ing. Jiří Kašpar • CT-Group, a.s. • 1982-1989 odborný pracovník na FJFI ČVUT • od 1990 soukromé podnikání v oblasti IS • 1995-2001 účast na projektech informačních strategií ve finančních institucích a energetických společnostech • 1997-1998 vedoucí analýzy IS Expandia Banky (dále eBanka, dnes eKonto) • 1999-2003 vedoucí analýzy ASP projektů CT-Group • 2008-2009 vedoucí projektu xBanky

Úvod • Struktura přednášky –Situace • Nekonfliktní vstupní tvrzení, u kterých se dá předpokládat, že s nimi většina posluchačů souhlasí

–Komplikace • Při bližším pohledu to není tak jednoduché

–Otázky • Seznam otázek, ke kterým situace a komplikace vedou a kterými se chceme zabývat

–Odpovědi • Náš názor na položené otázky

Program: 1. Úvod 2. eBanka (dříve Expandia Banka, dnes eKonto) případová studie 3. Role IT v (elektronické) bance, 4. Budoucnost bankovních IS 5. Závěr

Program:

• Program: • 2. eBanka (Expandia Banka) - případová studie • 2.1 Úloha vlastníka podnikatelského záměru • 2.2 Zadání, tj. specifikace požadovaných vlastností IS bez znalosti konkrétních produktů banky • 2.3 Komponenty IS elektronické banky • 2.4 Role datového modelu jádra transakčního systému, • 2.5 Vrstvy datového modelu, • 2.6 Bezpečnost dat • 2.7 Datový model a řízení projektu vývoje IS

2.1 Situace: • Vlastník podnikatelského záměru je důležitou osobou a má co mluvit do zadání i průběhu řešení • Spokojenost vlastníka s výsledkem je pro osud díla klíčová

2.1 Komplikace • Vlastník většinou pouze tuší co chce (má vizi) a neví, co k tomu potřebuje. Jeho představa se mění s průběhem projektu. • V praxi nepůsobí uznané metodiky umožňující předat vizi vlastníka v kontrahovatelné formě • Vlastník většinou nemá čas a proto deleguje svou kompetenci (vždy však jenom část) na podřízené. –Mají jiné motivy než vlastník. Primárně se věnují „krytí svých zad“ –Jejich schopnost zastupovat vlastníka je omezená

2.1 Otázky: • Jak získat zadání ? • Jak zajistit jeho zpřesňování ? • Jak předat výsledek ?

2.1 Odpověď: • Otázka: Jak získat zadání ? • Odpověď: Nelze získat zadání bez vlastního přičinění. Je třeba jej společně vytvořit a odsouhlasit. • Otázka: Jak zajistit jeho zpřesňování ? • Odpověď: Projektový tým by měl být kombinovaný, tvořený řešiteli a zástupci zadavatele. • Otázka: Jak předat výsledek ? • Odpověď: Nelze mít předávací kritéria na začátku. Součástí prací musí být proto vytvoření akceptačního scénáře.

2.1 Odpověď: • eBanka: – Projekt navazoval na informační strategii finanční skupiny – Vlastník záměru měl velmi vysokou motivaci a ve věcech IS dal na „cizí lidi“, se kterými ale měl dobrou zkušenost z předcházejících projektů – Vlastník měl licenci a nefungující Zemskou banku. Měl vizionáře a neměl bankéře – Na trhu nebyl IS, který by byl schopen podpořit její podnikatelský záměr – Okolí (ČNB) po nich chtělo, aby se co nejrychleji začali jevit jako fungující banka – Časový faktor hrál v podnikatelské strategii klíčovou roli – Zadání vznikalo z pohledu klienta banky. Podpora vnitřních procesů se brala jako nekritická a vlastník se spolehl na know-how řešitelů. – Před finálním rozhodnutím vlastník investoval do analytického projektu, který umožnil zevrubně popsat informační systém a naplánovat projekt. – Celý vývoj se odehrával uvnitř banky a pod denním dohledem zadavatele.

2 Program:


2.2 Situace: • Vývoj se odehrává v řetězci analýza programování - testování • Chceme-li od někoho něco, musíme mu říci co. V případě vývoje to musíme říci analytikovi, programátorovi i testerovi.

2.2 Komplikace • Banka neměla zaměstnance, neznala své produkty, neměla popsané procesy. Zadavatel neměl nikoho, kdo by byl schopen zadání stanovit. • Termín otevření banky byl velmi krátký. Nešlo čekat na dobu, kdy bude vše rozmyšlené a připravené.

2.2 Otázky: • Je za těchto okolností vůbec možné zahájit vývoj IS ? • Jak to udělat, aby se věci nemuseli předělávat v okamžiku, kdy se objeví „reálný odběratel“ s vlastní představou ?

2.2 Odpověď: • Otázka: Je za těchto okolností vůbec možné zahájit vývoj IS ? • Odpověď: Je to možné, dobrý IS nevychází z uživatelských požadavků, pouze je umožňuje realizovat • Otázka: Jak nepředělávat.. ? • Odpověď: Uživatelé v podstatě nemohou překvapit a je možné na ně být předem připraven. Je jenom třeba předem vědět, z čeho bude uživatel vybírat.

2.2 Odpověď: • eBanka: • Vycházelo se z pochopení společných rysů všech bankovních produktů doplněného o požadavky přímého bankovnictví: – účet a jeho vlastník – transakce a její zabezpečení – informace o transakci

• Oddělení komunikačních kanálů od transakčního jádra systému. V jádře už není důležité, jakým kanálem požadavek přišel. • Analytický tým se přímo účastnil tvorby produktů a popisu procesů ⇒ seznamoval pracovníky banky s možnostmi systému a neměl potom problém s tvorbou zadání

2 Program:


2.3 Situace: • Rozdělení IS do relativně nezávislých komponent je rozumné (tzv. federativní architektura IS). Základní výhodou je možnost odděleného vývoje. Komponenta je charakteristická: – Samostatným datovým modelem – Minimem vnějších vazeb – Je dostatečně malá a přehledná

2.3 Komplikace • Princip federativní architektury bývá zpochybňován s tím, že dnes se již vyvíjí jinak (objektové technologie).

2.3 Otázky: • Je vůbec třeba členit systém elektronické banky na komponenty ? • Jestliže ano, jaké komponenty to jsou ?

2.3 Odpověď: • Otázka: Je vůbec třeba členit systém elektronické banky na komponenty ? • Odpověď: Zcela určitě. Především proto, že byla zřejmá potřeba budoucích úprav systému a členění na komponenty snižuje rizika • Otázka: Jaké komponenty ? • Odpověď: – Registrace a distribuce požadavků – Jádro transakčního systému – CRM

2.3 Registrace a distribuce • Vlastní datové struktury • Funkce – Evidence požadavků na systém • Transakční požadavky • Netransakční požadavky

– Formální kontrola požadavků • • • •

Účty Syntaktická pravidla Datumové údaje …

– Předání k dalšímu zpracování

2.3 Jádro transakčního systému • Realizace požadavků • Dávkové úlohy • Notifikace • Komunikace s okolím – – – –

Clearing Platební karty Zahraniční platební styk Účetnictví

• Reporting

2.3 CRM • Evidence klientů • Kontakty s klienty – – – –

z iniciativy klienty z iniciativy banky produktové procesy kontrola kvality procesů

• Reporting

Program:

• Program: • 2. eBanka (Expandia Banka) - případová studie • 2.1 Úloha vlastníka podnikatelského záměru • 2.2 Zadání, tj. specifikace požadovaných vlastností IS bez znalosti konkrétních produktů banky • 2.3 Komponenty IS elektronické banky • 2.4 Role datového modelu jádra transakčního systému • 2.5 Vrstvy datového modelu, • 2.6 Bezpečnost dat • 2.7 Datový model a řízení projektu vývoje IS

2.4 Situace: • Bankovní systém je typickým představitelem IS systémů postavených na databázích. Schopnost pamatovat si historii je nejdůležitějším požadavkem. • Každé řešení postavené na databázi musí mít dobře promyšlený a zdokumentovaný datový model

2.4 Komplikace • Je málo co nebezpečnějšího, než měnit datový model u provozované aplikace • Rozvoj produktů však změnu vyžaduje • Bankovních produkty nejsou jenom běžné účty, termínované vklady a půjčky. –Akreditivy –Garance –Blokace –Platební karty –… –a stále se vyvíjejí

2.4 Otázky: • Jaké má datový model postavení v rámci analýzy a návrhu ? • Jak spojit požadavek na stálost s požadavkem na rozvojeschopnost ?

2.4 Odpověď: • Otázka:Jaké má datový model postavení v rámci analýzy a návrhu ? • Odpověď 1: Správně navržený DM je podmínkou nutnou, nikoliv postačující. Chyby v DM na úrovni entit a kardinality vazeb se nejhůře odstraňují. Poznámka:Při práci na DM jsme si museli dokonce vytvořit vlastní teorii, kterou jsme následně používali pro ověřování správnosti modelů.

• Odpověď 2: DM musí být postaven na fundamentálním pochopení modelované oblasti, nikoliv na požadavcích uživatelů. DM je výsadní území analytiků. Poznámka:Datové modely se velmi špatně předávají zadavateli. Je to velmi abstraktní část řešení.

• Odpověď 3: DM je základem morální odolnosti řešení

2.4 Odpověď • eBanka: • DM vznikl na základě dvou zdrojů: – IDM komponenty Obchodní systém z informační strategie skupiny – Zkušenost z práce na bankovních systémech (DM pro eBanku byla 3. generace)

• Otázka:Jak spojit požadavek na stálost s požadavkem na rozvojeschopnost ? • Odpověď 1: Je třeba oddělit analýzu od návrhu. Z analýzy vzniká pouze základní kostra logického DM, která se v dalším průběhu již nesmí měnit (pouze se řekne, že lebka je posazena na krční páteři, musí mít díry pro oči, nos a uši, dolní čelist bude volně viset, atd.). • Odpověď 2: Čím je LDM jednodušší a symetričtější, tím lépe. Ukazuje se, že „krása“ E-R diagramu DM je jedním ze znaků jeho správnosti (vazby se nekříží, entity tvoří přirozené shluky,...). LDM vznikl ještě v předrealizační etapě. • Odpověď 3: Návrh funkcí doplňuje datový model pouze aditivně a v místech, kde již nehrozí kolize s jinými funkcemi. • Odpověď 4: Entity DM mají v podstatě 2 role: – Uchovávat klientská data (ty jsou velmi stálá) – Umožnit parametrizaci systému a automatizaci funkcí (ty se neustále doplňují a mění)

2 Program:

• Program: • 2. eBanka (Expandia Banka) - případová studie • 2.1 Úloha vlastníka podnikatelského záměru • 2.2 Zadání, tj. specifikace požadovaných vlastností IS bez znalosti konkrétních produktů banky • 2.3 Komponenty IS elektronické banky • 2.4 Role datového modelu jádra transakčního systému • 2.5 Vrstvy datového modelu • 2.6 Bezpečnost dat • 2.7 Datový model a řízení projektu vývoje IS

2.5 Situace: • Složité datové modely je vhodné nějak strukturovat, aby bylo možné se v nich vyznat • Strukturovatelnost je jedním ze znaků správnosti datového modelu • Existují 3 základní možnosti strukturování DM – podle funkcí (správa partnerů, bankovní výpisy, autentizace,...) – podle procesů (nadtypy plánování, předepisování, realizování) – podle role entity • Doklad x transakce x proces x věc • výskyt x pojem

2.5 Komplikace • Datový model je velmi rozsáhlý • Strukturování nesmí vést ke snížení vnitřní konzistence či ke zkomplikování jejího dosažení.

2.5 Otázky: • Jak strukturu DM dokumentovat ? • Kdy strukturu založit a jak ji udržovat ?

2.5 Odpověď: • Otázka: Jak strukturu DM dokumentovat ? • Odpověď: Modelovací nástroj je naprosto nezbytný. Bez něj nelze dokumentaci DM zajistit. – DM funkcí dokumentujeme pomocí subsetů DM – Vrstvy DM z pohledu procesů definujeme mapováním entit na procesní model – Vrstvy DM z hlediska role definujeme kategorizací entit

• Otázka: Kdy strukturu založit a jak ji udržovat ? • Odpověď: Vrstvy musí být dokumentovány od začátku a to ze 2 důvodů: – Strukturování pomáhá ověřovat správnost a zvyšuje srozumitelnost pro všechny účastníky – Zpětně to je zřejmě nerealizovatelné (nevejde se to do projektu, formální výsledek)

2.5 Odpověď • eBanka: • Subsety DM z pohledu funkcí vznikají samozřejmě jako součást zadání do implementace. Je to striktní požadavek přijaté projektové normy • Mapování entit na procesy bylo prováděno v počátcích vývoje, kdy byl řešitelský tým pod obrovským tlakem a potřeboval sám sebe ujišťovat, že má vývoj pod kontrolou. • Vytváření vrstev z hlediska role bylo důležité na počátku a také se provádělo. V současné fázi naprostá většina nových entit je typová a patří do vrstvy parametrizace a automatizace.

Program:


2.6 Situace: • Odborníci považují bezpečnost dosažitelnou na elektronických kanálech za vyšší než klasickou • Z teoretického hlediska je bezpečnost vyřešenou věcí. • Nejběžnějším způsobem „elektronických“ podvodů jsou podvody s platebními kartami

2.6 Komplikace • Elektronické bankovnictví je laickou veřejností stále vnímáno jako méně bezpečné než klasické • Zadavatel je také laik a považuje vnímání nebezpečí ze strany veřejnosti za fatální překážku ⇒ • Základním problémem není faktická bezpečnost, ale pocit bezpečnosti

Otázky: • Jaká jsou slabá místa klasické a elektronické bezpečnosti z pohledu klienta ? • Kde je banka nejvíce zranitelná ? • Jak to udělat, aby banka byla nejenom teoreticky, ale i prakticky bezpečná ? • Jak klienta přesvědčit, aby bezpečnostním nástrojům banky věřil ?

Odpověď: • Otázka:Jaká jsou slabá místa klasické a elektronické bezpečnosti z pohledu klienta ? • Odpověď: – Klasická bezpečnost je postavena na ověření ručního podpisu a totožnosti osoby při předávání platebních příkazů (nad 100.000 Kč). Slabým místem je snadná dostupnost podpisů a relativně snadná zfalšovatelnost dokladů. Podvod lze provést bez fyzického kontaktu s klientem. – Elektronická bezpečnost je postavena na šifrování, certifikaci a nedostupnosti šifrovacích klíčů. Slabým místem je laxnost při péči o PIN.

2.5 Odpověď • Otázka: Kde je banka nejvíce zranitelná ? • Odpověď: – Zcela určitě zevnitř. Většinou jde o chyby a teprve pak přicházejí na řadu podvody. – Bezpečnost IS tedy musí řešit nejenom problém napadení zvenčí, ale především musí předcházet chybám a z hlediska autorizace transakcí musí považovat pracovníky banky za normální klienty.

2.5 Odpověď • Otázka: Jak to udělat, aby banka byla nejenom teoreticky, ale i prakticky bezpečná ? • Odpověď: – Využití standardních bezpečnostních technologií – Dokonalé procesní zabezpečení bezpečnosti – Fyzické oddělení nástroje umožňujícího přístup do systému a nástroje pro autorizaci a certifikaci. – Výchova klientů k bezpečnému chování.

2.5 Odpověď • Otázka: Jak klienta přesvědčit, aby bezpečnostním nástrojům banky věřil ? • Odpověď: –Klienta nelze přesvědčit odbornými důvody –Klient se spokojí s tím, že se to tak „normálně dělá“ (viz platební karty) –Situace se stále zlepšuje. Elektronické bankovnictví je již vnímáno ne jako experiment, ale jako jedna ze služeb –Je dobré vyprávět příběh, který názorně bezpečnostní mechanismy předvede.

Program:


2.6 Situace: • Chceme-li vytvořit IS, musíme naplánovat realizační projekt • Chceme-li IS rozběhnout, musíme naplánovat vytvoření infrastruktury • Chceme-li zavést IS do provozu, musíme naplánovat jeho zavedení •⇒ • Musíme plánovat

2.6 Komplikace • Nevíme co máme plánovat, protože máme pouze velmi hrubou představu o rozsahu projektu (jsme ještě před analýzou) • Variabilní část ceny projektu vychází z kapacitní náročnosti. Zadavatel přitom nerad platí více než je nutné a řešitel nemůže podcenit odhad náročnosti projektu • Zadavatel chce rychle výsledky

2.6 Otázky: • Jak odhadnout náročnost projektu ? • Jak naplánovat projekt ? • Jak řídit projekt ?

2.6 Odpověď: • Otázka: Jak odhadnout náročnost projektu ? • Odpověď: – Náročnost projektu koreluje s počtem entit logického datového modelu. Každou entitu je totiž třeba obsloužit nějakou funkcionalitou. Vytvoření této funkcionality vyžaduje kapacity a čas. – Funkční model ze značné části vychází z potřeby správy entit (cca 70%). Podpora procesů je zastoupena v podstatně menší míře. – Základním zdrojem pro odhad náročnosti je proto zjednodušený logický DM. Entity rozdělíme do skupin podle složitosti na jednoduché, středně složité a složité. Ke každé skupině určíme kapacitní náročnost.

Odpověď: • Otázka: Jak naplánovat projekt ? • Odpověď: – Na základě zjednodušeného DM a procesního modelu 1. a 2. úrovně je třeba vytvořit funkční model. – Ke každé funkci stanovíme kapacitní a časovou náročnost na návrh, implementaci a testování. – Vytvoříme základní projektový plán vycházející z konečného termínu, nutného pilotního provozu a konsolidovaného testování na konci a datové a procesní analýzy na začátku. Mezi se snažíme vtěsnat realizaci funkcí ⇒ vyjde nám potřeba paralelismů a časový průběh kapacitní náročnosti realizace. K té se připočte kapacita pro řízení.

Odpověď: • Otázka: Jak řídit projekt ? • Odpověď: – Na základě projektových standardů. Ty musí vzniknout hned na začátku a musí odrážet „best practise“ projektového řízení, reálie projektu a schopnost projektového týmu. – Projektové řízení není dogma a existuje spousta cest, jak se dostat ke kvalitnímu výsledku. Některými body však musí všechny cesty vést a všichni musejí hrát podle stejných not a za stejný tým. Smyslem projektového řízení je dávat noty, plánovat, vyhodnocovat a stmelovat tým.

2.6 Odpověď •eBanka: –Projekt nového bankovního systému na zelené louce –Zahájení vývojových prací 7.7.1997, otevření pro veřejnost 4.5.1998 –Ostrý provoz klientského systému od 1/1998 pro členy vývojového týmu a některé pracovníky banky –Ostrý provoz pro pracovníky banky od 3/1998 –Vysoká kapacitní a časová náročnost na usazení nového IS do prostředí v ČR (clearing, výkaznictví, platební karty, účetnictví, IS Zemské banky).

Program:

1. Úvod 2. eBanka (dříve Expandia Banka, dnes eKonto) případová studie 3. Role IT v (elektronické) bance 4. Budoucnost bankovních IS 5. Závěr

3. Situace: • Dnes jsou všechny banky fatálně závislé na fungování IS • Banky se snaží snižovat náklady a elektronické komunikační kanály jsou pro to vhodným prostředkem • Banky se snaží odlišovat od konkurence specifickými vlastnostmi produktů a vytvářením balíčků služeb. To vše musí mít podporu v IS. • Produkty musí být prodány klientům

3. Komplikace • IS v bankách již existují a ve většině případů je velmi obtížné chtít od nich něco jiného, než k čemu byli vytvořeny. • Orientace na klienta je hitem posledních let a starší bankovní IS ji jaksi opomíjejí. Jsou to spíše účetní systémy. • Požadavek na otevřenost bankovního systému a jeho automatické chování je stále vnímán jako podezřele kacířský.

3. Otázky: • Je možné vybudovat nové služby nad starými systémy ? • Jakou roli má hrát IT ? • Co vlastně má umět tvůrce bankovního systému ?

3. Odpověď:

• Otázka: Je možné vybudovat nové služby nad starými systémy ? • Odpověď: – Ano, s jistými omezeními. Nové služby se týkají především: • práce s klienty a k tomu jsou tak jako tak potřeba nové komponenty (CRM) • nové komunikační kanály a ty lze relativně snadno otevřít • kombinace produktů a cross-selling. To vyžaduje vyšší otevřenost základního systému a zde může nastat omezení.

– Původní systém je třeba překrýt aplikační nadstavbou, která vytvoří pseudo-interaktivní rozhraní. Nadstavba by měla mít i určitá vlastní data z vrstvy DM Parametrizace a automatizace. – Omezení jsou dána nepřekročitelnými vlastnostmi základního systému (např. jednodenní vnitřní zúčtování)

3. Odpověď: • Otázka: Jakou roli má hrát IT ? • Odpověď: – Banky nesmí být IT driven, ale business driven – Samoúčelného nasazování IT bylo již dost a proto jsou dnes top manažeři opatrní v rozhodování o dalších investicích. Prestiž útvarů IT je dnes nižší než dříve. – Úsek IT se musí snažit, aby byl schopen na každý rozumný obchodní nápad říci „No problem“. – Úsek IT by měl inspirovat, nikoliv tlačit – Úsek IT není software house. Musí být ale důstojným partnerem a zadavatelem.

3. Odpověď: • Otázka: Co vlastně má umět tvůrce bankovního systému (analytik) ? • Odpověď: – Musí zevrubně znát, o čem banka vlastně je, jaké vnitřní procesy v ní probíhají a kdo stanovuje jejich pravidla. Nesmí chodit hlavou proti zdi. – Musí mít nadhled. Všechno co od zadavatele slyší, musí prověřovat proti tomu co slyšel předtím, vlastnímu konceptu, zažité praxi, trendům atd. – Musí mít úctu k zadavateli a jeho odbornosti. – Musí vidět na 2 roky dopředu z hlediska trendů produktů.

Program:

1. Úvod 2. eBanka (Expandia Banka) - případová studie 3. Role IT v (elektronické) bance 4. Budoucnost bankovních IS 5. Závěr

4. Situace: • Bankovní služby jsou z informačního hlediska velmi jednoduché (až primitivní). Přitom jsou pouze prostředkem k uspokojení potřeb (zaplacení). Nemají vlastní užitnou hodnotu. • Bankám i v oblasti platebního styku a financování vzniká konkurence, která nabízí komfortnější služby • Tradiční finanční sektor (banky, investiční společnosti, burzyˇ,…) je v krizi důvěry

4. Komplikace • Podnikání v bankovnictví je svázáno velmi striktní legislativou, která ho znevýhodňuje vůči nebankovním subjektům • Banky procházejí procesem koncentrace zahrnujícím i jejich BIS

4. Otázky: • Může BIS pomoci při překonání hendikepu bank vůči „neregulovanému“ trhu ? • Kterým směrem by se měl rozvoj BIS ubírat?

4. Odpověď: • Otázka: Může BIS pomoci při překonání hendikepu bank vůči „neregulovanému“ trhu ? • Odpověď 1: – Přes všechny potíže jsou vnímány jako přirozený podnikatelský subjekt pro univerzální zprostředkování plateb. Za zprostředkování platby si ovšem nelze říci o příliš velkou odměnu, protože jde o primitivní službu. Platba se tedy musí odehrát za situace, kterou klient považuje za pro něj výhodnou ⇒ služba musí být poskytnuta v souvislosti s obchodním procesem a klient jejím využitím musí získat něco, za co je ochoten utratit peníze. To dnes bohužel ještě není čas. BIS je ale podmínkou nutnou pro provázání bankovnictví s obchodním procesem.

• Odpověď 2 – Bankovnictví je regulovaný trh pod silným dohledem (alespoň u nás). Díky tomu ale mají pro některé služby exkluzivitu. Služby, jejichž součástí je správa vkladů nebo investování, mohou být poskytovány pouze bankou nebo ve spolupráci s bankou (resp. se subjektem s „bankovní“ licencí). Bankovní služby jsou ze své povahy službami informačními a proto vyžadují BIS. Bez něj to nejde.

4. Odpověď: • Otázka: Může BIS pomoci při překonání hendikepu bank vůči „neregulovanému“ trhu ? • Odpověď 3: – Úspěch banky je závislý na jejím úspěchu u klientů – Internetbanking zkrátil cestu klienta do banky • ale mají ho všichni a prakticky stejný • neobsahuje reálný kontakt s pracovníkem banky • klient je odkázán sám na sebe (pomož si sám)

– Můžeme zkrátit cestu banky ke klientovi • Pracovník banky musí být mobilní a potřebuje BIS ⇒ potřebuje mobilní BIS ⇒Koncept internetbankingu je třeba aplikovat na vnitřní IS banky nebo alespoň na jeho část.

Program: 1. Úvod 2. eBanka (Expandia Banka) - případová studie 3. Role IT v (elektronické) bance 4. Budoucnost bankovních IS. 5. Závěr

ebanka a co Případová studie ebanky

Recommend Documents