Data Quality CZ - portál věnující se tématu kvalitních dat

Audit datové kvality podle IT Assurance Guide: Using COBIT - 3. díl

[1.3.2012] D. Pejčoch

Kritické zhodnocení použitelnosti IT Assurance Guide pro audit datové kvality

V rámci zpracování této studie jsem dospěl k řadě pochybností o praktické využitelnosti návodu IT Assurance Guide: Using COBIT pro účely auditu datové kvality. Především, IT Assurance Guide: Using COBIT se zdá být použitelný hlavně v případě, kdy firma přijala koncept IT Governance. V opačných případech zpravidla nebude řada kontrolních cílů sledována a proto bude v rámci auditu přeskočena. Vyjádření auditora v takovém případě bude zřejmě vždy obsahovat sáhodlouhý výčet doporučení, že je třeba tyto kontrolní cíle sledovat, než se dostane k meritu věci, tj. ke zhodnocení aktuálního stavu dat. Ke konvenčnímu stanovení úrovně vlastností dat na bázi jednotlivých atributů v rámci IT Assurance Guide dochází pouze až při stanovení dopadů úrovně kontrol. Zde by se potom zřejmě uplatnilo i provázání naměřené úrovně vlastností jednotlivých atributů přes jejich užití na související náklady, typické pro konvenční audity dat.

IT Assurance Guide se mi jeví jako příliš komplexní. Při pokusu o jeho konkrétní aplikaci popsaném v následující kapitole, jsem se nemohl ubránit dojmu, že se jedná o příslovečný „kanon na vrabce“. Jak uvádí [11], jeho aplikace vyžaduje od auditorů velkou schopnost vymezit a ohraničit předmět projektu ujištění a následně „vybrat ty doporučené kroky jednotlivých kontrol, které budou přínosem v kontextu business procesů dané organizace.“ Z uvedeného je zřejmé, že i jeho přizpůsobení pro účely auditu datové kvality by vyžadovalo značné schopnosti na straně auditora. Je zřejmé, že náklady auditu by za takové situace nebyly zrovna nízké. Problém by do značné míry vyřešil vznik dokumentu, který by toto přizpůsobení popisoval.

V přílišné komplexnosti lze však nalézt i jedno pozitivum. Běžnou praxí současnosti je, že audit datové kvality provádí dodavatel řešení pro její zlepšení. O nezávislosti takového auditu lze v takovém případě do značné míry pochybovat. Audit datové kvality je ze strany dodavatele často chápán spíše jako pre-sales aktivita před vlastní implementací řešení pro její zlepšení. Pokud by byl proces ujištění o kvalitě dat, resp. procesů jejich pořízení a transformace realizován pouze jako součást komplexního ujištění vztahujícího se na celé IT, dodávaného auditorskou společností, daly by se výsledky ujištění považovat za mnohem více nezávislé. Samozřejmě tedy za předpokladu, že auditorská společnost se nevěnuje jiným oblastem než auditu.

Nespornou výhodou IT Assurance Guide je hodnocení úrovně designu kontrol, které je v konvenčních auditech datové kvality opomíjeno. Konvenční přístupy uvažují procesy jako způsob, jakým lze dospět k prapůvodním příčinám chyb a k jejich konečným důsledkům. Slabiny těchto procesů však hodnotí až pokud naměří varující úroveň některé sledované vlastnosti dat. IT Assurance Guide postupuje obráceně. Nejprve nalezne nedostatek procesu (nedostatek v návrhu kontrolního cíle) a až poté určí jeho případné dopady do vlastností dat.

Při procházení jednotlivými kroky fází Plánování, Scoping a Realizace jsem se nemohl ubránit dojmu, že opakované vracení se k týmž oblastem jako je např. neustálá redefinice oblasti univerza, či hodnocených procesů a kontrolních cílů, by bylo v případě auditu datové kvality zbytečné. Nicméně, jak zmiňuje [11], na IT Assurance Guide je třeba pohlížet především jako na „bázi znalostí“, na jejímž základě si lze vytvořit své vlastní postupy. Je zde tedy reálná možnost redukce počtu redefinic na rozumnou míru.

