Infrastruktura a aplikační software korporátní banky

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

Infrastruktura a aplikační software korporátní banky Bakalářská práce

Autor:

Miroslav Šalanský Informační technologie, manaţer projektů IS

Vedoucí práce:

Praha

doc. Ing. Bohumil Miniberger, CSc.

březen 2011

Prohlášení: Prohlašuji, ţe jsem bakalářskou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Měchenicích dne 31. 3. 2011

Miroslav Šalanský

Poděkování Rád bych touto formou poděkoval panu doc. Ing. Bohumilovi Minibergerovi, Csc. za odbornou přípravu a pomoc při řešení problémů, za věnovaný čas, za rady k postupům vypracované práce a konzultace s ní spojené. Dále bych chtěl poděkovat svým blízkým za trpělivost a podporu, kterou mi věnovali během studia.

Anotace ŠALANSKÝ, M. "Infrastruktura a aplikační software korporátní banky" bakalářská práce. Praha, Katedra matematiky, statistiky a informačních technologií. Bakalářská práce se zabývá popisem infrastruktury a podporou IT/ICT korporátní banky, který bude popsán pomocí informační knihovny ITIL a jazyka UML. Banka, která je cílem zkoumání, prošla velmi zásadní změnou podpory ICT, proto se tato práce zaměří na popis obou modelů podpory, jak původního tak současného. Na základě průzkumu, je navrţeno optimální řešení modelu podpory, jak uţivatelů tak i celé infrastruktury.

Annotation ŠALANSKÝ, M. "Infrastructure and application software of corporate bank" Bachelor Thesis. Prague, Department of Mathematics, Statistics and Information Technology. This thesis is dealing with the description of the infrastructure and support of

IT/ICT

corporate bank, which will be described in terms of information library ITIL and UML language. The bank, which is under research, has done major change in the ICT support model, so this work will focus on the description of both support models, the previous and a current. There is designed new optimal solution of support model based on the survey , for both users and the entire infrastructure.

Obsah Úvod ........................................................................................................................................... 6 1. Infrastruktura korporátní banky .......................................................................................... 9 1.1. Networking ............................................................................................................... 12 1.1.1. Lokální síť - LAN ............................................................................................... 12 1.1.2. Globální síť - GAN ............................................................................................. 13 1.1.3. Extranet Firewall ................................................................................................ 16 1.1.4. Lokální Firewall ................................................................................................. 18 1.1.5. IP telefonie.......................................................................................................... 19 1.1.6. Proxy server ........................................................................................................ 20 1.1.7. Standardy ............................................................................................................ 21 1.2. Hardware .................................................................................................................. 23 1.2.1. Servery ................................................................................................................ 23 1.2.2. WINTEL servery ................................................................................................ 23 1.2.3. UNIX servery ..................................................................................................... 26 1.2.4. Pracovní stanice .................................................................................................. 28 1.2.5. Standardní PC ..................................................................................................... 29 1.2.6. Trader PC............................................................................................................ 29 1.2.7. Tiskové řešení ..................................................................................................... 30 2. Aplikační Software ........................................................................................................... 32 2.1. Standardní software .................................................................................................. 32 2.2. Zakázkový software .................................................................................................. 34 2.3. Datové toky............................................................................................................... 40 3. Podpora ICT ..................................................................................................................... 43 3.1. Lokální model podpory ............................................................................................ 43 3.2. Globální model podpory ........................................................................................... 46 3.3. Průzkum spojenosti s poskytovanou podporou ........................................................ 49 Závěry a doporučení ................................................................................................................. 52 Seznam pouţité literatury ......................................................................................................... 54 Seznam pouţitých zkratek ........................................................................................................ 55 Seznam obrázků a tabulek ........................................................................................................ 56 Seznam tabulek ......................................................................................................................... 57

5

Úvod Vymezení tématu práce a členění Téma této bakalářské práce je Infrastruktura a aplikační software korporátní banky. Cílovou skupinou zákazníků korporátní banky jsou velké společnosti, proto označení korporátní. Můţeme se také setkat s označením "Wholesale banking". Toto vymezení je velmi důleţité, protoţe infrastruktura a aplikační software

takovéto banky se liší od banky pro běţnou

klientelu, jinak označovanou také jako "Retail banking". V úvodní části se zaměřím na popis síťové topologie pobočkové sítě v České republice včetně napojení do globální celosvětové sítě označované jako GAN1. Nedílnou součástí bude také přehled

veškerých

pouţitých termínů a

zkratek,

které se velmi často pouţívají

v komunikaci mezi IT specialisty. Druhá část této práce se bude zabývat pouţívanou výpočetní technikou. Konkrétně půjde o vybavení koncových stanic, WINTEL a UNIX serverů. Jedna z hlavních částí se bude zabývat pouţívaným aplikačním SW a to jak SW na zakázku, tak i standardním. V této části se zaměřím spíše na popis spojení všech aplikací do jednoho fungujícího celku. Budu se zabývat datovým tokem mezi aplikacemi včetně bezpečnosti a automatizace procesů sniţující chybovost při manipulaci s daty. V závěrečná část se bude zaobírat problematikou týkající se podpory jednotlivých oblastí IT technologií. "Outsourcing a Insourcing" bude jedním z hlavních témat.

Cíle práce Cílem mé práce je poskytnout

zájemcům o práci v bankovním sektoru informace

o infrastruktuře a aplikačním SW, včetně informací

týkajících se podpory všech těchto

oblastí. Tato práce přinese čtenáři pohled o fungování IT oddělení jako celku, včetně napojení na centrální management procesů a podpory. Dalším cílem je rozebrání a vliv outsourcingu na úroveň podpory velké nadnárodní společnosti s ohledem na spokojenost koncových uţivatelů s outsourcingovými sluţbami.

1

GAN - zkratka z anglického výrazu Global Area Network

6

Důvody výběru této práce Zájem o informační technologie v posledních dekádách stále roste, stejně jako roste zájem o práci v oblasti informačních technologií. Podle Českého statistického úřadu bylo v roce 1993 zaměstnáno pouze 59 800 lidí v oblasti IT. Nicméně poslední monitorovaný rok 2008 měl jiţ na svém kontě 110 800 IT odborníků jak uvádí zdroj [7]. Vzhledem k těmto faktům jsem se rozhodl pro výběr tohoto tématu, protoţe mám jiţ 16 let zkušenosti jako IT odborník a z toho 10 let v bankovním sektoru. Způsob dosažení práce Abych dosáhl stanovených cílů vytvořím několik názorných modelů a diagramů, které budou popisovat jednotlivé oblasti. Vyuţiji zde standardů, které jsem si během studia na Bankovním institutu osvojil. Oblasti, které budu čerpat z odborné literatury uvedu v seznamu pouţité literatury a informačních zdrojů. Pro popis infrastruktury vycházím z publikace „Informační systémy a jejich řízení“2 popisující metodiku MDIS3, která se v České republice pouţívá jiţ od roku 1992. Tato metodika se liší od ostatních především tím, ţe nepředepisuje detailně jednotlivé kroky vývoje informačního systému, ale je především návodem, jak smýšlet při vývoji informačního systému. Ve smyslu

této metodiky bude také demonstrována architektura informačního

systému banky. Pro vybraný příklad demonstrace sluţeb pro klienty korporátní banky jsou pouţity diagramy jazyka pro modelování procesů v jazyce UML 2.0. Omezení práce Vzhledem k povaze informací týkajících se banky, jsou některá data pozměněna či úmyslně vynechána, nicméně na práci tyto změny nemají vliv, neboť jde pouze o změny, které nebudou mít vliv na např. jiný adresní rozsah, atd. Definice korporátní banky Nejprve je nutné vymezit pojem Korporátní banka. Takto nazývané banky

mají svou

klientelu pouze mezi firmami, které po těchto bankách poţadují jiné sluţby neţ banky, které nabízejí sluţby pro širokou veřejnost.

Nicméně pokud řekneme, ţe ta či ona banka

je korporátní neznamená to, ţe poskytuje pouze sluţby firmám. Většina bank na našem trhu 2 3

Voříšek Jiří: Informační systémy a jejich řízení, skripta BIVŠ Praha 2007 MDIS vychází z anglického termínu "Multidimensional Development of Information System" 7

poskytuje jak sluţby pro korporátní klientelu, tak i pro širokou veřejnost. Tato bakalářská práce bude popisovat banku, která má výhradně korporátní klientelu a specializuje se pouze na největší zákazníky na trhu. Všechny informace a popisy se týkají pouze jedné banky a to konkrétně "The Royal Bank of Scotland N.V.", (dále jen "RBS"), pobočka v České republice. Pod centrálu v Praze podléhá současně pobočka v Brně a v Bratislavě. Součástí celé infrastruktury je také záloţní centrum. Na obrázku č. 1 je zobrazeno blokové schéma ICT RBS banky včetně připojení na partnery třetích stran a klientů. Hlavní činností banky, stejně jako u kterékoliv jiné banky, je transakční zpracování. Tuto činnost procesují hned dvě oddělení (GTS a Payments4). Nicméně jiţ zde se tato banka liší od ostatních bank tím, ţe pro velké zákazníky provádí nadstandardní sluţby, které budou popsány v další časti této práce. Obrázek 1 : ICT RBS Banky

Autor : Miroslav Šalanský - vytvořeno pro účely Bakalářské práce

4

GTS a Payments - Global Transaction Services = Globální transakční zpracování; Payments = platební 8

1. Infrastruktura korporátní banky Základním rysem zvolené metodiky popisu infrastruktury je následující citace "mnohost pohledů na IS/IT5 jak při řešení, tak při provozu IS/IT je základním předpokladem efektivnosti IS/IT", jak uvádí

[1]. Tato multidimenzionalita je charakteristickým rysem

metodiky MDIS. Řešení IS/IT se musí realizovat souběţně ze všech pohledů, které mají vliv na IS/IT. Metodika MDIS se skládá ze dvou hlavních dimenzí IS/IT. První skupina dimenzí zahrnuje tyto následující pohledy: úroveň integrace IS/IT viz kapitola 3. Podpora ICT úroveň abstrakce časová dimenze řešení Druhá skupina reprezentuje ty dimenze IS/IT, které se aplikují v kaţdé fázi vývoje, jde o tzv. obsahové dimenze IS/IT. informační / datová viz kapitola 2.1. Networking softwarová viz kapitola 3. Aplikační Software hardwarová viz kapitola 2.2. Hardware metodická procesní viz kapitola 3. Aplikační Software ekonomická organizační pracovní / sociální / etická dokumentační manaţerská Tato práce se zaměřuje na infrastrukturu, aplikační software a podporu, tudíţ nebudou pouţity všechny dimenze této metodiky. Rovněţ nebudou tyto dimenze promítnuty do jednotlivých fází ţivotního cyklu vývoje IS/IT, protoţe se mém případě nejedná o klasický popis návrhu IS/IT korporátní banky, nýbrţ spíše o jeho část odpovídající fázím provozování a údrţbou informačního systému.

5

IS/IT - informační systém / informační technologie 9

Obrázek 2 : Základní stavební bloky architektury IS/IT podle [1]


