MCTL - Managing Computer Technology Library

Transcriptie

1 8. TAAKGEBIED GEGEVENSBEHEER Gegevensbeheer, met name de gegevens in elektronische databases, is in essentie altijd een zaak van de eigenaar van de gegevens; de gebruikersorganisatie dus. In dit taakgebied wordt beschreven hoe vanuit functioneel support en de leverancierszijde dit gegevensbeheer kan worden ondersteund. In voorkomende gevallen kan het vanuit de gebruikersorganisatie worden gedelegeerd aan functioneel support of een leverancier. Laatstgenoemde leverancier kan een technologieleverancier zijn. Voor het efficiënt beheren van gegevens is computertechnologie wel noodzakelijk, maar het beheer zelf kan bijvoorbeeld door een gegevensmakelaar worden gedaan; een bedrijf dat bestaat van het verzamelen, verrijken, leveren en verhandelen van gegevens. ACHTERGROND In de afgelopen tientallen jaren is de rol van computertechnologie in opslag en beheer van gegevens steeds groter geworden. Al in 1995 verscheen van Nicholas Negroponte het boek Being digital, waarin als principe wordt gesteld dat "bits moeten geprefereerd worden boven atomen". Met andere woorden, alles wat digitaal kan worden, zal dat ook worden (Razorfish). Op het gebied van cijfers en letters kan dat inderdaad voor 100%. Evenals voor muziek, beeld en video. Terwijl dat voor bijvoorbeeld een auto of koffiezetmachine (in ieder geval op dit moment) tot de onmogelijkheden behoort; in bits kun je nu eenmaal niet rijden en bits opdrinken is, laten we zeggen, waarschijnlijk ook een heel bijzondere ervaring. Een ontwikkeling, die grote invloed heeft (gehad en nog heeft) op het beheer van gegevens, is dat in eerste instantie, bij de digitalisering, vaak gegevens op dezelfde manier werden behandeld als in de fysieke wereld. In de fysieke wereld kunnen gegevens immers maar op één plek tegelijkertijd zijn. Er ontstonden dan ook, net als ooit op papier, digitale decentrale gegevensverzamelingen. Omdat het maken van een digitale kopie tegen lage kosten mogelijk is, ontstond in een volgende fase de situatie dat van een originele gegevensset op diverse plaatsen kopieën ontstonden. Met alle gevolgen van dien, omdat het vrij lastig bleek om alle kopieën gelijk te houden aan het origineel. En bijvoorbeeld ook om te organiseren dat als ergens in een kopie een fout werd ontdekt, dit dan in het origineel te laten bijwerken. Was eigenaarschap in eerste instantie een kwestie die op een heel natuurlijke wijze werd geregeld omdat gegevens op papier slechts op één plek kunnen zijn en het verschil tussen origineel en kopie doorgaans heel duidelijk, nu werd dat een serieus issue. Hierna ontstond de derde fase, van interne digitale centrale gegevensverzamelingen. In plaats van het naar verschillende plaatsen distribueren van gegevens werden gegevens op één centrale plaats in de organisatie neergezet. Vandaaruit worden dan de gegevens via netwerken ter beschikking gesteld. Feitelijk is daarmee technisch een fraaiere situatie ontstaan omdat allerlei synchronisatieproblematiek tussen gegevens op verschillende fysieke plaatsen verleden tijd is. En ook het eigenaarschap is eigenlijk weer helderder: wie is de eigenaar van welke gegevensset? Toch blijkt dat bij gegevenssets die door veel organisatieonderdelen worden gebruikt het eigenaarschap nog niet heel eenvoudig. Bij gegevens die op veel plaatsen worden gebruikt zijn gegevenskwaliteit, consistentie in betekenis (verstaat iedereen hetzelfde onder hetzelfde gegeven) en aanpassingen (meer afstemming, meer verschillende wensen) lastiger in de greep te houden. En welke eigenaar zit daarop te wachten? Al V1.0 Pagina 1