Otázkou je, do jaké míry by pomohlo při použití IT Assurance Guide pro účely auditu datové kvality nahrazení COBITu jiným kontrolním rámcem. Pokud uvažujeme nekvalitní data jako operační riziko firmy, nabízel by se rámec COSO, který se používá pro budování integrovaného systému interních kontrol. Navíc by měl být podle [13] sladěn s COBIT, čímž by odpadl problém nekonzistence různých standardů použitích současně pro audit IS/IT. Nicméně, jak zmiňuje [11], COSO se kontrolám IS/IT věnuje pouze okrajově a jeho implementace se doporučuje provádět současně právě s COBIT. Z dalších standardů se ISO 27000 omezuje pouze na bezpečnost informací a ISO 9000 pouze na zdokumentování procesů.

Z pohledu auditu dat jsou z celé sady kontrol poskytovaných IT Assurance Guide nejzajímavější aplikační kontroly, které jsou specifické pro jednotlivé aplikace a nepokrývají je COBIT IT procesy. Jsou to ty kontroly, které by zůstaly v rámci IT Assurance Guide k dispozici i při náhradě COBITU jako kontrolního rámce rámcem jiným.

V případě bank by bylo vhodné konfrontovat kontrolní cíle COBITu s požadavky Basel II (resp. vznikajícího Basel III) na kvalitu dat. Otázkou je, do jaké míry Basel II podává konkrétní doporučení. [23] např. hovoří o tom, že data vstupující do modelů kreditního rizika mají být správná a „odpovídající svému účelu “. V jiné části dokumentu [23] se hovoří o nutnosti identifikace volatility dat a auditu správnosti, úplnosti, konzistentnosti, aktuálnosti a důvěryhodnosti datových zdrojů. Dokument se též vyjadřuje k nutnosti uchovávání historických dat a jejich použití v rámci modelů.

Obdobně v případě pojišťoven by bylo vhodné zvážit, zda kontrolní cíle COBITu nedoplnit o požadavky Solvency II. Tato regulace stejně jako Basel II uvažuje v rámci System of Governance řízení dat jako jednoho z největších operačních rizik firmy. Na úrovni Level1 (viz [24]) tato směrnice hovoří též o úplnosti, přesnosti a vhodnosti použitých údajů pro interní model. Na dalších úrovních bude zřejmě poněkud sdílnější. Level 2 (Implementing Measures) i Level 3 (doporučení) však dosud nemají svou konečnou podobu. Zprostředkovaně o požadavcích Solvency II na datovou kvalitu píše [25]. Zdůrazňuje význam kvalitních dat zejména pro interní modely. Zmiňuje zjeména tři vlastnosti: vhodnost, úplnost a správnost. Stejně tak jako v případě Basel II je kladen důraz i na uchování historických dat. [25] též zmiňuje význam porovnávání dat s externími zdroji za účelem ověření konzistence. S odvoláním na materiály CEIOPS (Committee of European Insurance and Occupational Pensions Supervisors) uvádí požadavky na transparentnost, granularitu, sběr historických dat a dohledatelnost dat. Obecně lze dle mého názrou doporučení CEIOPS ohledně datové kvality považovat za best practices z oblasti pojišťovnictví. V tomto směru [25] odkazuje na podrobnější zdroje CEIOPS [26], [27] a [28].

Pokud bych měl zmínit ještě další doporučené best practices, které je vhodné v rámci auditu datové kvality realizovat a IT Assurance Guide je vysloveně nezmiňuje, pak se rozhodně jedná o validaci adresních údajů proti územně identifikačním registrům. Zavedení těchto kontrol se zřejmě skrývá v COBIT kontrolních cílech PO2.1 Enterprise Information Architecture Model, resp. PO2.4 Integrity Managementm definice validačních pravidel v PO2.2 Enterprise Data Dictionary and Data Syntax Rules a monitoring v ME1.2 Definition and Collection of Monitoring Data. Nicméně i v případě, kdy tyto kontrolní cíle nejsou sledovány, v rámci auditu dat považuji tento krok za vhodný.

I za předpokladu, že nejsou sledovány kontrolní cíle PO3.3 Monitor Future Trends and Regulations a PO4.8 Responsibility for Risk, Security and Compliance, považuji za vhodné provést ověření, zda jsou splněny požadavky zákona č. 101/2000 Sb., o ochraně osobních údajů a o změně dalších zákonů a v případě bank PCI DSS (Data Security Standard, viz [29]).

