Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod
Tvorba metasystému a popis informačních systémů v bance Diplomová práce
Autor:
Bc. David Koudelka Informační technologie a management
Vedoucí práce:
Praha
Ing. Zdeněk Voznička, CSc.
Duben, 2015
Prohlášení Prohlašuji, ţe jsem diplomovou práci na téma Tvorba metasystému a popis informačních systémů v bance 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 Praze dne 5. dubna 2015
Bc. David Koudelka
Poděkování Děkuji Ing. Zdeňku Vozničkovi, CSc., vedoucímu mé diplomové práce, za metodické vedení, za čas věnovaný mé práci, za jeho odborné rady, cenné podněty a připomínky. Poděkování zároveň patří vedení společnosti Raiffeisen stavební spořitelny, a.s. a všem spolupracovníkům
za
poskytnutí
odborné
literatury,
firemních
podkladů
a specializovaných časopisů umoţňujících celkové zpracování všech poznatků uvedených v této diplomové práci.
Anotace Tato diplomová práce se zabývá metainformačními systémy, metadaty a informačními systémy. Součástí práce je stručný úvod do problematiky a seznámení se základními pojmy. Následuje popis metainformačního systému, kde je popsána metodika tvorby a základní charakteristiky těchto systémů. Hlavním cílem je popis informačních systémů v konkrétní stavební spořitelně a ukázka reálného příkladu popisu metadat s moţnou optimalizací řešení.
V praktické části práce jsou zobecněna některá základní fakta,
dochází k porovnání teorie a praxe. Zároveň jsou navrţena doporučení ke zkvalitnění. Na závěr je vyhodnoceno splnění cíle práce a obecné zamyšlení.
Klíčová slova analýza, datová kvalita, metadata, metainformační systém, metasystém
Annotation The thesis focuses on the meta-information systems, metadata and information systems. The first part is devoted to a brief introduction to the topic and defining basic concepts. The following chapter describes meta-information systems, including a description of the methodology of the creation and basic characteristics of these systems. The aim of this thesis is a description of information systems in a concrete building society and an illustration of a real example of metadata description with a potential solution optimization. In the practical part of the thesis there are some key facts generalized and theory with praxis compared. Furthermore there are recommendations for an improvement proposed. At the same time, I propose recommendations for improvement. At the end of the thesis there is an evaluation of the meeting of the work objectives and the final part also includes a general reflection.
Keywords analysis, data quality, metadata, meta-information system, metasystem
Obsah Úvod .................................................................................................................................... 7 1
Zvolené metody zpracování .............................................................................. 9
2
Charakteristika metasystémů a metainformačních systémů ...................... 10 2.1
Systémová věda a systém................................................................................... 10
2.2
Data, informace, znalosti ................................................................................... 11
2.3
Informační systém.............................................................................................. 13
2.4
Metasystém a metainformační systém ............................................................... 15
2.5
Metadata............................................................................................................. 16
2.6
Dimenze metasystému a vazby mezi nimi ......................................................... 18
2.7
Základní operace ................................................................................................ 22
2.8
Poţadované vlastnosti ........................................................................................ 22
2.9
Architektura ....................................................................................................... 23
2.10
Moţné přínosy a rizika....................................................................................... 25
3
Kvalita dat a metadat ...................................................................................... 27 3.1
Obecný úvod ...................................................................................................... 27
3.2
Nekvalitní data ................................................................................................... 27
3.3
Kvalita metadat .................................................................................................. 28
3.4
Shrnutí kapitoly.................................................................................................. 30
4
IS v prostředí vybrané společnosti ................................................................. 31 4.1
Představení společnosti ...................................................................................... 31
4.1.1 Obchodní činnost ........................................................................................... 31 4.1.2 Akcionáři........................................................................................................ 31 4.1.3 Společnost a stavební spoření ........................................................................ 31 4.1.4 Historie společnosti........................................................................................ 32 4.1.5 Konkurenční prostředí ................................................................................... 32 4.1.6 Vnitřní struktura společnosti .......................................................................... 33 4.1.7 Obchodní zastoupení ...................................................................................... 35 4.1.8 Shrnutí údajů o společnosti ............................................................................ 36 4.2
Odbory zajišťující IT v organizaci ..................................................................... 38
4.3
Informační systémy v organizaci ....................................................................... 42
4.4
Moduly hlavní bankovní aplikace (HBA).......................................................... 43
5
5
Metasystém hlavní bankovní aplikace ........................................................... 46 5.1
Popis, resp. řízení poţadavků na změnu SW ..................................................... 46
5.2
Popis, resp. metasystém HBA ............................................................................ 48
5.3
Poţadavek na novou úlohu v HBA .................................................................... 51
5.4
Metadata konkrétní úlohy v HBA ...................................................................... 52
5.5
Popis datového modelu a relací v IS .................................................................. 61
5.6
Shrnutí kapitoly.................................................................................................. 64
6
Porovnání a návrh doporučení ke zkvalitnění .............................................. 65 6.1
Úvod do kapitoly................................................................................................ 65
6.2
Porovnání teorie a praxe .................................................................................... 65
6.3
Náměty na zlepšení a doporučení ke zkvalitnění ............................................... 68
6.4
Výsledky shrnutí, výhody a nevýhody metasystémů ......................................... 69
Závěr ................................................................................................................................. 71 Seznam použité literatury ............................................................................................... 74 Seznam zkratek ................................................................................................................ 76 Seznam obrázků ............................................................................................................... 78 Seznam tabulek ................................................................................................................ 78 Seznam příloh ................................................................................................................... 79
6
Úvod Hlavním cílem diplomové práce je analyzovat informační systémy v konkrétní stavební spořitelně a na reálném příkladu ukázat popis metadat a moţnou optimalizaci řešení. To znamená, ţe cílem práce je uvedení do základní problematiky informačních systémů, metasystémů a metainformačních systémů. Primárním cílem je pak popis konkrétního řešení v praxi, porovnání s teorií a navrţení moţných vylepšení a změn v oblasti popisu dat a metadat. V praxi to znamená, ţe se budu v práci věnovat analýze informačních systémů, a to v konkrétní finanční instituci typu stavební spořitelna. Na reálném příkladu pak ukáţu popis metadat a pokusím se navrhnout optimalizaci řešení. Tím bude naplněn cíl práce dle zadání. V úvodní části se zamyslím nad pojmy systémová věda a systém. Poté popíšu zvolené metody zpracování, základní charakteristiku uvedených systémů a seznámím čtenáře s několika důleţitými základními pojmy, jako jsou informace, znalosti, data, metadata apod. V dalších podkapitolách se budu věnovat dimenzím metasystému a vazbou mezi nimi. Přiblíţím základní operace, poţadované vlastnosti metasystému a moţnou architekturu případných řešení. Na závěr kapitoly shrnu moţná rizika a přínosy. V třetí kapitole se budu detailněji věnovat kvalitě dat a metadat. Uvedu, v čem můţe spočívat problém nekvalitních dat a zároveň uvedu, proč je kvalita dat a metadat důleţitá pro další pouţití korektních informací v informačních systémech. V následující, čtvrté, kapitole představím společnost, ve které pracuji. Budu se krátce věnovat historii, konkurenci, ale také vnitřní a organizační struktuře, včetně obchodního zastoupení firmy. Pro komplexní představu vydefinuji hlavní činnosti odborů, které řeší IS/IT v organizaci. Jiţ ve čtvrté kapitole plynule přejdu do praktické části. Začnu popisem informačních systémů v organizaci a základních modulů hlavní bankovní aplikace, která s mnoha dalšími podpůrnými systémy komunikuje přes předem definovaná rozhraní. Komunikace probíhá se systémy v rámci organizace, ale také s okolním světem, např. stahování a odesílání dat do clearingového centra, kontroly na registry apod. V páté kapitole detailněji popíšu, jak máme popsána data (tedy metadata) v hlavní bankovní aplikaci. Na několika obrázcích budu demonstrovat vlastní popis sekcí a dílčích 7
komponent bankovní aplikace, a to tak, abych neporušil obchodní tajemství stavební spořitelny ani dodavatele hlavní bankovní aplikace. V šesté kapitole porovnám řešení v naší organizaci oproti teoriím a metodice z teoretické části práce. Zároveň uvedu svůj vliv na změny v řešení, které vyústily v konkrétní vylepšení daných metadat či úprav v některých méně přehledných podpůrných aplikacích. Zkusím nalézt další náměty a doporučení ke zkvalitnění datové základny a ke zkvalitnění metadat v reálném ţivotě informačních systémů v Raiffeisen stavební spořitelně. V závěru své práce zhodnotím přínosy kvality dat, metadat, a to se zdůrazněním navrţených opatření. Zároveň uvedu, proč nemůţe být řešení shodné, a to ani v organizacích, které jsou svým zaměřením podobné či dokonce shodné. Shrnu přínosy vlastní diplomové práce, a to jak pro mě (osobní vyuţití), tak i pro čtenáře.
8
1 Zvolené metody zpracování Téma diplomové práce jsem zvolil z důvodu aktuálnosti tématu. Dalším rozhodujícím faktorem bylo to, ţe v bankovním sektoru pracuji jiţ řadu let a téma informačních systémů, jejich popisu a především kontrol a testování nových dodávek do hlavní bankovní aplikace patří mezi mé činnosti, stejně jako definice poţadavků na dodavatele. Zabývám se datovým popisem a kvalitou datové základny, a proto jsem cítil toto téma jako výzvu k získání nových obzorů a zkušeností. Zároveň předpokládám, ţe nově získané znalosti budu schopen přenést i do praktického ţivota ve své podnikové praxi. Ve své diplomové práci vycházím z odborné literatury, publikovaných článků a internetových zdrojů. Seznam pouţitých externích zdrojů je pak uveden na konci práce. Zároveň jsem vyuţil zkušenosti, statistické a datové zdroje, pracovní postupy, metodiky, data a myšlenky ze společných schůzek, a to v rámci své profesní činnosti, ke kterým mám přístup v rámci svého pracovního zařazení u zaměstnavatele. Vycházím ze své praxe v oboru v délce přibliţně dvanácti let (stavební spořitelna) a zhruba deseti let v Komerční bance (KB). Porovnávám metody zpracování, uchování dat a popisu metadat z dřívějšího působení s realitou současnou, včetně srovnání s teorií. Pouţil jsem metody pozorování, sledování reality a metody rozhovorů se spolupracovníky, ale i s pracovníky externích dodavatelů komponent informačního systému či podpůrného aplikačního softwaru (SW). Základním stavebním kamenem teoretické části práce je metodika metainformačního systému doc. Ing. Jiřího Voříška, CSc., která je rozvíjena na VŠE.1 Metody, které jsem v diplomové práci pouţil, mi umoţnily lepší pochopení problematiky metadat, metasystémů a v podstatě mi umoţnily získání nového pohledu na celou problematiku. Jsem schopen lépe pochopit současný stav popisu informačních systémů v konkrétním prostředí organizace, kde pracuji. Zároveň jsem schopen se v podnikové praxi dobře orientovat v popisech a dodávkách nových funkcionalit. Jsem schopen odhalit nedostatky v dodávkách oprav a nových funkčností do naší bankovní aplikace a umím navrhnout lepší, resp. přesnější popis jednotlivých částí systému, včetně případného odstranění duplicit.
1
VŠE – Vysoká škola ekonomická. Více o VŠE na stránkách: http://www.vse.cz/
9
2 Charakteristika metasystémů a metainformačních systémů V této kapitole se budu zabývat základními pojmy. Vysvětlím některé základní myšlenky ohledně systémového myšlení, vědy a obecně popíšu systém, informační systém a s tím související pojmy.
2.1 Systémová věda a systém Rozvoj systémových věd byl podmíněn zejména pokroky v oblasti systémového myšlení, v matematice, výpočetní technice a podobných vědních oborech. V reálném ţivotě velmi často posuzujeme okolí a zároveň se snaţíme rozhodovat na základě vlastních vnitřních mentálních modelů. Tím odhadujeme, co by se mohlo v okolním světě stát a jaká zvolená strategie nás můţe dovést ke zvolenému cíli. Vlastní mentální modely však mohou být poměrně omezené, neboť naše znalosti a zkušenosti nemusí být dostatečné. V mnoha případech si snaţíme realitu přiblíţit vlastnímu modelu, čímţ ji zjednodušíme, abychom v ní dokázali najít jednoduše smysl a vlastní, ale v zásadě neobjektivní logiku. Systémové myšlení a následně i systémová dynamika a analýza nám pomáhá překonat naše mentální modely. Systémové myšlení je obecně vzato modernějším přístupem, neţ systémová dynamika. Na systémovou dynamiku přímo navazuje. Z ní pak přejímá řadu věcí, které následně rozvíjí. Nástroje a přístupy rozvíjí tak, aby z nich následně mohli těţit maximum odborníci, kteří jsou v systémové dynamice speciálně vzdělaní, a zároveň i běţní uţivatelé - studenti, technici, manaţeři, ale i vědci z jiných oborů [3]. Samotné systémové vědy se vyčleňují jako samostatný odborný proud na konci dvacátého století, kdy se vědci snaţili reagovat na příliš velkou specializaci oborů, ztrátu porozumění mezi odborníky a vědci, a to jak ve vzdálených, tak i poměrně příbuzných disciplínách. V mnoha oborech se pak v podstatě objevovaly tytéţ poznatky a zákonitosti, coţ mělo za důsledek velký reţijní čas vývoje či poznání v mnoha vědních oborech. Systémové myšlení lze pak definovat, jako sdílené paradigma, které slouţí pro vytváření lepších mentálních modelů, jejich kvalitnější simulaci a efektivnější komunikaci. V podstatě se jedná o metodu učení, řešení problémů a společný jazyk zainteresovaných osob [3].
10
Bylo dokázáno, ţe existující vztahy a spolupráce objektů a jejich pochopení je de facto důleţitější neţ části objektů samotných. Na poměrně různorodých případech se daly nalézt velmi podobné či analogické procesy. Obecným cílem systémové vědy je nalezení společné řeči, aby mohla být pouţita při týmové práci. Dalším cílem je moţnost přenositelnosti výsledků mezi jednotlivými vědními obory a moţnost vypracovávání jednotných metodologií. V neposlední řadě se dají formalizovat některé postupy při práci s různými systémy. Základním prvkem nebo pojmem je systém. Definice systému můţe být různá. Např. můţeme systém popsat jako soubor lidí, metod a technologických prostředků, které zabezpečují, řídí, prezentují a navzájem tvoří jeden celek. Obecně jej můţeme chápat jako mnoţinu věcí a vztahů mezi nimi. Systém můţeme také chápat jako účelově definovanou mnoţina prvků a vazeb mezi nimi, které spolu se svými vstupy a výstupy vykazují jako celek ve svém vývoji kvantifikovatelné vlastnosti a chování [18]. Definicí se budu zabývat v samostatné podkapitole.
2.2 Data, informace, znalosti Všechny tyto pojmy jsou si velice blízké a navenek působí jako synonyma. Pojem data pak představuje výraz pro údaje, které se pouţívají pro popis nějakého konkrétního jevu nebo vlastnosti pozorovaného objektu. Zjednodušeně se dají data charakterizovat jako libovolná posloupnost znaků, přičemţ se nemusí jednat pouze o chápání v oblasti výpočetní techniky, typicky bity a bajty. Pod posloupností se mohou skrývat jakékoli libovolné znaky, např. i ty, které vůbec neznáme či u kterých si nedokáţeme představit, ţe se jedná o nějaké znaky či o nějaké písmo. Posloupnost dat můţe být jiţ sama o sobě na první pohled pro nás nesrozumitelná, sloţená z něčeho, co vůbec nemusíme chápat. Znaky posloupnosti, kterou nechápeme, mohou pro nás být jen jakási neurčitá a nic neříkající data. Ta nám mohou, ale nemusí něco konkrétního říkat [16]. Data můţeme definovat jako vyjádření skutečností formálním způsobem tak, aby je bylo moţno přenášet nebo zpracovávat. Data jsou číselné nebo jinak symbolicky reprezentované údaje a hodnoty nějakých entit či událostí. Data jsou zároveň jakékoli fyzicky zaznamenávané znalosti, poznatky, zkušenosti nebo výsledky pozorovacích
11
procesů, činností apod. Data jsou základní sloţkou pro tvorbu informace a de facto jsou základem informačního bohatství organizace. Informace můţeme chápat jako cíleně a funkčně interpretovaná data. Neodborně (laicky) lze definovat informaci jako sdělení či sdělitelnou znalost. Informace nám přináší určitá fakta. V odborné literatuře existuje velké mnoţství obsáhlých definic a není potřeba je všechny zmiňovat, neboť pojem informace je jiţ všeobecně znám, rozšířen a skloňován v mnoha odvětvích. Definice informace je různá, dle pohledu: komunikačního pojetí, filozofického pohledu, matematického přístupu nebo kybernetického pojetí. V obecném pojetí se informace můţe chápat jako údaj o reálném prostředí, o jeho stavu a procesech v něm probíhajících. Kvalitní informace by měla být solidní, spolehlivá a důvěryhodná. Pochopitelně informace můţe být nějakým způsobem napadena, narušena či deformována, a to i záměrně. Proto je potřeba klást důraz na zdroje dat a informací. Načerpaná data a kvalitní informace je potřeba chránit a zálohovat. Znalost je pak informace, která prošla nějakým uspořádáním a analýzou, aby se stala srozumitelnou a pouţitelnou k řešení problémů nebo byla vyuţita při rozhodovacích procesech. De facto je znalost transformovaná informace do vyuţitelné podoby a je zaloţena na praktickém významu, vyuţití a učení. Informace je de facto zorganizována a analyzována tak, aby byla srozumitelná a pouţitelná pro řešení problémů nebo rozhodování a učení. Typicky jsou znalosti zabudovány v dokumentech a archivech, ale i v organizačních postupech, procesech, vnitřních předpisech a normách. Nejprve je potřeba se „něco“ naučit, a to pak umět vyuţít v praxi.
Obrázek č. 1: Hierarchie: Data-Informace-Znalost-Moudro. Zdroj: [3]
12
2.3 Informační systém Systém je komplex informací, které spolu vzájemně souvisí a interaktivně spolupracují. Informační systém (IS) je pak komplex lidí, pouţitých informačních technologií (IT), informací, řízení chodu systému a organizace práce. IS zabezpečuje propojení metod a technických prostředků na prostředí, které následně slouţí k uchování, sběru, přenosu a dalšímu zpracování dat. Účelem těchto kroků je tvorba, ale i prezentace informací. IS je nějakým konkrétním způsobem organizován a začleněn do vlastní organizační struktury organizace, má určité ekonomické charakteristiky a musí být určitým způsobem řízen. To platí jak pro období budování IS, tak pro dobu jeho provozování a fungování [13]. Pojem informační systém je velmi podobný pojmu byznys systém. Komponenty IS se obvykle shodují s komponentami byznys systému, často je zde však důleţitější informace o komponentě (o člověku, stroji, materiálu apod.) spíše neţ ona komponenta byznys systému samotná. Z tohoto pohledu můţeme IS chápat jako součást byznys systému, a to jako součást neoddělitelnou. Informační systém a byznys systém se tedy mohou shodovat svými komponentami, liší se ale svým účelem. Účelem informačního systému je zajištění správných informací na správném místě ve správný čas [2]. Podnikový IS (PIS) slouţí jako podpůrný nástroj pro jeho řízení. Jeho hlavním cílem je automatizace procesů pro kaţdodenní rutinní činnosti, jedinečnost dat v systému pro všechny uţivatele a zároveň IS umoţňuje sledovat a kontrolovat běţné činnosti [1]. Některé informace pak slouţí i jako podklady pro rozhodování. Přidanou hodnotou IS je pak ve většině případů vloţené know-how dodavatelskou firmou. Jsou optimalizovány procesy a jednotlivé funkčnosti podporují automatizaci zpracování dat, čímţ se organizace stává konkurenceschopnější. V současné době je vlastně nemoţné řídit firmu bez SW podpory, neboť v současné době je organizace povinna plnit celou řadu zákonných poţadavků, norem, vyhlášek či nařízení (např. v účetní oblasti, personální oblasti, vykazovací povinnosti na nadřízené instituce, konsolidace v rámci skupiny, ISO normy a zákony). SW umoţňují automatické vytváření alespoň části těchto dokumentů. Na následujícím obrázku je znázorněno „Obecné schéma globální architektury IS/IT“. Obrázek znázorňuje jednotlivé vrstvy, jejich propojení a spolupráci přes celé vertikální členění. Jedná se o zjednodušený tříúrovňové rozdělení – EIS (Executive Information System, též IS exekutivy - výkonné složky managementu; podpora strategického řízení), 13
MIS (Management Information System - manažerský informační systém; BI – Business Intelligence; podpora operativní a taktické části řízení), TPS (Transaction Processing System – transakční a procesní systém (de facto operativní části IS – typicky provozní IS); ERP - Enterprise Resource Planning, CRM - Customer relationship management, RIS Reservation IS, GIS - Geografic IS, MRP - Material Resource Planning; typicky provozní IS, zajišťující hlavní činnost společnosti).
Obrázek č. 2: Obecné schéma architektury IS/IT. Zdroj: [13]
Kaţdá z úrovní je pak ideálně obohacena o metadata a společně pak tvoří metainformační systém, jak je ve zjednodušené podobě zachyceno na Obrázku č. 3. V podstatě se ve všech vrstvách jedná o evidenci primárních a výsledných dat (zdroj dat, formát dat, autor a správce dat, struktura dat, apod.) a evidenci procedur a funkcí, které tato data spravují (transformace dat, sled událostí – metodika, parametry a atributy, apod.). Na řídící úrovni Metainformační systém (MtS) popisuje transformační záleţitosti aplikačního SW (ASW) vybavení manaţerů, zatímco na úrovni výkonného IS se popisují primární data společnosti. Pokud jsou data spojována z více zdrojů, je popis výrazně sloţitější.
14
Obrázek č. 3: Obecná architektura IS rozšířená o metasystém. Zdroj: [4]
2.4 Metasystém a metainformační systém Obecně se dá pojmem metasystém označit takový systém, jeţ popisuje, resp. modeluje jiný systém, typicky pak informační systém. Vlastní metainformační systém je tedy tvořen metadaty a operacemi. Operace pak umoţňují zpracování a uchování dat v patřičné podobě a potřebné kvalitě [7]. V současné době si téměř ţádná společnost nemůţe dovolit fungování bez podpůrného informačního systému. Proto základním nárokem na informační systém je jeho komplexní podpora činnosti společnosti, ideálně v plné šíři napříč organizační strukturou, aby mohly být plněny základní strategické, střednědobé a krátkodobé cíle, ale i operativní plány. Metainformační systém pak mimo jiné popisuje procesy, data, operace a zároveň přiřazuje, resp. popisuje odpovědnosti za jednotlivé části. Je potřeba mít na zřeteli neustále se rozvíjející sloţitost datové základny a datových struktur. Zvyšující se poţadavky na vlastní IS, které mají vliv na sloţitost datové architektury, která musí být schopna na dané změny a poţadavky reagovat. Z uvedeného jasně vyplývá, ţe se zvyšuje potřeba mít celý systém řádně popsán a provázán, aby jednotlivé části systému pracovali efektivně, nedocházelo ke ztrátě dat či zbytečnému duplikování mnoha údajů. K tomuto účelu by nám měl právě metasystém slouţit. Metainformatika je pak odvětví informatiky, jejímţ úkolem je shromaţďovat a podle potřeby i poskytovat data o jiných datech interního IS (případně i o datech z externích systémů) [4]. Metasystém je pak navrhován jako specifická součást IS/IT podniku. V podstatě se jedná o nástroj systémové integrace, jehoţ hlavním cílem je dosaţení a udrţení jednoty IS s cíli a hlavními aktivitami podniku a udrţení jednoty všech částí IS/IT navzájem [7]. 15
2.5 Metadata Metadata popisují data (typicky data IS/IT) organizace a jejich významné vazby na další součásti organizace, včetně podnikových aktivit a procesů [7]. MtS vyuţívá těchto metadat, tedy dat, v nichţ jsou popsány, jak datové zdroje, tak jejich formáty. Data zároveň popisují transformační pravidla a proudí prakticky ze všech úloh IS. V datech jsou popsány zejména postupy pro převody dat mezi aplikacemi, podklady pro plnění datových skladů, způsoby výpočtů ukazatelů pro podporu manaţerské práce apod. Metadata jsou obsahem MtS. Ten s nimi pracuje jako se svými primárními daty. Metadata neslouţí k řízení hlavních nebo podpůrných procesů, ale naopak, jsou určena k řízení a sledování informačních zdrojů, a tím pak de facto zprostředkovaně slouţí jako nástroj k uspokojování informačních potřeb manaţerů na všech úrovních řízení společnosti. Data vstoupí do MtS organizace - podporují činnosti podniku na operativní úrovni řízení podniku (TPS vrstva - Transakční a procesní systém - viz Obrázek č. 4); do aplikací podporující manaţerskou činnost (ostatní vrstvy na tomtéţ schematickém znázornění).
Obrázek č. 4: Schematické znázornění úlohy metadat v architektuře úloh. Zdroj: [4]
Kaţdý ze zde uvedených zdrojů metadat má trochu jiný význam pro řízení datových zdrojů. Zatímco v provozním IS společnosti jsou předmětem zájmu MtS primární data
16
a všechna fakta s nimi související, z manaţerských aplikací proudí do MtS organizace především metadata o transformacích primárních dat [4]. Metadata můţeme členit dle NISO2 do tří základních kategorií [19]: i.
popisná metadata - slouţí k identifikaci a vyhledání objektu (typické atributy: název; autor; klíčová slova),
ii. strukturální metadata - definují vnitřní organizaci subjektu (organizace kapitol), iii. administrativní metadata - uchovávají technické a přístupové informace o tom, jak s daty nakládat (autorská práva či formát). Z pohledu statistických dat se pouţívá spíše členění metadat podle organizace OECD3. Organizace rozděluje metadata pouze na dvě základní kategorie [9]: i.
strukturální metadata - představují identifikátor a deskriptor dat (typicky: hlavičky řádků a sloupců; informace o jednotkách, obdobích apod.),
ii.
referenční metadata - popisují metodický obsah a kvalitu dat (např. dílčí/předběţná data).
Metadata se také člení dle toho, komu jsou primárně určena, resp. dle kategorie cílových skupin uţivatelů. Základní strukturální metadata jsou určena pro nejširší skupinu uţivatelů. Jedná se o skupinu, která není expertem pro danou problematiku, ale spíše klasickým konzumentem informací. Střední skupina uţivatelů se jiţ částečně v problematice dokáţe orientovat a je schopna data vyuţít v rozhodovacích procesech. K tomu potřebuje znát souhrnná metadata, typicky informace o kvalitě dat. Třetí a nejméně početnou skupinu tvoří uţivatelé, kteří data vyuţívají jako zdroj pro další analýzu dat, systémů apod. Jedná se o pracovníky či uţivatele, kteří jiţ zvládají pokročilejší či specializované techniky dolování a výběru dat. V podstatě se jedná opět o klasické pyramidové uspořádání, kdy na vrcholu jsou základní popisná metadata. V stále větší hloubce je potřeba mít metadata popsána, a to v co nejširším pojetí, aby mohly být informace a data co nejpřesněji interpretovány.
2
Více o společnosti National Information Standards Organization: http://www.niso.org/home/
3
Více o společnosti Organisation for Economic Co-operation and Development: http://stats.oecd.org/
17
2.6 Dimenze metasystému a vazby mezi nimi MtS slouţí jako nástroj systémové integrace a je navrhován jako zvláštní, resp. specifická součást IS/IT podniku. Umoţňuje analýzu, popis a řízení dimenzí z mnoha hledisek dle metodologie MDIS4. Tato metodika je vyvíjena od počátku 90 let na VŠE, přičemţ jejím hlavním cílem je vývoj a údrţba komplexního integrovaného IS, který následně optimálně podporuje všechny podnikové cíle. Jedná se o systém, který je sloţen z komponent různých výrobců a dodavatelů, které jsou spolu efektivně propojeny a vzájemně spolupracují. Systém následně podporuje všechny významné procesy napříč organizací. Základem metodologie MDIS je Systémová integrace, která představuje přístup k vývoji a provozu IS tak, aby se minimalizovala rizika spojená s vývojem a zavedením systému do provozu a zároveň maximalizovaly efekty IS. Cílem integrace je vytvoření a údrţba integrovaného IS, který optimálně vyuţívá IT firmy k maximální podpoře cílů organizace. Principem systémové integrace je, ţe poţadované funkce IS jsou odvozeny od podnikových cílů a od potřeb podnikových procesů [17].
Řešitelské pohledy na obsah a organizaci vývoje a provozu IS se řeší ve dvou základních dimenzích. K obsahové dimenzi patří zejména funkce a procesy, data a informace, organizační a legislativní aspekty, pracovní a sociální aspekty, SW, HW, ekonomické a finanční aspekty. Do metodicko-organizační dimenze patří pak časové hledisko, metody, dokumenty a principy řízení jednotlivých fází vývoje. i.
Obsahová dimenze – zaměřuje se na předmět řešení. Řeší otázku, co se vlastně řeší. Tyto dimenze jsou řešeny v podstatě ve všech fázích vývoje IS. Aby bylo výsledné řešení konzistentní, musí se dimenze řešit v závislosti na sobě. Je nutné analyzovat a navrhnout všechny jejich vzájemné vztahy. Mezi obsahové dimenze patří: Data a informace – řeší, jaké typy dat a informací jsou potřebné pro hlavní podnikové funkce. Zároveň řeší strukturu a obsah datové základny. Dále řeší, jak budou dané informace fyzicky uloţeny. Získané poznatky jsou pak obsaţeny v návrhu a realizaci datové architektury IS a jsou děleny dle dalších základních charakteristik (Typ informace – signální, strukturální a genetická informace; Úroveň obecnosti informace – Vlastní obsah informace; Abstraktní nebo
4
Multidimensional Development of Information System - Metodický základ systémové integrace
18
konkrétní; Časové vymezení informace – historická, aktuální a prognostická; Zdroj informace; Kdo informaci získal; Způsob uloţení informace – v databázi, v dokumentaci, apod.). MtS zachycuje pak všechny potřebné údaje o vztazích objektů, datových strukturách, datových tocích, segmentech apod. Funkce a procesy – tato dimenze se zaměřuje na procesy probíhající v podniku a jejich moţnou podporu IS. Výsledky jsou obsaţeny v návrhu a realizaci funkční a procesní architektury IS. MtS zachycuje cíle IS podniku a dekompozici do subsystémů, funkcí apod. Zaznamenává informace o podnikových procesech, o událostech, které tyto procesy vyvolávají, ale i termíny a časové okamţiky, kdy má konkrétní událost nastat. MtS popisuje hierarchickou strukturu funkcí IS. Základní úroveň tvoří elementární funkce, které jsou popsány svými vstupy, výstupy a řídícími daty. MtS popisuje pravidla transformace a algoritmus, který transformuje vstupní data na data výstupní. Zároveň popisuje sloučené mnoţiny souvisejících funkcí z podřízených úrovní. Kaţdá funkce či procedura je spuštěna nějakou konkrétní událostí, které můţeme rozdělit na typ události informační, která nastává příchodem nějaké informace, časový typ události, kdy se startuje v určitém čase a typ události mimořádný, kdy je nějakým způsoben narušen normální průběh procesů. Organizační, personální a legislativní aspekty – legislativní dimenze určuje směrnice, normy a především zákony, které musí IS respektovat podle platného znění zákonů a norem, a to jak ve vazbě na konkrétní zemi podnikání, tak i ve vazbě na zemi, kde má sídlo, příp. na zákony, směrnice a normy platné v zemích Evropské unie. Organizační dimenze popisuje organizační strukturu podniku platnou v době provozování jednotlivých verzí IS. MtS musí evidovat a sledovat hierarchické členění organizace a útvarů. Musí evidovat počty funkčních míst a jejich pracovní náplň v jednotlivých útvarech. MtS eviduje také pravidla platná pro průběh procesů a zároveň udrţuje informace o pracovnících ve funkcích a jejich umístění v lokalitách. Pracovní, sociální a etické aspekty – dimenze určuje potřebnou strukturu pracovníků organizace (tzn. jejich kvalifikace a počet) po zavedení IS. Metodologie MDIS v zásadě sleduje sociální a etické důsledky, které by mohly vzniknout zavedením IS a navrhuje nutná opatření související se zavedením nového IS (propouštění, rekvalifikace, školení, nábor nových zaměstnanců). 19
V MtS tato dimenze není samostatně zastoupena, většinou je podchycena jiţ v dimenzi Organizace a personál. Softwarová – SW MDIS dimenze určuje programové vybavení systému. Určuje parametry, typy a vzájemné vazby komponent. Zároveň řeší, které komponenty mají být vyvíjeny vlastními silami a které budou zakoupeny. U vyvíjených komponent definuje nástroje a vývojové prostředí. MtS pak uchovává základní údaje o ASW, o modulech aplikací, včetně SW pomocí kterého je IS vyvíjen, včetně aplikací pro podporu, jako jsou CASE nástroje. Zároveň dokumentuje informace o základním SW jako je operační či databázový systém. Hardwarová – určuje technické vybavení systému, určuje typy, parametry a počty počítačů, periferních zařízení a komunikačních sítí. Ekonomické aspekty – dimenze zahrnuje především finanční náklady, tj. časový harmonogram plateb, nákladovost IS (tvorba a vlastní provoz IS), plánované přínosy související se zavedením IS, včetně analýzy rizik. Mimo jiné obsahuje analýzu a výběr kritických procesů, které mají být podpořeny funkcemi IS, aby bylo dosaţeno co moţná nejvyšších ekonomických efektů. Opět většinou není přímý popis objektů v MtS, ale všechny tyto podklady bývají v popisech vlastností objektů v jiných dimenzích. Např. lze dohledat ceny SW a HW částí, mnoţství spotřebovaných lidských zdrojů apod. ii. Metodicko-organizační dimenze – zaměřuje se na způsob řešení, tedy na otázku, jak a čím se řeší vývoj a provoz. Patří sem: Metody a normy – dimenze určuje metody, techniky a nástroje pouţívané v jednotlivých fázích vývoje IS pro analýzu, návrh, následnou implementaci a pozdější provozování IS. MtS podporuje integraci různých metod a nástrojů. Pro IS/IT pak poskytuje údaje a odkazy na literaturu, příp. na další podpůrné metodiky či nástroje. Dokumenty – dimenze určuje, které dokumenty vznikají v průběhu vývoje a provozu IS, co je jejich obsahem a jaké mají na sebe vazby. MtS poskytuje podporu a různé nástroje pro dokumentaci k systémům, která bývá v hodně rozličných podobách. Kvalitní, úplná a hodnotná dokumentace bývá kritickým místem mnoha organizací, a proto je potřeba nepodcenit dokumentační dimenzi. Zpětné popis jsou velmi pracné a časově náročné.
20
Principy řízení – dimenze určuje postupy řešení jednotlivých fází vývoje IS, pravidla a organizaci vývoje a provozu. V podstatě se popisuje kdo, kdy a co má vykonat. Zároveň určuje role a velikosti podílů na řízení a vývoji IS - externí specialisté, vrcholové vedení a koncoví uţivatelé. De facto se optimalizují lidské, finanční a materiální zdroje, aby byly dosaţeny cíle při efektivním vyuţití zdrojů. Čas – v MtS se udrţují údaje o jednotlivých projektech, etapách projektů a časových harmonogramech. Bezpečnost – v MtS dříve opomíjená sloţka, která během času dosahuje velkého významu. Je potřeba vyřešit oprávnění uvnitř firmy, tedy klasická oprávnění k funkcím, tabulkám i procesům, ale také ve vazbě na případné bezpečnostní opatření proti vnějším vetřelcům (viry, ataky hackerů, apod.). Pro správné fungování MtS jsou velmi významné vazby mezi jednotlivými dimenzemi. Jejich existence pak umoţňuje realizovat hlavní funkce a vlastnosti metasystému. Obsah metadatabáze a vazby mezi jednotlivými částmi metadatabáze umoţňují analyzovat a popsat, např. následující vazební situace v IS [7]. i.
Vazby mezi objekty datové, funkční, procesní a organizační dimenze umoţňují: a. definovat přístupová práva k datům, funkcím a procedurám, b. analyzovat frekvenci uţití jednotlivých procedur a funkcí, c. vyhledávat chybějící nebo naopak nadbytečné typy dat.
ii. Vazby mezi objekty datové, HW a organizační dimenze umoţňují: a. analyzovat umístění datových struktur v jednotlivých lokalitách na jednotlivých počítačích, tzn., ţe dochází k analýze distribuce dat, b. analyzovat vývoj a stav nároků IS na kapacitu systému a kapacitu sítí. iii. Vazby mezi SW, datovou a funkční dimenzí umoţňují popsat a analyzovat datové toky mezi jednotlivými aplikacemi, včetně společně pouţívaných dat, z čehoţ lze následně analyzovat případné duplicity ve zpracování. iv. Vazby funkčního místa organizační struktury na skupiny funkcí či procesy popisující jednotlivé řídící činnosti umoţňují odhalit rozpory v přiřazených zodpovědnostech či umoţňují odhalit procesy, funkce apod., kde není zodpovědný pracovník nadefinován.
21
v.
Vazba organizační struktury na HW dimenzi popisuje pak umístění jednotlivých komponent IT v útvarech a lokalitách organizace. Dá se tedy snadněji analyzovat potřeba vybavení IT, propojení mezi útvary, odbory apod.
vi. Vazby projektů na cíle a funkce IS umoţňují zjištění nepokrytých cílů či duplicity v projektech. Tím se dají analyzovat a odhalit problémy v návaznosti etap projektu či projektů jako takových. vii. Vazby projektů, funkční a personální dimenze umoţní evidenci a vyhodnocení poţadavků, námětů a stíţností pracovníků ve vazbě na projekty, cíle či funkce IS.
2.7 Základní operace Důleţitým faktorem pro realizaci základních operací MtS, je především dobře definovaný a správně naplněný obsah metadabáze, popis objektů a vazeb mezi nimi, a to napříč dimenzemi. Operace realizují buď pasivní, nebo aktivní roli MtS. Operace, které realizují pasivní roli MtS, nevyţadují propojení IS a MtS. V zásadě se jedná o dotaz na strukturu a obsah IS/IT, o analýzu konzistence, kdy jsou analyzována nadbytečná data, chybně navazující procesy či chybějící celé části IS apod. Dále jsou to operace, kdy je vytvářena metadabáze, typicky přidávání či aktualizace popisů, objektů, nových datových prvků, změny ve struktuře. Jsou to také operace analýzy dopadů změn na moduly, procesy a funkční místa. Operace vyţadující přímé propojení IS a MtS pak realizují aktivní roli MtS. Jde o operace sledování provozu, typicky pak sledování vytíţenosti jednotlivých zdrojů a monitorování přístupů. Jedná se také o operace řízení IS/IT jako je: kontrola přístupových oprávnění, spouštění jednotlivých úloh, zajištění reakcí IS na konkrétní události apod.
2.8 Požadované vlastnosti Na základě různých potřeb uţivatelů, které jsou definovány jejich pravomocí, rolí a typem, můţeme vydefinovat základní poţadované vlastnosti MtS. Jde především o přiměřenou pracovní náročnost, jednoduchost pouţití, pruţnost a funkčnost MtS jako takovou. Samotný provoz MtS nesmí na uţivatele klást takové nároky, které by nebyly vyváţeny patřičným efektem. MtS by měl být schopen importovat data z CASE nástrojů. Velké 22
mnoţství atributů a vlastností objektů by mělo být nepovinné a jejich vyuţití je pak na uţivatelích. Minimalizace náročnosti by měla být podporována i v provozu MtS (automatické reakce na podněty), čímţ dochází k redukci chyb a ke sniţování nákladů na IT a IS organizace. Obecně hovoříme o přiměřené pracovní náročnosti. Pružností se potom rozumí umoţnění popisu IS jakoukoli metodikou, a to ať uţ strukturovaně či objektově orientovanou. Zároveň musí MtS být schopen přijímat další objekty, vazby, operace a jejich popisy dle potřeb uţivatelů. Předpokladem kvalitního SW je přehlednost a jednoduchost funkcí a komunikace. Z pohledu jednoduchosti užití MtS je potřeba vyjít z následujícího principu. Analýza, návrh i samotná implementace musí vycházet ze základních standardů (algoritmických, komunikačních). Ty umoţní práci obdobným způsobem pro různé funkce. De facto se unifikuje tvorba SW MtS, čímţ se MtS i snadněji udrţuje. Druhým základním principem je umoţnění popisu stavu IS/IT i v nekonzistentní podobě. Pak ale MtS musí poskytnout nástroj pro kontrolu konzistencí. Např. striktní poţadavek na vazbu SW s počítačem znamená, ţe pak nemůţeme popsat SW, který dosud není provozován. MtS musí zabezpečovat celou řadu funkcí (základních operací) pro heterogenní skupiny uţivatelů. Do MtS se musí promítat změny v okolí podniku a i v organizaci samotné, a to i přes velmi dynamický vývoj IS/IT. Hovoříme o funkčnosti MtS, kdy MtS podporuje většinu činností na všech úrovních řízení (operativní, taktické, strategické) vývoje a provozu IS/IT, včetně nových projektů a procesů. Funkce zároveň umoţní všem zaměstnancům orientovat se v systémech, a to jak v uloţených datech, tak i při změnách SW, kdy mohou dohledat potřebné informace o změnách apod. Pokud organizace komunikuje s externí organizací, pak tyto funkce umoţní vzájemnou informovanost o obsahu a formě předávaných dat a informací, resp. o záleţitostech, které se týkají komunikace.
2.9 Architektura MtS podporuje různé oblasti a úrovně řízení. Všechny základní operace MtS jsou obsaţeny v hlavních funkcích. Architektura musí řešit především vazby mezi funkcemi, a to ve všech úrovních. Nejvýše je strategické řízení, které musí vycházet z globální strategie organizace. Podporuje zejména činnosti, které určují celkový směr a koncepci organizace. Mimo jiné
23
podporuje projekty reengineeringu, dokumentaci dle ISO norem. Dále obsahuje podporu globální a informační strategie firmy. Strategické řízení působí a zároveň je ovlivňováno plánováním IS/IT. Tato skupina zajišťuje podporu taktického řízení. Udrţuje konzistentní stav mezi řešenými, právě provozovanými, ale i budoucími či plánovanými projekty. Tzn., ţe např. podporuje evidenci projektů a jednotlivých etap, definuje jednotlivé projekty, plánuje rozvoj IS/IT, bilancuje plánované a stávající zdroje apod. Aby plánování bylo účinné a smysluplné, je potřeba analýza provozu IS/IT. Zde se nachází skupina funkcí, která podporuje nejenom analýzu, ale současně kontroluje plnění pravidel, čímţ plní zpětnou vazbu z provozu do úrovně strategického a ataktického řízení. Sem patří např. analýzy okolí systému, důleţitých rozhodovacích událostí, externích partnerů, organizačních a funkčních struktur apod. Výsledky analýz jsou většinou zaznamenány v MIS, kde jsou pak interpretovány přes příslušné databázové kostky. MIS představuje IS/ICT podporu pro vrcholové i operativní rozhodování, která můţe mít buď podobu sjednocených, předmětově orientovaných databází navrţených za tímto účelem nebo jednoduchých analýz prováděných v DB transakčních systémů [5]. Plánování má vliv na metodické řízení provozu a na řízení vývoje IS. Funkce metodického řízení provozu jsou realizovány nad metadaty a podporují především pravidla pro řízení a plánování. Zahrnují např. kapacitní plánování provozu, specifikaci záloţních řešení a obecně popis pravidel jednotlivých subsystémů. Funkce řízení vývoje slouţí ke specifikaci pravidel a řízení projektů. Zahrnuje pak předávání údajů z/do CASE nástrojů a přebírá informace o jiţ řešených situacích z repozitury CASE nástrojů. Jádro funkční části MtS popisuje stavy dle dimenzí a verzí. De facto popisuje verze IS/IT ze všech moţných hledisek do významných podrobností (minulé, současné, budoucí). Nad současnou verzí běţí funkce slouţící ke sledování stavů datové základny. Dochází k monitoringu provozu a jsou monitorovány procesy, vazby a konzistence, stejně jako vyuţití funkcí IS, DB a MtS. Zpětnou vazbou se pak promítají do analýzy provozu, a tím se vytváří opět základní informace pro strategické přehledy, které se vyuţijí při plánování budoucího vývoje. Funkce řízení provozu umoţňují především správcům IS/IT, příp. oprávněným kvalifikovaným osobám, aktivaci jednotlivých funkcí IS. Jsou to funkce např., pro
24
definici uţivatelských rolí, přístupů a přístupových oprávnění k údajům/datům v IS, definice plánovaných automatických operací, kontrola těchto automaticky, ale i manuálně spuštěných událostí, zpřístupnění nebo vystavení některých funkcí externím partnerům. Potom jsou tu ještě funkce slouţící k ukládání a vyuţití údajů z jiných zdrojů. Jedná se o funkce skupiny rozhraní. Funkce MtS pak vyuţívají nejenom data z metadatabáze, ale i z databází jiných aplikací. Příkladem můţe být sledování docházky, evidence mezd, evidence majetku, apod. Tato architektura navrţená na VŠE je pak graficky znázorněna na následujícím obrázku.
Obrázek č. 5: Architektura MtS. Zdroj: [7 - vlastní úprava]
2.10 Možné přínosy a rizika Obecně je pak potřeba zváţit přínosy a rizika zavedení MtS v konkrétní organizaci. Částečně se dá vycházet z předchozích zkušeností při zavádění či pouţívání MtS v konkurenční, ale i partnerské organizaci. Zároveň se dá předpokládat, ţe jiţ existuje řada případových studií uveřejněných na internetových stránkách či v odborných publikacích.
25
Podle Voříška [7] je moţné přínosy MtS spatřit především ve vytvoření efektivních vazeb mezi globální a informační strategií a taktickým a operativním řízením. MtS jsou vysoce perspektivním nástrojem při řešení velkých různorodých IS (integrace IS na různých platformách). MtS se také stávají společnou platformou řešení problémů. Sjednocují pohledy na IS/IT a přibliţují tyto pohledy významným skupinám uţivatelů v různých rolích (vývojář, analytik, provozní personál). MtS přináší analýzy a popisy vazeb k okolí systému, coţ umoţňuje integraci s okolím a poměrně rychlou reakci na případné změny. Koncepce zaloţená na multidimenzionálním základu zajišťuje úplnost popisu projektů, metodik, vazeb, zdrojů, konzistencí apod. MtS jsou pochopitelně zatíţeny také celou řadou rizik. Rizika MtS pak Voříšek spatřuje např. ve vysokých nárocích na kvalitu a objem dat, která musí být aktualizována. Tento objem dat se zvyšuje s detailnějším popisem všech dimenzí, a pokud se data nedostávají do MtS automatizovaně (alespoň z větší, potřebné části), pak tento faktor vede, resp. můţe vést, k intuitivnímu (tedy nepopsanému) řízení IS/IT. Dalším rizikem je znepřístupnění všem potřebným uţivatelům či skupinám uţivatelů, kteří si pak vytvářejí sami své vlastní evidence, které jsou mnohdy duplicitní, ale nezálohované, nestrukturované a nepřístupné zase dalším uţivatelům. Z toho pak plyne také nedostatečné či neúplné stanovení zodpovědností za data a jejich aktualizaci. Vysoce nákladné řešení MtS se pak stane jakýmsi skladištěm či archivem málo vyuţívaných, ne-li nepotřebných dat a informací. I přes tato uvedená rizika, která jsou s pořízením, definicí a provozem MtS spojena, by měly přínosy převaţovat nad zápory. Při dynamickém vývoji IS/IT se dá očekávat perspektiva a uţitek takového systému. Jedná se o velmi moderní a sofistikované SW nástroje, které si sloţitost a vyšší komplexnost IS/IT v zásadě vynucuje. MtS přináší uţivatelům ve všech skupinách a úrovních přehlednost o zdrojích a informacích uloţených v PIS. Tato skutečnost má bezpochyby také výhody při vytvoření pracovních pozic, při přiřazení pravomocí a zodpovědností, včetně zaškolení uţivatelů do těchto pozic zařazených. To platí v případě, ţe jsou nástroje, data a MtS pouţívány v přiměřeném počtu a míře (viz kapitola Poţadované vlastnosti).
26
3 Kvalita dat a metadat 3.1 Obecný úvod S rozvojem technologií, potřeb a nároků firem na informační systém, který musí být na kvalitní úrovni, včetně kvalitně naplněných informací v datových skladech, se stává pro firmy kvalita dat a jejich popis významným faktorem. Firmy musí umět vytěţit úplné a kvalitní informace ze svých IS o klientech, zákaznících, dodavatelích, ale i o zboţí, fakturacích, termínech apod., aby byly konkurenceschopné a dosahovali co moţná největšího růstu. Tím dochází k výraznému rozšíření datové základny. Pochopitelně je potřeba udrţovat a spravovat kvalitní data a metadata i o samotných IS. Je potřeba vědět, kde se který údaj nachází, jak se k němu má systém chovat a kam je potřeba jej dále předávat, typicky např. názvy sloupců, datové typy, integritní omezení. Nejen proto je kvalita významným problémem, ale i výzvou. Z uvedeného vyplývá, ţe nekvalitní data mohou mít významný vliv na zpomalení základních procesů, na chybném řízení firmy, neboť vedení se rozhoduje na základě neúplných či chybných informací, na ztrátu klientů či zákazníků, coţ v obecném důsledku vede ke zhoršení postavení firmy na trhu. Kapitolu jsem se do své práce rozhodl zařadit právě proto, ţe kvalita dat a metadat je pro samotnou existenci metasystémů důleţitá, byť s tématem zdánlivě nesouvisí. Kvalitě dat a metadat se budu věnovat jen ve zkrácené podobě.
3.2 Nekvalitní data Základním zdrojem nekvalitních dat je převáţně lidský faktor, příp. technika. Je potřeba si uvědomit, ţe ukládání a veškeré procesy, jak a kam se mají informace a popisy uloţit vţdy definuje nějaký člověk. Faktorem techniky se pak myslí existence velkého mnoţství IS od různých dodavatelů, kdy je zároveň pouţito široké mnoţství technologií a platforem vývoje. To vede k celkové nesourodosti a velmi obtíţnému udrţení konzistence, popisů a přenosů dat. Řešením je částečná nebo komplexní systémová integrace. Taková integrace představuje co nejvyšší moţné sjednocení datových základen, integraci aplikací a technologií, integraci metodik a procesů, ale i co největší sjednocení operačních a databázových systémů, včetně HW komponent. 27
Hlavním zdrojem nekvality je lidský faktor. Nejedná se „jen“ o chyby v pořizování dat (nedostatečné kompetence, nedostatečná kontrola, nepozornost), ale také pozdní či nedostatečné reakce na změny v zákonech, normách, předpisech či metodice. Za zdroj lidského faktoru se dají označit téţ nedostatky na vstupních pořizovacích formulářích, které obsahují nedostatečné kontroly a umoţňují zápis dat do databází (chyby při návrhu formulářů, datových struktur, nedostatečné definice integrit apod.). V obecné rovině můţeme hovořit o chybně navrţené aplikaci, a to buď architektonicky, nebo na úrovni interface (rozhraní). Chyby a nedostatky se pak promítnou i do případných navazujících operací - plnění datových skladů (DW - Data Warehouse), podkladů pro MIS, BI či další sekundární zdroje pro podporu řídích procesů či nutných výkazů k nejrůznějším účelům (regulátor, státní instituce, konsolidační celek). Problémy můţeme rozdělit, resp. zařadit do skupin, na nedostatky obsahové, typicky jsou to překlepy, chybná data, nepovolené kombinace či chybějící data. Za strukturální nedostatky můţeme povaţovat chybné či nedostatečné nastavení délky, datových typů a povolených hodnot, tzv. nedostatky entitní integrity a nedostatky referenční integrity, např. nedostatečné definice klíčů mezi tabulkami, příp. triggerů, řešení „referenční integrity“ aplikační apod. Problémy mohou způsobit i nedostatečné definice a standardy, např. více formátů pro jeden atribut nebo různé pojmenování shodného atributu, více informací v jednom atributu, vícejazyčná pravidla atd. Nejčastějšími problémy z pohledu migrace a integrace je existence duplicitních (redundantních) záznamu, problémy s konverzí datových typů či zcela chybějící záznamy.
3.3 Kvalita metadat MtS je řízen a definován metadaty. Proto je kvalita metadat základním prvkem a předpokladem ke správnému fungování takového systému. Metadata nám slouţí k řízení procesů, identifikaci a dohledání dat, tedy de facto k popisu a plnému porozumění dat, a proto pro zvyšování a kontrolu kvality dat je třeba disponovat kvalitními metadaty (integritní a obchodní pravidla). Základem metadat jsou atributy a vztahy, resp. vazby mezi nimi. Základní a stěţejní normou je česká technická norma (ČSN), která vychází z mezinárodní normy ISO/IEC 11179 a jejíţ překlad byl zajištěn Českým normalizačním institutem (ČNI). ČSN popisuje Registry metadat (MDR) a v podstatě specifikuje jednak poţadavky, a zároveň i některá
28
doporučení pro konstruování definic dat a metadat. Tato norma se skládá z následujících 6 částí [8]: i.
Část 1: Rámec pro specifikaci a normalizaci dat
ii. Část 2: Klasifikace dat iii. Část 3: Metamodel registru a základní atributy iv. Část 4: Formulace definic dat v.
Část 5: Principy identifikace a tvorby názvů dat
vi. Část 6: Registrace dat V normě jsou mimo jiné definovány kategorie, názvy, závaznosti, ale i aktuálnost atributů oproti minulé verzi normy. ČSN pak předpokládá, ţe standardizované atributy budou vyţadovány dle závaznosti (z normy čerpá i následující tabulka). Ta je dána jednoduchou logikou: povinné - tedy musí být vyplněno vţdy; volitelné - můţe být pouţito, ale nemusí; podmíněné - vyţaduje se naplnění dle předem nadefinovaných pravidel. Tabulka č. 1: Atributy dle ISO/IEC 11179. Zdroj: [10 - vlastní úprava]
Kategorie atributu Identifikační
Definiční Relační
Prezentační
Administrativní
Název atributu
Závaznost Aktuálnost
Název Identifikátor Verze Registrační autorita Synonymum Kontext
povinný podmíněný podmíněný podmíněný volitelný podmíněný
Definice
povinný
Klasifikační schéma Klíčová slovo Odkaz na související data Typ vztahu
volitelný volitelný volitelný podmíněný
Kategorie prezentace Forma prezentace Datový typ hodnot datového prvku Maximální délka hodnot datového prvku Minimální délka hodnot datového prvku Uspořádání (layout) prezentace Přípustné hodnoty datového prvku
povinný povinný povinný povinný povinný podmíněný povinný
Odpovědná organizace Registrační status Předkládající organizace Komentář
volitelný podmíněný volitelný volitelný
29
Zastaralý
Zastaralý Zastaralý Zastaralý Zastaralý
Zastaralý Zastaralý Zastaralý
3.4 Shrnutí kapitoly Můţeme říci, ţe kvalita dat a metadat je obsáhlým problémem, který není jednoduché řešit. Neexistují jednoznačná pravidla, která by se dala jednoduše stanovit napříč spektrem organizacemi nejrůznějších typů. To je dáno rozdílnými potřebami firem. Můţeme se však přiblíţit ideálnímu stavu dodrţováním některých technických norem, které se primárně nezabývají strukturou uloţení metadat. Normy se soustřeďují na podchycení významu informací a dat, na jejich správu a popis. Abychom dosáhli zvýšené kvality je potřeba zkvalitnit kontrolu a provést analýzu a změny u vlastních dat a procesů, které s daty pracují. Základem zajištění datové kvality jsou správná a kompletní metadata (integritní a obchodní pravidla) a rozšířená asociační pravidla, která vedou k identifikaci a odstranění chyb v datech primárních a sekundárních. Dá se říci, ţe kaţdý prvek by dle základní normy měl být jednoznačný, to je správně oklasifikovaný
a
zaregistrovaný,
unikátně
a identifikátorem.
30
definovaný,
s jedinečným
názvem
4 IS v prostředí vybrané společnosti 4.1 Představení společnosti 4.1.1 Obchodní činnost Provozování stavebního spoření ve smyslu § 1 zákona č. 96/1993 Sb., o stavebním spoření a státní podpoře stavebního spoření a výkon činností uvedených v § 9 odst. 1 zákona č. 96/1993 Sb.
4.1.2 Akcionáři Raiffeisen Bausparkassen Holding GmbH, s podílem na hlasovacích právech 90 %, s 5850 akciemi. Raiffeisenbank a.s., s podílem na hlasovacích právech 10 %, se 650 akciemi.
4.1.3 Společnost a stavební spoření Raiffeisen stavební spořitelna a. s. (RSTS) je moderní dynamická firma, která je součástí finanční skupiny Raiffeisen v ČR. Finanční skupina Raiffeisen působí především na rakouském trhu, kde má zázemí největší soukromé finanční skupiny, přičemţ tradice skupiny sahá aţ do roku 1862. Logem a tradiční ochrannou známkou celé skupiny Raiffeisen jsou dvě zkříţené koňské hlavy. Toto logo, resp. emblém, je po staletí ochranným znakem před útrapami a zlem. Pro členy skupiny Raiffeisen pak symbolizuje především závazek stability a garance nejmodernějších sluţeb klientům. Z tradice, zkušeností a značky těţí i RSTS. Od roku 1998 se RSTS profiluje nebo představuje jako „Specialista na bydlení“. Snaţí se pruţně reagovat na individuální potřeby svých klientů. Proto se snaţí nalézt řešení k uspokojení bytových potřeb pro kaţdého a tím výrazně posiluje své jméno i pozici na trhu. RSTS je jedním z nejvýznamnějších hráčů na trhu stavebního spoření a nenabízí pouze bankovní produkty, nabízí moţná řešení bytových potřeb klientů. Stavební spoření je poměrně mladým produktem na trhu v ČR. Zákon byl schválen v roce 1993, a to je tedy i rok, kdy stavební spořitelny mohly zahájit svoji kampaň a činnost. Stavební spoření bylo převzato podle modelu Rakouska a Německa, přičemţ produkt má slouţit na řešení bytových potřeb, kdy za jistých podmínek je poskytnut úvěr na řešení bytových potřeb, a to za velmi výhodných úvěrových a splátkových podmínek. Produkt je
31
taktéţ zvýhodněn státem, neboť v úvěrové fázi se dají úroky odpočítávat z daňového základu a zároveň je ve fázi spoření poměrně značná pobídka ve formě státní podpory. Úvěry jsou účelové a jejich vyuţití je striktně dáno zákonem, resp. vyhláškou. Stavební spořitelny jsou zvláštním druhem bank, přičemţ doposud platí, ţe jiné banky nemohou stavební spoření nabízet. Princip tkví v přijímání účelových vkladů a v návaznosti na ně, při splnění podmínek, poskytnutí účelových stavebních úvěrů. Stát podporuje stavební spoření různými formami, např. státní podporou, moţností odečítat úroky z úvěrů ze základu daně z příjmů [6]. Původní výhoda osvobození úroků z vkladů od daně z příjmu jiţ byla novelou zákona upravena. Změnou zákona byla upravena i výše státního příspěvku a finanční základ, z kterého se vypočítává.
4.1.4 Historie společnosti RSTS působí na českém trhu de facto jiţ od roku 1993. Tehdy však začala fungovat ještě pod názvem AR stavební spořitelna a.s. Zakladateli byli Agrobanka Praha a.s. a Raiffeisen Bausparkasse GmbH (Vídeň). Jedním z mezníků v historii byl pro Raiffeisen stavební spořitelnu rok 1998. Původní akcionář, tj. Raiffeisen Bausparkasse GmbH, navýšil vlastní podíl ve spořitelně na 75% všech akcií a zbývajících 25 % akcií převzala Raiffeisenbank a.s. V souvislosti s tímto krokem AR stavební spořitelna zároveň změnila své obchodní jméno na Raiffeisen stavební spořitelna a.s. Názvem se tedy zařadila plnohodnotně do finanční skupiny Raiffeisen v ČR. Vlastnické podíly se pak ještě v průběhu času změnily na současnou úroveň. Dalším historickým mezníkem byla akvizice či fúze s Hypo stavební spořitelnou a.s., kterou RSTS oznámila v průběhu listopadu 2007. Fúze obou stavebních spořitelen byla úspěšně dokončena na podzim roku 2008. Ke spojení IS, resp. k migraci dat, došlo na konci roku 2009.
4.1.5 Konkurenční prostředí Po fúzi RSTS s Hypo stavební spořitelnou a.s. je v současné době na trhu stavebního spoření v České republice pět silných společností, přičemţ kaţdá z nich má za sebou velmi významného strategického partnera. Kromě jiţ zmiňované RSTS to je Českomoravská stavební spořitelna (akcionářem je Československá obchodní banka a Bausparkasse Schwäbisch Hall AG), Modrá pyramida stavební spořitelna, která je pod hlavičkou Komerční banky, Wüstenrot se stejnojmennou skupinou na pozadí a Buřinka, resp. Stavební spořitelna České spořitelny, která je, jak patrno z názvu, pod většinovou správou České spořitelny. 32
Očekávají se také další zákonné úpravy, a to především ve smyslu moţnosti nabízet produkt i v běţných komerčních bankách. Novela zákona však dosud nebyla předloţena v konečné podobě.
4.1.6 Vnitřní struktura společnosti Společnost je vedena tříčlenným představenstvem, kterému jsou podřízeni ředitelé odborů dle logických celků. Jednotlivé odbory pak zabezpečují plnou funkčnost banky. Vedením kaţdého úseku je pověřen jeden člen představenstva, který řídí přímo několik odborů. V některých odborech existují ještě oddělení (ta nejsou na schematickém znázornění). Oddělení jsou řízena vedoucím oddělení, který je podřízen řediteli odboru. Představenstvo je výkonný orgán, který řídí dozorčí rada a té se zodpovídá nezávislý interní audit. Nicméně, obecně se dá říci, ţe organizační struktura RSTS není příliš hluboká. Na následujícím obrázku je graficky znázorněna Organizační struktura RSTS, přičemţ zkratky odborů jsou pouţity i v další části práce (viz Obrázek č. 6). V úseku C jsou především provozní útvary, tj. odbor zpracování úvěrů (např. oddělení správy úvěrů, oddělení schvalování úvěrů, a to v členění fyzických a právnických osob), odbor spoření a sluţeb klientům (typické oddělení OSS je call centrum, korespondenční oddělení, oddělení platebního styk, oddělení exekucí a oddělení správy klientů a účtů). Ve stejném úseku figuruje i odbor řízení rizik (oddělení analýzy rizik, oddělení operačních rizik, oddělení kreditních rizik - posuzování úvěrů, matice chování klientů při vymáhání, stanovení skórovacích funkcí, apod.) a odbor všeobecné správy (technická správa, správa dokumentů – skenovna, podatelna). Úsek B se především stará o vše, co se týká prodeje a vystupování firmy vůči médiím. Zde je zařazen odbor podpory prodeje, kde je vyvíjen produkt pro klienty v samostatném oddělení. Odbor také poskytuje odborný servis, včetně podpory vývoje odbytových IS. Do tohoto odboru patří i poradenské místo - klientská hala. Druhým odborem v úseku je odbor odbytu, který má na starosti především vývoj a správu odbytových cest, včetně školení a náboru odbytových pracovníků. V tomto odboru je i oddělení, které se zabývá produktovou nabídkou partnerských organizací - tzv. cross-sellingové produkty. Třetím odborem v úseku je odbor PR a marketingu (MKT), který se stará o reklamu, vystupování v médiích a podílí se na různých průzkumech trhu. Z výsledků a analýz MKT pak těţí Odbor podpory prodeje (OPP) při tvorbě produktů a při řešení plánů prodeje. Do úseku B
33
je zařazen i relativně nový odbor, který se zabývá externími distribučními sítěmi (OEO). Typickým zástupcem takové externí sítě je Česká pošta5. Do úseku A je zařazen největší počet odborů. Je to odbor finanční, v kterém jsou oddělení bilance, controllingu, finančního účetnictví a nově i oddělení výplat provizí obchodním zástupcům (OZ). Dále je v úseku odbor právní, který řeší smlouvy, zúčastňuje se soudních jednání, ale zároveň řeší také vymáhání pohledávek a správu insolvenčních řízení. Dle těchto činností jsou zřízena jednotlivá oddělení, která opět úzce spolupracují. Dalšími odbory jsou, odbor řízení lidských zdrojů (školení zaměstnanců, zajištění kvalitních lidských zdrojů – nových zaměstnanců, správa mezd, docházky apod.), odbor organizační, v kterém je soustředěna i metodika spoření a úvěrů, nově také odbor compliance (ten zajišťuje součinnost při průřezových řešeních a kontroluje, zda materiály a předpisy na sebe navazují a jsou ve správném vzájemném vztahu). V úzké spolupráci jsou pak odbory analýzy a aplikačního vývoje (OAV) a odbor informačních technologií (OIT). V rámci OAV je zřízena i projektová kancelář, která řeší nové projekty v rámci celé RSTS a zároveň zřizuje či vede pracovní skupiny, které řeší vývoj hlavní bankovní aplikace (HBA). OAV má na starosti nová SW řešení, správu poţadavků, definice a konzultace s dodavateli SW, chybová hlášení apod. OAV za pomoci OIT testuje i nové verze HBA a podpůrných SW. Odbor informačních technologií má pak na starosti nasazování nových verzí na testovací a produkční servery, vlastní správu technologických a uţivatelských stanic a serverů, údrţbu aplikací, atd. V odboru OIT je oddělení výpočetního střediska, které zajišťuje mimo jiné i přenosy dat, typicky do České národní banky (ČNB)6, čímţ zajišťuje zpracování souborů z clearingového centra. Z výše uvedeného popisu je zřejmé, ţe v některých odborech existuje mezistupeň v řízení chodu společnosti, kterým je oddělení. Oddělení vznikla proto, aby bylo moţné efektivně řídit větší odbory, příp. rozdělit rozdílné a specifické činnosti do logických celků. Některé odbory mají více oddělení a některé nemají ţádné. To je závislé na rozdělení činností a celkovém počtu pracovníků. V odborech, kde není oddělení zřízeno, je přímo pod ředitelem odboru výkonná sloţka, tj., řadový zaměstnanec. Pro jasnější představu je na obrázku zobrazeno i grafické schéma organizační struktury (v odborovém členění). Na schématu je zobrazen i nezávislý orgán, kterým je Výbor pro audit. V grafickém 5
Více o společnosti a sluţbě: Sluţby: Stavební spoření. Česká pošta, s.p. [online]. 2014 [cit. 2014-09-11]. Dostupné z: http://www.ceskaposta.cz/sluzby/platebni-a-financni-sluzby-cr/stavebni-sporeni/
6
ČNB – Česká národní banka http://www.cnb.cz/cs/index.html
-
regulátor
34
bankovního
trhu.
Více
o
společnosti:
znázornění nejsou naopak zobrazeny další nezávislé poradní orgány, které dávají doporučení, a to jak ředitelům, tak představenstvu. Takovým typickým představitelem poradních orgánů je Výbor pro řízení úvěrových rizik, Výbor pro řízení změn, Výbor pro řízení aktiv a pasiv a Výbor pro řízení operačního rizika.
Obrázek č. 6: Organizační struktura RSTS. Zdroj: [12]
4.1.7 Obchodní zastoupení RSTS má obchodní zastoupení po celé ČR v podobě obchodních zástupců. RSTS jako taková nemá ţádnou pobočku a má jedinou vlastní budovu, tou je centrála v Praze. Ta řídí a organizuje činnost celé společnosti, včetně vedení svých obchodních zástupců, kteří nabízejí bankovní produkty koncovým uţivatelům. Vedení obchodních zástupců je rozděleno do regionů dle regionální příslušnosti, která víceméně kopíruje kraje. Celá síť je téţ řešena hierarchicky, tzn. stupňovitě a podle různých pozic obchodních zástupců
35
(OZ) jsou pak vypláceny odměny, provize a prémie centrálou RSTS. Obchodní síť spravuje centrála, pod kterou spadají nejvyšší logické celky, regionální ředitelství. Regionální ředitelé jsou téţ potenciálními uţivateli MIS, resp. IS RSTS. Mimo to jsou obchodními zástupci také partnerské organizace. Typickým zástupcem spolupracující organizace je společnost ZFP group7. V poslední době dochází k optimalizaci územního uspořádání, tzn., ţe byl sníţen počet regionálních ředitelství na pět a zároveň došlo i ke sloučení a sníţení počtu oblastí. To mimo jiné znamená, ţe záběr oblastí a ředitelství je výrazně vyšší neţ v minulosti a zároveň jsou ušetřeny náklady za vedení regionů a oblastí. Podle pozic jednotlivých OZ jsou také zpřístupněny různé systémy, typicky: Portál OZ, kde mohou OZ sledovat výkony (vlastních, podřízených), změny v dokumentech; HBA s moţností pořizování nových smluv (spořících i úvěrových; sledování obratů; zařazení akvizičních příleţitostí, apod.); SW LMS, tedy e-learningu (moţnost vzdělávání dle zákonných poţadavků, ale i poţadavků dle pozice OZ v síti RSTS) atd.
4.1.8 Shrnutí údajů o společnosti RSTS je tedy firmou působící v sektoru bankovních sluţeb, přičemţ počtem zaměstnanců je na hraně střední a velké firmy, neboť tento počet se pohybuje kolem 250-260 zaměstnanců. Byť se jedná o společnost, která podniká především na základě Zákona o stavebním spoření, vztahuje se na ni i Zákon o bankách, v jehoţ smyslu je „zvláštním“ typem banky. Tím pádem se jako banka řadí do skupiny velkých firem, a to i díky vysoké bilanční sumě, která je na poměrně vysoké hodnotě, stejně jako ukazatel zisku na jednoho zaměstnance. Přesná čísla týkající se obchodní úspěšnosti, resp. týkající se zveřejňovací povinnosti jsou na webových stránkách společnosti v sekci povinně zveřejňovaných informací8, kde se nacházejí výsledky hospodaření a jednotlivé výroční zprávy. Aby mohla být všechna vykazovaná čísla správně vykládána a prezentována, je potřeba mít důkladně propracovaný popis IS a metadat. Na metadatech a jejich kvalitě závisí mnoho vykazovaných poloţek. Mnohé z nich jsou pod dohledem regulátorů trhu - typicky státní podpora pod dohledem MF, výkaznictví pod dohledem ČNB. Z dat vychází
7
Více o společnosti: ZFP Group. ZFP akademie, a.s. [online]. 2014 [cit. 2014-08-19]. Dostupné z: http://www.zfpa.cz/co-umime/
8
Povinně zveřejňované informace RSTS: O nás. Raiffeisen stavební spořitelna a.s. [online]. 2014 [cit. 2014-09-11]. Dostupné z: http://www.rsts.cz/povinne-uverejnovane-informace/
36
i auditoři většinového vlastníka a auditor dohledu bankovních norem. Tím je v prostředí RSTS firma KPMG9. Metadatům musí rozumět všechny odbory napříč RSTS. V následující tabulce je pro představu uveden podíl RSTS na celkovém trhu stavebního spoření. Zdrojem údajů je MIS RSTS, který pracuje s vlastními daty a s daty od Asociace stavebních spořitelen ČR (ASSČR). Pro účely práce jsou formáty výstupů a některé údaje částečně modifikovány či z výsledků odstraněny, aby mohly být v práci uvedeny a pouţity. Tabulka č. 2: Podíl RSTS na trhu stavebního spoření v ČR. Zdroj: [Vlastní úprava] 2009
2010
2011
2012
2013
2.q 2013
2.q 2014
Nově uzavřené smlouvy o stavebním spoření
94 409
73 741
64 834
95 322
87 280
41 952
67 558 101 681
podíl (%)
16,4%
13,8%
15,8%
22,0%
19,4%
22,5%
24,2%
Podíl RSTS
Průměrná CČ u nově uzavřených smluv FO (tis. Kč)
2014
21,1%
366,5
331,1
323,1
463,3
385,1
401,4
346,4
349,8
podíl (%)
118,7%
110,2%
93,3%
126,6%
103,8%
107,6%
106,3%
104,1%
Stav platných smluv - počet
869 167 832 537 756 298 735 367 702 443 713 207 698 424 683 908
podíl (%) Stav platných smluv - saldo (uspořená částka, mld. Kč)
17,6%
17,2%
16,6%
17,0%
17,3%
17,1%
17,6%
17,9%
74,31
75,09
74,59
76,07
74,87
74,72
72,23
72,70
podíl (%)
17,9%
17,5%
17,2%
17,5%
17,4%
17,5%
17,3%
17,6%
Nové překlenovací úvěry - počet
14 574
16 198
11 320
11 865
12 751
6 140
5 572
11 067
Nové překlenovací úvěry - výše (mld. Kč) podíl počtu (%) Nové stavební úvěry přímo vzniklé - počet Nové stavební úvěry přímo vzniklé - výše (mld. Kč) podíl počtu (%) Nové stavební úvěry překlopené počet Nové stavební úvěry překlopené výše (mld. Kč) podíl počtu (%) Stav platných úvěrů - počet
9,40
9,78
6,17
6,24
7,28
3,53
2,79
5,84
13,3%
16,5%
14,4%
17,8%
19,8%
19,4%
18,6%
17,8%
2 780
1 645
1 854
1 311
1 165
595
564
1 077
0,54
0,31
0,36
0,24
0,20
0,11
0,10
0,20
14,4%
10,5%
12,9%
12,7%
13,5%
12,9%
14,2%
15,6%
7 231
7 487
9 680
10 113
8 598
4 318
3 873
7 769
1,07
1,24
1,84
1,91
1,68
0,86
0,77
1,55
9,5%
9,7%
12,9%
15,4%
15,3%
15,0%
13,2%
14,7%
110 306 114 037 112 149 110 311 104 417 107 102 101 939
99 966
v tom: ze stavebního spoření
61 602
58 879
58 750
59 143
56 209
57 389
54 461
53 571
v tom: překlenovací
48 704
55 158
53 399
51 168
48 208
49 713
47 478
46 395
11,2%
11,5%
11,7%
12,3%
12,8%
12,5%
13,0%
13,3%
29,48
35,86
37,13
37,10
34,54
35,83
33,59
32,61
4,18
4,63
5,49
6,14
6,15
6,18
6,11
6,04
25,30
31,23
31,64
30,96
28,39
29,65
27,49
26,58
podíl (%)
11,0%
12,2%
12,7%
13,1%
13,2%
13,3%
13,2%
13,1%
Dlužná částka / uspořená částka
39,7%
47,8%
49,8%
48,8%
46,1%
48,0%
46,5%
44,9%
podíl (%) Stav platných úvěrů - saldo (dlužná částka, mld. Kč) v tom: ze stavebního spoření v tom: překlenovací
9
Více o společnosti: KPMG. KPMG Česká republika, s.r.o. [online]. 2015 [cit. 2015-03-01]. Dostupné z: http://www.kpmg.com/cz/cs/Stranky/default.aspx
37
4.2 Odbory zajišťující IT v organizaci V RSTS existují dva zásadní odbory, které mají spojitost s IT ve společnosti. Jedná se o odbor informačních technologií - OIT a OAV - odbor analýzy a aplikačního vývoje. V bodech se pokusím shrnout základní okruhy a odpovědnosti IT, včetně napojení na číslo procesu, pokud je k bodu nějaký popsaný (identifikovaný) proces váţe. Identifikátor procesu je následně navázán do evidence MtS a lze dle něj vyhledávat. Nicméně existují omezení dle přístupových práv uţivatelů, neboť některé procesy jsou chráněné (např. právní postupy vymáhání apod.). Identifikátory procesů mají svoji strukturu – označení odboru (3-4 znaky), pořadí procesu (4 místa), klasifikace (písmena; A=stěţejní, B=střední; C=méně důleţité) a priorita (číselné vyjádření, 9 = nejvyšší priorita). Identifikátory uvádím jen u případů, kdy jsem dokázal nadefinovat činnost a k ní nalézt odpovídající proces v MtS. Funkční náplní OAV je zejména: i.
Zajištění provozuschopnosti IS RSTS po obsahové stránce a sjednocení poţadavků jednotlivých uţivatelů, resp. skupin uţivatelů. Podpora stávajících IS všemi dostupnými prostředky. Proces řízení poţadavku - „OAV0005A9“.
ii. Stanovení plánů investičních a nákladových limitů na další rozvoj a údrţbu SW aplikací, řízení jejich čerpání (vše dle poţadavků odborných útvarů) „OAV0001A9“. iii. Analytická spolupráce na vypracování poţadavků na IT podporu s odbornými útvary a jejich předání k programovému zpracování příslušnému dodavateli SW. Zároveň přebírá k testování zpracovaný program od dodavatele SW a posuzuje, zda převzaté dílo odpovídá poţadavku. Předává ASW (konkrétní IS) konečnému uţivateli, jako prostředek pro jeho činnost. iv. Organizace a řízení akceptačních testů dodaných programů a IS - „OAV0035A9“. v.
Odpovědnost za průběh a dokumentaci změnového řízení pouţívaných SW aplikací - „OAV0026A8“.
vi. Zajištění analýzy, odstraňování chyb a dopracování jednotlivých modulů IS RSTS na základě nových, případně upřesněných poţadavků uţivatelů - „OAV0101A6“. vii. Analýza a koordinace datového toku mezi jednotlivými sloţkami IS RSTS a jednotlivými odbornými útvary - „OAV0034B4“.
38
viii. Návrh technologických procesů v rámci organizace s ohledem na všechny pouţívané IS, včetně koordinace procesů, a to zejména v souvislosti se změnou a rozvojem činnosti organizace - „OAV0089A7“. ix. Spolupráce s externími subjekty, zajišťujícími pro RSTS činnosti, které souvisí s úkoly odboru OAV - typicky podíl na dokumentaci, popisu IS a metadat, zařazení ASW (ve spolupráci s OIT) - „OAV0075A5“. x.
Zajištění školení školitelů IS pouţívaných v RSTS, včetně zabezpečení jejich podpory prostřednictvím konzultací či hotline - „OAV0130C8“.
xi. Řešení provozně organizačních úkolů (aktivní účast v projektech, hodnocení pracovních a organizačních opatření, kontrola konzistence celkového systému (spolu s dalšími odbory), realizovatelnost a hospodárnost nových řešení). xii. Správa modelu řízení přístupů IS organizace - „OAV055A9“. xiii. Zajištění výkonu funkce manaţera změn a řídí SW poţadavky na změnu „OAV0005A9“. V rámci OAV je zařazena i projektová kancelář, jejíţ hlavním úkolem je: i.
Koordinace a evidence akcí projektového charakteru - časová koordinace přípravy, vazeb mezi projekty a jejich realizace (i částí) - „OAVP0001A9“.
ii. Příprava projektového záměru, plánu projektu, průběţné zprávy o projektu a závěrečné vyhodnocení (vše ve spolupráci s dalšími odbory RSTS) „OAVP0003A8“. iii. Metodická podpora a konzultace v oblasti řízení projektů v rámci RSTS. iv. Čerpání rozpočtu v rámci schváleného rozpočtu na projekt - „OAVP0005A9“. v.
Výkon funkce garanta procesu projektového řízení - „OAVP0015B5“.
Přibliţná funkční náplň OIT, resp. co vše odbor zajišťuje a na čem se podílí: i.
Definuje firemní strategii v oblasti IT. Zajišťuje plánování, výběr a implementaci nových technologií. Určuje a odpovídá za vnitrofiremní standardy (normy) pro oblast IT - „OIT0018A9“.
ii. Zajišťuje plnou
provozuschopnost
prostředků výpočetní techniky
RSTS
a odpovídá za jejich bezproblémové a efektivní vyuţívání (včetně telefonní ústředny, obsluhy datových schránek a dalších podpůrných IS) iii. Zabezpečuje systémovou integraci prostředí IT a zajišťuje optimální funkčnost IT pro běh ASW a IS v organizaci - „OIT0023A7“.
39
iv. Podílí se na vytváření a aktualizaci bezpečnostní politiky v oblasti IT. Navrhuje a realizuje technická a metodická opatření proti ztrátě, poškození a zneuţití dat „OIT0002A9“. v.
Zajišťuje bezpečnost IS (přístupové, bezpečnostní, komunikační, autentizační systémy), správu a konfiguraci systémů proti počítačovým virům, resp. obecně škodlivým SW. Provádí jejich analýzu a řeší následné reakce na zjištěný stav „OIT0010A9“.
vi. Zabezpečuje instalaci, konfiguraci a pravidelnou údrţbu HW (firmware, mikrokód), systémového a ASW (service pack, update, fix). Plánuje a provádí změny (rozšíření) konfigurace provozovaného HW a SW. Zároveň zabezpečuje provoz paměťových a archivačních zařízení. vii. Realizuje zavedení, změnu a kontrolu jednotlivých uţivatelů v síťových operačních systémech. Ve spolupráci s OAV přiděluje uţivatelská oprávnění v jednotlivých IS,
včetně
evidence
o
přidělených
přístupových
právech
k zařízením, administrovaným aplikacím a datovým souborům v síti. viii. Přijímá ţádosti jiných útvarů pro oblast IT; zajišťuje preventivní opatření pro minimalizaci přerušení provozu, informuje uţivatele o akcích týkajících se provozu a o přerušení provozu prostředků výpočetní techniky - „OIT0033B7“. ix. Zajišťuje pořízení prostředků výpočetní techniky, jejich zavedení do uţívání a evidenci v poţadované formě. Zhotovuje zařazovací protokoly. x.
Zabezpečuje správu prostředků výpočetní techniky (vč. oprav). Vystavuje vyřazovací protokoly.
xi. Zpracovává uţivatelské návody, pokyny a rutiny pro správu a vyuţívání provozovaného HW, operačních systémů a standardních kancelářských aplikací. xii. Vytváří metodiku pro bezpečné vyuţívání a ochranu prostředků výpočetní techniky - „OIT0044C9“. xiii. Spolupracuje na tvorbě a aktualizaci krizového plánu pro oblast IT „OIT0004A9“. xiv. Poskytuje systémovou podporu uţivatelům (helpdesk) - „OIT0089C6“. xv. Zajišťuje funkci garanta dohledu nad provozem a rozvojem komunikačního systému. xvi. Zajišťuje výkon funkce manaţera provozu - „OIT0007A9“. V rámci OIT funguje i oddělení výpočetního střediska, jehoţ hlavním úkolem je:
40
i.
Organizace a provádění akcí, popsaných v operačních plánech ve stanovených termínech a zajištění provozuschopnosti výpočetního střediska.
ii. Spolupráce na operativních opatřeních při haváriích HW/SW. Vedení deníku akcí hlavních aplikací (SAP, HBA), s důrazem na nestandardní akce a odchylky od standardů - „OITV008A9“. iii. Aktualizace popisu činností. Odpovědnost za správu vybraných částí IS RSTS (dle katalogu aplikací a IS) - „OITV0014A3“. iv. Zhotovení výstupů zpracování dat (sestavy, výstupy, přenos do BI, apod.) „OITV007A8“. v.
Zabezpečení nasazování nových verzí jednotlivých částí IS (dle dispozice OAV) na DB servery, koncové stanice a webové aplikační servery. Podílí se na jejich testování - „OITV0011A9“.
vi. Záloha dat IS podle interních předpisů zálohování. Archivace speciálních dat, a přenos datových nosičů na zabezpečená úloţiště. Provádění obnovy dat (pokud je
to
třeba)
a
testy
obnovitelnosti
archivovaných/zálohovaných
dat
-
„OITV0004A9“. vii. Evidence záznamů o všech zjištěných chybových stavech jednotlivých částí IS a v případě potřeby předání k dalšímu zpracování - především OAV. viii. Předávání a přebírání dat z clearingového centra ČNB - „OITV0003A9“. ix. Plánování a spouštění výpočtů denních a měsíčních uzávěrek HBA po dohodě s OAV, a to s přihlédnutím k operačnímu reţimu a provozním potřebám „OITV0001A9“. x.
Přidělení uţivatelských oprávnění v IS RSTS (dle vnitřních předpisů) „OITV0002A9“.
xi. Zabezpečení definovaných tiskových výstupů (dle definice odborných útvarů) „OITV0005A8“.
41
4.3 Informační systémy v organizaci V RSTS se pouţívá celá řada IS menšího či většího rozsahu. Kaţdý IS má svoje opodstatnění a je potřeba k němu evidovat některé základní údaje. Tyto údaje jsou průběţně opravovány, resp. udrţovány. Existuje aplikace na podporu přehledu IS - viz ukázka (zobrazení části IS, včetně úprav parametrů). Údrţba je poměrně náročná, neboť některé IS jsou upgradovány či patchovány poměrně často. Velmi často se také mění údaje o podpoře IS nebo časy zálohování, apod.
Obrázek č. 7: Ukázka seznamu IS. Zdroj: [15 - vlastní úprava]
Prolinkem se přes název IS/aplikace dostaneme na konkrétní kartu IS, kde je sada dalších potřebných dat/údajů. Z důvodu neveřejného přístupu k těmto informacím, nebudu ukázku karty konkrétního IS zveřejňovat (jde o údaje: typ databáze, HW a SW vybavení serverů, zodpovědnosti, data změn, definice síťových propojení a prvků apod.). Základní informace jsou však z příkladu patrné. Eviduje se verze a hlavní parametry ohledně provozu, podpory a zálohování. Dokumentace, dodavatelé a řada dalších důleţitých údajů, se nachází právě v kartách jednotlivých IS, včetně konkrétních kontaktů, odkazů a nasměrování na datová úloţiště a popisy metadat jednotlivých IS. Jsou zde uvedeny detaily minimální, doporučené a reálné konfigurace HW vybavení, včetně doporučených SW na těchto zařízeních.
42
Na dalším obrázku jsem znázornil hlavní IS ve společnosti (viz Obrázek č. 8), včetně modulů HBA a vazeb mezi nimi. Jedná se o hlavní/základní systémy, které spolupracují s okolním prostředím, a na kterých běţí základní byznys procesy společnosti. Pro podporu odborných útvarů ještě existuje celá řada malých IS a aplikací, které podporují jejich činnost, avšak nemají význam na okolní části nebo jen minimální. Jádrem bankovního systému je SAP a HBA CIBIS (CORE systém RSTS). Výstupy jsou pak exportovány a transformovány (ETL procesy) do MIS, sestav, reportů, elektronických archivů, datových skladů a dalších podpůrných výstupů. Ve své práci se soustředím především na HBA, na její moduly a posléze na konkrétní část z funkcionality, na které ukáţu moţný popis metadat, resp. jeden z moţných způsobů evidence.
Obrázek č. 8: Schéma základních IS v RSTS. Zdroj: [Vlastní úprava]
4.4 Moduly hlavní bankovní aplikace (HBA) Jak to ve většině moderních aplikací bývá (nejen u bankovních aplikací), je HBA vysoce modulární. HBA v prostředí RSTS je produkt CIBIS od firmy Turboconsult. Základem je účetně transakční jádro, na které jsou napojeny veškeré produkty, účty a informace o osobách. Účetní jádro pracuje dle poţadavků RSTS, ČNB a dalších regulátorů ve vazbě
43
na účetní standardy. HBA je koncipována pro mezinárodní pouţití - implicitní česká verze odpovídá legislativním opatřením ČR, včetně jazykové mutace. V řešení je zajištěna i provozní bezpečnost na úrovni standardů dle Zákona o bankách. Data jsou uloţena ve společné databázi a zpracování probíhá důsledně na transakčním principu, tzn., ţe operace jsou do databáze promítnuty aţ po úspěšném dokončení. V případě přerušení transakce se výchozí datový stav nezmění a operaci je moţné opakovat. Základní stavební kameny CORE systému, tj. hlavní bankovní aplikace (HBA) CIBIS, jsou uvedeny na následujícím obrázku. Označení CIBIS - Main obsahuje základní obsluţné úlohy Osoby (evidence klientů, resp. osob, které mají s RSTS něco společného a jejichţ údaje můţe RSTS vést v souladu se zákonem o ochraně osobních údajů), Produkty (spořící a úvěrové produkty, včetně jejich plné správy), Státní podpora (vedení zálohy státního příspěvku; přenosy a kontrola dat na MF ČR), Řízení rizik (podpora schvalování, skóringu apod.), Platební styk (zpracování souborů z/do CC, SIPO, poštovních poukázek, podnikových plateb apod.), Klientské a Finanční účetnictví, Reporting (standardní nadefinované sestavy směrem k regulátorovi, apod.).
Obrázek č. 9: Základní rozloţení oblastí CORE systému v RSTS. Zdroj: [11]
K tomu pochopitelně existují další moduly, např. CIBIS - Sale, který zaštiťuje celou škálu úloh týkající se obchodu, včetně modelování/simulace průběhu produktů a podpory pro prodej smluv stavebního spoření či úvěrů. Na tento modul je nepřímo napojen i modul 44
CIBIS – OS, který obhospodařuje servis obchodním zástupcům, akviziční příleţitosti, přehledy výkonů (napojení na výstupy z MIS), novinky určené pouze pro OZ atd. Modul CIBIS - Web umoţňuje provoz internetového bankovnictví, tedy přístup klientů ke svým osobním údajům, datům a produktům v RSTS. Modul CIBIS - Central obsahuje pak napojení na Katastr nemovitostí, včetně nadstavbové evidence nemovitostí pro CIBIS Main. Na sluţby katastru nyní vytváříme nadstavbu, kde se budou zachytávat všechny změny na konkrétních nemovitostech. Moduly jsou spolu vzájemně provázány a data jsou uloţena na jedné produkční DB. Na HBA navazuje další řada nadstavbových řešení, které jsou součástí HBA a komunikují s externími organizacemi, kterým poskytují data nebo z nich naopak údaje čerpají. Typicky jde o napojení na bankovní a nebankovní registry, z nichţ se tvoří skórovací karty, blacklisty apod. Důleţitým článkem je i napojení na clearingové centrum ČNB, přes které se provozuje mezibankovní platební styk. Modulem HBA je i výkaznictví, resp. poskytnutí údajů přes rozhraní na BANKSTAT (výkaznictví pro ČNB) a modul CIBIS RM, který zpracovává údaje dle metodiky BASEL pro akcionáře společnosti. Data se pak následně zasílají do Vídně ke konsolidaci přes webové rozhraní. Následují další moduly CIBIS - FinFlow (toky peněţních prostředků), CIBIS - FinAcc (sledování finančního účetnictví) atd. Zároveň HBA generuje přenosové dávky do hlavního účetního systému typu ERP, kterým je SAP. Komunikace je obousměrná, tzn., ţe se do HBA importují dodavatelské faktury a následně se zasílají do ČNB přes další moduly a rozhraní. Základními moduly jsou také moduly administrace a dávkového aparátu, dle kterých se řídí denní, měsíční a roční závěrka. Jde o moduly CIBIS - Adm a CIBIS - Batch. Je zřejmé, ţe celý popis modulů není moţné uvést, a ţe většina údajů, zde uvedených, slouţí jen pro představu sloţitosti celého modelu a průchodu jednotlivých dat. Na této malé ukázce je vidět, ţe bez důkladného popisu dat a metadat se dá jen velmi sloţitě konkrétní záleţitost a chování modulu nebo jeho konkrétní části (typicky funkcionalita, proces či jeho část) dohledat.
45
5 Metasystém hlavní bankovní aplikace Vzhledem ke sloţitosti IS bank a stavebních spořitelen se budu v práci zabývat primárně HBA, na které se dá způsob a pouţití nejlépe demonstrovat a analyzovat. Zároveň popíšu svůj přínos a moji činnost při vytváření konkrétních částí HBA. Typicky se jedná o doplnění některých nových funkcionalit, které se musí do SW zabudovat. Tyto funkčnosti jsou předmětem změnových řízení, a to buď ve formě poţadavků či projektů. Kaţdá část dodaného řešení v bance má svůj vlastní popis a svoji vlastní agendu. Kaţdá část je pak vţdy řešena samostatně a tedy i rozdílně, a i proto neexistuje komplexní metainformační systém napříč spektrem všech pouţívaných IS, aplikací, modulů a rozhraní.
5.1 Popis, resp. řízení požadavků na změnu SW Vzhledem ke sloţitosti IS bank a stavebních spořitelen se budu v práci zabývat primárně HBA, na které se dá způsob a pouţití nejlépe demonstrovat a analyzovat. Šíře HBA je natolik obsáhlá, ţe bude vhodné se věnovat jedné konkrétní oblasti, a to ještě jen částečně. Základem popisu HBA je dokumentace, která je výsledkem odsouhlasených postupů, názorů a analýz. Poţadavky jsou důkladně zmapovány a návrhy řešení jsou pak odsouhlaseny dle pravidel interních předpisů. Krátce popíši základy řízení poţadavků na změnu. Neţ vznikne samotná dokumentace a patřičné návrhy řešení, class diagramy apod., na jejichţ řešení se podílí náš odbor (analýzy a vývoje OAV), prochází poţadavek schvalovacím řízením v RSTS. Jedná se o mnohostránkový předpis, kde jsou vydefinovány základní pojmy a definice, např. uţivatelský poţadavek, řízení změn, nasazení změn, dotčené odbory apod. Součástí předpisu je také velmi důleţitá pasáţ prioritizace poţadavků. V metodickém pokynu/předpisu jsou uvedeny kompetence a zodpovědnosti jednotlivých účastníků změny SW. Nejprve vydefinujeme základní role: ţadatel, schvalovatel, analytik, řídící výbor změn, manaţer změn, manaţer provoze a správce testovacího a produkčního prostředí. Detailnější, ale stručný popis rolí následuje. Žadatel – zaměstnanec RSTS, resp. člen projektového týmu, který je kompetentní pro vyjednávání a přípravu poţadavku.
46
Schvalovatel – většinou se jedná o vedoucího zaměstnanec, resp. ředitele odboru. Výjimku tvoří projektový vedoucí, pokud je předkladatelem vedoucí projektu. Analytik – pracovník odboru analýzy a vývoje (OAV – v zásadě moje pracovní pozice), na kterém stojí především analytická část, včetně stanovení přínosů změny, způsobů řešení a alternativních řešení. Analytik se podílí na tvorbě diagramů, návrhů Use Case, dokumentace, popisu metadat apod. Řídící výbor změn je rolí, do jejíţ kompetence patří především posouzení priority jednotlivých poţadavků, určení zdrojů (materiálních, finančních, lidských, informačních) a termínů, včetně příp. pozastavení poţadavku na SW, apod. Jde o poradní výbor představenstva RSTS a jsou v něm předem určení vedoucí a klíčoví pracovníci napříč všemi organizačními úseky. Manažer změn – role, která má vedoucí úlohu. V současnosti ji zastává ředitel odboru OAV. Ředitel OAV je vlastníkem celého procesu řízení změn a úzce spolupracuje s pracovníkem v roli manaţera provozu. Většinou zároveň řídí i Řídící výbor změn, pokud funkci nepřevezme přímo člen představenstva. Manažer provozu – ředitel odboru informačních technologií (OIT). Ten zodpovídá za bezpečnost a plány nasazení, včetně krizových scénářů. Tato činnost je konzultována a připravována vţdy v úzké spolupráci obou odborů IS/IT (OAV, OIT). Manaţer provozu vede a řídí roli správce prostředí. Správce testovacího a produkčního prostředí – je zodpovědný za testovací prostředí a vlastní nasazování jednotlivých poţadavků a patchů do patřičných testovacích, resp. produkčních prostředí. Roli většinou vykonává a plní pověřený pracovník OIT. Na následujícím obrázku je graficky znázorněno schéma celého procesu změn. Schéma čerpá také z interní dokumentace a pro potřeby práce je záměrně upraveno. Jde o dokumentaci týkající se procesu řízení změn, coţ je velmi obsáhlý předpis, v kterém je řada definic, pojmů a odkazů na další interní dokumenty.
47
Obrázek č. 10: Znázornění procesu změn. Zdroj: [15 - vlastní úprava]
Součástí předpisu je i formulář „Ţádost o změnu software“ a termíny pro stanovení maximální lhůty pro realizaci poţadavků v závislosti na jejich sloţitosti (velikosti).
5.2 Popis, resp. metasystém HBA Celý základ metasystému, popisu dat v HBA, je v konkrétním úloţišti dat na file systému. Zde je celá adresářová struktura, která odpovídá konkrétní, resp. aktuální verzi IS CIBIS. Adresářová struktura koresponduje s jednotlivými moduly, které jsem popsal výše, resp. zmínil jsem alespoň některé základní. V ukázce se jedná jiţ o seznam ke konkrétní verzi dodávky (viz Obrázek č. 11). Adresářová struktura má svoji historii a ta souvisí s jednotlivými dodávkami HBA, které jsou pravidelně uskutečňovány. To znamená, ţe je moţné modely a jednotlivé případy uţití zpětně porovnávat a verifikovat. Část dokumentace se tvoří automatickými exporty z databáze a část je vytvářena dle aktuální verze dodávaných změn. 48
Starší část dat je automaticky archivována, nicméně data lze kdykoli zrestaurovat. Je potřeba říci, ţe nárůst modulů, úloh a funkcionalit je velmi dynamický a ţe se spolu s některými úlohami mění i vlastní instalace DB Informix a HW zařízení či servery, coţ má za důsledek, ţe bychom sice metadata a dokumentace mohli porovnávat, ale zprovoznit samotnou aplikaci, např. z roku 2009, by bylo s největší pravděpodobností nemoţné.
Obrázek č. 11: Adresářová struktura metadat. Zdroj: [Nastavení PC - vlastní úprava]
Já se budu soustředit na základ HBA pro uţivatele v RSTS, tj. CIBIS – Main. V podadresářích je pak funkční katalog, přehled práv, vlastní datový model, včetně nově zařazených změn na základě poţadavků RSTS. Důleţitou součástí IS je popis tzv. parametrů či registrů. Nejedná se o registry PC, ale registry IS CIBIS i kdyţ např. parametry pro tiskové výstupy či nastavení aplikace se zaznamenávají i do standardních registrů PC. To umoţňuje konkrétním pracovníkům směrovat výstupy na potřebné úloţiště, příp. si udrţovat vlastní nastavení některých menu, podbarvení, implicitních filtrů ve formulářích IS apod. Na následujícím obrázku je ukázka zapsání údajů do registrů. Část nastavení je v sekci CURRENT_USER a část v LOCAL_MACHINE (viz Obrázek č. 12). Nastavuje se řada defaultních hodnot pro aplikaci a chování tištěných a souborových výstupů. 49
Obrázek č. 12: Ukázka zápisu IS CIBIS do registrů. Zdroj: [Registry PC]
Krom zápisu HBA do klasických registrů vyuţívá HBA svoje registry (registry aplikace). Ukázkou se nebudu zabývat, jen povaţuji za důleţité se o takové moţnosti zmínit. Jedná se o určitou podobu číselníku, který nemá klasické zobrazení na formuláři (na front endu). Těmito parametry se řídí celá řada potřebných nastavení, defaultních hodnot atd. Vestavěné procedury, funkce a v podstatě i kód HBA si je načte a pracuje s těmito nastaveními. Popis, resp. metadata, těchto registrů je velmi sloţitý a sofistikovaný pro prostředí RSTS (formulace pojmů, definice stavů, apod.).
50
5.3 Požadavek na novou úlohu v HBA V dalších podkapitolách se budu věnovat konkrétní části HBA, která se týká insolvence. Co to vlastně insolvence je? Jde o vyhlášení osobního bankrotu, který musí schválit insolvenční soud na základě splnění podmínek Zákona č. 182/2006 Sb., o úpadku a způsobech jeho řešení (insolvenční zákon). Aby se daly úpadky či osobní bankroty veřejně sledovat a banky měly nástroj pro kontrolu vlastních pohledávek, vznikl veřejný rejstřík Insolvence (ISIR10) na webových stránkách. Z pohledu finanční instituce je potřebné splnit termíny a náleţitosti přihlášky pro správné přihlášení pohledávky. Pokud tak neučiní, můţe pohledávka za nesplativším klientem být neuspokojena a později odepsána. Jedná se úlohu a funkcionality, které jsem řešil jako hlavní analytik a koordinátor OAV na straně RSTS. Celý proces zadání poţadavku na změnu či vývoj nové úlohy jsem řídil a koordinoval od definice, analýzy potřeb a dopadů, přes schůzky s dodavatelem HBA. Vzhledem ke sloţitosti řešení se jednalo o poměrně sloţitý proces, a proto se nejprve na základě nejasných definic uţivatelů přikročilo k posunutí termínu o cca půl roku. V průběhu tohoto období jsem si s uţivateli vyjasňoval detailně potřeby, studoval insolvenční zákon atd. Toto období bylo tedy vyuţito k určení jasného zadání. Uţivatelé velmi často měnili svůj názor a pohled na celou problematiku. Bylo nutné stav zapsat a nechat schválit, abychom měli na čem stavět. S dodavatelem IS jsme následně vytvořili základní principy řešení, které prošly schvalovacím řízením a následným odsouhlasením uţivatelů a změnového výboru. Na základě principů vznikla nabídka a ocenění poţadavku. Cenovou nabídku posuzoval řídící výbor změn spolu s představenstvem, neboť cena se pohybovala na vyšší cenové hladině (řádově cca 3-4 miliony Kč). Následoval úvodní návrh řešení. Samotný návrh procházel tříkolovým systémem připomínek a vyjasňováním nejasností na obou stranách. Konečný dokument (v páté verzi), ke kterému jsme následně tvořili Annexy na základě dalších zjištění při implementaci, nových právních úprav insolvence či zbylých nedořešených (skrytých) nejasností.
10
Více na stránkách: http://portal.justice.cz/Justice2/Uvod/uvod.aspx, kde lze dohledat podmínky webové sluţby, ale i konkrétní fyzické či právnické osoby v insolvenci. Sluţba umoţňuje i dávkové přenosy.
51
Součástí spolupráce byl i popis chování úloh a funkcionalit, včetně spolupráce na tvorbu dokumentace, grafů a diagramů, které se pak staly nedílnou součástí dodávky části IS a popisu dat, tedy obecně metadat této části HBA.
5.4 Metadata konkrétní úlohy v HBA Základem metadat je vygenerovaný model v Eterprise Architect (EA) a výše zmiňovaný funkční katalog. V katalogu jsou zaznamenány všechny funkce v systému k dané úloze – viz Obrázek č. 13. Přes číselné odkazy se dá pak vyhledávat konkrétní funkcionalita či Use Case přímo v elektronické dokumentaci k HBA CIBIS.
Obrázek č. 13: Ukázka funkčního katalogu "Insolvence". Zdroj: [15 - vlastní úprava]
Na funkční katalog navazují metadata oprávnění a zařazení do stromové struktury aplikace. Z ukázky je pak poznat, v které sekci se nachází ta či ona úloha a které funkce jsou do úloh zařazeny i s vazbou na konkrétní případy uţití. Sekce oprávnění není zobrazena a zveřejněna. Součástí metadat je i seznam práv k jednotlivým úlohám a funkcím, a to dle členění jednotlivých skupin řešitelů a odborných útvarů. Výjimky jsou pak sloţitě popsány v samostatném dokumentu.
52
Obrázek č. 14: Ukázka zařazení do aplikace. Zdroj: [15 - vlastní úprava]
Do modelu EA jsou dopracovány v průběhu času všechny úlohy, Use Case diagramy, Class diagramy, Business Process diagramy, Obchodní pravidla apod. Jedná se o celou řadu důleţitých definic pro pochopení chování IS a vazeb jednotlivých činností.
Obrázek č. 15: Ukázka stromu metadat v EA. Zdroj: [15]
Na následujícím obrázku ukáţu, jak se proces insolvence zahájí. Nejdříve slovní popis principu. V IS CIBIS jsou zaznamenáni klienti RSTS, ti se replikují v nočních hodinách na IS IDFU-ISIR, který zprostředkovává komunikaci s portálem justice.cz (ISIR). V pozadí běţí „Daemon“ proces, který kaţdých 5 minut kontroluje změny v rejstříku ISIR a ty zaznamenává do IS IDFU-ISIR od firmy Aegis. Tento systém generuje emaily a zasílá je pověřeným osobám k dalšímu zpracování. Pokud osoba není klientem RSTS je zaznamenán záznam pouze do vlastní DB IDFU-ISIR. Na základě emailu a dalších údajů 53
pověřená osoba nastartuje proces v IS CIBIS. Vlastní napojení CIBIS na ISIR předpokládáme v další fázi vývoje úlohy Insolvence. Start procesu je v tuto chvíli ruční zadání do úlohy insolvence. Některé atributy jsou definovány jako povinné a jiné nikoli. Všechny vstupní údaje podléhají nadefinovaným kontrolám, které jsou naprogramovány, příp. zadány jako integritní omezení v definici relačního modelu. Případ začíná v systému svůj cyklus, přičemţ vznikají konkrétní úkoly ke konkrétním datlům a zároveň se dle dalších vstupních dat mění stavy insolventního řízení v systému.
Obrázek č. 16: Byznys proces zahájení "Insolvence". Zdroj: [15 - vlastní úprava]
Je jasné, ţe insolvence má nějaký ţivotní cyklus a ţe prochází předem definovanými stavy. Ty jsou zachyceny na stavovém diagramu. Vytvoření a popsání tohoto diagramu bylo poměrně sloţitou záleţitostí, neboť jsem naráţel na jiné pojetí vnímání samotnými uţivateli. Nakonec jsme si však terminálové stavy dokázali společně vysvětlit a pochopit. Konkrétní stav je popsán v dokumentaci a měl by být srozumitelný i člověku, který nezná detailně průchod insolventního řízení. Celá problematika má ještě druhou stranu mince. Tou je legislativa, která se velmi často mění, a zároveň nejsou prověřeny všechny větve 54
právního výkladu, neboť institut insolvence je poměrně mladou záleţitostí. K poměrně velkému mnoţství případů a stavů ještě nebyla vydána patřičná usnesení. Zároveň k některým okrajovým případům nebyla vydána prováděcí vyhláška. I to je důvodem, proč jsou vysvětlení právníků rozdílná a proč jsou různě chápány situace v různých finančních (nejen finančních) institucích. Pojďme si ukázat základní stavy insolvence, jak jsem je identifikoval a zapsal do stavového diagramu, který je taktéţ součástí modelu a metadat.
Obrázek č. 17: Stavový diagram insolvence. Zdroj: [Vlastní úprava]
Nyní zkusme v metadatech či dokumentaci najít Use Case diagram k zahájení insolvence. Intuitivně v menu EA dohledáme - viz Obrázek č. 15 - část
Insolvence Zahájení insolvence. Je potřeba si uvědomit, ţe tvorba všech diagramů, případů uţití, byznys pravidel a datového modelu, probíhala v rámci řešení poţadavku, coţ mimo jiné znamená, ţe všechny tyto dokumenty byly přílohou nebo obsahem materiálu návrhu řešení Insolvence. Je tedy jasné, ţe dokument měl technický ráz, včetně základních
55
a alternativních cest procesů, ale zároveň měl dokument sekci „lidsky“ psanou, aby se dokázali v problematice orientovat i „běţní“ odborní pracovníci (uţivatelé), kteří znají svoji práci a jejich byznys pohled na řešení je rozdílný od chápání a řeči analytiků, programátorů a architektů SW.
Obrázek č. 18: Model případu uţití – zahájení insolvence. Zdroj: [15 - vlastní úprava]
Z diagramu, resp. modelu případu uţití je vidět, ţe při zahájení insolvence se provádí celá řada automatických kontrol a úkonů. Z dokumentace, resp. metadat v EA, se dá vţdy provolat na patřičný Use Case (případ uţití), z kterého se dá následně vyčíst, jak a co IS v daném okamţiku vykonává, za jakých podmínek a co je vstupem, resp. výstupem. V tomto konkrétním případu jsme si našli případ uţití „Aktualizovat okolí insolvence automaticky“. Zde jsme vydefinovali, jak se mají měnit agendy (kartotéky či matriky), které přímo souvisí s obsluhou produktů daného klienta v insolvenci (insolventa). Pro snazší chápání ukázky je pak popsáno dále v práci. Zároveň je vidět, ţe se při zahájení insolvence nějakým způsobem přidělí číslo jednací RSTS. Vlastní algoritmus je pak detailně popsán v Use Case „Přidělit číslo jednací banky“. Zaevidují se produkty do samostatné evidence, včetně dalšího UC, kdy se přiřadí, resp. vyhodnotí a zaevidují i role klientů k produktům. Na pozadí probíhají i kontroly na základě byznys pravidel, zda dodané číslo insolvenčního řízení je v pořádku, to se pak následně rozloţí do jednotlivých polí v tabulkách.
56
Obrázek č. 19: Ukázka provolání na Use Case. Zdroj: [15 - vlastní úprava]
Vlastní dokument případu uţití nepatří mezi metadata, nicméně je potřeba si uvědomit, ţe součástí metadat jsou i vloţené a přiloţené dokumenty nebo odkazy na ně. Je potřeba na celý IS, metadata a jejich popis nahlíţet komplexně, včetně uţivatelské dokumentace. V záloţce Other Links jsou vidět vazby na okolí konkrétního UC – viz následující Obrázek č. 20. V poloţce, resp. sloupci, Direction je příznak, zda je UC volán či kam naopak sám zapisuje/vstupuje a z jakého UC (sloupec Object).
Obrázek č. 20: Detail Other links. Zdroj: [15]
V modelu je opět moţné se provolávat do konkrétního objektu, např. do UC „Provést vinkulaci vkladů“. Jedná se o UC, který byl do modelu zaveden jiţ v minulosti – viz Obrázek č. 21 níţe, včetně identifikace, tj. záloţka Tagged Values. Nicméně samotný UC je jiţ modifikován na základě nového poţadavku, nachází se na správném úloţišti souborů a odkaz přes webovou správu metadat (dokumentace) odkazuje na aktuální/upravený UC, byť se v modelu nemění čas modifikace. V našem případě je to
57
důvod vinkulace typu „insolvence“ a pochopitelně se také mění stavy, pořadí vinkulací, atd. Vlastní UC do práce nepřikládám, neboť není potřeba podmínky a způsob průběhu vyhodnocování a zpracování zveřejňovat a pro potřeby popisu metadat nemá znění UC význam, resp. dopad.
Obrázek č. 21: UC Provést vinkulaci vkladů – identifikace. Zdroj: [15]
Za zmínku stojí také záloţka Associations To (viz Obrázek č. 22), kde je vidět Aktor nebo zjednodušeně uţivatel, resp. skupina uţivatelů, která implicitně funkci vyuţívá a smí spouštět. Krom pracovníků back office pracuje s UC také na základě UC „Zahájení insolvence“ IS automaticky.
Obrázek č. 22: Ukázka záloţky Associations To. Zdroj: [15]
58
Pro bliţší dokreslení situace bychom si museli ještě zveřejnit výše uvedená vlivy nastavení číselníku. Číselník řídí mimo jiné i okamţiky, kdy dochází k automatické aktualizaci, a to na základě definice té či oné funkce, viz class diagram parametrů (viz Obrázek č. 23). Jedná se jiţ o zapracování aplikační logiky dle uţivatelských nastavení HBA, které se můţe v průběhu času měnit. Číselník pouţívaný v aplikaci je pak blíţe popsán v dokumentaci, resp. jeho obsah je poměrně intuitivní. Pro představu si však jeho obsah ukáţeme, aby bylo patrné, které konkrétní funkce ovlivňují, resp. s příslušným UC pracují. Ovlivněných případů uţití je celá řada, a to vţdy dle nastavení. Pokud je potřeba dopracovat novou funkcionalitu, která má mít vliv na chování aktualizace okolí, je potřeba zadat změnový poţadavek na SW, neboť o takovém chování je potřeba programovat (funkci nebo proceduru), včetně formuláře na správu úlohy.
Obrázek č. 23: Class Parametry – doménový model. Zdroj: [15 - vlastní úprava]
Jak je z ukázek diagramu (viz Obrázek č. 23: Class Parametry – doménový model. Zdroj: [15 vlastní úprava]), metadat číselníku (viz Obrázek č. 24) a formulářového zobrazení číselníku
v aplikaci patrné (viz Obrázek č. 25), vlastní interpretace v číselníku, např. hodnota minimální klasifikace osoby (integer), nemusí odpovídat vizuální podobě (slovně: ztrátový) ve formuláři aplikace. Na pozadí pochopitelně pracuje aplikační logika (vestavěné funkce a procedury). Údaje byly pro ukázku v testovacím prostředí modifikovány a neodpovídají reálnému nastavení.
59
Obrázek č. 24: Metadata číselníku parametrů. Zdroj: [15 - vlastní úprava]
Obrázek č. 25: Číselník HBA - Aktualizace okolí. Zdroj: [14]
Součástí funkcionality „Insolvence“ jsou i podpůrné výběry přímo přes aplikační rozhraní. I tyto standardizované výstupy (většinou soubor v textové podobě „txt“ oddělený nadefinovaný příslušným oddělovačem a soubor MS Excel) mají svůj popis metadat. Je potřeba určit význam polí na výstupu, jejich stručný popis a definici. V metadatech je určen datový typ a délka poloţky. Krátká ukázka metadat „Exportu insolvence“ následuje na dalším obrázku (viz Obrázek č. 26). V ukázce nejsou uvedeny všechny poloţky výstupu a zároveň jsou doplněny některé chybějící základní údaje metadat. Na základě zjištění se snaţím o optimalizaci současného řešení. Většina
60
optimalizací se daří uvést do reálného ţivota. Výsledek exportu je v podobě souboru MS Excel
a
zároveň
v podobě
textového
souboru
s pevnou
délkou.
Obdobně,
resp. podrobněji, a to dle sloţitosti exportovaných údajů, jsou popsány všechny exporty/extrakty z HBA. Výsledkem některých exportů je soubor, v některých případech tisková podoba. Často se objevuje i kombinovaná forma. Pak na tiskovém výstupu můţe být rozdílná mnoţina údajů neţ v souborové podobě. Zde vidím velký potenciál pro zlepšení kvality metadat, neboť v některých případech chybí definice datových typů, délky polí, názvy výstupních polí. U jiných sekcí chybí bliţší popis významu poloţky, zdroje dat, vyuţití (kdo a jak často) apod. V rámci analýzy jsem jiţ navrhl úpravy – viz upravený obrázek. Nedostatkům se budu důkladněji věnovat v kapitole 6.
Obrázek č. 26: Metadata exportního souboru. Zdroj: [Vlastní úprava]
5.5 Popis datového modelu a relací v IS Na krátkém výseku datového modelu ukáţu i část a popis týkající se modelu databáze. Nebudu se věnovat popisu jednotlivých tabulek a konkrétnímu významu atributů. Pokusím se však ukázat praktický model a evidenci konkrétní relace, která se týká vazeb mezi konkrétní úlohou, číselníkem, ale i referenční integrity. Pro ukázku pouţiji jednodušší tabulku produktů insolvence. V podstatě se jedná o jakousi matriku, kde jsou 61
evidovány všechny údaje a vazby mezi produktem, konkrétní osobou, resp. jeho rolí k produktu a vlastním číslem insolvenčního řízení. Při exportech těchto dat hledají koncoví uţivatelé velmi často význam jednotlivých polí. Aby byli schopni dohledat konkrétní význam, je jim zpřístupněna databáze s metadaty, kde podle názvu úlohy a příslušného exportu zjistí zdroje dat (konkrétní tabulky), příp. mohou nahlédnout do celého modelu a poţádat OAV o vysvětlení. Na následujících obrázcích je ukázka moţného popisu konkrétní tabulky, klíčů, triggerů (předem definované akce), apod. Jedná se o vlastní upravený návrh, neboť na současném řešení popisu metadat řada údajů není k dispozici (jde tedy o návrh optimalizace – viz Obrázek č. 27). Pro představu následuje ukázka modelu, kde se daná tabulka nachází. Celý model je pochopitelně daleko sloţitější, neboť nejsou zobrazeny vazby do okolních základních úloh (Osoby, Produkty, Státní podpora, apod.) , z kterých daná úloha „Insolvence“ vychází.
Obrázek č. 27: Metadata konkrétní tabulky. Zdroj: [Vlastní úprava]
Následuje ukázka, jak by mohl vypadat výstřiţek z dokumentace datového modelu (webové rozhraní metadat pro koncové uţivatele) ke konkrétní úloze (viz Obrázek č. 28). Jedná se o spíše analytický pohled pro znalé uţivatele, nicméně je dobré si část modelu zobrazit, resp. ukázat. Jedná se kopii z dokumentace, neboť dílčí (vlastní zpracované)
62
návrhy jsou jiţ jen v interní dokumentaci, resp. byly aplikovány přímo do popisu a dokumentace HBA. Je pochopitelné, ţe v práci nelze udělat v podstatě ucelený náhled na takto sloţitou část IS, včetně metadat. Pro představu uvádím rozsah návrhu řešení úlohy Insolvence. Dokument s „Principy“ cca 60 stran, „Návrh řešení“ cca 220 stran. Přibliţně 8 Annexů na doplnění v průběhu implementace řešení. Datový model, včetně číselníků čítá kolem 30 tabulek, včetně napojení na mnoho stávajících evidencí. S tím souvisí i rozšíření dokumentace, modelů, popis exportů (tisky, soubory), včetně doplnění metadat.
Obrázek č. 28: Ukázka části datového modelu „Insolvence“. Zdroj: [15]
Na obrázku v příloze znázorním návrh třídy matriky insolvence (datového modelu), který jsem navrhl v rámci tvorby návrhu řešení (viz Příloha č. 1). Zároveň stručně popíšu entitu „Insolvence“ mimo vazebních a referenčních poloţek. Jde o hrubý obrys, jak jsem si představil konkrétní řešení třídy „Insolvence“ a její napojení na další objekty.
63
5.6 Shrnutí kapitoly Domnívám se, ţe v kapitole 5 jsem poměrně důkladně přiblíţil jednu část funkcionality HBA. Na zjednodušeném modelu, výkladu chování úlohy „Insolvence“ a dalších podpůrných záleţitostí okolo řešení insolvence, jako jsou sledované transakce z důvodu insolvence, číselníky a další přidruţené úlohy a obsluţné funkce, jsem ukázal důleţitost dat samotných, ale zároveň i velkou důleţitost popisu dat, tedy metadat. Ze systémových ukázek a vlastních ukázek moţností rozšíření řešení evidence metadat je patrné, jakým směrem se dá metasystém v dalším období směrovat. Nastínil jsem další moţnosti doplnění metasystému, kterému se budu v praxi věnovat, neboť je evidentní, ţe některé údaje zcela chybí nebo jsou značně neúplné. To můţe vést k nepochopení existence evidencí a celého systémového řešení ze strany koncových uţivatelů. Taková situace můţe následně vést ke sníţení efektivity práce a přínos zavedení nových funkčností pak není optimální. De facto se sniţuje procentní přínos zavedení části IS do produkčních systémů, neboť odborné útvary nedokáţou vyuţít všechny výhody. Zároveň nedokáţou optimalizovat procesy, a to jen proto, ţe některým datům, údajům a postupům nerozumí.
64
6 Porovnání a návrh doporučení ke zkvalitnění 6.1 Úvod do kapitoly V této části práce se budu věnovat porovnání teoretické hladiny metasystémů s praxí, kterou mám jednak z předchozího působiště (Komerční banka), ale především z řešení v Raiffeisen stavební spořitelně (RSTS) a Hypo stavební spořitelně, která byla fúzí převedena do RSTS v roce 2008. V Hypo stavební spořitelně jsem se mimo jiné zúčastnil zavedení MIS, včetně všech popisů metadat. Podrobněji jsem celé zavádění MIS popsal ve své bakalářské práci.
6.2 Porovnání teorie a praxe Domnívám se, ţe teoretický popis dat, metadat a metasystémů je poměrně odlišný od praktického stavu v jednotlivých metasystémech společnosti. Ţádná z výše uvedených institucí nepouţívá univerzální metasystém napříč všemi IS. Zároveň jsem se v praxi nesetkal s takovou komplexností popisu dat, resp. vlastnostmi metadat, které jsou v teoretické části práce popsány. Teorie, resp. metodika má svůj význam, ale je zřejmé, ţe kaţdá instituce se jí snaţí přizpůsobit k obrazu svému, a proto některé dimenze vypouští. Vše se děje na základě vyhodnocení priorit a důleţitosti těch či oněch dat a metadat z pohledu konkrétní instituce. Vzhledem k tomu, ţe v RSTS neexistuje jednotný metasystém, ale data, resp. metadata, jsou uloţena v jednotlivých IS nebo přímo v dokumentacích ke konkrétním IS nebo v projektové dokumentaci, nelze srovnání provést na optimální bázi a úrovni. Existuje pochopitelně celá řada dokumentů, které řeší vazby mezi dimenzemi, stejně jako projekty či dokumentace, která primárně vzniká za účelem integrace datových údajů, nicméně je to sloţitá a poměrně „drahá“ (zdroje – časové, lidské, finanční) záleţitost. Nicméně pro naše účely a potřeby budu hovořit o metasystému RSTS, byť se jedná o fragment celého komplexního metasystému. Tyto fragmenty by se musely poskládat a zastřešit jednotným MtS přes všechny důleţité IS. Pokud se na řešení podíváme z globálního hlediska, pak se dá říci, ţe se v teorii i praxi pouţívá datový slovník (popis datového obsahu pomocí metadat). Jednotlivé části metasystémů jsou skutečně založeny na dimenzích, kdy jsou obory hodnot dány číselníky. MtS zahrnují, alespoň ve většině případů, strukturální a referenční metadata.
65
Dá se také říci, ţe při pouţití standardů, je zvýšena efektivita algoritmizace a automatizace procesu zpracování, sběru, transformace, ale i prezentace dat. Všechny tyto charakteristiky umoţňují efektivní řízení datové kvality a efektivní vyuţití dat k dalším vyuţitím, včetně výkazů směrem k regulátorům trhu. Hlavním a základním cílem MtS v RSTS je podpora odborných útvarů. Proto je velký důraz kladen především na strukturu a výměnu dat. Strukturování metadat je pak zaměřeno na agregovaná data a zobrazovaná data ve formulářích aplikace. To znamená, ţe se metadata zabývají z velké části prezentací (publikací) dat, a to v prezenční vrstvě aplikace nebo v tištěné či tabulkové podobě výstupů. Další důleţitou oblastí je podpora managementu firmy. Úplný a pravdivý popis struktur a dat pomocí metadat umoţňuje vedení dělat správná rozhodnutí na úrovni operativního, taktického i strategického rozhodnutí. Nejde o přímou podporu, ale o kvalitu analýzy podkladů pro tato rozhodnutí. Jednotlivé dimenze jsou však víceméně v RSTS pokryty, a to především v jednotlivých IS, resp. částech IS a dokumentacích. Podívejme se na jednotlivé dimenze: Data a informace – MtS zachycuje všechny potřebné údaje o vztazích objektů, datových strukturách, datových tocích a segmentech. HBA je pokryta dokumentací. Vazby mezi IS, rozhraním a daty jsou většinou popsány v dokumentaci, která právě vzniká a řeší integraci datových údajů. Funkce a procesy – dimenze se zaměřuje na procesy probíhající v podniku a jejich moţnou podporu IS. MtS RSTS nepokrývá tuto dimenzi globálně. Data jsou roztroušena v jednotlivých projektových dokumentacích, interních předpisech a příkazech. Zde vidím poměrně velkou potřebu doplnění zodpovědností za procesy a funkce, včetně stanovení vlastníků jednotlivých procesů. Údaje je potřeba doplnit do dokumentace, minimálně k HBA a k rozhraním, se kterými HBA komunikuje. Organizační, personální a legislativní aspekty – v RSTS částečně řeší IS pro personální oddělení, nicméně důleţité části s vazbou na projekty a organizační strukturu, která má dopad na procesy a funkce je definována spíše v interních předpisech a příkazech. Pracovní, sociální a etické aspekty – v podmínkách RSTS dimenze není samostatně zastoupena. Víceméně je řešena jiţ v dimenzi organizační. Softwarová – MtS RSTS poměrně podrobně eviduje jednotlivé IS (operační, databázový systém), ASW, včetně vazeb na dodavatele a informací o provozu IS, aplikací, včetně podpory. U vyvíjených komponent definuje nástroje a vývojové prostředí. 66
Hardwarová – samostatná dokumentace, která je primárně vedena v OIT. Dokumentace řeší technické vybavení systému, určuje typy, parametry a počty počítačů, periferních zařízení a komunikačních sítí. Část je pak řešena v evidenci majetku. Ekonomické aspekty – většina údajů je vedena v konkrétních projektových dokumentacích. Celková nákladovost, včetně analýzy rizik je vedena sledována v MIS, kam jsou data exportována ze všech důleţitých IS (fakturace za IS, náklady projektů, náklady za ASW, HW, lidské zdroje, sluţby). V MtS tyto údaje samostatně nefigurují. Metody a normy – v podmínkách RSTS tato dimenze v MtS zastoupena není. Zde vidím však opět potenciál a potřebu, neboť není zřejmé, proč se rozhodlo právě tak či onak a na základě jakých metodik či norem. Nejsou určeny konkrétní metody, techniky a nástroje pouţívané v jednotlivých fázích vývoje IS pro analýzu, návrh, následnou implementaci a pozdější provozování IS. Opět je částečně řešeno formou interních předpisů a příkazů Dokumenty – většina dokumentace je udrţována a tvořena manuálně. Existují části dokumentace, které jsou tvořeny za pomoc sofistikovaných CASE nástrojů (typickým zástupcem je dokumentace HBA). Výstupy je však potřeba manuálně opatřit dalšími důleţitými popisy. Kvalitní, úplná a hodnotná dokumentace bývá kritickým místem mnoha organizací, a proto je potřeba nepodcenit dokumentační dimenzi. Zpětné popisy jsou velmi pracné a časově náročné, nicméně takový postup bývá velmi často aplikován. Principy řízení – jsou řešeny především v kompetenčním řádu a interních příkazech týkajících se IS/IT. K optimalizaci lidských, finančních a materiálních zdrojů, aby byly dosaţeny cíle při efektivním vyuţití zdrojů, dochází především při zaloţení pracovních skupin a projektových týmů. Metodika, organizace a plány jsou řízeny projektovou kanceláří, kde je následně uloţena i dokumentace. Vazby na konkrétní MtS IS však v popisech chybí. Čas – v MtS se udrţují údaje o jednotlivých projektech, etapách projektů a časových harmonogramech, a to v projektové kanceláři. Typickým nástrojem je MS Project. Vazby na konkrétní IS a ASW však v MtS nejsou podchyceny, tzn., ţe vyhledání napojení na konkrétní systém či aplikaci není snadnou a úplně triviální záleţitostí. Bezpečnost – není řešeno přímo v MtS, ale existuje řada logů a aplikace, do které se incidenty zaznamenávají. Ataky zásadního charakteru jsou pak sledovány aplikací na bezpečnost v odboru řízení rizik. Funkce (pracovní místo) bezpečnostního manaţera je právě definována a v nejbliţší době bude vypsáno výběrové řízení.
67
Operace MtS jsou aplikovány jen na úrovni systémového vyuţití. Tzn. je aplikováno sledování provozu, typicky pak sledování vytíţenosti jednotlivých zdrojů a monitorování přístupů, včetně sledování logů a oprávnění. Komplexní architektura MtS není v RSTS definována. Opět je potřeba konstatovat, ţe vzhledem k neexistenci globálního řešení MtS, nelze hovořit o jednoduchosti uţití, přiměřené pracovní náročnosti, ani o pruţnosti řešení. Tyto parametry v podstatě splňují jednotlivé komponenty, tedy jednotlivé IS, jejich dokumentace a interní předpisy, příkazy a schválené postupy. Z globálního pohledu se dá ale říci, ţe v RSTS MtS existuje a je pro hlavní činnosti instituce provozuschopný, splňující základní metodické vlastnosti, při porovnání dle doc. Ing. Voříška, CSc., a je přínosem pro všechny organizační stupně v instituci (koncoví odborní pracovníci, uţivatelé IS a dat, střední management, vedení společnosti).
6.3 Náměty na zlepšení a doporučení ke zkvalitnění Byť v RSTS neexistuje jednotné komplexní řešení MtS, je částečná funkce MtS zastoupena v jednotlivých IS. V práci se věnuji především CORE systému, kterým je HBA CIBIS. V práci jsem si dovolil pouţít několik ukázek popisu metadat, které jsem buď doplnil či celé vytvořil. Řada popisů a diagramů vzniká v rámci jednotlivých projektů či pracovních skupin, resp. při tvorbě návrhů a řešení konkrétních funkcionalit a potřeb instituce. V první chvíli se na úplný popis dat a metadat, bohuţel, tolik nemyslí, coţ přináší problémy v dalších fázích pouţití IS. V současné době se snaţím prosadit důkladnou analýzu a popis dat jiţ v raném stádiu zavádění nových funkcionalit IS do systému, abychom předešli vícenákladům a problémům s výkladem pojmů v budoucnu (v průběhu implementace, školení atd.). Osobně jsem jiţ navrhl konkrétní opatření na doplnění některých důleţitých vazeb. Typickým představitelem návrhu na zlepšení je plnohodnotné doplnění vlastnictví dat v jednotlivých relacích IS. S tím je přímo spjatá i zodpovědnost za data a následné procesy zpracování dat, včetně jejich vyuţití (v jakém čase, za jakých podmínek, kdo je bude vyuţívat apod.). Většina těchto připomínek a vylepšení je ve fázi schvalování pracovní skupinou a výborem pro řízení změn, neboť je to zásah do současných struktur, ale i zásah do tvorby dokumentace pomocí EA.
68
V některých metadatech exportů chybějí základní údaje o délce exportovaného pole, datovém typu, či přímo popis zdroje dat (významy hodnot) a jejich další vyuţití (kdo, kdy a jak). I zde jsem podal základní náměty na vylepšení, neboť není splněn základní princip metasystému, kterým je popis dat a souvisejících procesů pomocí metadat. Tím by se obecně měla zvýšit efektivita správy dat, exportů, rozhraní na okolní systémy z HBA. Obecně se vytváří robustnější datová základna a její popis. Velkou část úprav metadat jsem se pak snaţil začlenit i do vlastních podpůrných úloh. Typickým představitelem je aplikace „Sestavy“, do které zapisují pracovníci OAV důleţité SQL dotazy a procedury, které vybírají data dle potřeb odborných útvarů. Pročistil jsem nepouţívané sestavy. Sestavy, které odkazovaly na neexistující tabulky, byly odstraněny (s předchozí zálohou) nebo přepracovány na odpovídající současné datové struktury. Zároveň jsem provedl popis vstupů, výstupů a pouţitelnost jednotlivých sestav a pokusil jsem se zavést nějaký rozumný přístup popisů přímo do procedur (viz Příloha č. 2). U sestav se nově eviduje primární věcné určení, ţadatel a jejich vyuţitelnost (popis polí), aby nedocházelo k duplikování výstupů (exportů dat či tisků) a k rozdílné interpretaci stejných dat. Je jasné, ţe pro finanční instituce představují data a jejich popis, základní nástroj pro sledování a plnění cílů globální strategie. Data musí být u koncových uţivatelů včas, v potřebné kvalitě, srozumitelná a jednoznačně určená. Z dat se dají vyvodit potřeby a moţnosti, ale dají se zároveň vyhodnotit rizika a hrozby. MtS tak hraje klíčovou úlohu v integraci IS a v kvalitě dat v IS samotných.
6.4 Výsledky shrnutí, výhody a nevýhody metasystémů Jak je jiţ výše popsáno, je evidentní, ţe metasystémy hrají velkou úlohu v IS jednotlivých institucí. Metadata mají přímý vliv na kvalitu dat a tím i na kvalitu IS samotného. Zároveň kvalita metadat ovlivňuje pohled od běţných uţivatelů aţ po vedení společnosti. Instituce typu bank vyuţívají i metadata regulátora trhu, např. metadata ČNB pro výkaznictví. Tato metadata jsou pak přímo integrována do vlastních IS a při komunikaci s ČNB se pouze vyuţívají pro společnou „řeč a komunikaci“ mezi systémy. Kvalitní systém je řízen skutečnými odborníky, kteří problematice rozumí. Změny obsahu a struktury exportů či výkazů mohou být realizovány na vrstvě metadat, čímţ můţe docházet k úspoře lidských zdrojů z oblasti IT odborníků. V případě široké integrace MtS
69
do IS instituce nevzniká popis dat na jedno pouţití, ale vznikají plnohodnotně popsané datové prvky, které se dále vyuţívají při prezentaci dat, tvorbě výkazů, definici údajů a v neposlední řadě při běţné provozní činnosti jednotlivých odborných útvarů. Výhodou je taktéţ „verzování“ dokumentací a modelů, tzn., ţe se dají dohledat rozdíly a nové vstupy na úrovni jednotlivých návrhů řešení v průběhu času. Ideální se zdá být i automatizované řešení správy metadat a procesů. To však je jiţ velmi nákladnou záleţitostí. I přesto, ţe se domnívám, ţe klady převaţují nad zápory, je potřeba se o záporech zmínit. Jedním ze záporů můţe být přílišná jemnost či podrobnost datové základny, která se pak můţe stát velmi těţko udrţovatelnou. To následně ovlivní s největší pravděpodobností i kvalitu dat. Ukládání dat nesmí být primárně řešeno z pohledu MtS, ale z pohledu transakčních systémů, aby se neprodlouţily odezvy uţivatelům. Tím by mohlo dojít ke zvýšené zátěţi technologických zdrojů a databází. Výsledkem by bylo zpomalení či praktická neovladatelnost či nefunkčnost IS. Zároveň je velmi těţké o potřebách důkladného popisu přesvědčit koncové uţivatele, neboť pro ně je téměř vţdy rychlejší a výhodnější ad hoc řešení, kde je výsledná sestava prakticky shodná s tabulkou (např. MS Excel). Uţivatelé, resp. vlastníci dat a procesů musí odvést poměrně velké mnoţství práce při zmapování informací, procesů a popisu datové základny, coţ na ně klade další nároky. Samotný popis procesů je velmi obtíţnou a sloţitou záleţitostí. Je potřeba důkladně popsat nejen vstupní data, ale i data po ETL procesech, kdy dochází k jejich modifikaci. Taková činnost není standardním uţivatelům zcela vlastní a instituce si musí alokovat zdroje, především lidské u externích dodavatelů, coţ celé řešení prodluţuje, zesloţiťuje a prodraţuje. Vyuţití vlastních lidských zdrojů bývá zpravidla omezené moţnostmi instituce a interními předpisy. Dnešní finanční sektor je v drtivé většině se zahraniční kapitálovou účastí a ve většině „matek“ jiţ MtS existují, a proto se snaţí „donutit“ i instituce podnikající na českém trhu MtS zavést, a to dle pravidel vlastníka či celé skupiny. Počty transakcí, operací, ataků na bezpečnost atd., jsou nesrovnatelně vyšší neţ před několika lety. Obecně mohu říci, ţe celý systém HBA generuje obrovské objemy dat, výkazů a exportů. Z tohoto důvodu je jejich popis a popis vlastních procesů naprostou nezbytností. MtS tak hraje svoji klíčovou roli.
70
Závěr Ústředním cílem práce byla analýza informačních systémů v konkrétní stavební spořitelně a na reálném příkladu ukázat popis metadat a moţnou optimalizaci řešení. V práci jsem se proto věnoval teoretickému základu, který vychází především z teorií a metodiky doc. Ing. Voříška. Zabývám se popisem charakteristiky, vlastností a funkcí MtS. Následně se zabývám kvalitou dat a metadat. V další kapitole se snaţím přiblíţit finanční instituci (stavební spořitelnu), v které působím na pozici analytika v Odboru analýzy a vývoje IS. Plynule přecházím na analýzu a popis IS, tedy do praktické části práce. Detailněji se pak věnuji především hlavní bankovní aplikaci, resp. části aplikace, aby ukázka měla smysl a působila, alespoň částečně, v kompaktní podobě. Na některých případech jsem ukázal stávající popis v dokumentaci a IS v RSTS, který jsem v některých případech doplnil, příp. jsem ukázky a diagramy kompletně vytvořil. Řada těchto úprav byla přenesena i do reálného ţivota a do interní dokumentace k jednotlivým IS. V poslední části se pak snaţím shrnout výhody a nevýhody řešení MtS. Dochází k porovnání teorie a praxe a k návrhům na moţnou optimalizaci řešení. Doporučení ke zlepšení, resp. moţná optimalizace řešení je jiţ průběţně popisována i v páté kapitole. Domnívám se, ţe tím byl cíl práce naplněn. Nyní bude následovat detailní analýza potřeb na straně RSTS a pokusím se následně prosadit potřebné změny ke zkvalitnění metadat. O existenci komplexního řešení MtS se však nyní v RSTS neuvaţuje. Částečně budou pokryty chybějící údaje a procesy, a to i na základě auditu z Vídně (vlastník RSTS). Řada opatření byla však jiţ zapracována do materiálů RSTS na základě mých analýz v průběhu tvorby práce. Přínos pro čtenáře práce spatřuji v rozšíření pohledu na řešení popisu dat, metadat a tvorbu MtS. Zároveň se můţe poučit z chyb, nástrah a příkladů v práci uvedených. Práce se snaţí čtenáře nasměrovat do správných rozhodnutí při tvorbě MtS, včetně důleţitého rozhodnutí a výši podrobností metadat. Toto téma a jeho zpracování je taktéţ přínosem i pro moji osobu, neboť jsem nastudoval značné mnoţství materiálů, analyzoval stávající stav v instituci a dokázal jsem některá opatření uvést i do ţivota. Poznatky získané díky zpracování tématu práce jsem dokázal aktivně vyuţít. Pochopitelně se budu problematice i nadále věnovat, abych byl schopen 71
nabyté zkušenosti realizovat a prosazovat v praxi, a to v co největší míře. Dá se říci, ţe tento úkol mohu začlenit i do své skutečné pracovní náplně. Musím však konstatovat, ţe se nepodařilo prokázat naprostou nezbytnost existence MtS pro instituci. Je zřejmé, ţe kvalitní metasystémy a metadata mohou vést ke konkurenční výhodě, ale nedá se, se stoprocentní určitostí tvrdit, ţe firmy nedokáţou bez MtS existovat. Na druhou stranu je potřeba říci, ţe hranice výrazu metasystém a metadata je velmi diskutabilní, takţe i firma, která nemá metasystém, v zásadě nějaký blíţe popsaný IS pouţívá. Ten zcela jistě má i svá metadata. I přesto, ţe v RSTS neexistuje komplexní řešení MtS, je funkce MtS částečně zastoupena v jednotlivých IS či dokumentacích. Aplikování MtS je tedy moţné v jakékoli standardní instituci, včetně finančních institucí. Jednotlivá řešení se však budou výrazně lišit, a to jak komplexností, vazbami, tak i cenovou hladinou řešení. MtS jako takový má obrovské přednosti, je však potřeba se také zamyslet nad tím, kdo jej bude pouţívat a jaké přínosy skutečně bude mít. Nejde o pouhý popis skutečností, ale o popis reálných potřeb společnosti. Jsou popsány vazby mezi daty a procesy, včetně vlastníků a definice zodpovědnosti. Na základě údajů v MtS je potřeba nová a stávající řešení porovnávat a vyhodnocovat, včetně identifikace výhod, nevýhod, skutečných potřeb a přínosů. Musí tedy existovat nezávislý IS nebo popis, do kterého má moţnost nahlédnout příslušný kompetentní pracovník, který je schopen na základě zjištění dobře analyzovat potřeby a na stávající řešení dobře napasovat řešení doplněná/nová. Na základě modelů, resp. celého MtS, následně aplikuje, analyzuje a reportuje veškeré potřebné hodnoty. Z toho mimo jiné vyplývá, ţe instituce nemusí mít dostatek kvalitních a kompetentních pracovníků na správu a obsluhu MtS a musí shánět odborníky se zkušenostmi a analytickými či programátorskými schopnostmi, kteří jsou na trhu práce poměrně drahou investicí. Důvody, proč se poţadavky na popis, data, metadata, informační systém samotný a jejich analýzou musíme zabývat, jsou tedy zcela zřejmé. Kaţdá společnost se zabývá jinou obchodní činností, a pokud podniká ve stejném oboru jako jiná organizace či instituce, např. banky, tak byznys logika je natolik odlišná, ţe je potřeba pokrýt poţadavky kaţdé organizace samostatně. Kaţdá společnost chce dosáhnout jisté konkurenční výhody, a to je také jeden z faktorů, proč neexistuje zcela shodné softwarové vybavení a jeho popis.
72
Další změny v popisech a v samotných IS je potřeba aplikovat z důvodu případných legislativních změn ze strany regulátora, zákonů, ale i např. dle poţadavků EU či změn standardů mateřské společnosti. Je tedy evidentní, ţe je potřeba nejprve nashromáţdit poţadavky, data, informace a ty velmi důkladně analyzovat, aby konkrétní organizace dospěla ke kýţenému cíli co nejdříve, a to v potřebné kvalitě a v relativně krátkém čase. Nemalou úlohu hrají také finanční moţnosti a skutečné potřeby odborných oddělení. U menších firem bude kvalita MtS na zcela odlišné úrovni neţ u velkých firem. Zároveň se dá očekávat, ţe u menších a středních firem se nebude jednat s největší pravděpodobností o komplexní řešení MtS, ale pouze o případné dílčí popisy metadat, aby firmy vyhověly regulím, zákonům a potřebám trhu. Téma práce je velmi široké a obsáhlé a dalo by se rozvíjet i v budoucnu. Osobně se budu snaţit zrealizovat ještě více konkrétních kroků, aby MtS RSTS byl co nejkomplexnější a dokázal uţivatelům na všech úrovních poskytovat potřebný komfort. Částečně se daří některá rozšíření realizovat. Některá opatření si však vyţadují součinnost externího dodavatele a zde je výrazně těţší úpravy a změny prosadit.
73
Seznam použité literatury Tištěné monografie [1] BASL, J. a R. BLAŢÍČEK. Podnikové informační systémy: podnik v informační společnosti. 3., aktualizované a doplněné vydání. Praha: Grada, 2008. ISBN 978-80247-4307-3. [2] BRUCKNER, T., J. VOŘÍŠEK a A. BUCHALCEVOVÁ. Tvorba informačních systémů: principy, metodiky, architektury. 1. vyd. Praha: Grada, 2012, 357 s. Management v informační společnosti. ISBN 978-80-247-4153-6. [3] BUREŠ, Vladimír. Znalostní management a proces jeho zavádění: průvodce pro praxi. 1. vyd. Praha: Grada, 2007, 212 s. ISBN 978-80-247-1978-8. [4] DOUCEK, Petr. Statistika. Praha: Český statistický úřad, 1960, roč. 2005, č. 3. ISSN 0322-788x. [5] SODOMKA, P. a H. KLČOVÁ. Informační systémy v podnikové praxi. 2., aktualizované a rozšířené vydání. Brno: Computer Press, 2010. ISBN 978-80-2512878-7. [6] SYNEK, M. a kol. Podniková ekonomika. 4., přepracované a doplněné vydání. Praha: C. H. Beck, 2006. ISBN 978-80-7179-892-4. [7] VOŘÍŠEK, Jiří. Informační systémy a jejich řízení. 3. vyd. Praha: Bankovní institut vysoká škola, 2007, iv, 278 s. ISBN 978-80-7265-100-9.
Internetové a jiné zdroje [8] ČSN ISO/IEC 11179-4. Česká technická norma: Informační technologie - Registry metadat (MDR). Praha: Český normalizační institut, 2006. Dostupné z: [9] Glossary of Statistical Terms. Organisation for Economic Co-operation and Development: OECD [online]. 2006 [cit. 2014-09-02]. Dostupné z: [10] Information Technology Standards. ISO/IEC 11179: Information Technology Metadata registries (MDR) [online]. 2005, 2014 [cit. 2014-09-11]. Dostupné z: 74
[11] IS a SW pro finanční instituce. TURBOCONSULT S.R.O. Informační systém pro stavební spořitelny: CIBIS [online]. 2013 [cit. 2014-12-25]. Dostupné z: [12] RAIFFEISEN STAVEBNÍ SPOŘITELNA A.S. Management a akcionáři: Organizační struktura [online]. 2014 [cit. 2014-08-19]. Dostupné z: [13] RÁBOVÁ, I. MENDELOVA UNIVERZITA V BRNĚ. Informační systémy: Základní definice [online]. 2007 [cit. 2014-07-15]. Dostupné z: [14] RSTS. Hlavní Bankovní Aplikace CIBIS. Praha, 2014. [15] RSTS. Interní dokumentace. Praha, 2014. [16] SKŘIVÁNEK, František. Databázový svět [online]. 2008 [cit. 2014-08-18]. Dostupné z: [17] ŠMÍD, Vladimír. MDSI - Multidimensional Development of Information System [online]. web Fakulta informatiky MU, [2008] [cit. 2014-09-09]. Dostupné z: [18] ŠUSTA, Marek. Proverbs, a.s. Systémové vědy: systémové myšlení a systémová dynamika [online]. 2004 [cit. 2014-07-13]. Dostupné z: [19] Understanding metadata. National Information Standards Organization [online]. 2003 [cit. 2014-09-01]. Dostupné z:
75
Seznam zkratek a.s.
Akciová společnost - právní forma právnické osoby
ASSČR
Asociace stavebních spořitelen ČR (sdruţení stavebních spořitelen v ČR)
ASW
Aplikační softwarové vybavení
BI
Business Intelligence - podnikové zpravodajství (zdroj dat společnosti)
BRKI
Bankovní registr klientských informací
CASE
Computer Aided Software/System Engineering - počítačem podporované softwarové (systémové) inţenýrství
CBCB
Czech Banking Credit Bureau – společnost spravující BRKI a NRKI
CC
Clearingové centrum ČNB (přenos dat platebního styku)
CIBIS (CB)
Provozní IS pro stavební spořitelny
CRM
Customer Relationship Management - systém řízení vztahu se zákazníky
ČNB
Česká národní banka
ČNI
Český normalizační institut (úřad)
ČR
Česká republika
ČSN
Pův. československá státní norma, nyní neoficiálně Česká soustava norem; zákonem chráněné výlučné slovní označení je česká technická norma
DB
Databáze
DW
DataWarehouse - datový sklad
EA
Eterprise Architect – modelovací nástroj; nástroj dokumentace
EDI
Electronic Data Interchange - elektronická výměna dat (strukturovaných zpráv); nástroj pro komunikaci, propojení aplikací a výměny dat
EIS
Executive Information System - IS exekutivy - výkonné sloţky managementu
ERP
Enterprise Resource Planning - IS integrující a automatizující hlavní činnosti organizace
ETL
Extraction, Transformation, Loading - mechanismus získávání dat z provozních systémů podniku (ekonomika, skladové hospodářství, výroba, odbyt atd.) - datová pumpa
EU
Evropská unie
GIS
Geografic Information System - geografický informační systém
HBA
Hlavní bankovní aplikace (CORE systém; významově shodné s CIBIS)
76
HW
Hardware - technické vybavení serverů nebo počítačů
IEC
International Electrotechnical Commission - Mezinárodní elektrotechnická komise - vypracovává a publikuje mezinárodní normy
IS
Information System - informační systém
ISIR
Insolvenční rejstřík
ISO
International Organization for Standardization - mezinárodní organizace zabývající se tvorbou norem
IT
Information Technology - informační technologie
KB
Komerční banka - jedna z největších bank v ČR (vznik při rozpadu ČNB)
LMS
Learning Management System - systém pro řízení výuky
MDIS
Multidimensional Development of Information System - Metodický základ systémové integrace
MDR
Metadata Registry - registr metadat
MF
Ministerstvo financí
MIS
Management Information System - manaţerský informační systém
MRP
Material Requirements Planning - plánování materiálových potřeb
MtS
Metainformační systém - nástroj řízení vývoje integrovaného IS
NISO
National Information Standards Organization
NRKI
Nebankovní registr klientských informací
OAV
Odbor analýzy a aplikačního vývoje v RSTS
OIS
Office IS - napojení na kancelářské balíky
OIT
Odbor informačních technologií v RSTS
OZ
Obchodní zástupce
PC
Personal Computer - osobní počítač
PIS
Podnikový informační systém
RIS
Reservation Information System - rezervační IS
RSTS
Raiffeisen stavební spořitelna a.s.
SAP
Společnost dodávající ERP systémy (původ firmy: Německo)
SIPO
Sdruţená inkasní platba obyvatelstva (sluţba České pošty)
SW
Software - programové vybavení
TPS
Transaction Processing System – Transakční a procesní systém - operativní části IS
UC
Use Case - Případ uţití
VŠE
Vysoká škola ekonomická 77
Seznam obrázků Obrázek č. 1: Hierarchie: Data-Informace-Znalost-Moudro. Zdroj: [3] ........................... 12 Obrázek č. 2: Obecné schéma architektury IS/IT. Zdroj: [13] .......................................... 14 Obrázek č. 3: Obecná architektura IS rozšířená o metasystém. Zdroj: [4] ....................... 15 Obrázek č. 4: Schematické znázornění úlohy metadat v architektuře úloh. Zdroj: [4] ..... 16 Obrázek č. 5: Architektura MtS. Zdroj: [7 - vlastní úprava] ............................................ 25 Obrázek č. 6: Organizační struktura RSTS. Zdroj: [12] ................................................... 35 Obrázek č. 7: Ukázka seznamu IS. Zdroj: [15 - vlastní úprava] ....................................... 42 Obrázek č. 8: Schéma základních IS v RSTS. Zdroj: [Vlastní úprava] ............................ 43 Obrázek č. 9: Základní rozloţení oblastí CORE systému v RSTS. Zdroj: [11] ................ 44 Obrázek č. 10: Znázornění procesu změn. Zdroj: [15 - vlastní úprava] ........................... 48 Obrázek č. 11: Adresářová struktura metadat. Zdroj: [Nastavení PC - vlastní úprava] ... 49 Obrázek č. 12: Ukázka zápisu IS CIBIS do registrů. Zdroj: [Registry PC] ...................... 50 Obrázek č. 13: Ukázka funkčního katalogu "Insolvence". Zdroj: [15 - vlastní úprava] ... 52 Obrázek č. 14: Ukázka zařazení do aplikace. Zdroj: [15 - vlastní úprava]....................... 53 Obrázek č. 15: Ukázka stromu metadat v EA. Zdroj: [15] ............................................... 53 Obrázek č. 16: Byznys proces zahájení "Insolvence". Zdroj: [15 - vlastní úprava] ......... 54 Obrázek č. 17: Stavový diagram insolvence. Zdroj: [Vlastní úprava] .............................. 55 Obrázek č. 18: Model případu uţití – zahájení insolvence. Zdroj: [15 - vlastní úprava] . 56 Obrázek č. 19: Ukázka provolání na Use Case. Zdroj: [15 - vlastní úprava] ................... 57 Obrázek č. 20: Detail Other links. Zdroj: [15] .................................................................. 57 Obrázek č. 21: UC Provést vinkulaci vkladů – identifikace. Zdroj: [15].......................... 58 Obrázek č. 22: Ukázka záloţky Associations To. Zdroj: [15] .......................................... 58 Obrázek č. 23: Class Parametry – doménový model. Zdroj: [15 - vlastní úprava] .......... 59 Obrázek č. 24: Metadata číselníku parametrů. Zdroj: [15 - vlastní úprava] ..................... 60 Obrázek č. 25: Číselník HBA - Aktualizace okolí. Zdroj: [14] ........................................ 60 Obrázek č. 26: Metadata exportního souboru. Zdroj: [Vlastní úprava] ............................ 61 Obrázek č. 27: Metadata konkrétní tabulky. Zdroj: [Vlastní úprava] ............................... 62 Obrázek č. 28: Ukázka části datového modelu „Insolvence“. Zdroj: [15] ........................ 63
78
Seznam tabulek Tabulka č. 1: Atributy dle ISO/IEC 11179. Zdroj: [10 - vlastní úprava] ......................... 29 Tabulka č. 2: Podíl RSTS na trhu stavebního spoření v ČR. Zdroj: [Vlastní úprava] ...... 37
Seznam příloh Příloha č. 1: Ukázka části návrhu datového modelu při tvorbě dokumentace Příloha č. 2: Ukázka SQL procedury s popisy uvnitř těla
79
Příloha č. 1: Ukázka části návrhu datového modelu při tvorbě dokumentace
Ukázka části návrhu datového modelu při tvorbě dokumentace V zásadě vznikne nová entita, která mimo vazebních a referenčních poloţek obsahuje následující údaje v tabulce. Položka
Datový typ
Popis
spisová značka – senát
string (10)
Spisová značka - část "senát". Poznámka: dle elektronické přihlášky by měla obsahovat pouze 6 číslic.
spisová značka rejstřík
string (5)
Spisová značka - část "Typ rejstříku"
string 10
Spisová značka - část "bc". Poznámka: dle elektronické přihlášky by měla obsahovat pouze 6 číslic.
string (4)
Spisová značka - část "ročník". Poznámka: dle elektronické přihlášky by měla obsahovat pouze 4 číslice.
string (10)
číslo jednací banky = číslo jednací RSTS
string (1)
stav insolvence Poznámka: nejedná se o stav insolvenčního řízení na justici.
string (2000)
Poznámka
spisová značka - bc spisová značka ročník číslo jednací banky stav poznámka
zpráva insolvenčního string (255) správce
zpráva od insolvenčního správce (volný text)
způsob řešení úpadku
enum (čistý úpadek / oddluţení / konkurz)
způsob řešení úpadku
datum zahájení insolvenčního řízení
date
datum zahájení insolvenčního řízení
datum zamítnutí insolvenčního návrhu
date
datum zamítnutí insolvenčního řízení
date
datum odvolání (k zamítnutí insolvenčního návrhu)
datum nabytí právní moci zamítnutí
date
datum nabytí právní moci zamítnutí insolvenčního návrhu
datum úpadku
date
datum úpadku
datum splátkového kalendáře
date
datum splátkového kalendáře
datum zpeněţení majetkové podstaty
date
datum zpeněţení majetkové podstaty
datum odvolání
1
datum konkurzu
date
datum konkurzu
datum přezkumného jednání
date
datum přezkumného jednání
číslo věřitele
string (10)
číslo věřitele
datum ukončení insolvence
date
datum ukončení insolvence
datum storna
date
datum storna
věřitelský výbor
boolean
banka je členem věřitelského výboru
datum odstoupení z věřitelského výboru
date
datum odstoupení z věřitelského výboru
datum splnění oddluţení
date
datum vzetí na vědomí soudem splnění oddluţení
datum oddluţení
date
datum oddluţení
datum osvobození od placení
date
datum usnesení o osvobození dluţníka od placení pohledávek
datum zrušení konkurzu
date
datum zrušení konkurzu
datum zániku osvobození od placení
date
datum zániku osvobození od placení
datum zrušení oddluţení / prohlášený konkurz
date
datum zrušení oddluţení / prohlášený konkurz
insolvenční správce - decimal (16,0) číslo účtu
číslo účtu insolvenčního správce
insolvenční správce - string (7) kód banky
Kód banky účtu insolvenčního správce
Tabulka údajů vychází z návrhu základu datového modelu třídy “Matrika Insolvence” – viz následující obrázek. Návrh vznikal při tvorbě návrhu řešení. Návrh byl konzultován s dodavatelem, který pak můj návrh převzal a přepracoval k obrazu svému, aby výsledek splňoval představu dodavatele a byl plně integrován do celého IS.
2
class Matrika insolv ence Objekt sledující transakce «ParamCodeList» _Domain::* Insolv enční správ ce
Objekt sledující transakce 0..1
1
«ArchivedRegistry» _Domain::Osoba
+insolvent 1
0..1 Objekt sledující transakce
«ArchivedRegistry» Produkt insolv enta
«ArchivedRegistry» Insolv ence + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
0..*
spisová značka - senát :string (10) spisová značka - rejstřík :string (5) spisová značka - bc :string 10 spisová značka - ročník :string (4) číslo jednací banky :string (10) stav :string (1) poznámka :string (2000) zpráva insolvenčního správce :string (255) způsob řešení údadku :enum (čistý úpadek / odlužení / konkurz) datum zahájení insolvenčního řízení :date datum zamítnutí insolvenčního návrhu :date datum odvolání :date datum nabytí právní moci zamítnutí :date datum úpadku :date datum splátkového kalendáře :date datum zpeněžení majetkové podstaty :date datum konkurzu :date datum přezkumného jednání :date číslo věřitele :string (10) datum ukončení insolvence :date datum storna :date věřitelský výbor :boolean datum odstoupení z věřitelského výboru :date datum splnění oddlužení :date datum oddlužení :date datum osvobození od placení :date datum zrušení konkurzu :date datum zániku osvobození od placení :date datum zrušení oddlužení / prohlášený konkurz :date insolvenční správce - číslo účtu :decimal (16,0) insolvenční správce - kód banky :string (7)
0..1
0..1
«ParamCodeList» Dův od storna insolv ence + + + +
1
osoba v dané roli
ID :number popis :description poznámka :note platnost :boolean
+ + + + +
smlouva :decimal (16,0) typ smlouvy :string (4) typ role :string (2) poznámka :string (2000) platnost :boolean
«Param... +pův ČJ ISIR 1 _Domain::Soud (po spojení) 0..1
0..*
«Code... _Domain:: 1 BankOfficer
+referent INS
+ + + + + + + + + + + + +
STOP úroků :boolean STOP poplatků :boolean STOP upomínek :boolean STOP výpisů :boolean jistina :částka běžný úrok :částka sankční úrok :částka poplatky :částka sankční poplatky :částka úhrady - pojištění UNIQA :částka úhrady - soudní poplatky :částka přihlášená pohledávka :boolean platnost :boolean
«ParamCodeList» Dův od popření přihlášky insolv enčním správ cem
«ParamCodeList» Dův od nepodání přihlášky + + + +
+ + + +
ID :number popis :description poznámka :note platnost :boolean
«ArchivedRegistry» Nepřihlášená pohledáv ka insolv enta
+ + počet dnů od úpadku do předání OZU :integer + datum předání OZU :date + + + «ParamCodeList» + Dův od nepodání + pokynu zaj ištěného + v ěřitele + + + ID :number + + popis :description + + poznámka :note + + platnost :boolean + 0..1 +
+ +
+B 0..1
+A 1
ID :number popis :description poznámka :note platnost :boolean
ID :number popis :description poznámka :note platnost :boolean
0..1
0..1
«ParamCodeList» Dův od ukončení insolv ence + + + +
«ArchivedRegistry» Pohledáv ka insolv enta
«ArchivedRegistry» Přihlášená pohledáv ka insolv enta datum přihlášky :date počet dnů od úpadku do přihlášky :date přihlášená výše pohledávky :částka aktuální výše přihlášené pohledávky :částka číslo pohledávky :integer typ přihlášky - nezajištěná :boolean typ přihlášky - zajištěná stavebním spořením :boolean typ přihlášky - zajištěná nemovitostí insolventa :boolean typ přihlášky - zajištěná majetkem třetí osoby :boolean typ přihlášky - zajištěná ručitelem :boolean podmíněná pohledávka :boolean zajištěný věřitel :boolean splatná pohledávka :boolean vykonatelná pohledávka :boolean popřená přihláška :enum: ANO/NE/NEZADÁNO datum popření přihlášky :date
0..1 «ArchivedRegistry» Náv ratnost přihlášené pohledáv ky insolv enta + + + + + + +
+logická vazba «ArchivedRegistry» Insolv ence - referenční údaj e + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference reference
zahájení - uživatel :string (20) zahájení - časová známka :datetime úpadku - uživatel :string (20) úpadku - časová známka :datetime storna - uživatel :string (20) storna - časová známka :datetime zamítnutí - uživatel :string (20) zamítnutí - časová známka :datetime přihlášení pohledávky - uživatel :string (20) přihlášení pohledávky - časová známka :datetime generování přihlášky - uživatel :string (20) generování přihlášky - časová známka :datetime splátkový kalendář - uživatel :string (20) splátkový kalendář - časová známka :datetime zpeněžení majetkové podstaty - uživatel :string (20) zpeněžení majetkové podstaty - časová známka :datetime splátkový kalendář / zpeněžení - uživatel :string (20) splátkový kalendář / zpeněžení - časová známka :datetime konkurzu - uživatel :string (20) konkurzu - časová známka :datetime ukončení - uživatel :string (20) ukončení - časová známka :datetime obživnutí - uživatel :string (20) obživnutí - časová známka :datetime nepřihlášení - uživatel :string (20) nepřihlášení - časová známka :datetime popření přihlášky - uživatel :string (20) popření přihlášky - časová známka :datetime uznání pohledávky - uživatel :string (20) uznání pohledávky - časová známka :datetime vytvoření - uživatel :string (20) vytvoření - časová známka :datetime změny - uživatel :string (20) změny - časová známka :datetime
datum první splátky :date datum předání k pokynu zajištěného věřitele :date datum pokynu zajištěného věřitele :date forma pokynu zajištěného věřitele :enum (Dražba, Přímý prodej mimo dražbu) datum žaloby na určení pohledávky :date datum žaloby na prodej zástavy :date platnost :boolean
«ArchivedRegistry» Vztah mezi insolv encemi + + + + + + + + +
typ vztahu :enum datum platnosti OD :date datum platnosti DO :date insolvent B je v evidenci osob :boolean původní spisová značka - senát :string (10) původní spisová značka - rejstřík :string (5) původní spisová značka - bc :string 10 původní spisová značka - ročník :string (4) platnost :boolean
3
Příloha č. 2: Ukázka SQL procedury s popisy uvnitř těla
Ukázka SQL procedury s popisy uvnitř těla create procedure "aris".daf_zlaty_ucet() {************************************************************************************} { } { (c) 2012 Raiffeissen stavební spořitelna a.s. } { Koněvova 99 Praha 3 } { } { } { Procedura ........ : daf_zlaty_ucet } { Verze ............ : 1.06 } { } { Napsáno ..........: 11.10.2012 } { Autor................: David Koudelka (OAV) } { Zadání.............: Jmeno Prijmeni (řízení rizik) } { Poţadavek.......: ORR_2012_024 } { } { Vstupní parametry : } { Výstupní parametry : } { Smlouva SS (stavebního spoření) } { Stav smlouvy } { VOP } { Tarif } { Cílová částka } { Datum návrhu } { Datum uzavření } { Datum potvrzení v systému } { Datum nakládání s vkladem } { Saldo SS } { Připsaný úrok na SS (včetně sráţkové daně) } { Příjmení a jméno, příp. název klienta (SS/PS) } { PSČ trvalé adresy } { Vek klienta, u PO=0 } { Procento naspoření, zaokrouhlení na 4 des. místa } { Kód banky transakčního účtu } { Existuje jiná smlouva SS zaloţená více jak 10 dní před zaloţením } { Počet provedených trvalých příkazů (TP) } { Suma provedených trvalých příkazů (TP) } { Počet provedených trvalých příkazů v rámci RSTS(TP) } { Suma provedených trvalých příkazů v rámci RSTS(TP) } { Počet provedených trvalých příkazů mimo RSTS(TP) } { Suma provedených trvalých příkazů mimo RSTS(TP) } { Počet NEprovedených trvalých příkazů (TP) } { Suma NEprovedených trvalých příkazů (TP) } { Počet NEprovedených trvalých příkazů v rámci RSTS(TP) } { Suma NEprovedených trvalých příkazů v rámci RSTS(TP) } { Počet NEprovedených trvalých příkazů mimo RSTS(TP) } { Suma NEprovedených trvalých příkazů mimo RSTS(TP) } { Počet provedených jednorázových příkazů (JP) } { Suma provedených jednorázových příkazů (JP) } { Počet provedených jednorázových příkazů (JP) } { Suma provedených jednorázových příkazů (JP) } { Počet provedených jednorázových příkazů (JP) } { Suma provedených jednorázových příkazů (JP) } { Počet chybných jednorázových příkazů (JP) }
1
{ Suma chybných jednorázových příkazů (JP) } { Počet návrhů jednorázových příkazů (JP) } { Suma návrhů jednorázových příkazů (JP) } { Počet potvrzených jednorázových příkazů (JP) } { Suma potvrzených jednorázových příkazů (JP) } { Suma očekávaných peněz z CC (nerozúčtované nahrané cleary) } { Suma nerozúčtovaná na sběrném kontě 106809 (nulté platby) } { Suma očekávaná z budoucích vypořádání (jen vypořádání, nikoli výplaty apod.) } { Přihlašovací login do SIS } { } { Funkce ........... : Přehled zlatých účtů – podpora MIS a ad hoc reportů, poţadované údaje } { Spuštění ........ : Typicky po EOM na kopii DB, moţno pouštět i průběţně } { Doba běhu...... : okolo 35 min. } { } { } { } { ZMĚNOVÝ PROTOKOL: } {------------------------------------------------------------------------------------------------------------------------------ } { Datum Změna } { 11.10.2012 Základní verze } { 03.09.2013 Doplnění distinct v sekci vyhledání přihlášení do SIS + doplnění platnosti banky v:1.01 } { 02.06.2014 Doplněn tarif zlatého účtu 201 (nový tarif) v:1.02 } { 02.07.2014 Změna výběru "K" pro PO - vybíráme max(K...) pro případ více disponentů v:1.03 } { 03.09.2014 Změna výběru banky klienta - pro případ chyby více transakčních účtů v:1.04 } { 29.10.2014 Formální změna – doplnění popisů do procedury v:1.05 } { 30.11.2014 Doplnění informace, zda má osoba nějaký úvěr v:1.06 } { } {*********************************************************************************** } RETURNING DECIMAL(16,0) AS Smlouva, VARCHAR(1) AS Stav, SMALLINT AS VOP, SMALLINT AS Tarif, DECIMAL(16,2) AS CC, DATE AS Dat_navrhu, DATE AS Dat_uzav, DATETIME YEAR to SECOND AS Dat_potvr, DATE AS Dat_naklad, DECIMAL(16,2) AS Saldo, DECIMAL(16,2) AS Pripsany_urok, VARCHAR(50) AS Prijmeni_Jmeno, VARCHAR(5) AS PSC_trvale, SMALLINT AS Vek, DECIMAL(12,4) AS Procento_naspor, VARCHAR(4) AS Banka_trans_uctu, VARCHAR(3) AS Exist_jina_SS, VARCHAR(3) INTEGER DECIMAL(16,2) INTEGER DECIMAL(16,2) INTEGER DECIMAL(16,2) INTEGER DECIMAL(16,2) INTEGER DECIMAL(16,2)
-- Smlouva -- Stav smlouvy -- VOP -- Tarif -- Cílová částka -- Datum návrhu -- Datum uzavření -- Datum potvrzení v systému -- Datum nakládání s vkladem -- Saldo SS -- Připsaný úrok na SS (včetně sráţkové daně) -- Příjmení a jméno, příp. název kli. (SS/PS) -- PSČ trvalé adresy -- Vek klienta, u PO=0 -- % naspoření, zaokrouhlení na 4 des. místa -- Kód banky transakčního účtu -- Existuje jiná sml. SS zaloţená > 10 dní -- před zaloţením AS Exist_uver_os, -- Exist. úvěr pro osobu klienta, který je -- platný a role je také platná (k výběru) AS Pocet_proved_TP, -- Počet provedených trvalých příkazů (TP) AS Suma_proved_TP, -- Suma provedených trvalých příkazů (TP) AS Pocet_proved_RSTS_TP, -- Počet provedených TP v RSTS AS Suma_proved_RSTS_TP, -- Suma provedených TP v RSTS AS Pocet_proved_mimo_TP, -- Počet provedených TP mimo RSTS AS Suma_proved_mimo_TP, -- Suma provedených TP mimo RSTS AS Pocet_neproved_TP, -- Počet NEprovedených trv. příkazů (TP) AS Suma_neproved_TP, -- Suma NEprovedených trv. příkazů (TP) AS Pocet_neproved_RSTS_TP, -- Počet NEprovedených TP v RSTS AS Suma_neproved_RSTS_TP, -- Suma NEprovedených TP v RSTS
2
INTEGER DECIMAL(16,2) INTEGER DECIMAL(16,2) INTEGER DECIMAL(16,2) INTEGER DECIMAL(16,2) INTEGER DECIMAL(16,2) INTEGER DECIMAL(16,2) INTEGER DECIMAL(16,2) DECIMAL(16,2)
AS Pocet_neproved_mimo_TP, AS Suma_neproved_mimo_TP, AS Pocet_proved_JP, AS Suma_proved_JP, AS Pocet_proved_RSTS_JP, AS Suma_proved_RSTS_JP, AS Pocet_proved_mimo_JP, AS Suma_proved_mimo_JP, AS Pocet_chybnych_JP, AS Suma_chybnych_JP, AS Pocet_navrhu_JP, AS Suma_navrhu_JP, AS Pocet_potvrzenych_JP, AS Suma_potvrzenych_JP, AS Suma_penez_ocek_z_CC,
DECIMAL(16,2)
AS Suma_na_SK_106809,
DECIMAL(16,2)
AS Suma_z_vyporadani,
VARCHAR(12)
AS Pristup_SIS
-- Počet NEprov. TP mimo RSTS -- Suma NEprov. TP mimo RSTS -- Počet provedenych JP -- Suma provedených JP -- Počet prov. JP v RSTS -- Suma prov. JP v RSTS -- Počet prov. JP mimo RSTS -- Suma prov. JP mimo RSTS -- Počet chybných JP -- Suma chybných JP -- Počet návrhů JP -- Suma návrhů JP -- Počet potvrzených JP -- Suma potvrzených JP -- Suma očekávaných peněz z CC -- (nerozúčtované nahrané cleary) -- Suma nerozúčt. na sběrném kontě -- 106809 (nulté platby) -- Suma očekávaná z bud. výplat -- (jen vypořádání, ne výplaty apod.) -- Přihlašovací login do SIS (el.bank)
{*********************** DEKLARACE **************************************} {--------------------------------- Definice proměnných ----------------------------------} DEFINE l_Smlouva DEFINE l_Stav DEFINE l_VOP DEFINE l_Tarif DEFINE l_CC DEFINE l_Dat_navrhu DEFINE l_Dat_uzav DEFINE l_Dat_potvr DEFINE l_Dat_naklad DEFINE l_Saldo DEFINE l_Pripsany_urok DEFINE l_Prijmeni_Jmeno (SS/PS) DEFINE l_PSC_trvale DEFINE l_Vek DEFINE l_Procento_naspor DEFINE l_Banka_trans_uctu DEFINE l_Exist_jina_SS
DECIMAL(16,0); -- Smlouva SS VARCHAR(1); -- Stav smlouvy SMALLINT; -- VOP SMALLINT; -- Tarif DECIMAL(16,2); -- Cílová částka DATE; -- Datum návrhu DATE; -- Datum uzavření DATETIME YEAR to SECOND;-- Datum potvrzení DATE; -- Datum nakládání s vkladem DECIMAL(16,2); -- Saldo SS DECIMAL(16,2); -- Připsaný úrok na SS (včetně sráţkové daně) VARCHAR(50); -- Příjmení a jméno, příp. název klienta VARCHAR(5); SMALLINT; DECIMAL(12,4); VARCHAR(4); VARCHAR(3);
DEFINE l_Pocet_proved_TP DEFINE l_Suma_proved_TP DEFINE l_Pocet_proved_RSTS_TP DEFINE l_Suma_proved_RSTS_TP DEFINE l_Pocet_proved_mimo_TP DEFINE l_Suma_proved_mimo_TP DEFINE l_Pocet_neproved_TP DEFINE l_Suma_neproved_TP DEFINE l_Pocet_neproved_RSTS_TP DEFINE l_Suma_neproved_RSTS_TP DEFINE l_Pocet_neproved_mimo_TP DEFINE l_Suma_neproved_mimo_TP DEFINE l_Pocet_proved_JP DEFINE l_Suma_proved_JP
-- PSČ trvalé adresy -- Vek klienta, u PO=0 -- % naspoření, zaokrouhlení na 4 des. místa -- Kód banky transakčního účtu -- Existuje jiná smlouva SS zaloţená -- více jak 10 dní před zaloţením INTEGER; -- Počet provedených trvalých příkazů (TP) DECIMAL(16,2); -- Suma provedených trv. příkazů (TP) INTEGER; -- Počet provedených TP v RSTS DECIMAL(16,2);-- Suma provedených TP v RSTS INTEGER; -- Počet provedených TP mimo RSTS DECIMAL(16,2);-- Suma provedených TP mimo RSTS INTEGER; -- Počet NEprovedených TP DECIMAL(16,2);-- Suma NEprovedených TP INTEGER; -- Počet NEprovedených TP v RSTS rámci DECIMAL(16,2); -- Suma NEprovedených TP v RSTS INTEGER; -- Počet NEprovedených TP mimo RSTS DECIMAL(16,2); -- Suma NEprovedených TP mimo RSTS INTEGER; -- Počet prov. jednorázových příkazů (JP) DECIMAL(16,2);-- Suma provedených JP
3
DEFINE l_Pocet_proved_RSTS_JP DEFINE l_Suma_proved_RSTS_JP DEFINE l_Pocet_proved_mimo_JP DEFINE l_Suma_proved_mimo_JP DEFINE l_Pocet_chybnych_JP DEFINE l_Suma_chybnych_JP DEFINE l_Pocet_navrhu_JP DEFINE l_Suma_navrhu_JP DEFINE l_Pocet_potvrzenych_JP DEFINE l_Suma_potvrzenych_JP DEFINE l_Suma_penez_ocek_z_CC DEFINE l_Suma_na_SK_106809 DEFINE l_Suma_z_vyporadani DEFINE l_Pristup_SIS DEFINE l_os DEFINE l_typOS DEFINE l_RC DEFINE l_Pocet DEFINE l_os_ma_UVER
INTEGER; -- Počet provedených JP DECIMAL(16,2); -- Suma provedených JP INTEGER; -- Počet prov. JP DECIMAL(16,2); -- Suma prov. jednorázových příkazů (JP) INTEGER; -- Počet chybných JP DECIMAL(16,2); -- Suma chybných JP INTEGER; -- Počet návrhů jednorázových příkazů (JP) DECIMAL(16,2); -- Suma návrhů JP INTEGER; -- Počet potvrzených JP DECIMAL(16,2); -- Suma potvrzených JP DECIMAL(16,2); -- Suma očekávaných peněz z CC -- (nerozúčtované nahrané cleary) DECIMAL(16,2); -- Suma nerozúčt. na sběrném kontě -- 106809 (nulté platby) DECIMAL(16,2); -- Suma očekávaná z budoucích -- vypořádání (jen vypoř., ne výplaty) VARCHAR(12); -- Přihlašovací login do SIS (el. bank.) DECIMAL(10,0); -- Vnitřní ident.osoby (nejde do výstupu) VARCHAR(2); -- Vnitřní typ osoby (nejde do výstupu) VARCHAR(13); -- Rodné číslo (nejde do výstupu) INTEGER; -- Pomocný počet pro přihlašovací login VARCHAR(3); -- Zda má osoba úvěr
{-------------------------------- Začátek procedury ------------------------------------} -- Inicializace proměnných LET l_Smlouva = 0; LET l_Stav = ''; LET l_VOP = 0; LET l_Tarif = 0; LET l_CC = 0; LET l_Dat_navrhu = ''; LET l_Dat_uzav = ''; LET l_Prijmeni_Jmeno = ''; LET l_PSC_trvale = ''; LET l_Vek = 0; LET l_os = 0; LET l_RC = '0'; LET l_typOS = ''; LET l_Pristup_SIS = ''; LET l_Pocet = 0; LET l_Dat_potvr = ''; LET l_Dat_naklad = ''; LET l_Saldo = 0; LET l_Pripsany_urok = 0; LET l_Procento_naspor = 0; LET l_Banka_trans_uctu = ''; LET l_Exist_jina_SS = ''; LET l_os_ma_UVER = ''; LET l_Pocet_proved_TP = 0; LET l_Suma_proved_TP = 0; LET l_Pocet_proved_RSTS_TP = 0; LET l_Suma_proved_RSTS_TP = 0; LET l_Pocet_proved_mimo_TP = 0; LET l_Suma_proved_mimo_TP = 0; LET l_Pocet_neproved_TP = 0; LET l_Suma_neproved_TP = 0; LET l_Pocet_neproved_RSTS_TP = 0; LET l_Suma_neproved_RSTS_TP = 0; LET l_Pocet_neproved_mimo_TP = 0;
4
LET l_Suma_neproved_mimo_TP LET l_Pocet_proved_JP LET l_Suma_proved_JP LET l_Pocet_proved_RSTS_JP LET l_Suma_proved_RSTS_JP LET l_Pocet_proved_mimo_JP LET l_Suma_proved_mimo_JP LET l_Pocet_chybnych_JP LET l_Suma_chybnych_JP LET l_Pocet_navrhu_JP LET l_Suma_navrhu_JP LET l_Pocet_potvrzenych_JP LET l_Suma_potvrzenych_JP LET l_Suma_penez_ocek_z_CC LET l_Suma_na_SK_106809 LET l_Suma_z_vyporadani
= 0; = 0; = 0; = 0; = 0; = 0; = 0; = 0; = 0; = 0; = 0; = 0; = 0; = 0; = 0; = 0;
-- Pomocná tabulka pro dohledání nultých plateb (rychlá tvorba + indexace) create temp table dk_106809 (varSym decimal (10,0), castka decimal(16,2)); insert into dk_106809 (varSym, castka) SELECT x3.varsym, sum(x0.castka) from ak_platba_kart x1, ac_ucbody_den x3, ac_uchead_den x0 WHERE x1.konto=106809 AND x1.stav in ('A','B','D','E') AND x1.zdrojser = 0 AND x1.ser = x0.ser AND x3.ser > 232892098 -- třeba vyhledavat az od urcite transakce (zrychleni) AND x1.ser = x3.ser AND x3.dbcr = 1 group by 1; create index daf_dk_106809_idx1 on dk_106809(varSym); -- pro vyhledání dle pin(rc) -- create index daf_idx_x11 on adm_userrecord_cmp(pin); -- Prohledám všechny smlouvy s tarifem 200 a 201 (zlatý účet) s nezrušenou rolí Klient (vše do proměnné) FOREACH SELECT s.smlouva, s.stav, s.vop, s.tarif, s.cc, s.datna, s.datuz, CASE WHEN o.typos='F' THEN (SELECT trim(fo.prijmeni) ||' '||trim(fo.jmeno) from eo_fo_mat fo WHERE fo.fo=o.os) WHEN o.typos='P' THEN (SELECT trim(po.nazevmajitel) from eo_po_mat po WHERE po.po=o.os) ELSE ' ' end, CASE WHEN o.typos='F' THEN (SELECT fo.psc from eo_fo_mat fo WHERE fo.fo=o.os) WHEN o.typos='P' THEN (SELECT po.psc from eo_po_mat po WHERE po.po=o.os) ELSE '0' end, CASE WHEN o.typos='F' THEN (SELECT trunc(abs(months_between(today,fo.datnaroz))/12) from eo_fo_mat fo WHERE fo.fo=o.os) ELSE 0 end, nvl(vypl.castka,0), o.os, o.typOS, CASE WHEN o.typos='F' THEN (SELECT fo.rc from eo_fo_mat fo WHERE fo.fo=o.os) WHEN o.typos='P' THEN (SELECT po.ico from eo_po_mat po WHERE po.po=o.os) ELSE '0' end INTO l_Smlouva, l_Stav, l_VOP, l_Tarif, l_CC, l_Dat_navrhu, l_Dat_uzav, l_Prijmeni_Jmeno, l_PSC_trvale,
5
l_Vek, l_Suma_z_vyporadani, l_os, l_typOS, l_RC from es_sml_mat s, eo_role_mat r, eo_osoba_mat o, outer (SELECT vy.konto smlouva, sum(vy.castkavypl) castka from vy_vyplkon_kart vy, vy_vyplzpusob_kart v, vy_vypl_kart v1, rz_storno_kart st WHERE vy.konto in (SELECT s1.smlouva from es_sml_mat s1 WHERE s1.tarif in (200,201)) -- konkretni tarif AND vy.vyplatazp=v.vyplatazp AND v.zpusob='K' AND v.vyplata=v1.vyplata AND v1.stav in ('A','B') AND v1.vyplata=st.vyplata AND st.stav in ('A','B') -- pripr.vyp. group by 1) vypl -- pomocne pro vyporadani WHERE s.tarif in (200, 201) AND s.smlouva=r.smlouva AND r.typrole='KL' -- jen role klient AND r.stav <>'Z' -- jen nezrušené AND r.os=o.os AND o.stav <> 'Z' -- jen nezrušené osoby AND s.smlouva=vypl.smlouva -- dohledání data potvrzení LET l_Dat_potvr = nvl((
SELECT min(cas) from (SELECT reftime Cas from es_sml_mat s1 WHERE s1.smlouva=l_Smlouva AND lower(s1.akce) ='pot' union SELECT min(reftime) Cas from es_sml_arch sa WHERE sa.smlouva=l_Smlouva AND lower(sa.akce) ='pot') ), '');
-- dohledání data nakládání s vkladem (z realizace spoření) LET l_Dat_naklad = (SELECT rs.datnakl from rs_real_mat rs, rz_real_mat rz WHERE rs.realn=rz.reals AND rz.smlouva=l_Smlouva); -- vypocet salda LET l_Saldo = nvl(( SELECT sum(saldo) from ac_sko_mat sk WHERE sk.tko in ('SS','PS') AND sk.konto=l_Smlouva),0); -- vypocet připsaných uroku od zavedeni tarifu LET l_Pripsany_urok = nvl(( SELECT sum(ur.pripsurok) from ur_pripsany_den ur WHERE ur.konto=l_Smlouva AND ur.tko in ('SS','PS') AND ur.typurok in ('BE','ZV') AND ur.valutapripis > mdy(6,1,2012)),0); -- vypocet naspořenosti LET l_Procento_naspor
= round(((SELECT nvl(sum(saldo),0) from ac_sko_mat sk WHERE sk.tko in ('SS','PS') AND sk.konto=l_Smlouva)/decode(l_CC,0,1,l_CC)),4);
-- dotazeni banky z transakčního uctu (spravne by v primárních datech mel byt max. jeden zaznam) LET l_Banka_trans_uctu = nvl(( SELECT distinct banka from es_transucet_mat tu WHERE tu.stav='A' AND tu.priorita=1 AND tu.smlouva=l_Smlouva),''); -- vyber, zda ma osoba jiné stav.spor. zaloţené vice jak 10 před zaloţením zlatého účtu LET l_Exist_jina_SS = CASE WHEN exists ( SELECT 1 from eo_role_mat rr, es_sml_mat s1, rz_real_mat r1 WHERE rr.typrole='KL' AND rr.os=l_os AND rr.smlouva <> l_Smlouva AND rr.smlouva=s1.smlouva AND s1.datuz < l_Dat_uzav -10 AND s1.smlouva=r1.smlouva
6
AND nvl(r1.datukoncsp,mdy(12,31,2200)) >= l_Dat_uzav) THEN 'Ano' ELSE 'Ne' end; -- příznak, zda ma osoba (klient) nejaky platny uver LET l_os_ma_UVER = CASE WHEN exists ( SELECT 1 from eo_role_mat rr, eu_sml_mat uv WHERE rr.typrole='KL' AND rr.os=l_os AND rr.stav='A' AND rr.smlouva = uv.smlspor AND uv.stav='L') THEN 'Ano' ELSE 'Ne' end; --trvalé příkazy -- pripadne pomocne indexy (pokud je třeba je tvorit) -- create index daf_pomocny_idx_001 on ac_uchead_den(ser, druh); -- create index daf_pomocny_idx_002 on ac_memobody_den(ser, konto, dbcr);
-- cca 17 min. db REPL -- cca 30 min. db REPL
-- Nutno vyhledávat v memorialu (sloţité a náročné na čas) LET l_Pocet_proved_RSTS_TP, l_Suma_proved_RSTS_TP = (SELECT count(*), sum(x2.castka) from ac_uchead_den x2, ac_memobody_den x5 WHERE x2.ser > 232892098 AND x2.ser = x5.ser AND x2.druh ='OT02' AND x5.dbcr = -1 AND x5.konto = l_Smlouva); -- Dohledání je přes druh operace a směr a hledáne aţ od konkrétního čísla transakce (dříve neexistovaly) LET l_Pocet_proved_mimo_TP, l_Suma_proved_mimo_TP = (SELECT count(*), sum(x2.castka) from ac_uchead_den x2, ac_memobody_den x5 WHERE x2.ser > 232892098 AND x2.ser = x5.ser AND x2.druh ='OT01' AND x5.dbcr = -1 AND x5.konto = l_Smlouva); LET l_Pocet_proved_TP LET l_Suma_proved_TP
= l_Pocet_proved_RSTS_TP + l_Pocet_proved_mimo_TP; = l_Suma_proved_RSTS_TP + l_Suma_proved_mimo_TP;
-- pomocne indexy (ihned hotovo) -- create index daf_pomocny_idx_003 on at_prikaz_den(dokladbds, arch); -- create index daf_pomocny_idx_004 on ab_doklad_kart(dokladbds, druh,dokladtyp, dbkonto); LET l_Pocet_neproved_RSTS_TP, l_Suma_neproved_RSTS_TP= (SELECT count(*), sum(x0.castka) from at_prikaz_den x1, ab_doklad_kart x0 WHERE x1.dokladbds = x0.dokladbds AND x1.arch = 0 AND x0.dokladtyp ='TP' AND x0.druh='OT02' AND x0.dbkonto=l_Smlouva); LET l_Pocet_neproved_mimo_TP, l_Suma_neproved_mimo_TP= (SELECT count(*), sum(x0.castka) from at_prikaz_den x1, ab_doklad_kart x0 WHERE x1.dokladbds = x0.dokladbds AND x1.arch = 0 AND x0.dokladtyp ='TP' AND x0.druh='OT01' AND x0.dbkonto=l_Smlouva); LET l_Pocet_neproved_TP LET l_Suma_neproved_TP
= l_Pocet_neproved_RSTS_TP + l_Pocet_neproved_mimo_TP; = l_Suma_neproved_RSTS_TP + l_Suma_neproved_mimo_TP;
--jednorázové příkazy LET l_Pocet_proved_JP, l_Suma_proved_JP = (SELECT count(*), sum(yy.castkacelk) from an_prikazh_kart yy WHERE yy.stav='C' AND yy.konto=l_Smlouva); LET l_Pocet_proved_RSTS_JP, l_Suma_proved_RSTS_JP = (SELECT count(*), sum(hh.castkacelk) from an_prikazb_kart bb, an_prikazh_kart hh WHERE bb.prikazid=hh.prikazid AND hh.stav='C' AND bb.bankacizi = 7950 AND hh.konto=l_Smlouva); LET l_Pocet_proved_mimo_JP, l_Suma_proved_mimo_JP = (SELECT count(*), sum(hh.castkacelk) from an_prikazb_kart bb, an_prikazh_kart hh WHERE bb.prikazid=hh.prikazid AND hh.stav='C' AND bb.bankacizi <> 7950 AND hh.konto=l_Smlouva);
7
LET l_Pocet_chybnych_JP, l_Suma_chybnych_JP = (SELECT count(*), sum(castkacelk) from an_prikazh_kart y WHERE y.stav='E' AND y.konto=l_Smlouva); LET l_Pocet_navrhu_JP, l_Suma_navrhu_JP = (SELECT count(*), sum(castkacelk) from an_prikazh_kart z WHERE z.stav='A' AND z.konto=l_Smlouva); LET l_Pocet_potvrzenych_JP, l_Suma_potvrzenych_JP = (SELECT count(*), sum(castkacelk) from an_prikazh_kart zz WHERE zz.stav='B' AND zz.konto=l_Smlouva); --další údaje z platebního styku LET l_Suma_penez_ocek_z_CC = (SELECT sum(c.kccastka) from cc_doklad_kart c WHERE c.ukkonto = l_Smlouva); LET l_Suma_na_SK_106809 = (SELECT castka from dk_106809 WHERE varSym=l_Smlouva); LET l_Pristup_SIS
= '';
-- dohledání přihlašovacího login (identifikace pro SIS) -- pro FO (fyzickou osobu) IF l_typos='F' THEN LET l_Pocet = 0; LET l_Pocet = (SELECT count(*) FROM adm_userrecord_cmp adm WHERE adm.userrecordid like "K%" AND adm.discontinued=0 AND adm.pin = l_RC); IF l_Pocet > 1 THEN LET l_Pristup_SIS = (SELECT distinct adm.userrecordid FROM adm_userrecord_cmp adm WHERE adm.userrecordid like "K%" AND adm.discontinued=0 AND adm.pin = l_RC AND exists (SELECT 1 from eo_sluzba_kart slk WHERE slk.login=adm.userrecordid AND slk.po is null)); ELSE LET l_Pristup_SIS = (SELECT distinct adm.userrecordid FROM adm_userrecord_cmp adm WHERE adm.userrecordid like "K%" AND discontinued=0 AND adm.pin = l_RC); END IF; -- pro PO (pravnickou osobu) ELSE LET l_Pristup_SIS = (SELECT max(adm.userrecordid) -- distinct adm.userrecordid --drive FROM adm_userrecord_cmp adm --, eo_sluzba_kart slu WHERE adm.userrecordid like "K%" AND adm.discontinued=0 AND exists (SELECT 1 from eo_sluzba_kart sp WHERE sp.login=adm.userrecordid AND sp.po = l_os)); END IF; { --pro případné vyhledání více záznamů při problému – většinou error v primárních tabulích IF l_typos='F' THEN LET l_Pocet = 0; LET l_Pocet = (SELECT count(*) FROM adm_userrecord_cmp adm WHERE adm.userrecordid like "K%" AND discontinued=0 AND adm.pin = l_RC); IF l_Pocet > 1 THEN
8
LET l_Pristup_SIS = (SELECT 'A-'|| count(distinct adm.userrecordid) FROM adm_userrecord_cmp adm WHERE adm.userrecordid like "K%" AND discontinued=0 AND adm.pin = l_RC AND exists (SELECT 1 from eo_sluzba_kart slk WHERE slk.login=adm.userrecordid AND slk.po is null)); ELSE LET l_Pristup_SIS = (SELECT 'B-'|| count(distinct adm.userrecordid) FROM adm_userrecord_cmp adm WHERE adm.userrecordid like "K%" AND discontinued=0 AND adm.pin = l_RC); END IF; ELSE LET l_Pristup_SIS = (SELECT 'C-'|| count(distinct adm.userrecordid) FROM adm_userrecord_cmp adm --, eo_sluzba_kart slu WHERE adm.userrecordid like "K%" AND discontinued=0 AND exists (SELECT 1 from eo_sluzba_kart sp WHERE sp.login=adm.userrecordid AND sp.po = l_os)); END IF; } -- Na výstupu budou tyto hodnoty RETURN l_Smlouva, l_Stav, l_VOP, l_Tarif, l_CC, l_Dat_navrhu, l_Dat_uzav, l_Dat_potvr, l_Dat_naklad, l_Saldo, l_Pripsany_urok, l_Prijmeni_Jmeno, l_PSC_trvale, l_Vek, l_Procento_naspor, l_Banka_trans_uctu, l_Exist_jina_SS, l_os_ma_UVER, l_Pocet_proved_TP, l_Suma_proved_TP, l_Pocet_proved_RSTS_TP, l_Suma_proved_RSTS_TP, l_Pocet_proved_mimo_TP, l_Suma_proved_mimo_TP, l_Pocet_neproved_TP, l_Suma_neproved_TP, l_Pocet_neproved_RSTS_TP, l_Suma_neproved_RSTS_TP, l_Pocet_neproved_mimo_TP, l_Suma_neproved_mimo_TP, l_Pocet_proved_JP, l_Suma_proved_JP, l_Pocet_proved_RSTS_JP, l_Suma_proved_RSTS_JP, l_Pocet_proved_mimo_JP, l_Suma_proved_mimo_JP, l_Pocet_chybnych_JP,
-- Smlouva SS -- Stav smlouvy -- VOP -- Tarif -- Cílová částka -- Datum návrhu -- Datum uzavření -- Datum potvrzení v systému -- Datum nakládání s vkladem -- Saldo SS -- Připsaný úrok na SS (včetně sráţkové daně) -- Příjmení a jméno, příp. název klienta (SS/PS) -- PSČ trvalé adresy -- Vek klienta, u PO=0 -- Procento naspoření, zaokrouhlení na 4 des. místa -- Kód banky transakčního účtu -- Existuje jiná smlouva SS zaloţená > 10 dní před zaloţením -- Existuje úvěr u osoby (jakýkoli, kde je v platné roli KL) -- Počet provedených trvalých příkazů (TP) -- Suma provedených trvalých příkazů (TP) -- Počet provedených trvalých příkazů v rámci RSTS(TP) -- Suma provedených trvalých příkazů v rámci RSTS(TP) -- Počet provedených trvalých příkazů mimo RSTS(TP) -- Suma provedených trvalých příkazů mimo RSTS(TP) -- Počet NEprovedených trvalých příkazů (TP) -- Suma NEprovedených trvalých příkazů (TP) -- Počet NEprovedených trvalých příkazů v rámci RSTS(TP) -- Suma NEprovedených trvalých příkazů v rámci RSTS(TP) -- Počet NEprovedených trvalých příkazů mimo RSTS(TP) -- Suma NEprovedených trvalých příkazů mimo RSTS(TP) -- Počet provedených jednorázových příkazů (JP) -- Suma provedených jednorázových příkazů (JP) -- Počet provedených jednorázových příkazů (JP) -- Suma provedených jednorázových příkazů (JP) -- Počet provedených jednorázových příkazů (JP) -- Suma provedených jednorázových příkazů (JP) -- Počet chybných jednorázových příkazů (JP)
9
l_Suma_chybnych_JP, l_Pocet_navrhu_JP, l_Suma_navrhu_JP, l_Pocet_potvrzenych_JP, l_Suma_potvrzenych_JP, l_Suma_penez_ocek_z_CC, l_Suma_na_SK_106809, l_Suma_z_vyporadani, l_Pristup_SIS WITH RESUME; END FOREACH;
-- Suma chybných jednorázových příkazů (JP) -- Počet návrhů jednorázových příkazů (JP) -- Suma návrhů jednorázových příkazů (JP) -- Počet potvrzených jednorázových příkazů (JP) -- Suma potvrzených jednorázových příkazů (JP) -- Suma očekávaných peněz z CC (nerozúčt. nahrané cleary) -- Suma nerozúčtovaná na sběrném kontě 106809 (nulté platby) -- Suma očekávaná z budoucích výplat (jen vypoř., ne výplaty) -- Login přístupu na SIS (el.bank.) pro smlouvu
–Vymazání dočasné tabulky drop table dk_106809; END PROCEDURE;
10