2 snel ontstaat het gevoel bij een dergelijke gegevenseigenaar dat deze zit opgescheept met allerlei problemen terwijl de rest van de organisatie alleen maar profiteert. Langzamerhand ontstaat de vierde fase, waarin grote basisgegevensverzamelingen door veel verschillende organisaties / bedrijven gezamenlijk gebruikt gaan worden. Dat is bijvoorbeeld te zien bij persoonsgegevens en locatiegegevens, maar ook bij basistabellen als wettelijke percentages, postcodes en gemeentecodes. In de publieke sector is het volgende Stelsel van Basisregistraties opgesteld: BRP - Basisregistratie personen (bestaat uit ingezetenen en niet-ingezetenen) NHR - Handelsregister BAG - Basisregistraties Adressen en Gebouwen (bestaat uit twee basisregistraties) BRT - Basisregistratie Topografie BRK - Basisregistratie Kadaster BRV - Basisregistratie Voertuigen (kentekenregister) BLAU - Basisregistratie voor Lonen, Arbeidsverhoudingen en Uitkeringen BRI - Basisregistratie Inkomen WOZ - Basisregistratie Waarde Onroerende Zaken BGT - Basisregistratie Grootschalige Topografie (voorheen GBKN) BRO - Basisregistratie Ondergrond (voorheen ook wel DINO) Ook in specifieke andere sectoren zijn dergelijke ontwikkelingen te ontwaren. Bijvoorbeeld in de zorgsector bestaan gezamenlijk gebruikte tabellen met behandelcodes en tabellen met gegevens van contra-indicatie; aandoeningen waarbij bepaalde medicijnen niet mogen worden toegepast, en tabellen met medicijnen die elkaar negatief beïnvloeden (wisselwerking). Goed beschouwd is dit gezamenlijk gebruik buitengewoon efficiënt, maar het leidt tegelijkertijd tot nieuwe problemen die moeten worden opgelost. Het wordt namelijk steeds lastiger om de eigenaar van dergelijke gegevens te bepalen en deze eigenaren zijn steeds meer geneigd het beheer niet zelf uit te voeren. Deze gegevenssets bewandelen daarmee hetzelfde pad dat we al gezien hebben bij hardware- en software; via hosting, cloud-computing etc. wordt iets steeds minder op locatie zelf geregeld, maar vanuit een leverancier op maat aangeboden. Op deze laatste ontwikkeling wordt binnen dit taakgebied geanticipeerd. DOEL VAN DIT TAAKGEBIED Het ondersteunen van de eigenaar bij het beheer van gegevens ofwel het namens de eigenaar beheren van gegevens. HOE WEET JE DAT HET DOEL IS BEREIKT? De volgende indicatoren zijn te benoemen om te weten of bovenstaande doel is bereikt: Gegevens blijken bij controle voor 99,9% correct en compleet Gegevensgebruik blijkt bij controle juist V1.0 Pagina 2

3 Onnodige gegevensduplicatie (zelfde gegevens op meerdere fysieke plaatsen) komt in < 5% van de totale gegevensset voor (Genoemde percentages zijn uiteraard indicatief) ORGANISATIE VAN GEGEVENSBEHEER Een illustratief plaatje om aan te geven hoe gegevensbeheer kan worden georganiseerd is: Het is ook mogelijk om functioneel support en gegevens support te combineren in één afdeling. Op die wijze ontstaat het volgende organisatieplaatje: V1.0 Pagina 3

4 Hierbij moet worden opgemerkt dat de eigen organisatie en leveranciers natuurlijk los van elkaar staan: het kan zijn dat in de eigen organisatie FS en GS zijn gecombineerd, terwijl bij de leverancier(s) FS en GS zijn gesplitst, of andersom. In het laatste schema wordt extern onderscheid gemaakt tussen de leverancier(s) die de computertechnologie verzorgen en de leveranciers van gegevens: VERSCHILLENDE SOORTEN GEGEVENS Binnen een gemiddeld bedrijfsproces worden verschillende soorten gegevens gebruikt. Onderstaand plaatje geeft daarvan een illustratie: V1.0 Pagina 4