Na obrázku č. 2 jsou znázorněny základní bloky architektury IS/IT , které se dají dobře aplikovat i na model aplikačního vybavení banky, kde jsou zobrazeny aplikace z různé úrovně pohledu, ať jiţ jsou to aplikace pro vrcholový management banky (EIS), nebo pro střední řídící pracovníky (MIS). Další pohled patří koncovým uţivatelům informačního systému (TPS). Boční trojúhelník vlevo (EDI), znázorňuje rozhranní mezi bankou a ostatními účastníky bankovního obchodu, ať jiţ jsou to klienti, banky nebo servisní partneři třetích stran. Trojúhelník vpravo (OIS) znázorňuje aplikace, které se pouţívají na všech úrovních řízení banky. V následující tabulce č. 1 jsou popsány jednotlivé bloky tohoto modelu s příklady jednotlivých aplikací, které spadají do příslušné kategorie.

10

Tabulka 1 : Popis stavebních bloků architektury

Systém

Popis

Výstupy

EIS - Executive Information System

DWH - Data Warehouse, ze kterého se pomocí reportu tzv. kostek (cubes) vytvářejí potřebné výstupy

MIS - Management Information System

Tyto výstupy jsou taktéţ extrahovány z datových skladů nicméně jejich rozsah, struktura a komplexnost je odlišná od reportů pro exekutivu.

TPS - Transaction processing system

Centrální informační systém banky je aplikace s názvem SCORE

Reporting pro management, Informační systém pro vrcholový management (exekutiva). Výstupy jsou v podobě grafu či reportu. Tento systém zpracovává informace z databází, podle poţadavků jednotlivých útvarů, za účelem optimálního řízení firmy. Výstupy jsou taktéţ v podobě grafů či reportů. Tato aplikace v sobě obsahuje veškeré informace týkající se transakčního zpracování a účetnictví celé banky. Tato aplikace má mnoho rozhraní, přes které je připojena do ostatních aplikací.

EDI - Electronic Data Interchange

Pro elektronickou výměnu dat se pouţívá hned několik aplikací, jako je EDIFACT pro zasílaní a přijímání faktur, dále jsou to systémy AMET/CERTIS, které slouţí pro zasílání a přijímání transakčních souborů s ČNB. V této skupině aplikací se v naší firmě pouţívá MS Exchange. Tento nástroj se pouţívá nejen jako poštovní klient ale také jako aplikace pro řízení na té nejniţší úrovni. Nicméně vzhledem k potřebě oběhu velkého mnoţství dokumentů je pouţít dokument management systém pro ukládání a výměnu dokumentů

OIS - Office Information System

Autor : Miroslav Šalanský

11

Tyto aplikace pracují na principu výměny souborů, které jsou patřičně zabezpečeny proti manipulaci

V pobočce RBS Praha se pouţívají hned dva systémy pro správu dokumentů. Lokální systém slouţí pro oběh dokumentů z tzv. datových schránek a druhý systém slouţí pro ukládání smluv klientů. Tento druhý systém je umístěn v Indii a veškerá data se přenášejí po datových linkách.

1.1.

Networking

1.1.1.

Lokální síť - LAN

Lokální síť, jinak také označovaná jako LAN6 je postavena výhradně na CISCO zařízeních, které jsou součástí tzv. schválených standardů, které se mohou pouţívat. Celá lokální síť je zcela nově vybudována na stíněné strukturované kabeláţi kategorie 6 (CAT 6)7. Nicméně pro propojení jednotlivých síťových prvků se pouţívá optického kabelu, který můţe dosahovat rychlosti přenosu aţ 111 Gb/s, i kdyţ v aplikovaných systémech jsou typické rychlosti 10 nebo 40 Gb/s. Bohuţel, tato rychlost ještě není nastavena, protoţe tato konfigurace není součástí standardů, které jsou schválené. Stávající rychlost připojení serverů je 100 Mbit/s a s pouţitím HP network managementu můţeme dosáhnout sloučením dvou síťových karet aţ 200 Mbit/s s nastavením vyvaţování zátěţe "Load balancing" 8. Celá síť je zapojena podle tzv. hvězdicové topologie. Hvězdicová topologie označuje propojení počítačů do útvaru, tvarem připomínající hvězdici. Jedná se o nejpouţívanější způsob propojování počítačů do sítě. Kaţdé zařízení (PC, server, tiskárna nebo telefon) je připojen pomocí kabelu (STP) k přepínači (switch), který je připojen optickým kabelem do centrálního přepínače. Centrální přepínač a ostatní důleţité přepínače jsou spojeny ve dvojici pomocí EtherChannel technologie, která umoţňuje seskupovat několik fyzických Ethernet spojení v jedno logické spojení, coţ má za následek zvýšení tolerance chybovosti a rychlosti mezi jednotlivými přepínači. Lokální síť v hlavním sídle banky v ČR je spojena také s ostatními lokalitami, kde

má banka své aktivity.

Jedná se o pobočku v Brně

9

a o záloţní pracoviště označované jako STIM . Mezi primárním sídlem a záloţním pracovištěm je datová linka o rychlosti 100 Mbit/s. Brno - Praha a Brno - STIM jsou datové linky o rychlosti 10 Mbit/s. Znázornění celé sítě je názorně zobrazeno

schématem

na obrázku č. 4 WAN a LAN síť. Zde můţeme názorně vidět, ţe lokální sítě jsou spojeny do trojúhelníku, který slouţí sám o sobě jako záloha, protoţe v případě, ţe na některé z linek dojde k výpadku, automaticky se přepne komunikace na zbývající datové linky. Hlavním důvodem proč je mezi hlavním sídlem a záloţním pracovištěm linka o rychlosti 100Mbit/s, je poţadavek na online replikace všech důleţitých databází a transakčních souborů, které

6

LAN je označení pro lokální síť a vychází z anglického výrazu Loacal Area Network Cat. 6 - tato kategorie byla schválena v roce 2002. Pracuje s dvojnásobnou šířkou pásma neţ kategorie 5E (tj. aţ 250 MHz). Vyšší kvalita komponent s větší šířkou pásma zajišťuje vynikající spolehlivost přenosu Gigabit Ethernetu (1 Gb/s) 8 Load balancing je rozloţení zatíţení mezi dva nebo více síťových linek nebo jiných zařízení, aby bylo dosaţeno optimálního vyuţití, prostupnosti nebo času odezvy. 9 STIM - označení budovy Strojimportu kde je umístěno záloţní pracoviště 7

12

se mohou v případě výpadku na primární straně okamţitě, nebo po manuálním zásahu přepnout do produkčního prostředí a pokrýt tak výpadek primární sluţby.

1.1.2.

Globální síť - GAN

Jak jiţ bylo zmíněno GAN konektivita je velmi důleţitá, protoţe hlavní bankovní systém a účetní knihy jsou fyzicky umístěné v datových centrech v Amsterdamu a v Londýně. Pro připojení do této celosvětové sítě pouţíváme technologii MPLS10. Na obr. č. 3 můţete názorně vidět jaká je latence mezi serverem v Praze a serverem v Londýně. Tato technologie nám umoţňuje provozovat aplikace hostované ve vzdálených datových centrech, kterých má banka po celém světě hned několik. Např. Singapur, Chennai, Amsterdam, Londýn, Edinburgh atd. Nejčastěji se jedná o aplikace, které se ze vzdálených datových center přenášejí pomoci CITRIX clienta. Obrázek 3 : Latence mezi Prahou a Londýnem


CITRIX technologie má velmi malé nároky na šířku datové linky a proto je toto řešení ideální pro aplikační vrstvu, která zobrazuje front-end

11

. Poţadovaná minimální šířka pásma pro

jednoho uţivatele je 10-20 kb/s, nicméně pokud aplikace pouţívá grafické obrazce, tak se poţadovaná šířka násobí i několikrát. I přesto je zátěţ datové linky vzhledem k dnešním rychlostem datových linek zanedbatelná. Připojení do GAN sítě je realizované dvěma datovými okruhy, které spojují českou pobočku do celosvětové sítě banky označovanou jako GAN. Rychlost těchto datových linek je 4 Mbit/s. Jedno spojení je ukončeno v záloţní lokalitě a druhé v primární lokalitě. Tato 10

MPLS - Multiprotocol Label Switching - mechanismus jak ve výkonnostních sítích řídí a přenáší data z jednoho uzlu sítě na další pomocí štítku 11 front-end - ta část aplikace, do které uţivatel zadává či exportuje informace, většinou se jedná o grafické zobrazení, kde uţivatel pracuje s aplikací pomocí vstupních zařízeních. 13

konfigurace byla zvolena pro absolutní nezávislost záloţního pracoviště v případě, ţe by došlo k úplné ztrátě hlavního pracoviště. Podrobně o moţných scénářích vyuţití pojednávají havarijní plány banky, kde se berou v potaz všechny známé moţnosti, za kterých se má pouţít "DR site"12. Tyto plány se také pravidelně testují a banka ověřuje schopnost systémů v záloţním pracovišti plně nahradit produkční prostředí. Z tohoto důvodu jsou do záloţní lokace přivedeny datové linky z ČNB a z Burzy cenných papírů, které můţeme aktivovat v případě nutnosti. Celkový přehled zapojení lokální sítě a připojení do GANu je znázorněno schématem na obrázku č. 4.

12

DR Site - anglicky výraz "Disaster Recovery Site" pro záloţní pracoviště 14

Obrázek 4 : WAN a LAN síť

Zdroj : Převzato z dokumentace banky

1.1.3.

Extranet Firewall

Extranet Firewall slouţí k připojení partnerů ať uţ ze strany zákazníků nebo ze strany ostatních bank či servisních organizací. Vzhledem k tomu, ţe je tento přístup do bankovní sítě povaţován za potenciální riziko proniknutí, rozhodla se banka vytvořit takovou strukturu zabezpečení, aby nebylo moţné ji prolomit. Datové linky, které jsou připojeny do vstupních přepínačů, jsou přímé linky bez přístupu do ostatních sítí. Pravidla, která jsou nadefinována na Extranet Firewallu jsou velice striktní. Zde se specifikuje, kdo komunikaci navazuje a jakým směrem, na jakém portu atd. Struktura tohoto bezpečnostního prvku není sloţena pouze z jednoho typu firewallu, ale z více typů najednou, které jsou spojeny do jednotlivých clusterů pro případ hardwarové chyby či jakéhokoliv jiného výpadku (např. výpadek elektřiny, odpojený kabel atd.). Pravidla pro přístup do sítě jsou nastavena na kaţdém prvku Extranet Firewallu, to znamená, ţe nejenom firewall má nastavena pravidla pro přístup, ale i zařízení typu router a switch13 mají nastavena pravidla pro komunikaci. Příkladem tohoto připojení je spojení do ČNB, po kterém se realizuje transakční zpracování na denní bázi, včetně zasílání zákonem povinných reportů. Konektivita do ČNB je příkladem spojení mezi bankami, ale častějším typem spojení je spojení se servisní organizací, jako je např. konektivita do společnosti MUZO, která kompletně zabezpečuje provoz platebních karet pro banku. Další příklad je spojení do Burzy Cenných papírů, kde je realizováno spojení přímo s centrálním systémem, coţ bance umoţňuje uzavírat obchody s klienty online a všechny transakce jsou automaticky zaúčtovány v účetních systémech pomocí rozhraní, které byly vytvořeny IT oddělením. Poslední příklad datové linky připojené přes Extranet Firewall je spojení s klienty, kterým banka poskytuje rozmanité sluţby dle jejich přání. Například rekonciliace došlých plateb s odeslanými fakturami atd. Na obrázku č. 5 je znázorněno, jak můţe vypadat struktura takového Extranet Firewallu.

