Tvorba metasystému a popis informačních systémů v bance

Transkript

1 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: Ing. Zdeněk Voznička, CSc. Praha Duben, 2015

2 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

3 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.

4 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

5 Obsah Úvod Zvolené metody zpracování Charakteristika metasystémů a metainformačních systémů Systémová věda a systém Data, informace, znalosti Informační systém Metasystém a metainformační systém Metadata Dimenze metasystému a vazby mezi nimi Základní operace Poţadované vlastnosti Architektura Moţné přínosy a rizika Kvalita dat a metadat Obecný úvod Nekvalitní data Kvalita metadat Shrnutí kapitoly IS v prostředí vybrané společnosti Představení společnosti Obchodní činnost Akcionáři Společnost a stavební spoření Historie společnosti Konkurenční prostředí Vnitřní struktura společnosti Obchodní zastoupení Shrnutí údajů o společnosti Odbory zajišťující IT v organizaci Informační systémy v organizaci Moduly hlavní bankovní aplikace (HBA)

6 5 Metasystém hlavní bankovní aplikace Popis, resp. řízení poţadavků na změnu SW Popis, resp. metasystém HBA Poţadavek na novou úlohu v HBA Metadata konkrétní úlohy v HBA Popis datového modelu a relací v IS Shrnutí kapitoly Porovnání a návrh doporučení ke zkvalitnění Úvod do kapitoly Porovnání teorie a praxe Náměty na zlepšení a doporučení ke zkvalitnění Výsledky shrnutí, výhody a nevýhody metasystémů Závěr Seznam použité literatury Seznam zkratek Seznam obrázků Seznam tabulek Seznam příloh

7 Ú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

8 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

9 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: 9

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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 NISO 2 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 OECD 3. 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: 3 Více o společnosti Organisation for Economic Co-operation and Development: 17

18 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 MDIS 4. 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

19 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

20 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

21 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

22 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

23 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

24 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

25 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 Možné přínosy a rizika Obrázek č. 5: Architektura MtS. Zdroj: [7 - vlastní úprava] 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

26 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

27 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

28 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 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

29 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 Zdroj: [10 - vlastní úprava] Kategorie atributu Název atributu Závaznost Aktuálnost Identifikační Název povinný Identifikátor podmíněný Verze Registrační autorita podmíněný podmíněný Synonymum volitelný Zastaralý Kontext podmíněný Definiční Definice povinný Relační Klasifikační schéma volitelný Klíčová slovo volitelný Zastaralý Odkaz na související data volitelný Zastaralý Typ vztahu podmíněný Prezentační Kategorie prezentace povinný Zastaralý Forma prezentace povinný Zastaralý Datový typ hodnot datového prvku Maximální délka hodnot datového prvku povinný povinný Minimální délka hodnot datového prvku povinný Zastaralý Uspořádání (layout) prezentace podmíněný Zastaralý Přípustné hodnoty datového prvku povinný Zastaralý Administrativní Odpovědná organizace volitelný Registrační status podmíněný Předkládající organizace Komentář volitelný volitelný 29

30 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ě definovaný, s jedinečným názvem a identifikátorem. 30

31 4 IS v prostředí vybrané společnosti 4.1 Představení společnosti 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 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 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 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

32 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á Historie společnosti RSTS působí na českém trhu de facto jiţ od roku 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 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 Fúze obou stavebních spořitelen byla úspěšně dokončena na podzim roku Ke spojení IS, resp. k migraci dat, došlo na konci roku 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

33 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ě 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

34 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šta 5. 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 6 Více o společnosti a sluţbě: Sluţby: Stavební spoření. Česká pošta, s.p. [online] [cit ]. Dostupné z: ČNB Česká národní banka - regulátor bankovního trhu. Více o společnosti: 34

35 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] 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

36 (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 group 7. 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 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 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] [cit ]. Dostupné z: 8 Povinně zveřejňované informace RSTS: O nás. Raiffeisen stavební spořitelna a.s. [online] [cit ]. Dostupné z: 36

37 i auditoři většinového vlastníka a auditor dohledu bankovních norem. Tím je v prostředí RSTS firma KPMG 9. 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] Podíl RSTS q q Nově uzavřené smlouvy o stavebním spoření podíl (%) 16,4% 13,8% 15,8% 22,0% 19,4% 22,5% 24,2% 21,1% Průměrná CČ u nově uzavřených smluv FO (tis. Kč) 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 podíl (%) 17,6% 17,2% 16,6% 17,0% 17,3% 17,1% 17,6% 17,9% Stav platných smluv - saldo (uspořená částka, mld. Kč) 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 Nové překlenovací úvěry - výše (mld. Kč) 9,40 9,78 6,17 6,24 7,28 3,53 2,79 5,84 podíl počtu (%) 13,3% 16,5% 14,4% 17,8% 19,8% 19,4% 18,6% 17,8% Nové stavební úvěry přímo vzniklé - počet Nové stavební úvěry přímo vzniklé - výše (mld. Kč) 0,54 0,31 0,36 0,24 0,20 0,11 0,10 0,20 podíl počtu (%) 14,4% 10,5% 12,9% 12,7% 13,5% 12,9% 14,2% 15,6% Nové stavební úvěry překlopené - počet Nové stavební úvěry překlopené - výše (mld. Kč) 1,07 1,24 1,84 1,91 1,68 0,86 0,77 1,55 podíl počtu (%) 9,5% 9,7% 12,9% 15,4% 15,3% 15,0% 13,2% 14,7% Stav platných úvěrů - počet v tom: ze stavebního spoření v tom: překlenovací podíl (%) 11,2% 11,5% 11,7% 12,3% 12,8% 12,5% 13,0% 13,3% Stav platných úvěrů - saldo (dlužná částka, mld. Kč) 29,48 35,86 37,13 37,10 34,54 35,83 33,59 32,61 v tom: ze stavebního spoření 4,18 4,63 5,49 6,14 6,15 6,18 6,11 6,04 v tom: překlenovací 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% 9 Více o společnosti: KPMG. KPMG Česká republika, s.r.o. [online] [cit ]. Dostupné z: 37

38 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

39 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

40 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

41 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

42 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

43 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

44 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

45 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

46 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

47 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

48 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

49 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

50 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

51 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 (ISIR 10 ) 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: 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

52 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

53 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 y 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ě u a dalších údajů 53

54 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

55 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 č část <functionality> 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

56 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

57 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

58 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

59 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

60 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

61 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