Praktický příklad assessmentu podle IT Assurance Guide

Přes některé uvedené výhrady k použití IT Assurance Guide: Using COBIT pro audit datové kvality se pokusím jeho praktické použití demonstrovat na konkrétním příkladu. Nejprve seznámím s architekturou auditované firmy – univerzální pojišťovny. Poté popíši praktickou náplň jednotlivých fází auditu dat podle IT Assurance Guide.

Popis architektury firmy použité v příkladu

Zkusme si pro účely praktického příkladu realizace auditu datové kvality představit následující univerzální pojišťovnu, která poskytuje pojistné produkty z těchto oblastí:

Archiktektura základních aplikací této pojišťovny je zachycena na obrázku č. 2. Obrázek znázorňuje idylický stav; v rámci modelového auditu budou zjištěny dílčí nedostatky . Do pojišťovny vstupují data jednak z externích číselníků a registrů (1) a jednak od externích partnerů jako jsou makléři a banky nabízející pojistné produkty v rámci finančních plánů (4). Standardně jsou pojistné smlouvy typovány buď ručně v rámci backoffice (3), anebo jsou dávkově přenášeny z kalkulaček pojistného nainstalovaných na noteboocích jednotlivých získatelů (2). Veškerá klientská data procházejí na vstupu procesem porovnávání se záznamy stávajících unifikovaných klientů. V případě zjištění dostatečné shody je příchozí klientský záznam sloučen s již existujícím. Kontrakty jednotlivých klientů jsou zpracovány v oddělených provozních systémech pro neživotní (11) a životní (10) pojištění. Separátně od těchto systémů je používán provizní systém (9). Aktualizace číselníků a dat z externích registrů jsou nahrávány do centrální správy číselníků (1), odkud jsou přenášeny do datového skladu (7). Data z primárních systémů životního a neživotního pojištění a provizního systému jsou dále přenášena do účetního systému (14,16,18) a datového skladu (13,15,17). Současně s nimi je do datového skladu přenášen i konsolidovaný klient (8). Na nejvyšší úrovni datového skladu jsou vystavěny data marty pro pojistnou matematiku (20), analytické CRM (21), Sales Management (22), řízení rizik (23) a reporting pro účely controllingu (24), které jsou dále publikovány na Intranetu (25). V rámci online portálu jsou jednak distribuována data pro externí partnery (5,19) a jednak je možné přes něj online sjednat vybrané typy pojištění . Při sjednávání pojištění probíhá porovnání klienta s master databází (6) a následně je nový kontrakt zanesen do IS neživotního pojištění (12).

Obrázek 2: Schéma IS architektury univerzální pojišťovny

Představme si nyní méně idylickou situaci, tj. že v architektuře pojišťovny zcela chybí MDM Hub centralizující kmenová data klientů. Vstupní kontroly duplicit jsou realizovány pouze na úrovni dvou oddělených provozních systémů. Online pojištění má svou vlastní datovou bázi a je s provozním systémem neživotního pojištění integrováno až v okamžiku, kdy dojde k platbě prvního pojistného. Klienti jsou v rámci aplikace pro online pojištění vždy nově zakládáni a stejně tak následně při jejich importu do systému neživotního pojištění. Provizní systém je napojen na oba systémy pro správu smluv, nicméně v rámci něj opět nedochází k deduplikaci klienta, neboť pro něj je stěžejní pohled přes jednotlivé získatele jednotlivých smluv, kteří mohou být u jednoho klienta rozdílní. K deduplikaci nedochází ani na úrovni datového skladu. Klient je na jeho úrovni definován na bázi identifikátoru z primárního systému, resp. rodného čísla / IČa.

Vedení této modelové pojišťovny se v nejmenovaném marketingovém časopisu dočetlo o úspěších své konkurenční pojišťovny v přímých kampaních. Rozhodlo se tedy též implementovat nástroj pro jejich řízení a za tímto účelem vytvořilo oddělení CRM, v jehož kompetenci řízení přímých kampaní bude. V rámci článku se též dočetlo, že jedním z kritických faktorů úspěšnosti implementace takového nástroje jsou kvalitní data. Rozhodlo se tedy povolat externího konzultanta v oboru datové kvality, aby zhodnotil stav jejích dat s ohledem na využití v rámci CRM.