13

Router - směrovač, Switch - přepínač 16

Obrázek 5 : Extranet Firewall

Zdroj : Převzato z dokumentace banky

17

1.1.4.

Lokální Firewall

Další moţností vyuţití firewallu je izolace citlivých dat, za které se povaţují soubory pro transakční zpracování. K těmto datům má oprávnění pouze velmi malý okruh lidí, nicméně hodně lidí s nimi potřebuje pracovat. Z tohoto důvodu je zde Lokální Firewall, který umoţňuje vybraným počítačům přistupovat na clearingové servery. Přístup k těmto datům je samozřejmě upraven i na úrovni práv v aplikaci, kdy uţivatel se svými doménovým přístupem

není schopen číst, modifikovat či smazat tyto data. Přístup k těmto datům

je zprostředkován přes aplikačního uţivatele a pouze sama aplikace má právo manipulovat se soubory. Samozřejmě všechny tyto manipulace jsou zaznamenávány a v případě, ţe aplikace bude vykonávat důleţité kroky, jako je odeslání plateb do zúčtovacího centra České Národní Banky, je zapotřebí, aby se do aplikace přihlásil druhý operátor. Tomuto zabezpečení se říká kontrola čtyř očí. Jiným typem pouţití Lokálního Firewallu je izolace určité skupiny serverů od ostatních serverů či uţivatelů sítě, kterému se říká demilitarizovaná zóna, zkratka DMZ. Důvodem je zvýšení bezpečnosti kritických aplikací. V našem případě se jedná o aplikaci pro "Home banking".

Kdyby se Home banking servery neoddělily od standardního segmentu, tak

kdokoliv z celého světa, kdo je v bankovní síti, by se mohl dostat na tyto servery a způsobit tak materiální škodu, nemluvě o poškozené reputaci. Příklad zapojení takovéhoto firewallu je zobrazen na obrázku č. 6. Obrázek 6 : Lokální Firewall


18

1.1.5.

IP telefonie

V současnosti banka pouţívá IP telefonování a to nejen uvnitř jedné pobočky, ale i do ostatních poboček, které jsou pod správou IT oddělení v Praze. Před pěti lety byla vybudována síť telefonních ústředen na technologii firmy AVAYA a díky propojení všech těchto telefonních ústředen jsme schopni telefonovat mezi Prahou, Brnem a Bratislavou zcela zdarma po bankovních linkách. Kvalita přenosu je velmi dobrá, respektive několikanásobně lepší neţ standardní meziměstský či zahraniční hovor. Jedinou podmínkou pro tuto bezproblémovou funkčnost bylo nastavení QoS14. Toto nastavení neboli sluţba garantuje či rezervuje datový tok pro přenos hlasu tak, aby nedocházelo k zahlcení datové linky, čímţ by se způsobilo přerušení komunikace či zpoţdění odezvy. Všeobecně lze QoS nastavit pro jakoukoliv komunikaci, nicméně v RBS se jedná o upřednostnění hlasu (VoIP15) před datovou komunikací. Schéma zapojení IP telefonie je znázorněno na obrázku č. 7.

14 15

QoS - z anglického výrazu Quality of Services (kvalita sluţeb) VoIP - z anglického výrazu Voice over IP (hlas přes IP) 19

Obrázek 7 : IP Telefonie


1.1.6.

Proxy server

Proxy server pouţívaný v RBS je nainstalován na Linuxovém serveru.Tato lokální instalace Proxy serveru je připojena na centrální Proxy servery, kterým se říká "Parent Proxy16". Jiţ tento globální Proxy server blokuje komunikaci, která přichází či odchází z lokálního Proxy serveru. Tyto servery se samozřejmě nepouţívají jen na správu uţivatelů pro přístup do Internetu a pro ukládání dočasných souborů, ale i pro omezování přístupu na některé stránky. Typickým příkladem je omezení přístupu na stránky, které poskytují volný přístup k poštovním sluţbám, coţ je jedním z mnoha bezpečnostních nastavení, které sniţují riziko výskytu neţádoucích problémů. Tento server také slouţí k monitorování uţivatelů a jejich přístupu na jednotlivé stránky, včetně statistik o mnoţství staţených dat. Tyto informace se vyuţívají pro odhalení problémů při přetíţení datových linek. Nejčastějším důvodem zahlcení šířky pásma datové linky nicméně není stahování dat z internetu, ale aplikace, které se připojují přes Proxy server na aplikační server umístěný mimo Českou republiku. Proto se pouţívá

pro

konfiguraci

Internet

Exploreru

17

konfigurační

soubor

označován

v IT terminologii jako "PAC FILE ". Je to skript pomocí jehoţ se můţou jednotlivé 16 17

Parent Proxy - moţno také přeloţit jako rodičovský Proxy server PAC FILE - vychází z anglického výrazu Proxy Access Control 20

poţadavky přesměrovat na cílové servery, aniţ by komunikace zatěţovala Proxy server. Bohuţel, Proxy sluţba má také z principu jednu slabinu. Prochází přes ni velké mnoţství spojení a její výpadek znamená omezení, nebo zastavení velkého počtu důleţitých aplikací. Z tohoto důvodu je stejný Proxy server ještě v záloţní lokalitě a v případě jakéhokoliv výpadku se můţou přesměrovat všechny poţadavky na tento server, který plnohodnotně nahradí primární Proxy server. Příklad statistik, které poskytuje Proxy server je zobrazen na obrázku č. 8. Obrázek 8 : Proxy server statistiky

Zdroj : Report z aplikace SQUID Proxy server

1.1.7.

Standardy

Stejně jako v kterékoliv bance, má i RBS svoje standardy, které vyházejí ze standardu ITIL verze 2, nicméně jiţ je naplánována implementace verze 3. "ITIL® je zkratkou pro "Information Technology Infrastructure Library", knihovna infrastruktury informačních technologií" (Telefónica O2 Czech Republic). Chtěl bych poznamenat, ţe tyto standardy jsou pouze doporučení, které dle poučky vytvářejí IT odborníci, nicméně do vytváření těchto standardů jsou zapojeny ty největší celosvětové firmy, které tato doporučení interpretují tak, aby jim generovaly patřičný zisk. Je přeci logické, ţe firma typu banka, jejímţ hlavní naplní jsou bankovní sluţby, nic neví o informačních technologiích a tudíţ jen slepě implementuji tyto rady, aniţ by se nikdo pozastavil nad tím, kolik tato implementace bude stát a zda výhody, které přináší implementace nového procesního modelu

stojí za vynaloţené

prostředky. Proto bych chtěl ještě jednou zdůraznit, ţe ITIL® je pouze doporučení nikoliv zákon, podle kterého by se měla kaţdá firma řídit. "ITIL® je veřejně dostupný rámec, jenţ popisuje nejlepší praktiky ve Správě sluţeb IT. Poskytuje rámec pro zvládnutí IT v organizaci, pojednává komplexně o sluţbách a zaměřuje se na neustálé měření a zlepšování kvality dodávaných sluţeb IT, a to jak z pohledu 21

businessu, tak z pohledu zákazníka. Toto zaměření je hlavní příčinou celosvětového úspěchu ITIL® a přispělo k rozšířenému vyuţití a ke klíčovým přínosům, získaným u těch organizací, které aplikovaly tyto techniky a procesy ve svých strukturách." (itSMF Czech Republic)18 Další oblastí, kde se pouţívají globální standardy je oblast hardwaru, coţ je z pohledu IT velmi praktické, protoţe se v celé infrastruktuře nevyskytují rozmanité typy serverů, PC, tiskáren nebo síťových komponent, ale pouze schválené typy těchto zařízení.. Tyto HW standardy

pak

velmi

usnadňují

distribuci

operačního

systému

a

zařazení

do monitorovacích aplikací jako je např. HP Inside Manager®, Tivoli® atd. K tomu, aby byl IT specialista schopen zastávat pozici síťového specialisty je potřeba, aby měl certifikaci CCNA a CCNP, nebo znalost na této úrovni. Dále je vyţadována znalost Unixových operačních systémů.

18

itSMF Česká republika - fórum zabývající se správou IT sluţeb a ITILem 22

1.2.

Hardware

1.2.1.

Servery

Serverová infrastruktura se v pobočce RBS banky v České republice rozděluje do dvou hlavních skupin, a to na WINTEL and UNIX servery. V současně době dochází ke změnám servisního modelu a WINTEL servery přecházejí pod globální podporu, nicméně v současně době jsou stále pod správou IT oddělení v ČR. Z tohoto důvodu budu popisovat stávající situaci řešení podpory těchto zařízeních.

1.2.2.

WINTEL servery

Všechny servery, na kterých je nainstalován operační systém Windows, konkrétně Windows server 2003 SP2, jsou pouţity výhradně servery HP.

Operační systém nainstalovaný

na těchto serverech je speciálně modifikovaný s ohledem na zvýšení bezpečnosti těchto serverů. Pro tyto účely byl vytvořen tzv. bankovní build, který se instaluje přímo z distribučního serveru a to včetně všech jiţ zmiňovaných bezpečnostních změn a aplikací, které jsou vyţadovány pro kaţdý server. Jedná se o antivirový program, SW pro správu operačního systému a hardwaru, monitorovací SW, WinZip, Acrobat atd. Monitoring těchto serverů se provádí pomocí HP Inside Manager®19, který zjišťuje poţadované informace o serverech a na základě nastavených pravidel zasílá informace do HelpDesk

20

aplikace. V této aplikaci pro správu poţadavků (TrackIT) se pak událost

přiřadí příslušnému technikovi, který ji vyřeší. V případě, ţe se jedná o závadu na HW, tak se objedná vadný díl u dodavatele. Pokud je problém v operačním systému, tak je problém řešen přímo tímto technikem. Monitorují se všechny dostupné informace, ale pouze kritická hlášení jsou reportována do HelpDesku. Nejčastější událostí je například nedostupnost serveru na síti, respektive jedné z jeho síťových karet, protoţe kaţdý server má dvě síťové karty, které jsou sloučeny v jeden tzv. TEAM. Tento TEAM je pak nakonfigurován buď v "load balancing" nebo "fail over" módu. Load balancing se pouţívá u těch serverů, kde se poţaduje vyšší datová prostupnost, protoţe v tomto módu se rychlost sítě zdvojnásobuje, respektive to funguje tak, ţe se zátěţ rozděluje na obě síťové karty rovnoměrně. Fail over mód se na druhou stranu pouţívá u serveru, kde není důleţitá rychlost spojení, ale kde je důleţitá funkčnost spojení. V tomto módu se v případě výpadku komunikace přepne na tu síťovou kartu, která je schopna komunikovat. Hlášení o zaplnění místa na disku 19 20

HP Inside Manager® - SW pro monitoring HW od firmy HP HelpDesk - podpora, servisní centrum, pomoc 23