5 Toelichting: 1. Allereerst bestaan gegevens die alleen voor een specifiek bedrijfsproces benodigd zijn. Hierbij spelen de kwaliteit van en de relaties met andere gegevens een rol. 2. Vervolgens bestaan generieke gegevens, die binnen meerdere interne bedrijfsprocessen een rol spelen. Voorbeelden hiervan zijn klant- of ordergegevens. Hier spelen naast kwaliteit ook autorisaties en eigenaarschap vaak een rol (wie mag wat). 3. Tot slot bestaan er externe gegevens, die kunnen worden aangeleverd of via een koppeling ter beschikking kunnen staan. Voorbeelden hiervan zijn postcodegegevens. Hierbij spelen naast kwaliteit en eigenaarschap ook beveiliging en de tijdstippen waarop gegevens ter beschikking staan / worden geactualiseerd, een rol. 4. Los hiervan kunnen parameters worden benoemd. Dit zijn uiteraard ook gegevens, die ergens worden opgeslagen. Parameters dienen om applicaties op een bepaalde wijze in te stellen. Binnen MCTL worden met name de functionele instellingen in ogenschouw genomen. Voorbeelden hiervan zijn limieten, indeling van gegevens op schermen en taalinstellingen. Aanpassing van parameters leidt tot een functionele wijziging en wordt daarom in het taakcluster Change control als wijziging verwerkt. Gegevens worden nimmer direct in een bedrijfsproces gebruikt, dit loopt altijd via de applicatielaag. Ook in het geval van BI-tools, die om de standaard applicaties heen, gegevens op een andere manier kunnen benaderen en presenteren, zijn gewone applicaties, zij het met een wat specifieke functionaliteit. INPUT, ACTIVITEITEN, OUTPUT De activiteiten in dit taakgebied zijn als volgt weer te geven: Input De input is een aanvraag vanuit de klant. Activiteiten De volgende los van elkaar staande activiteiten zijn op functioneel vlak te onderkennen: 1. Aanpassen van gegevens 2. Ondersteuning bij uitwisseling van gegevens 3. Uitvoeren van controles op gegevenskwaliteit Deze activiteiten worden in de paragrafen hierna verder uitgewerkt. Output De output wordt gevormd door gegevens die ter beschikking staan aan de bedrijfsprocessen en waarbij vanuit Functioneel support en / of leverancier een juiste rol is ingevuld op het gebied van juistheid, tijdigheid en kwaliteit van die gegevens. NB. Op het gebied van gegevensbeheer moet natuurlijk ook aandacht zijn voor een juiste en veilige fysieke opslag van gegevens, het maken van back-ups etc. Dit is het aandachtsgebied van de infra en applicatie support en / of leveranciers (bijv. bij cloud oplossingen). V1.0 Pagina 5

6 ACTIVITEIT 1: AANPASSEN VAN GEGEVENS Het aanpassen van gegevens is een activiteit die normaal gesproken uitgevoerd door de gebruikers in de gebruikersorganisatie. Dat verloopt via de normale werkprocedures en systemen. Echter, het kan in uitzonderlijke gevallen voorkomen dat gegevens niet juist in de database zijn opgenomen en dat via de normale werkprocedure deze gegevens niet zijn te herstellen. Dan moet om het systeem heen, vaak rechtstreeks in de database, een aanpassing worden gedaan. Het mag duidelijk zijn dat dit zoveel mogelijk voorkomen moet worden; systemen (applicaties) kunnen enerzijds zo worden gemaakt dat zo min mogelijk foute gegevens in databases terecht komen (invoercontroles), en anderzijds dat gebruikers veel mogelijkheden wordt geboden om zelfstandig foutieve gegevens te corrigeren. Toch blijft altijd de kans bestaan dat onjuiste gegevens in de database staan die niet door gebruikers zelf kunnen worden hersteld. Op onderstaande gestructureerde en gecontroleerde wijze kunnen dit soort foutieve gegevens in de databases worden aangepast. De in het schema genoemde acties zijn op zichzelf duidelijk en worden hier niet verder toegelicht. Uitvoering van deze activiteiten wordt doorgaans gedaan door de functioneel specialist. Het schema geeft aan dat een tamelijk formele werkwijze wordt gevolgd. Ook indien binnen een bedrijf doorgaans een wat lossere werkwijze wordt gevolgd, is het hier toch zaak de uit te voeren acties relatief strak uit te voeren. Deze acties moeten worden uitgevoerd door personen die zowel de kennis hebben van de benodigde tools (waarmee rechtstreeks in de database wijzigingen kunnen worden aangebracht), als van de structuur van de gegevens (om ongewenste consequenties te voorkomen) en die de benodigde autorisaties hebben om dergelijke activiteiten uit te voeren. V1.0 Pagina 6