Plánování auditu

V tomto případě je proces ujištění vztahem mezi IT co by stranou odpovědnou za stav kvality dat, externím auditorem co by profesionálem ujištění a oddělením CRM, které dostalo od vedení společnosti mandát být jeho zadavatelem (zainteresovanou stranou).

Externí auditor ve spolupráci s útvary IT a CRM při aplikaci horizontálního přístupu k definici základních parametrů univerza přes datové objekty identifikoval následující oblasti relevantní pro zamýšlené byznys procesy CRM:

Jelikož firma přijala principy IT Governance podle standardu COBIT, shodly se všechny zúčastněné strany na volbě této metodiky jako kontrolního rámce použitého v rámci procesu ujištění.

V souvislosti s analýzou rizik byla vytvořena hrubá matice užití atributů z datových zdrojů spadajících do univerza procesu ujištění. Znázorňuje ji tabulka č. 2. Pro účely rychlé analýzy rizika byla vytvořena na úrovni skupin atributů, v tomto případě na úrovni granularity definované atributem Doména.

Tabulka 2: Příklad matice užití jednotlivých atributů
Doména Exekuce přímých kampaní Podpůrné modely
Dožití ŽP Up-sell X-sell Retence Predikce storna Predikce koupě Hodnota klienta
KLIENTAAAAAAA
KONTAKTAAAA
SMLOUVAAAAAAAA
ŠKODAAA
POJISTNEAA
PŘEDMĚTAAA
ZÍSKATELAAAA

Matice užití tvoří základ pro prioritizaci auditu jednotlivých atributů. K jednotlivým užitím jsou následně definovány v hrubé výši náklady, které mohou plynout z nedostatečné úrovně vlastností jednotlivých atributů / skupin atributů. Atributy jsou vztaženy k procesům pořízení dat a jejich transformací. Na základě výše nákladů jsou označeny procesy pořízení / zpracování dat, jejichž selhání přináší největší rizika. V případě modelové pojišťovny to jsou procesy pořízení a zpracování údajů klienta umožňujících jeho unifikaci, jeho adresních údajů, vybraných atributů smluv umožňujících identifikaci aktuální propojištěnosti a atributy popisující dosavadní škody a dispozice k nim (detaily předmětu pojištění), které mohou předurčit možné budoucí ztráty v případě chybného zacílení kampaně.

 Dále následuje rychlý assessment jednotlivých procesů COBITu na „high-level“ úrovni. Pro znázornění výstupu assessmentu bylo použito jedno ze schémat uvedených pro tyto účely v [13]. Připomeňme, že závažnost procesu z pohledu rizika je hodnocena na škále od 1 (nejnižší) do 5 (nejvyšší), výkonnost procesu od 1 (velmi dobrá) do 5 (neznámá nebo špatná), „A“ / „N“ v případě místa realizace procesu, příznaku existující formalizace (ve smyslu existujícího kontraktu, SLA nebo zdokumentované procedury) a realizovaného monitoringu znamená výskyt nebo absence jevu. Posledním údajem matice je uvedení osoby zodpovědné za realizaci procesu. V případě, že proces COBITu není pro audit datové kvality na dané úrovni hierarchie řízení dat (v našem případě Data Governance) relevantní, uvádím u něj nulovou závažnost.