je dalším příkladem, co vše je moţné monitorovat pomocí tohoto nástroje. Samozřejmě tento monitoring zasílá informace o vadném hardware. Nejčastějším výskytem takovéto chyby je vadný disk. Nicméně vzhledem ke konfiguraci diskových polí, která se pouţívá na všech serverech, není tato závada nijak závaţná, protoţe všechny servery pouţívají pro operační systém dvou disků, které jsou zrcadlené, tudíţ při výpadku jednoho disku vše funguje bez problému dál. Pokud jde o disk v diskových polích, kde jsou uloţena data, tak i zde se pouţívá technologie RAID a to konkrétně RAID 5. Tato verze ukládá paritní informace na všech discích v poli, nicméně stále je při zápisu třeba přečíst paritní informace, přepočítat je a znovu uloţit, coţ je podstatně pomalejší neţ u zrcadlení (RAID 1), minimální počet disků jsou tři pro vytvoření pole typu RAID 5, nicméně v RBS se pouţívá konfigurace ještě s jedním náhradním diskem, kterému se říká "HOT SPARE". Tento disk není aktivně pouţíván pro ukládaní dat, ale je připraven pro případ, ţe jeden z disků je poškozen. Tuto funkčnost má na starost přímo řadič diskového pole, který v případě závady, nebo jen prediktivní závady okamţitě vyřadí vadný disk a rekonstruuje data na tomto náhradním disku. Tomuto procesu se říká "rebuilding". V prostředí RBS je přes 40 WINTEL serverů a proto je potřeba pouţívat ucelené postupy pro pojmenování serveru. Pojmenování se vytváří na základě účelu serveru a lokace. Pravidlo pro pojmenování je následující: první čtyři znaky jsou písmena, kde první dva znaky označují zemi, ve které se nachází daný server (v tomto případě CZ) a další dva znaky označují účel serveru viz přehled v tabulce č. 2 za čtyřmi znaky následuje pomlčka a pět čísel označující pořadí vzniku serveru. do těchto pravidel nespadají servery, které nejsou v korporátní doméně (nejlepším příkladem jsou servery v DMZ zóně) Pokud si sloţíme výše zmiňovaná pravidla, tak nám vychází, ţe např. doménový server se bude jmenovat CZDC-00001, pokud budeme mít dva tyto severy, tak následující bude mít jméno CZDC-00002 a stejně tak je to i s ostatními servery.

24

Tabulka 2 : Kódy serverů

Kód serveru

Anglické označeni

Popis serveru

CA

Certificate Server

Certifikační server

DC

Domain Controller

Doménový řadič

GS

Generic Server

Všeobecný server

TS

Terminal Server

Terminálový server

AS

Application Server

Aplikační server

FS

File Server

Souborový server

PS

Print Server

Tiskový server

IN

Infrastructure Service

Infrastrukturní server


Serverová infrastruktura je velmi důleţitým prvkem celého informačního systému, tudíţ i zde jsou aplikované metodiky standardu ITIL®. Konkrétně se jedná o změnové řízení, neboli Change Management a záloţní plány neboli Business Continuity. Záloţní plány jinak označované také jako DR21 plány jsou velmi důleţitou součástí informačního systému banky. Tyto plány spadají pod tzv. Business Continuity 22 plány, které se pravidelně revidují a testují. Součástí těchto testů je plné převedení všech aplikací do záloţní lokace a provozování těchto aplikací ze záloţní lokace. Proto je velmi důleţité počítat s tímto poţadavkem při vytváření nové aplikace popřípadě nového serveru. Je třeba zváţit jakým způsobem bude realizovaná aplikace v záloţní lokalitě. V současné době máme

celou serverovou infrastrukturu

rozmístěnou přes několik typů serverů s různým výkonem viz tabulka č. 2.

Vzhledem

ke globální strategii firmy se nám otevírá moţnost převést všechny serverové instance do dvou virtuálních řešení, kdy jedno řešení bude pro hlavní lokalitu a druhé pro záloţní pracoviště. Toto nové řešení by vyřešilo mnoho problémů, se kterými se musíme potýkat při aktivaci záloţního centra. V současné době je toto řešení v podobě plánů architektury celého řešení. Stávající DR plány jsou postaveny na principu obnovy dat z archivních pásek a na online replikování produkčních databází pomocí "Oracle Data Guard" řešení, které replikuje archivní logy všech Oracle databází a aplikuje je do záloţních databází v záloţní lokaci.

21 22

DR - "Disaster recovery" - havarijní plány Business Continuity plan - Plánování kontinuity obchodování 25

Tabulka 3 : Typy serverů

Typ serveru COMPAQ

Generace

Počet serverů 1

PROLIANT

5500 HP Proliant DL 360

G2

11

HP Proliant DL 360

G4

4

HP Proliant DL 360

G4

1

HP Proliant DL 380

G3

1

HP Proliant DL 380

G4

23

HP Proliant DL 380

G5

1

HP Proliant DL580

G2

1


Kvalifikace pro správu serverů v RBS je znalost Active Directory, certifikace nebo znalost na úrovni MCSA23, znalost programování v CMD a VBS skriptu. Přehled o hardwaru serverů a diskových polích. Schopnost navrhnout a realizovat konfiguraci diskových polí. Navrhnout serverovou infrastrukturu pro nové aplikace, včetně řešení zálohování. Zkušenosti s distribucí software pomocí SMS24 nebo jiných nástrojů na distribuci software.

1.2.3.

UNIX servery

Unixové servery zastávají velmi důleţitou úlohu v serverové infrastruktuře banky. Dalo by se říci, ze pokud máme nějaký kritický systém, který nesmí mít výpadky, tak je v tomto případě vţdy pouţit Unixový operační systém. Unixových systémů je pouţito hned několik viz tabulka č.4 : UNIX Systémy. Různé distribuce Unixových systémů jsou pouţity na základě poţadavků dodavatelů bankovních aplikací. Příkladem takovéto aplikace je Kondor+® od firmy Reuters, která vyţaduje,

aby aplikace byla instalována pouze

na operační systém Solaris. Unixové servery mají tu nevýhodu, ţe nejsou schopné v základní distribuci sdílet data. Z toho důvodu jsou zde nainstalované SAMBA25 servery, které tuto moţnost poskytují. Další velmi často pouţívaný nástroj je crontab. Je to nástroj, který umoţňuje automatické spouštění úkolů (skriptů) v pravidelných intervalech. To je velmi uţitečné při spouštění reportů, kterých

23

MCSA - Microsoft Certified Systems Administrator - toto je certifikační zkouška od Microsoftu SMS - Systems Management Server - nástroj od Microsoftu pro správu systémů 25 SAMBA - je SW balík, který implementuje rozhraní poskytující souborové a tiskové sluţby 24

26

je v bankovním prostředí celá řada. Pravidelná údrţba operačního systému nebo databází běţících na UNIXu jsou další způsoby vyuţití tohoto plánovacího nástroje . Crontab (cron tabulka) je soubor, který obsahuje soupis tzv. cron údajů, které jsou spouštěny v určeném čase. jednotlivé plány spuštění jsou na samostatném řádku. Jak můţe jednoduchý záznam v tomto crontabu vypadat je znázorněno na obrázku č. 9. Obrázek 9 : Crontab


V tomto záznamu vidíme, ţe se skript spouští pouze v pondělí a to v 6 hodin ráno. Dále je zde výraz 2>&1> coţ znamená, ţe chybové hlášky se přesměrují do standardního výstupu a standardní výstup se přesměruje do logu pod jménem "kpl_night.log" a je uloţen v adresáři /export/home/kplus/. Zároveň je patrné, ţe znak "#" je znakem, za kterým je moţno vloţit poznámku, nebo také zastavit jiţ naplánovanou akci. U druhého příkladu, který je jak jsem jiţ zmínil vyřazen z plánovače bylo spuštění skriptu na osmnáctou hodinu a to od pondělí do pátku. Výstupy z tohoto skriptu se neukládají, ale vkládají se přímo do koše, pokud pouţiji Windows terminologii. Syntaxe záznamu v crontab souboru je následující: * * * * * příkaz/skript/program ke spuštění den v týdnu (0 - 6) (Neděle=0) měsíc (1 - 12) den v měsíci (1 - 31) hodina (0 - 23) minuta (0 - 59)

27

Tabulka 4 : UNIX systémy

Název OS

Verze

CPU

HW

Solaris

8 a 10

Sparc

SUN-Fire-240

AIX

5.3

Power

IBM eServer p5 550

Oracle Linux

X64 Intel

HP DL 380 G4

Oracle Linux

Sparc

SUN-Fire-240

Red Hat

Sparc

SUN-Fire-120

LINUX


Pokud bych opět specifikoval poţadavky na Unixového specialistu, tak by to byla certifikace "SUN Certified System Administrator II" nebo znalosti na této úrovni. Programování v shellu na vyšší úrovni, nejen schopnost čtení skriptu, ale jejich vytváření. Nedílnou součástí dovedností odborníka, který je zodpovědný za správu UNIX systémů, je konfigurace a správa diskových polí. Ladění výkonu serveru včetně monitoringu výkonu a schopnost modifikovat systém za účelem zvýšení výkonu.

1.2.4.

Pracovní stanice

Stejně jako všechny ostatní velké firmy, tak i RBS má své standardy na širokou škálu hardwaru a pracovní stanice nevyjímaje. Pro tyto účely je zřízena intranetová stránka, kde se pravidelně uvádějí veškeré dostupné informace o standardech týkající se hardwaru. Na obrázku č. 10 je ukázka této intranetové stránky. Standardy jsou zavedeny z jednoho pragmatického důvodu. Počítačové stanice jsou Obrázek 10 : Hardware standardy

Zdroj : Převzato z Intranetových stránek banky 28

instalovány pomocí distribuovaného systému, který má banka speciálně upravený pro své účely. V tomto tzv. "BUILDu"26 jsou nainstalovány ovladače právě těch zařízeních, které jsou součástí BUILDu. Operační systém pouţívaný na všech stanicích je MS Windows XP.

1.2.5.

Standardní PC

PC, které uţívají uţivatelé, jsou počítače pro běţný kancelářský provoz, který neklade ţádné speciální poţadavky na hardware. Zde je uveden poslední model standardního počítače: Model: HP 8000 Elite SFF Procesor: Core 2 Duo E8400 Operační paměť: 4Gb (2x2GB) Pevný disk: 250Gb SATA Optická mechanika: DVD-R disk (bez floppy disku)

1.2.6.

Trader PC

Pracovní stanice pouţívané na oddělení, které se zabývá obchodem na burze nebo na mezibankovním trhu, jsou zcela odlišné od běţných počítačů. Hlavní rozdíl je především v moţnosti výstupu grafické karty aţ na čtyři monitory. Dalším rozdílem je osazení dvěma procesory se čtyřmi jádry. Na těchto stanicích se vyţaduje velmi rychlá odezva celého systému a tak jsou tyto výkonné počítače vybaveny disky s SSD technologii. Standardní konfigurace pro "TRADER" PC Model: HP Z400 Procesor: Xeon W3570 Operační paměť: 4GB Grafická karta: NVidia Quadro NVS 295 Pevný disk: INTEL X25-M 160GB SSD Optická mechanika: DVD-R disk (bez floppy disku) Tyto pracovní stanice se nejen vyznačují odlišnou konfigurací, ale jsou vybaveny klávesnicemi od firmy REUTERS, které umoţňují hned několik funkcí. Na těchto vstupních zařízeních jsou tlačítka, kterými obchodník můţe uzavřít nebo odmítnout nabízený obchod. Tyto klávesnice jsou zapojeny do KVM27 přepínače, pomocí kterého se obchodníci přepínají 26