7 Over het algemeen zijn dergelijke acties (gelukkig) vrij uitzonderlijk en bij een aanpak zoals in bovengenoemd schema geschetst zal het de goedkeuring van een interne controller of externe auditor kunnen krijgen. En ten overvloede: functioneel / gegevens support kan hier een ondersteunende rol spelen, maar uiteindelijk blijft de gebruikersorganisatie verantwoordelijk voor de gegevens, ook als deze op genoemde wijze zijn aangepast. ACTIVITEIT 2: ONDERSTEUNING BIJ UITWISSELING VAN GEGEVENS Het is, zoals al eerder betoogd, niet ongewoon dat gegevens worden uitgewisseld of gezamenlijk worden gebruikt tussen verschillende onderdelen binnen een bedrijfsproces, maar ook tussen verschillende bedrijfsprocessen binnen de organisatie en tot slot tussen bedrijfsprocessen in verschillende organisaties. De eigenaren van de systemen en gegevens moeten dit zelf onder controle moeten houden. Er wordt in dit kader wel gesproken van proceseigenaarschap of keteneigenaarschap. Toch kan een bedrijfsproces met de bijbehorende gegevens zo complex zijn dat ondersteuning bij het uitwisselen van gegevens noodzakelijk is. Functioneel support kan dat bieden door ondersteunende diensten op het vlak van gegevensuitwisseling en gezamenlijk gegevensgebruik binnen die bedrijfsprocessen. ACTIVITEIT 3: UITVOEREN VAN CONTROLES OP GEGEVENSKWALITEIT De verantwoordelijkheid voor de kwaliteit van de gegevens ligt bij de eigenaar van die gegevens. Toch kan vanuit functioneel / gegevens support een ondersteunende rol worden gespeeld. Het is vaak mogelijk diverse (kruis)controles uit te voeren op gegevens, zodat (mogelijke) fouten in die gegevens worden geconstateerd. Ook kunnen fouten worden achterhaald doordat in het ene bedrijfsproces gegevens anders worden gebruikt dan in het andere bedrijfsproces. Dan kan functioneel / gegevens support een coördinerende rol spelen. In het geval van een ogenschijnlijk incidentele fout kan een gegevensbeheerder een nader onderzoek doen of de fout toch niet een meer structureel karakter heeft. Al met al zal duidelijk zijn dat vanuit functioneel / gegevens support nuttige kwaliteitscontroles zijn te ondernemen om de eigenaar van de gegevens te ondersteunen. Het volgende schema geeft de uit te voeren acties aan: V1.0 Pagina 7