Tabulka 3: Zhodnocení zralosti procesů
Riziko IT procesy Realizace Auditován Formalizován Zodpovědnost
ZávažnostVýkonnostITOstatníExterníNení známo
04PO1 Define a strategic IT planANNNNACIO
43PO2 Define the information architectureANNNNACIO
04PO3 Determine technological directionANNNNNCIO
44PO4 Define the IT processes, organisation and relationshipsANNNN ACIO
04PO5 Manage the IT investmentANNNNACIO
14PO6 Communicate management aims and directionANNNNNCIO
24PO7 Manage IT human resourcesNANNAAPersonální ředitel
52PO8 Manage qualityANNNAAVedoucí oddělení řízení kvality
24PO9 Assess and manage IT risksANNNNACIO
24PO10 Manage projectsNANNNAVedoucí úseku řízení projektů
03AI1 Identify automated solutionsANNNNACIO
13AI2 Acquire and maintain application infrastructureANNNNACIO
13AI3 Acquire and maintain technology infrastructureANNNNACIO
13AI4 Enable operation and useANNNNACIO
23AI5 Procure IT resourcesANNNNACIO
14AI6 Manage changesANNNNACIO
14AI7 Install and accredit solutions and changesANNNNACIO
33DS1 Define and manage service levelsNANNNAVedoucí oddělení nákupu
13DS2 Manage third-party servicesANNNNACIO
13DS3 Manage performance and capacityANNNNACIO
13DS4 Ensure continuous serviceANNNNNCIO
34DS5 Ensure system securityANNNNAOddělení compliance a security
33DS6 Identify and allocate costsANNNNACIO
45DS7 Educate and train usersNANNNAPersonální ředitel
15DS8 Manage service desk and incidentsANNNAACIO
15DS9 Manage the configurationANNNNACIO
25DS10 Manage problemsANNNNACIO
53DS11 Manage dataANNNAACIO
15DS12 Manage the physical environmentANNNAACIO
15DS13 Manage operationsANNNNACIO
33ME1 Monitor and evaluate IT performanceANNNAACIO
53ME2 Monitor and evaluate internal controlANNNAACIO
54ME3 Ensure compliance with external requirementsANNNNACIO
04ME4 Provide IT GovernanceNNNANNBoard

Z uvedené matice je „překvapivě“ patrné, že je třeba audit zaměřit na procesy řízení dat, řízení kvality, monitoring kontrol a zajištění shody s externími požadavky (v tomto případě požadavky na data).

Stanovení rozsahu auditu

Na základě výstupů z předchozí fáze byly nejprve na základě schématu organizační struktury identifikováni pracovníci, spjatí jak po byznys stránce, tak po stránce IT s vymezeným předmětem ujištění. Byly identifikovány jejich role a odpovědnosti v souvislosti s tímto předmětem. Na základě interview s těmito zainteresovanými stranami (včetně pracovníků CRM oddělení) byly detailně vyspecifikovány požadavky na data a procesy, které je pořizují a transformují. Množina relevantních atributů byla určena konkretizací matice užití na úroveň jednotlivých atributů (viz Tabulka č. 4). Současně byla definována rizika spojená s nedodržením jednotlivých vlastností. Rizika byla popsána na základě své pravděpodobnosti výskytu a svého možného dopadu. Nejvýznamnější rizika se vztahovala k vlastnostem atributů klienta, vybraných kontaktních a adresních údajům klienta, data konce kontraktu a atributů popisujících předmět pojištění.

Tabulka 4: Matice užití na úrovni jednotlivých atributů
Doména Označení atributu Exekuce přímých kampaní Podpůrné modely
Dožití ŽP Up-sell X-sell Retence Predikce storna Predikce koupě Hodnota klienta
KLIENTPříznak nesouhlasu s oslovenímAAANNNN
KLIENTID unikátního klientaAAAAAAA
KLIENTRole klienta na smlouvěAAAAANA
KLIENTTitul před jménemAAAANNN
KLIENTJménoAAAANNN
KLIENTPříjmeníAAAANNN
KLIENTUlice + č.p. + č.or.AAAANNN
KLIENTObecAAAANNN
KLIENTPSČAAAAAAA
KLIENTDatum narozeníAANAAAA
KLIENTPohlavíAANNNAA
KONTAKTTelefonAAAANNN
KONTAKTE-mailNNANNNN
KONTAKTMobilAAAANNN
SMLOUVADruh stornaNNNAAAA
SMLOUVADatum vypracování návrhuNNNAANN
SMLOUVADatum počátkuAAAAAAA
SMLOUVADatum konceNNANANA
SMLOUVAFrekvence placeníNAANANN
SMLOUVADůvod stornaNNANANA
SMLOUVARoční pojistné celkemAAANANA
SMLOUVAHodnota smlouvy ŽPANNNNNN
SMLOUVAPříznak vinkulaceANNNNNN
ŠKODACelkové plněníNNNNNNA
ŠKODADatum hlášeníNNANNNA
ŠKODADruh plněníNNANNNA
PŘEDMĚTRozhodná dobaNNANNNN
PŘEDMĚTRok výroby vozidlaNNAAANN
ZÍSKATELStupeň karieryAAAANNN