BUILD - znamená ucelenou stavbu operačního systému, která obsahuje specifické prvky právě pro tuto jednu verzi KVM - zkratka vychází z anglických slov Keyboard, Video, Mouse - jedná se přepínač klávesnice, obrazovky a myši, coţ umoţňuje uţivateli ovládat vice počítačů z jedno pracovního místa 27

29

na jiné PC, které je umístěno v datovém centru. Na těchto vzdálených počítačích je spuštěna aplikace pro obchodování s cizími měnami.

1.2.7.

Tiskové řešení

Všechny tisky v bance mají na starost dva tiskové servery, které jsou v clusteru pro splnění poţadavku businessu na dostupnost tiskových sluţeb. Zvláštností, na kterou bych chtěl upozornit, je propojenost celého tiskového řešení, které je propojeno prakticky po celé globální síti. Bankovní hlavní knihy jsou uloţeny na centrálním serveru v Amsterodamu, kam je uţivatel připojen pomoci emulátoru obrazovky, který zabezpečuje přenos dat na vzdálenou obrazovku uţivatele. Na této obrazovce si uţivatel zvolí tisk a data jsou poté poslána na tiskový server v České republice a posléze na příslušnou tiskárnu, která byla zvolena pro tisk. Podobné řešení je i u ostatních aplikací, které jsou poskytovány ze vzdálených datových center. Pouze pro zobrazování uţivatelského rozhranní je pouţit CITRIX® klient. Speciálním druhem tisků jsou SWIFT zprávy, které se tisknou automaticky ze serveru v Londýně a výstupy jsou vytištěny na tiskárně, která je umístěna v zabezpečené místnosti, kam má přístup jen omezený počet osob, které jsou oprávněny pracovat s těmito výpisy. Velmi pouţívanou sluţbou multifunkčních tiskáren je zasílání naskenovaných dokumentů přímo do poštovní schránky uţivatele. Zvláštností je, ţe dokument ve formě jedniček a nul putuje přes půl světa neţ se dostane na místo určení. Všechny výše zmiňované způsoby tisku jsou znázorněny na obrázku č. 11.

30

Obrázek 11 : Tiskové řešení


2. Aplikační Software Software v RBS se vyuţívá nejčastěji ten, který je standardně dodávaný z mateřské společnosti. Do těchto standardů samozřejmě spadají operační systémy na serverech, pracovních stanicích a na přenosných počítačích. Více informací naleznete v odstavci 2.1. Nicméně nedílnou součástí softwarového vybavení banky jsou také aplikace psané na zakázku. Neţ začnu popisovat jednotlivé aplikace pouţívané v korporátní bance, vysvětlím rozdělení softwaru uvedené v [2]., Základní software (ZSW) - do této skupiny softwaru patří operační systémy, systémy pro řízení báze dat - SŘBD (DBMS - Data Base Management System), dále do této skupiny patří systémy pro automatizaci kanceláře (OIS - Office Information System).. Zde s autorem nesouhlasím, protoţe OIS se uvádí také u TESW, coţ mi připadá správně. Můţe se to však u jednotlivých dodavatelů SW pro OIS lišit, např. firma Microsoft dodává. MS Office 2007 jako jeden balík včetně OS. Aplikační software (ASW) - účetnictví, řízení výroby apod. jsou typickými softwary této skupiny Technologicky orientovaný aplikační software (TESW) - pod tímto označením si můţeme představit standardní kancelářský software - OIS. Tento typ softwaru vyuţívá provázanost systémů k zajištění přímých vazeb předávání dat mezi těmito aplikacemi. Typový aplikační software (TASW) - jedná se o software vyvinutý specializovanou firmou pro potřeby konkrétního podniku. Nevýhodou takovéto aplikace je nutnost integrace legislativních změn.

2.1.

Standardní software

Převáţná většina standardního softwaru, který je vyuţíván v RBS je od firmy Microsoft. Standardní kancelářský balík obsahující programy jako jsou MS Word, MS Excel, Power Point nebo MS Outlook je nainstalován na kaţdém PC. Dále dle potřeby je instalován MS Access, ale pouze v případě, ţe byl poţadavek na tuto aplikaci odůvodněný, coţ je schvalováno ve dvou úrovních. Jednak po technické stránce (IT manaţer nebo jeho zástupce) a pak také po stránce finanční (finanční ředitel nebo jeho zástupce).

32

Instalace aplikací se liší v závislosti oddělení dle okruhu činností, které jsou vykovávány v příslušném útvaru. Při instalaci nového standardního softwaru není potřeba sloţitého změnového řízení, protoţe se jedná o standardní aplikaci. Nicméně tato aplikace musí být v databázi aplikací, které je moţno distribuovat pomocí SMS serveru. Tato databáze je v prostředí RBS banky nazývána GAPS. Pokud chce uţivatel nainstalovat standardní aplikaci, která není součástí této databáze, musí projít tato aplikace procesem, který tuto aplikaci umoţní instalovat vzdáleně na jakékoliv PC. Součástí tohoto procesu je testování a uţivatelská akceptace nainstalované aplikace. Tento proces se provádí pouze jednou, kaţdá další instalace je jiţ ušetřena od tohoto testování. Vzhled aplikace GAPS je na obrázku č. 12.

Obrázek 12 : Systém pro ţádost o novou aplikací

Zdroj : Převzato z Intranetových stránek banky

O správu všech licencí se stará audit software, který pravidelně sbírá informace ze všech počítačů, které jsou dosaţitelné po síti. Proto, aby aplikace kontrolovala licence pouze v České republice bylo zapotřebí vydefinovat všechny sítě, ve kterých jsou tyto počítače připojeny. Jedná se konkrétně o produkt AuditPro od firmy TruconneXion a.s. Na základě těchto sběrů se kaţdý rok zpracovává správa autorizovaným auditorem pro potřeby banky.

33

Na ZSW je v RBS buď licenční ujednání nebo faktura, tak jak to předepisuje zákon č. 121/2000 Sb. o právu autorském. ASW je licenčně pokryt výhradně fakturami od dodavatele respektive výrobcem té dané aplikace. V tabulce č. 5 je seznam aplikací, které se instalují na kaţdý kancelářský počítač. Tabulka 5 : Seznam aplikací instalovaných na každém PC Název aplikace

Verze

Popis

Microsoft Office XP

2003 SP3

Standardní edice

Lotus Notes

6.5.5

Reporting do NBS

Symantec Anti Virus

10.1.6.

Adobe Acrobat

9.3.0

WinZip

11.2

Tato verze jiţ umoţňuje šifrování souborů

CITRIX ICA Client

9.2

128 bit SSL

Lock Drive Utility

V1.3.6

Zamykání CD,FDD a USB

Microsoft Java Virtual Machine

Verze 6 Update 24

Nezbytný poţadavek některých aplikací

Microsoft .NET Framework

3.5 SP1

Nezbytný poţadavek některých aplikací

RBS Root Certificates iPASS Dialler

Přístup do intranetových aplikací 1.0

Připojení do Internetu přes autorizované poskytovatele

Cisco VPN Client

4.8.1

Připojení do RBS sítě pomocí šifrovaného spojení

Zone Labs Personal Firewall

5.1

Ochrana přenosných počítačů

SafeBoot hard disk encryption

Šifrování pevných disku přenosných


2.2.

Zakázkový software

V RBS se pouţívá 21 aplikací napsaných dle našich poţadavků, z toho 5 aplikací je přímo součástí transakčního zpracování. V následující části bude popsán celý proces transakčního zpracování a jednotlivé části budou popsány do větších detailů. Aplikace pro zpracování transakcí je nejdůleţitějším ZSW v bance. Tuto aplikaci nazýváme CCMCS. Rozebereme si jednotlivé moduly a rozhranní do ostatních aplikací, které slouţí k předávání důleţitých informací. CCMCS je propojovacím transakčním můstkem mezi stovkami klientů systému MULTICASH (Home banking ), bankovním systémem 34

SCORE, kde transakce musí být zaúčtovány, a mezi Clearingovým centrem České národní banky, přes který musí podle zákona veškerý tuzemský platební styk probíhat. Z tohoto pohledu tento systém zajišťuje konverze různých transakčních formátů, kontrolu a případnou korekci dne splatnosti, nastavení řady transakčních směrovacích parametrů, zabezpečený příjem a odesílání transakcí. CC/MCS Interface je však také současně tzv. "Transaction Warehousing System" a plní funkci jakéhosi skladiště transakcí, které jím protekly, a současně všech protokolů, které byly v průběhu transakčního zpracování vytvořeny. V tomto smyslu je druhou nejvýznamnější pomůckou, vedle systémů SCORE/FPS, pro zpětné vyhledávání informací o transakcích. Obrázek 13 : CCMCS - Zpracování transakčních souborů


35

Na obrázku č. 13 je znázorněn celý proces transakčního zpracování v RBS (schéma platí pouze pro pobočku Praha). Celá tato aplikace CCMCS je lokálně vyvinuta, tím je myšleno, buď lokálními IT vývojáři nebo externí firmou v České republice. Historie této aplikace sahá aţ do roku 1993, kdy ji na základě potřeb banky napsal jeden vývojář v programovacím jazyce PASCAL. V roce 2009 byla aplikace přepsána externí firmou za pouţití programovacího jazyka označovaného jako C++28. Důvodů pro tuto změnu bylo hned několik. Při kaţdém auditu měla banka nález, kde vytýkali závislost na jednom klíčovém člověku bez moţnosti náhrady. Dalším důvodem byla také zastaralá technologie aplikace, která ještě nevyuţívala grafických moţností operačního systému Windows, protoţe původní aplikace byla napsána pro MS-DOS29. Nicméně logika aplikace zůstala původní, neboť za 15 let ostrého provozu byly jiţ všechny chyby odladěny. Schéma zobrazené na obrázku č. 13 znázorňuje tok poţadavků, respektive souborů od zákazníka přes všechny bankovní aplikace aţ do České národní banky. Klienti mohou pro přístup do Home Banking systému pouţít, jak připojení označované jako Multicash online, které umoţní klientovi, aby vyuţil internetové konektivity, coţ je v současné době zhruba 95% všech připojení. Zbývajících 5% připojení je realizováno přes ISDN linky. Převáţná většina klientů pouţívá primárně internetové připojení a ISDN je nastaveno jako záloţní spojení v případě, ţe by došlo na straně zákazníka k výpadku internetového připojení. Existuje ještě připojení přes vytáčenou telefonní linku, která spojí klienta na modemové pole, které přes komunikační server připojí klienta na Home Banking server. Nicméně na tomto způsobu připojení není ţádný aktivní klient, z tohoto důvodu není tato moţnost zobrazena ve schématu. Tok souborů od klienta aţ do ČNB je znázorněn dvěma barvami, kde je rozlišena tzv. urgentní větev (červená barva) a standardní větev (zelená barva), označované anglickým výrazem HIGH a LOW. Ţlutě je zobrazen zahraniční platební styk, který není realizovaný přes ČNB, ale přes systém SWIFT, který je napojen do modulu FPS umístěného na stejném operačním systému OS/400, stejně jako aplikace SCORE. Název aplikace FPS je odvozen od anglického názvu aplikace "Foreign Payment System". Veškerý přenos informací z aplikace do aplikace je realizován pomocí souborů, které obsahují informace v blocích (větách), které mají přesně specifikovanou syntaxi. Samozřejmě tato aplikace má i jiné funkce, jako je například rekonciliace transakčních souborů, jak tuzemských, tak i zahraničních. 28 29