8 Constateringen wordt geleverd aan de eigenaar van de gegevens. Indien het een gegevensset betreft die wordt onderhouden door leverancier, dan wordt het overzicht met constateringen uiteraard (ook) naar hen gestuurd. OPMERKINGEN De volgende opmerkingen zijn over het taakgebied Gegevensbeheer te maken. 1. EIGENAARSCHAP EN BEHEER VAN GEGEVENS Gegevens zijn in principe eigendom van de gebruikersorganisatie. Bij gemeenschappelijk gebruikte gegevens ontstaat de vraag: waar precies moet het eigenaarschap terechtkomen? Veel gekozen oplossingen zijn: 1. De afdeling die het meeste belang heeft bij de (juistheid) van de gegevens, wordt eigenaar 2. Er wordt intern een aparte afdeling opgericht (gegevensbeheer), die het beheer van gemeenschappelijke gegevens voor zijn rekening neemt Vervolgens moet het beheer worden belegd. Vaak wordt ervoor gekozen om het eigenaarschap en uitvoerend beheer op één plaats neer te leggen, maar dat hoeft niet. Het beheer van gegevens kan worden gedelegeerd aan anderen, onder andere aan een leverancier. Een verdere kwestie is of gegevens support een onderdeel van functioneel support zou moeten zijn. Immers, gegevens vormen op zichzelf geen functionaliteit, bieden die ook niet, en dus is hierop ook geen Functioneel support van toepassing. Aldus zou naast infra, applicatief en functioneel support, ook gegevens support als aparte eenheid kunnen worden ingericht. Indien dit organisatorisch niet wenselijk is, dan is het het meest logisch gegevens support en functioneel support samen te voegen. Beheer betekent niet dat de eindverantwoordelijkheid ook kan worden overgenomen door de beheerder. Bijvoorbeeld gegevensconversies kunnen worden uitgevoerd onder auspiciën van de beheerder, de inhoudelijke verantwoordelijkheid blijft liggen bij de eigenaar. 2. NIET-GEDIGITALISEERDE GEGEVENS Naast de in dit taakgebied geschetste gegevens die in digitale vorm zijn opgeslagen in databases op computers, bestaan ook nog de niet-gedigitaliseerde gegevens (ook wel met de weinig fraaie term niet-geautomatiseerde informatievoorziening aangeduid). Zolang deze niet-gedigitaliseerde gegevens nog bestaan, moet de relatie met de gedigitaliseerde gegevens worden onderhouden. Een voorbeeld is een ziekenhuis waar alle patiëntgegevens in een elektronisch dossier zijn opgenomen, maar toch ook nog een papieren dossier bestaat. Omdat ervan wordt uitgegaan dat Alles wat digitaal kan worden, ook digitaal zal worden, zijn nietgedigitaliseerde gegevens een aflopende zaak. Er wordt dus goed aan gedaan hier zo min mogelijk tijd, geld en energie in te steken waardoor de overgangsperiode zal worden verkort. V1.0 Pagina 8

9 3. BASISGEGEVENS VERSUS PARAMETERS Binnen MCTL wordt een parameter gezien als een instelling waarmee de functionele werking van een systeem binnen het bedrijfsproces kan worden beïnvloed. Voorbeelden zijn een instelling waarmee het maximum aantal rollen per werknemer kan worden ingesteld, de presentatie van gegevens op een scherm en de volgorde waar op het scherm door deze gegevens kan worden gelopen. Basisgegevens als bijvoorbeeld tarieven, afdelingscoderingen etc. daarentegen beïnvloeden weliswaar de uitkomsten van bedrijfsprocessen (bijv. een ander BTW-percentage geeft andere eindbedragen), de functionele werking van het systeem verandert niet. Daarom worden dergelijke gegevens binnen MCTL gezien als gewone gegevens, die vervolgens wel (zie schema aan het begin van dit taakgebied) specifiek voor een bedrijfsproces kunnen zijn, generiek of extern aangeleverd. Basisgegevens kunnen door de gebruikersorganisatie zelf worden gewijzigd. Indien hulp op dit vlak gewenst is kan het via dit taakgebied door functioneel / gegevens support worden ondersteund. Parameterwijzigingen worden NIET in dit taakgebied uitgevoerd. Dit betreft een aanpassing van de functionaliteit, en wordt daarom afgehandeld via het taakcluster Change control. V1.0 Pagina 9