Současně byly identifikovány stávající politiky, procedury a z nich vyplývající kontroly zabezpečující dosahování požadované míry vlastností dat. Interview též ukázala, že zde v intervalu 1-2 let docházelo k ad-hoc prověřování datové kvality na bázi zjišťování kvantitativních (objektivních) vlastností dat vedoucích k jednorázovým nápravným opatřením, nikoliv však systematickým. Systematickým vstupním kontrolám v mnoha případech bránilo tvrzení obchodu (zejména ze strany agenturníků pracujících na IČO, disponujících profitabilními pojistnými kmeny), že by je vstupní kontroly zdržovaly a jsou plánovány na atributech, které nejsou podstatné.

V této fázi doporučuje IT Assurance Guide prolinkování byznys cílů na IT cíle a IT procesy. Pro tyto účely poskytuje COBIT v dodatku č. 1 matici mapující 17 generických byznys cílů na IT cíle (viz [40)]. My je pro naše účely nepoužijeme, neboť se v rámci uvažovaných cílů pohybujeme na větší úrovni granularity. Výsledkem této fáze je schéma enterprise architektury omezené na definovanou oblast univerza zobrazené na Obrázku č. 3 prolinkované na jednotlivé IT zdroje. Symbol trojúhelníku značí do „jisté míry“ prováděné kontroly.

V dalším kroku byly vybrány kontrolní cíle v návaznosti na kontrolní rámec COBIT. Paradoxně pro účely auditu datové kvality je nejzajímavějších 6 aplikačních kontrol, které jsou specifické pro jednotlivé aplikace a nejsou pokryty COBIT IT procesy.Ty testují implementaci nadefinovaných byznys kontrol vztahujících se k jednotlivým požadovaným vlastnostem informací (potažmo dat). Jedná se zejména o následující aplikační kontroly:

Obrázek 3: Schéma enterprise architektury

Z obecných kontrol založených na 34 COBIT procesech jsou pro modelový audit datové kvality nejrelevantnější ty související s procesem DS11 Manage Data, zejména:

Z dalších kontrol jsou dále relevantní např.:

IT Assuance Guide v následujícím kroku umožňuje customizaci vybraných kontrolních cílů. V našem příkladu (ale i v rámci použití kontrolních cílů pro audit datové kvality obecně) by bylo např. vhodné rozšířit kontrolní cíl aplikační kontroly AC3 Accuracy, Completness and Authenticity Checks (zjevně orientovaný na objektivní vlastnosti dat) i o měření dalších vlastností dat (např. pokrytí, u níž může být diskutabilní, zda ji v sobě neskrývá vlastnost „úplnost“). Pokud uvažujeme vlastnost „unikátnost“, není vhodné o ni rozšiřovat AC3 nebo jinou aplikační kontrolu, ale naopak je vhodné zjistit, zda tuto vlastnost v sobě neobsahuje některá obecná kontrola na úrovni některého z procesů COBITu. Především z toho důvodu, že unikátnost dat není specifikum jediné aplikace. Nalezneme ji v rámci procesu PO2 Define the Information Architecture v rámci kontroly PO2.1 Enterprise Information Architecture Model.

Realizace

V první fázi realizace ujištění je dle IT Assurance Guide vhodné se znovu ubezpečit o porozumění subjektu ujištění. V rámci této fáze provedl externí auditor řadu interview jejichž výsledkem byl plán aktivit, které budou realizovány. Nicméně se tato dodatečná interview nijak nedotkla původního rozsahu kontrolních cílů zařazených do scope projektu. Univerzem projektu zůstala část Enterprise architektury zobrazená na obr. 3 a kontrolní cíle v rámci kontrol AC2, AC3, AC4, AC5, DS11.1, DS11.2, DS11.6, PO2.1, PO2.2, PO2.3, PO2.4, PO4.9, PO8.1, PO8.6.

V dalším kroku provedl auditor test efektivnosti návrhu kontrol v rámci jednotlivých kontrolních cílů a test výstupu kontrolních cílů tam, kde se provádějí. Součástí testu byl jednak test návrhu kontrol, potvrzení, zda jsou skutečně realizovány a hodnocení jejich operativní efektivnosti a účinnosti. Test skutečné realizace mimo jiné ukázal, že na základě požadavku byznysu nejsou u všech atributů prováděny kontroly v rámci AC3 na vstupu z kalkulaček do provozního systému neživotního pojištění.