Tato rekonciliace je realizovaná aplikací Intellimatch, která je umístěna

C++ je objektově orientovaný programovací jazyk MS-DOS je operační systém firmy Microsoft, je to první operační systém určený pro jednoduchou obsluhu PC 36

v datovém centru v Indii, kam se posílají všechny potřebné informace pro vyhodnocování a odhalování diskrepancí. Další pomocná aplikace, která poskytuje zaměstnancům velmi individuální přístup k jednotlivým klientům, je databáze cen v aplikaci CXpricing. Tato aplikace je zcela samostatná a obchodníci do ní ukládají domluvené podmínky pro své klienty a na základě těchto nastavených podmínek se provádí účtování transakčních operací. Rozhranní mezi CXpricingem a CCMCS zaručuje, ţe parametry nastavené obchodníkem jsou automaticky importované do aplikace CCMCS. Pro komunikaci k ČNB, která je obousměrná, se pouţívá aplikace AMET. Tato aplikace je pouze jednoduchý router, který vezme soubory, které chce CCMCS odeslat do ČNB, zkontroluje zašifrování a po té odešle soubor do ČNB. Spojení do ČNB je realizováno pomocí přímé datové linky spojené do RBS sítě přes Extranet Firewall, jak je znázorněno na obrázku č. 5 : Extranet Firewall. V předchozí aplikaci byl vyjádřen rozdíl mezi retailovou a korporátní bankou, a sice tím, ţe kaţdý klient má individuální přístup co se týče poplatku za zpracování transakčních sluţeb. Nicméně aplikace, které realizují tyto nadstandardní sluţby, je celá řada. Příkladem této sluţby je rekonciliace odeslaných sloţenek na zaplacení s reálným stavem. Zda sloţenka byla či nebyla uhrazena. Pro realizaci takovéto rekonciliace je zapotřebí dostat všechna potřebná data na jedno místo, kde dojde k poţadované rekonciliaci na základě předem stanovených kriterií a následně se výsledek posílá přímo do účetních systémů zákazníka. Těchto speciálních řešení je realizováno v infrastruktuře banky celá řada. Zvolil jsem příklad, který nejlépe demonstruje propojenost všech systémů, jak systému banky, klienta, ale i subjektů třetích stran.

37

Na obrázku č. 14 je zobrazen diagram znázorňující, jak je daná aplikace zakomponována do infrastruktury banky. Je zde znázorněno jaká je struktura aplikace z hlediska jejího nasazení na jednotlivých serverech. Kaţdý blok označený ţlutou barvou představuje jeden server, který má na starost právě zmiňovanou funkci. Poštovní server přijme e-mail od České Pošty a na základě nastavených pravidel se příloha uloţí do adresářové struktury, kde jej očekává aplikace. Dalším vstupem rekonciliace jsou zaplacené poukázky přímo převodem na účet klienta. Tyto

informace jsou exportovány z hlavních účetních knih pomocí

nadefinovaných reportů, které exportují data přímo do tabulek této aplikace. Obrázek 14 : Diagram nasazení


Posledním zdrojem dat pro celé zpracování je informace z pokladního systému, který poskytne informaci o tom, zda byla či nebyla poukázka uhrazena hotově. Tato informace se opět dostane přímo do tabulek aplikace pomocí rozhranní, které umoţňuje náhled přímo do pokladního systému. Diagram aktivit na obrázku č. 15 znázorňuje tok řízení z aktivity do aktivity. Na diagramu stavů jsou znázorněny jednotlivé stavy, kterých aplikace nabývá při zpracování dat. Základní stavy aplikace jsou načtení zdrojových dat ze všech potřebných zdrojů. Další stav aplikace popisuje kontrolu získaných údajů a případně znovu načtení vstupních dat. Rekonciliace je stavem, kde dochází k vytvoření poţadovaného výstupu, který se odesílá klientovi v posledním stavu této aplikace.

38

Obrázek 15 : Diagram aktivit


39

Obrázek 16 : Diagram stavů


2.3.

Datové toky

Aplikace, které jsou součástí vybavení korporátní banky, jsou navzájem propojené a lze říci, ţe drtivá většina aplikací má spojení na nějakou další aplikaci. Pokud hovoříme o spojení, tak je tím myšlen automatický nebo poloautomatický přenos dat z jedné aplikace do druhé. Vzhledem k tomu, ţe součástí standardů RBS jsou pravidla, která nařizují, aby přenos dat mezi aplikacemi nebyl ovlivnitelný lidskou chybou, tudíţ všechny přenosy dat mezi aplikacemi jsou prováděny pomocí programů, které zaručují bezchybný přenos. Některé datové toky jsou automaticky transferovány, ale pokud si to vyţaduje proces zpracování, jsou data přenášena na základě povelu v aplikaci, který je zadán uţivatelem. Příkladem těchto poloautomatických přenosů je zpracování transakčních plateb prováděných operátorem, který zadá příkaz k přesunu dat z jedné aplikace do druhé na základě splnění dalších podmínek, jako je potvrzení od různých oddělení, ţe nepotřebují odeslat ţádné platby k aktuálnímu dni. Jakmile operátor dostane všechny potřebné informace, přikáţe aplikaci odeslat transakční soubory do ČNB. Na obrázku č. 17 : Propojení všech aplikací, je znázorněn celkový pohled

40

na nejdůleţitější aplikace v celé infrastruktuře banky. Jsou zde znázorněna propojení jednotlivých aplikací a směr datového toku. Tento globální pohled dává na první pohled najevo, ţe je zde několik důleţitých aplikací, které interferují s ostatními aplikacemi. Tyto aplikace jsou klíčově pro běh bankovních procesů. Při výpadku těchto aplikací by bylo ohroţeno několik dalších aplikací, tyto aplikace nazýváme kritické. Pro kritické aplikace platí jiné standardy neţ pro nekritické. Hlavním rozdílem je vlastní řešení těchto aplikací. Kritické aplikace musí být vţdy zdvojené. Běţná je realizace za pomocí dvou serverů, které jsou spolu v clusteru. V infrastruktuře RBS banky Praha je pouţíváno řešení od firmy Microsoft, které je součástí Enterprise edition serveru.

Druhý typ řešení je postaven na clusteru od firmy Legato30. Některé důleţité

aplikace jako například Kondor+ pouţívají jiná řešení. Aplikace Kondor+ vyţaduje operační systém Solaris, který poskytuje dostatečně široké moţnosti při výpadku na jednom serveru a převzetí sluţby na druhém. Všechny sluţby, které se spouští na těchto Unixových serverech jsou nastaveny tak, ţe v případě, ţe poţadovaná sluţba není nalezena na primárním serveru, tak je automaticky vyhledána na druhém serveru. Jestliţe

sluţba na primárním serveru

vypadne, tak se ji skript pokusí nastartovat znovu a pokud se mu to nepodaří, tak nastartuje stejnou sluţbu na záloţním serveru. Toto řešení je občas pouţíváno i pro rozloţení zátěţe Unixových serverů.

30 SW Legato NetWorker patří mezi nejlepší produkty v oblasti zálohování dat. Je určen pro všechna prostředí – od nejjednodušších homogenních s několika servery aţ po velmi sloţitá heterogenní prostředí http://www.legato.com

41

Obrázek 17 : Propojení všech aplikací

Zdroj : Bankovní dokumentace - autor: Miroslav Šalanský

3. Podpora ICT Tuto práci jsem začal psát v době, kdy se v RBS dokončoval projekt implementace nového modelu podpory, jak uţivatelů tak celé infrastruktury. Z tohoto důvodu bych chtěl popsat starý neboli lépe řečeno původní model podpory a také nový model, který je v současné době jiţ naimplementovaný. Budu se snaţit popsat zkušenosti s oběma modely z různých úhlů, jak z úhlu uţivatelského, administrátorského tak i manaţerského. Vysvětlím svůj pohled a názor na tyto celosvětově implementované změny a pokusím se potvrdit či vyvrátit své tvrzení pomocí průzkumu, který jsem na toto téma zorganizoval.

3.1.

Lokální model podpory

Od roku 1993 kdy banka pod jménem ABN AMRO N.V.31 získala licenci, byla veškerá podpora jak uţivatelů, tak IT/ICT výhradně na IT specialistech, kteří byli zaměstnanci banky. Tento model podpory spočíval na IT oddělení, které mělo pod správou veškerou infrastrukturu banky, do které patřily sítě, aktivní prvky, UNIX a WINTEL servery, databáze, tiskárny, koncové počítače, notebooky a ostatní záleţitosti týkající se IT technologií jako např. chlazení serverové místnosti či záloţní zdroj energie. Pro kaţdou oblast byli v IT oddělení určeni dva lidé, aby byl dodrţen poţadavek na zastupitelnost. Tento model podpory skončil 18.3.2011. Lokální IT oddělení přijímalo všechny poţadavky od uţivatelů, ať uţ to bylo hlášení závady nebo poţadavku na administraci nějakého systému či aplikace. Samozřejmě byly a jsou ve spektru podporovaných aplikací také aplikace, které jsou z hlediska infrastruktury v jiných datových centrech po celém světě. K zaregistrování poţadavků byl pouţit ZSW HelpDesk 32, který zaznamenával veškeré poţadavky od uţivatelů. Hlášení o závadě či poţadavku bylo moţné poslat, buď přes email nebo telefonicky přes

operátora, který poţadavek přijal

a zaznamenal do HelpDesku. Jakmile tento poţadavek byl zaregistrován, ať jiţ pomocí emailu či telefonu, ţadatel okamţitě dostal informaci do poštovní schránky o zaregistrování poţadavku společně s číslem, pod kterým byl poţadavek zaregistrován. Tato informace slouţila pro případné eskalace či hodnocení uzavřených poţadavků. Tento HelpDesk systém neslouţil pouze uţivatelům, ale také všem zařízením, které byly na lokální síti. Vzhledem 31 32

ABN AMRO banka byla v roce 2008 koupena bankou The Royal Bank of Scotland HelpDesk - aplikace pro registraci a zprávu poţadavků (TrackIT) 43

k tomu, ţe všechny komponenty infrastruktury byly vţdy pořizovány v souladu se strategickým plánem vytvořeným lokálními

IT odborníky, byla všechna tato zařízení