Příklad testu návrhu kontrol si ukážeme taktéž na aplikační kontrole AC3 Accuracy, Completness and Authenticity Checks. Na základě namátkového porovnání údajů vzorku dat v provozním systému neživotního pojištění, písemných smluv ze spisovny a údajů z vybraných registrů byly zjištěny vážné nedostatky v návrhu vstupních kontrol správnosti dat. Hypotézy se potvrdily při revizi designu konkrétní služby realizující import dat z kalkulaček pojistných smluv.V případě atributu rok výroby vozidla není prováděna validace údajů proti registru vozidel. Rok vozidla tak může obsahovat libovolný syntakticky správný údaj, v mnoha případech však ve skutečnosti rok vzniku pojistné smlouvy. V případě rozhodné doby není prováděna validace proti databázi škod. Problém nastává zejména při dokládání rozhodné doby místopřísežným prohlášením pojistníka. Další interview s uživateli ukázala, že aktuální výši bonusu je možné na základě požadavku obchodu měnit pod záminkou přidělení „mimořádného bonusu“ jako obchodní slevy na pojistném. Rovněž nedostatečné kontroly se ukázali být v případě importu adresních údajů. Vlivem absence kontrol proti registru UIR-ADR se na náhodně vybraných pojistných smlouvách generovaných kalkulačkami vyskytovaly zjevné nekonzistence mezi jednotlivými atributy adres. V mnoha případech bylo uvedeno pouze číslo popisné nebo číslo orientační, přičemž v dané lokalitě mohla záměna čísla popisného a čísla orientačního vést k nedoručitelnosti zásilky na danou adresu. Tam, kde byly kontroly nastaveny korektně, provedl auditor test jejich výstupu. Např. u verifikace rodného čísla a kontroly konzistentnosti mezi ním, uvedeným pohlavím a datem narození tato kontrola vedla k zjištění, že validační proces zaloguje cca 10% záznamů jako nevalidní RČ nekonzistentní s „odvozenými“ atributy. Ve většině případů se jednalo o atributy cizinců bez trvalého pobytu v ČR. Tento log je dále zpracováván oddělením zákaznické podpory, které verifikuje, zda se skutečně jedná o cizince, či ne.

V předposledním kroku fáze realizace ujištění jsou zdokumentovány dopady zjištěných slabin kontrol, zejména do byznysu. Požadavek na zjištění byznys dopadu dle [13] často vede k dalším dodatečným analýzám. K nim je nutné se uchýlit v případě, kdy pro zhodnocení dopadu v rámci prováděných kontrol chybí metriky, kontroly fungují špatně nebo byly aplikovány nekonzistentně. Mezi konkrétními příklady analýz, které tento zdroj uvádí, figurují nám již známé přístupy praktikované v rámci konvečních přístupů k auditu datové kvality jako jsou např. anekdoty z vertikály, cause-effect analýzy či mapování dopadu do byznys procesů. Jako příklad konkrétní situace je možné zmínit namapování důsledků cca 2% výskytu chybějících či nevalidních adresních údajů na byznys procesy relevantní pro CRM. Zjištěné nedostatky byly ohodnoceny z pohledu přímých ekonomických důsledků ročními náklady cca 360 tis.

V posledním kroku realizace je formulován závěr a doporučení. Ta je vhodné doplnit porovnáním slabin s dotazy na základě root-cause analýzy, benchmarkingem a maturity modelem pro interní kontroly. Doporučení mají formu konkrétních akcí směřujících ke snížení dopadu slabostí kontrol, porovnáním výkonnosti se standardy a nejlepšími praktikami. V rámci doporučení auditor uvedl zejména nutnost zajištění jednotného pohledu na unifikovaného a deduplikovaného klienta, nutnost zavedení kontrol proti územně identifikačnímu registru UIR-ADR, databázi škod a registru vozidel. V případě zmiňovaného návrhu kontroly RČ auditor doporučil rozšířit kontrolu tak, aby zohledňovala místo narození. Tato změna by vedla k menšímu zatížení backoffice, neboť korektně nekonzistentní údaje cizinců by nebyly logovány.

Návrh struktury zprávy auditora pro účely auditu datové kvality