schopná zasílat email, který se nasměroval do HelpDesk systému. Zde byl pak poţadavek zpracován stejně jako kterýkoliv jiný. Operátor nastavil prioritu na základě předem daných kriterií dle důleţitosti té které aplikace či procesu, a přidělil záznam příslušnému technikovi. Ten následně dostal zprávu do emailu, aby nemusel stále kontrolovat zda má či nemá nový úkol ve své frontě v HelpDesku. Dle nastavené důleţitosti poţadavku byl také automaticky nastaven čas, za který má být úkol vyřešen. V případě, ţe do vyřešení úkolu zbývaly dvě hodiny, HelpDesk automaticky poslal technikovi upozornění na nedokončený úkol. Kdyţ nebyl poţadavek vyřešen do poţadované lhůty, dostal technik o této skutečnosti další upozornění a zároveň byl odeslán mail na eskalační osobu, coţ je zástupce IT manaţera. Pokud se poţadavek nevyřešil do nově nastavené poţadované lhůty, které byly nastaveny různě dle závaţnosti problému, došlo k další eskalaci na IT manaţera. Jakmile technik problém vyřešil, uţivatel dostal emailem informaci o uzavření poţadavku spolu s řešením a odkazem na intranetové stránky, kde mohl ohodnotit spokojenost s řešením, popřípadě uzavřený poţadavek znovu otevřít.

Celý tento postup splňuje poţadavky specifikované

v standardu ITIL verze 2. Jak jiţ bylo naznačeno tento lokání HelpDesk software zpracovával všechny poţadavky a nutno říci, ţe bez výjimky. Existuje nicméně celá řada aplikací, které jsou pouţívány v infrastruktuře praţské pobočky, ale nejsou pod správou lokálního IT týmu. Ţádosti na správu těchto aplikací byly předávány na příslušné týmy, které jsou zodpovědné za danou aplikaci. Nesporná výhoda pro tyto globální týmy byla komunikace s IT člověkem, který exaktně vysvětlil problém a řešení netrvalo nijak dlouho. Navíc technická angličtina IT odborníků je na vyšší úrovni neţ u běţného uţivatele. Za zmínku stojí propracovanost správy celé infrastruktury. Jak jiţ bylo zmíněno, kaţdé zařízení bylo schopno poslat poţadavek na servis do HelpDesku. Typickým příkladem jsou tiskárny, které těchto poţadavků posílaly nejvíce. Jedná se zejména o zasílání informací o došlém toneru či poţadavku na výměnu opotřebeného válce nebo jednoduše o potřebu servisní kontroly, která se musí realizovat pravidelně po vytištění určitého počtu kopií v závislosti na daném typu tiskárny. Nicméně zařízení, která jsou k dispozici jsou schopna zasílat i zaseknutí papíru, takţe uţivatel se ani nedozvěděl o nějaké závadě, protoţe při vyjmutí zmačkaného tisku se poškozená stránka automaticky vytiskne znovu z vyrovnávací paměti tiskárny. Další důleţitou skupinou, která zasílala informace do HelpDesku jsou

44

servery. Všechny WINTEL33 servery měly nastavený HP Systém Management a byly připojeny na HP Inside Management server, který monitoroval všechny servery a v případě, ţe se na některém vyskytla kritická chyba, tak byl okamţitě odeslán poţadavek do HelpDesku na opravu této závady. Za posledních několik let, kdy byl systém v provozu, byl nejčastějším poţadavkem výměna vadného pevného disku, nebo problém se síťovým připojením. Další dvě důleţité skupiny, které pouţívaly tohoto centralizovaného systému jsou aplikace a databáze. Všechen ZSW musel být schopen zasílat zprávy o poţadovaných skutečnostech do HelpDesku. Ţádosti zaslané do HelpDesku nebylo moţné mazat. Důvodem zasílání těchto informací jsou případné pokusy o prolomení hesla vícenásobným přihlášení, neúspěšný kontrolní součet nebo chyba certifikátu a další bezpečnostní kontroly. Samozřejmě aplikace zasílaly informace i o neúspěšném zpracování dat, které by mohlo vést ke ztrátám. Zejména jsou tyto sluţby o zasílání informací vyuţívány u nočního zpracování, kdy veškeré procesy jsou automaticky nastavené a kontrola jednotlivých logů by zabrala celou pracovní dobu. Do těchto logů se přistupuje cíleně na základě zaslané informace do HelpDesku. Schéma znázorňující předchozí model podpory je zobrazen na následujícím obrázku č. 18

33

WINTEL - označení pro servery s operačním systémem MS Windows 45

Obrázek 18 : Schéma původního systému podpory


3.2.

Globální model podpory

Globální model podpory je naprosto diametrálně odlišný od lokálního modelu, neboť u tohoto modelu jsou jednotlivé oblasti infrastruktury podporovány vertikálně na rozdíl od lokálního modelu, kde byla podpora řešena horizontálně. V praxi to znamená, ţe na globální úrovni existuje mnoho týmů, které se zaměřují pouze na velmi úzkou oblast. Pod touto oblastí si můţeme představit například tyto skupiny: pracovní stanice, WINTEL Servery, UNIX servery, síťové prvky, firewally. Dále je zde mnoho skupin, které zabezpečují podporu aplikací. Pro zadávání poţadavků, které jsou standardizované, jako je například vytvoření uţivatele, reset hesla, změna nastavení aplikace nebo práv v aplikaci, slouţí intranetové stránky, kde pomocí vyplnění a odeslání formuláře se vygeneruje mail, který je odeslán do příslušné schránky daného týmu, který je zodpovědný za vyřízení poţadavku. Pak jen uţivatel čeká, zda je poţadavek vyřešen či nikoliv. Druhou skupinou poţadavků je hlášení závad v aplikaci. Tyto závady se hlásí výhradně přes telefon, kde se musí operátorovi nahlásit závada a dle uváţení ţadatele se nastaví priorita, která závisí na závaţnosti a rozsahu výpadku. Poslední 46

skupinu poţadavků tvoří ţádosti o nový hardware nebo software, který si uţivatel zadá přes intranetovou

aplikaci, která připomíná klasický e-shop. Vzhled aplikace je zobrazen

na obrázku č. 19 Obrázek 19 : Uţivatelské rozhranní HelpDesku

Zdroj : Převzato z Intranetových stránek banky

47

Pro uţivatele je velmi obtíţné tyto poţadavky zadávat, protoţe formuláře obsahují aţ příliš mnoho technických informací, které koncový uţivatel pochopitelně pro svou práci nepotřebuje znát. Představme si situaci, kdy uţivatel pouţívá svůj Home Directory34 a najednou nemá do tohoto adresáře přístup. Jeden z dotazů ve formuláři je, na jakém serveru Obrázek 20 : Proces ţádosti o vytvoření přístupu do aplikace


je umístěn Home Directory a jak se jmenuje sdílený adresář na tomto serveru. Na základě krátkého průzkumu, kdy jsem se dotázal deseti respondentů a ani jeden nebyl schopný mi tyto informace sdělit. V případě, ţe tato situace nastane, je zde ještě moţnost zavolat na servisní linku, kde vyškolený pracovník z Indie se svým typickým přízvukem poradí, jak si tyto informace zjistit, v případě, ţe mu rozumíte, protoţe i někteří rodilí mluvčí mají problém s dorozuměním s těmito kolegy. Pak jiţ zbývá jen jediná moţnost, obrátit se na lokální IT, aby pomohlo s řešením či zadáním poţadavku. Nicméně tato pomoc není součástí nového systému podpory, protoţe počet lidí v IT oddělení byl zredukován a na tyto činnosti jiţ není prostor. Na obrázku č. 20 je popsán proces vytváření ţádostí na přístup do aplikace. Jde o velmi sloţitý proces, ve kterém běţný uţivatel musí najít cestu ke splnění jeho poţadavku. 34

Home Directory - domovský adresář pouţívaný v víceuţivatelském prostředí, kam si uţivatel ukládá data nebo jsou zde přesměrovány některé adresáře z profilu z důvodu zálohovaní a řízení kapacity 48

3.3.

Průzkum spojenosti s poskytovanou podporou

Na začátku března 2011 jsem provedl průzkum spojenosti s poskytováním IT sluţeb, jak z pohledu uţivatele na globální podporu, tak pohledu uţivatele na původní model podpory. Abych si potvrdil či vyvrátil názor, ţe současný stav podpory není pro uţivatele přínosem, ba naopak povede ke zvyšování nákladů celé společnosti a k potencionálnímu ohroţení důleţitých bankovních procesů. Do průzkumu jsem zadal následující dotazy: 1. Zadal/a jsi někdy poţadavek na podporu přes Service Line Express SLX? 2. Víš, jak zjistit jaké bylo přiděleno referenční číslo? 3. Víš, jak zjistit detaily zadaného poţadavku? 4. Dostal/a jsi řešení zadaného poţadavku? 5. Víš, jak eskalovat poţadavek pokud nebylo dodáno řešení? 6.

Pokud jsi dostal řešení problému, jak bys hodnotil/a jeho vyřešení z hlediska času dodání řešení. Známkování jako ve škole. 1-velmi spokojen/a ….5 – velmi nespokojen/a?

7. Jak bys hodnotil/a jeho vyřešení z hlediska kvality řešení. Známkování jako ve škole. 1-velmi spokojen/a ….5 – velmi nespokojen/a? 8. Jak bys hodnotil/a jeho vyřešení z hlediska kvality řešení. Známkování jako ve škole. 1-velmi spokojen/a ….5 – velmi nespokojen/a? 9.

Pokud znáš číslo problémového poţadavku či incidentu, uveď jej.

10. Zadal/a jsi někdy poţadavek na podporu přes Service Line (přes telefon) ? 11. Dostal/a jsi IM number? 12. Víš jak eskalovat poţadavek zadaný přes Service Line ? 13. Měl/a jsi problém s komunikací operátora (nesrozumitelná angličtina, otázky, na které jsi nevěděl/a odpověď – moc odborné)? 14. Podle tvých zkušeností z minulosti, jak bys hodnotil/a nový supportní model v porovnání se starým modelem, kdy se všechny poţadavky reportovali do lokálního HelpDesku, to z hlediska zadávání poţadavků. 15. Kolik času strávíte při zadávání problému do HelpDesku? 16. Popiš tvé zkušenosti s novým supportním modelem? Pro provedení průzkumu jsem vyuţil sluţeb internetového portálu, který

se zabývá

publikováním průzkumů (www.vyplnto.cz). Výsledek průzkumu potvrdil můj názor, 49