Formálním výsledkem činnosti auditora by měla být výstupní auditorská zpráva. Příloha č. 1 obsahuje návrh šablony použitelné pro audit datové kvality. Při její tvorbě jsem se inspiroval požadavky, které na formální náležitosti klade §20 zák. 93/2009 Sb. o auditorech, standard S7-Reporting a návod G20-Reporing publikovanými ISACA. Podle uvedeného zákona zpráva musí obsahovat identifikaci auditora, vymezení rozsahu auditu, odkaz na relevantní standardy, výrok auditora, popis skutečností relevantních k výroku, datum vyhotovení a podpis. Pro účely auditu datové kvality byly převzaty všechny požadované části s výjimkou výroku auditora, který v našem případně použít nelze. Auditor se podle §20 odst. 1 c) zák. 93/2009 Sb. vyjadřuje ke shodě reality s účetní závěrkou a jeho výrok může nabývat pouze těchto hodnot: (1) bez výhrad, (2) záporný výrok, (3) s výhradami, (4) odmítnutí výroku.

Standard S7 (viz [17]) vyžaduje tyto formální součásti zprávy auditora: (1) identifikace organizace, kde byl audit realizován, (2) vymezení rozsahu, (3) definici cíle, (4) vymezení doby po kterou se audit prováděl, (5) vymezení způsobu auditu, (6) uvedení hloubky auditu, (7) uvedení časového rozvruhu prováděných činností, (8) uvedení závěrů, nálezů a doporučení a konečně (9) uvedení všech omezení při provádění auditu. Šablona v příloze č. 1 obsahuje všechny tyto části.

Návod G20 (viz [18]) odkazující se na standard S7 doporučuje tyto formální části: (1) název zprávy, (2) identifikace adresáta, (3) popis rozsahu auditu (identifikace / popis objektů auditu, použitá kritéria hodnocení), (4) účel zprávy, (5) identifikace uživatelů zprávy, (6) omezení užití, (7) omezení při realizaci auditu, (8) doporučení opravných akcí a reakce odpovědných managerů na toto doporučení, (9) názor auditora na efektivnost kontrol, (10) podpis, adresa, datum zpracování zprávy a konečně (11) ustanovení, že audit byl vykonán v souladu s ISACA IT Audit and Assurance Standards nebo dalšími profesními standardy. Všechna tato doporučení byla zohledněna v šabloně auditu v příloze č. 1.

Kromě výše uvedených požadavků v sobě šablona zohledňuje i další standardní komponenty, s nimiž jsem se setkal v praxi u dokumentů typu „assessment datové kvality“, tj.: (1) historie a verze dokumentu, (2) identifikace tvůrce a revidujících osob, (3) manažerské shrnutí, (4) popis metodiky auditu, (5) terminologický slovník.

Závěry

IT Assurance Guide jako takový dle mého názoru lze aplikovat pro realizaci auditu datové kvality. Jedná se o posloupnost činností, kterou lze (jak ukazuje příloha č. 2) do značné míry namapovat na kroky doporučené v rámci konvenčních přístupů k auditu datové kvality. Některé opakované návraty k redefinici scope bude účelné v rámci aplikace na audit datové kvality vynechat. Jako problematická se může jevit volba COBITu jako kontrolního rámce a to zejména za situace, kdy auditovaný subjekt nepřijal principy IT Governance. Nicméně pro účely auditu datové kvality jsem jiný vhodný komplexní rámec nenalezl. Pro účely některých regulací by bylo zřejmě vhodné kontrolní cíle COBITu doplnit o kontrolní cíle požadované těmito regulacemi. Procesní kontroly doporučované IT Assurance Guide: Using COBIT jsou natolik komplexní, že je značně diskutabilní, zda se v případě malých auditů nejedná o příslovečný „kanon na vrabce“. Metodiky dosud považované v rámci auditu dat za komplexní, jako je např. TQdM (Total Quality Data Management) Larryho Englishe, se v porovnání s IT Assurance Guide jeví jako titěrné, už s ohledem na fakt, že odpovídají pouze podmnožině jeho kroků.

Seznam použité literatury

Přílohy

Komentáře ke článku

Stránka byla naposledy aktualizována dne 4.5.2015
Powered by HOLOPAGE
©2011 - 2015 D. Pejčoch