ţe koncoví uţivatelé jsou v drtivé většině nespokojeni, jak se zadáváním, tak s řešením jejich problémů. Na základě výsledků jsem zjistil následující informace. 90% respondentů jiţ zadalo poţadavek přes intranet portál. 36% z nich nedostalo řešení zadaného poţadavků a 30% neví, jak zjistit v jakém stavu je poţadavek. 63 % neví, jak poţadavek eskalovat. Z 64% ţadatelů, kteří dostali řešení, ohodnotilo 45% dotázaných nejhorší známkou (5) a 36% známkou (4) a to z hlediska času dodání řešení. Co se týče kvality řešení, ohodnotili ţadatelé spíše průměrně, výsledné hodnocení má průměr (3.2). Pokud je poţadavek zadán přes telefon, tak 73% dotázaných neví, jak eskalovat nevyřešené poţadavky. 55% respondentů uvádí problémy s komunikací přes telefon z důvodu nesrozumitelnosti angličtiny operátora nebo pokládání otázek, kterým uţivatel, jako neodborník nerozumí. Na dotaz ohledně nového modelu, 73% označilo jako výrazně horší a 27% jako horší v porovnání s původním modelem podpory. Velmi důleţité z hlediska nákladů je čas, který musí strávit ţadatel při zadávání poţadavků ať jiţ přes intranet nebo přes telefon. Na grafu viz níţe jsou vidět násobky času, které stačily při zadání poţadavku dle původního modelu podpory. Do průzkumu jsem také vloţil pole pro volné vyjádření ohledně zkušeností s novým modelem podpory. Několik uţivatelů uvedlo své velmi špatné zkušenosti i s detaily, které budou předány managementu společnosti, jako jeden z argumentů pro přehodnocení zvolené strategie. Z výše uvedených výsledků je patrné, ţe proces řešení problémů není optimálně nastaven a je potřeba jej změnit. Velmi alarmující je doba potřebná k nahlášení závady či jiného poţadavku. Přes dvě třetiny uţivatelů stráví 3x aţ 4x více času neţ byli zvyklí. Pokud tyto hodnoty převedeme na peníze, tak nám, vzhledem počtům nahlášených problémů a průměrné době, která je potřeba k nahlášení poţadavku, vzniknou náklady s tím spojené. Vyjádřeno v číslech, průměrná doba nahlášení je 20 minut přes telefon a 15 minut přes intranet stránky. Průměrný počet nahlášených událostí přes telefon je cca 50 měsíčně a cca 150 přes intranetový portál. Celkem se stráví 54 hodin měsíčně zadáváním poţadavků. Nicméně bychom ještě museli započítat dobu, po kterou není vyřešen problém a uţivatel nemůţe pracovat. Tento čas strávený řešením IT podpory jsou náklady, které nejsou na první pohled vidět, ale z hlediska produktivity práce jsou velmi hmatatelné. Statistiky ohledně doby trvání poţadavků ještě nejsou k dispozici, protoţe tento model podpory uţivatelů je nasazen pouze relativně krátkou dobu. Podrobnější výsledky průzkumu jsou zobrazeny na obrázku č. 21.

50

Obrázek 21 : Vyhodnocení průzkumu


51

Závěry a doporučení Za dobu 15-ti let se struktura a logika celé infrastruktury téměř nezměnila. Samozřejmě dochází k obnovám ZSW i ASW, instalují se nové operační systémy, vylepšuje se zabezpečení, ale propojení a vztahy mezi aplikacemi zůstaly stále stejné. Rozdíl je dnes pouze v pouţití nejmodernějších technologií, jak k zabezpečení přenosu dat, tak i jejich rychlejšímu zpracování a odeslání na místo určení. Naopak velmi činorodou sloţkou infrastruktury je podpora všech výše zmiňovaných částí. Měl jsem moţnost pracovat 4 roky pro ABN AMRO (dnes RBS) jako IT specialista a 10 let být součástí týmu, který měl celou infrastrukturu banky ve své správě. Na základě této dlouholeté zkušenosti mohu říci, ţe největší a nejdůleţitější změnou, která ovlivňuje infrastrukturu banky je supportní model, který zvolí vrcholový management banky, který je bezesporu ovlivňovaný mezinárodním metodickým rámcem pro řízení IT sluţeb nazývaným Cobit v současné verzi 4.1.

V dnešním globálním světě se přesouvá práce

do levnějších zemí, coţ pozitivně ovlivňuje náklady banky, ale na druhé straně sniţuje komfort a dostupnost poţadovaných sluţeb pro uţivatele. Za dobu své praxe jsem se setkal s celosvětovým projektem přesunu IT odborníků z banky do externí firmy. Tento projekt mel tři fáze. Před třetí fází se banka rozhodla projekt nedokončit, protoţe náklady, které za sluţby externí firmy, byly několikanásobně vyšší neţ náklady na platy zaměstnanců. V této třetí vlně byla i Česká republika, která tímto byla ušetřena přechodu na outsourcingové sluţby. Důvod, proč se velké firmy snaţí o outsourcing, je zcela zřejmý . Ať jiţ je to banka nebo jiná firma, která má za předmět činnosti třeba bankovnictví, výrobu aut nebo jiný okruh podnikaní, IT problematika je těmto firmám vzdálená a radši se obrátí na specializovanou firmu, aby se o vše postarala. Navíc existují doporučené standardy jako je například ITIL, které někteří odborníci interpretují tak, ţe lokální podpora je drahá, jak se můţeme dočíst v odborných časopisech, např. zdroj [6]. Pokud se vrcholový management drţí těchto standardů a doporučení odborníků, kteří pocházejí z velkých nadnárodních IT firem, tak není divu, ţe dochází k těmto globálním změnám, které nesou značné zisky právě těmto celosvětovým IT firmám. ITIL je velmi uţitečný nástroj pro nastavení procesů ve společnosti, nicméně dle mého názoru jej velké IT korporace zneuţívají ke svému prospěchu. Tento trend se uţ v některých bankách jiţ otočil. Jak informoval zdroj [8]

o těchto

nadcházejících trendech v článku "Banky přetahují firmám IT odborníky". Dochází k tzv. insourcingu a banky přetahují zkušené IT odborníky do vlastního zaměstnaneckého poměru.

52

Dle mého názoru není moţné, aby byla rozdělena podpora jednotlivých systémů do pěti nebo deseti supportních týmů, protoţe tyto týmy pak nejsou schopny řešit problém, který můţe zasáhnout více oblastí IT infrastruktury. Ideálním modelem je outsourcing pouze rutinních činností, které nepotřebují hlubší znalost provázanosti celého IS. Nicméně je bezpodmínečně nutné, aby si banka ponechala znalost unikátních procesů uvnitř banky a nepředávala tak cenné know how cizí firmě a doufat, ţe se tato znalost nikdy neztratí. Vţdy je potřeba, aby existoval tým odborníků, kteří mají komplexní znalost infrastruktury, která jim umoţní řešit problém v širším úhlu pohledu a tím velmi efektivně a rychle problém řešit. V dnešní době je velké mnoţství aplikací dodávaných globálně, nejčastěji přes CITRIX, které jsou podporované centrálními supportními týmy. Ideální model podpory pro pobočku velké nadnárodní banky, je malý tým odborníků se znalostí kompletní infrastruktury, kteří mají informace o všech lokálních aplikacích a zároveň znalost o

rozhraních do globálních

systémů. Lokální IT by pak slouţilo jako prostředník mezi uţivatelem a globálním supportem, coţ by odstranilo problémy pro uţivatele s niţší úrovní jazykových znalostí a problém s interpretací problémů z uţivatelského úhlu pohledu na problém. Tento lokální tým by pak zodpovídal za veškerou infrastrukturu, která by se samozřejmě musela podřídit globálním standardům.

53

Seznam použité literatury Tištěné monografie [1]

VOŘÍŠEK, Jiří. nformační systémy a jejich řízení, [cit. 2011-03-31] Serifa, Praha 2007. - 978-80-7265-100-9.

[2]

VOŘÍŠEK, Jiří. Strategické řízení informačního systému a systémová integrace [cit. 2011-03-31] Management Press, Praha 2003, ISBN 80-85943-40-9.

[3]

KANISOVÁ, Hana; MULLER, Miroslav. UML srozumitelně, Computer Press, a.s., Brno 2007, ISBN 80-251-1083-4.

[4]

SUN Microsystems, Inc., Solaris Administration II. Revision B.2, Boston 1998, Part number 805-5990-01

Části tištěných monografií [5]

JANEČEK, Vladislav. Test softwaru: Virtualizace [Článek]

Computer 5/11,

Europrint, Praha 2011, ISSN 1210-8790 [6]

VITOUŠ, Martin; DVOŘÁK, Jiří. Rozhraní mezi uživatelem a IT [Článek] Computer 4/11, Europtint a.s., Praha 2011, ISSN 1210-8790

Elektronické monografie [7]

Statistický_úřad, Strukturální mzdová statistika 2008, [cit. 2011-03-31], Dostupné z WWW:

[8]

SVOBODA, Petr. Banky přetahují firmám IT odborníky, deník E15, Mladá fronta, a.s., Praha 23.2.2011. [cit. 2011-03-31], Dostupné z WWW:

[9]

Telefónica

O2

Dostupné z WWW:

Czech

Republic

a.s.,

Metodika

< http://www.itil.cz/index.php?id=1>

54

ITIL,

Praha

2007,

Seznam použitých zkratek ASW

Aplikační software

ZSW

Zakázkový software

IT

Informační technologie

ICT

Informační a komunikační technologie

ITIL

Standard, v praxi osvědčený způsob řízení IT sluţeb

SLX

Intranetový portál pro zadávání poţadavků

GAN

Označení pro globální síť

SW

Software

HW

Hardware

MDIS

Metodika popisu infrastruktury pouţívající různé úhly pohledu

UML

Modelovací jazyk a souhrn metod pro popis procesů

STP

Označení stíněného datového/síťového kabelu

PC

Osobní počítač

ČNB

Česká Národní Banka

FPS

Název aplikace pro zahraniční platební styk

CCMCS

Název aplikace pro zpracování tuzemského a zahraničního styku

55

Seznam obrázků a tabulek Obrázek 1 : ICT RBS Banky ............................................................................................ 8 Obrázek 2 : Základní stavební bloky architektury IS/IT podle [1]................................. 10 Obrázek 3 : Latence mezi Prahou a Londýnem .............................................................. 13 Obrázek 4 : WAN a LAN síť.......................................................................................... 15 Obrázek 5 : Extranet Firewall......................................................................................... 17 Obrázek 6 : Lokální Firewall .......................................................................................... 18 Obrázek 7 : IP Telefonie................................................................................................. 20 Obrázek 8 : Proxy server statistiky ................................................................................. 21 Obrázek 9 : Crontab........................................................................................................ 27 Obrázek 10 : Hardware standardy .................................................................................. 28 Obrázek 11 : Tiskové řešení ........................................................................................... 31 Obrázek 12 : Systém pro ţádost o novou aplikací.......................................................... 33 Obrázek 13 : CCMCS - Zpracování transakčních souborů ........................................... 35 Obrázek 14 : Diagram nasazení ...................................................................................... 38 Obrázek 15 : Diagram aktivit ......................................................................................... 39 Obrázek 16 : Diagram stavů ........................................................................................... 40 Obrázek 17 : Propojení všech aplikací ........................................................................... 42 Obrázek 18 : Schéma původního systému podpory ....................................................... 46 Obrázek 19 : Uţivatelské rozhranní HelpDesku ............................................................ 47 Obrázek 20 : Proces ţádosti o vytvoření přístupu do aplikace ....................................... 48 Obrázek 21 : Vyhodnocení průzkumu ............................................................................ 51

56

Seznam tabulek Tabulka 1 : Popis stavebních bloků architektury ........................................................... 11 Tabulka 2 : Kódy serverů ............................................................................................... 25 Tabulka 3 : Typy serverů ................................................................................................ 26 Tabulka 4 : UNIX systémy ............................................................................................. 28 Tabulka 5 : Seznam aplikací instalovaných na kaţdém PC ........................................... 34

57

Infrastruktura a aplikační software korporátní banky

Recommend Documents