gegevens, informatie, informatiemodellen, gegevenseigendom en databases
Het klinkt misschien als een open deur, maar ik roep het toch maar even:
1. gegevens zijn de grondstoffen voor informatie die overgedragen wordt tussen één of meer zenders en één of meer ontvangers
2. of een gegeven ook inderdaad informatie oplevert, hangt van de ontvanger van de gegevens af en niet van de zender, de ontvanger interpreteert de gegevens binnen zijn/haar context.
3. het overdragen van gegevens vindt altijd in de tijd plaats.
4. directe overdracht komt natuurlijk voor, maar meestal is er sprake van een verschil in het moment en/of de plaats van het zenden van gegevens en het moment of de plaats van het ontvangen van gegevens.
Dit laatste punt vraagt om heldere definities van gegevens die zowel voor de zender als de ontvanger éénduidig interpreteerbaar zijn. In het IT vakgebied is er danook een heel deelgebied waar vele uren worden besteed aan het formuleren van gegevensdefinities. En terecht.
Als we kijken naar de houdbaarheid van de verschillende componenten in een architectuur, dan is de bezetting van de rollen in een proces het meest gevoelig woor wijzigingen, vervolgens de inrichting van het proces en daarna pas de gegevens die voor het proces en de besturing daarvan, van belang zijn. Een goed onderbouwd Informatiemodel levert danook de meest stabiele basis voor besluitvorming over bedrijfsinrichting en de benodigde Informatie Technologie.
Er zijn diverse technieken en tools beschikbaar voor het beschrijven van de gegevens, het maken van Informatiemodellen en het structuren van de opslag van gegevens, daar wil ik hier verder niet op in gaan. Wat ik wel van belang vindt is het onderscheid tussen gestructureerde en ongestructureerde gegevens. Simpel gezegd komt het er op neer dat 'een brok tekst' de structuur heeft van de taal waarin het is geschreven, maar voor ons doel (= borging van de integriteit van de Informatievoorziening) als ongestructuurd wordt bestempeld.
Iets dergelijks geldt ook voor informatie in een speadsheet. Daar kan de gebruiker (= zender) van het tool wel degelijk structuur aanbrengen met behulp van kolommen en rijen die aan elkaar gerelateerd zijn, maar de software doet helemaal niets aan het borgen van de integriteit van die gegevens. Typefouten in de waardes in de cellen van een kolom leiden bij het filteren van die kolom tot onbetrouwbare resultaten.
Pas als we gebruik gaan maken van relationele databases, worden de capaciteiten van de software voor het borgen van de integriteit van gegevens volledig benut. Maar dat betekent ook dat wij goed na moeten denken over de samenhang van de gegevens. Hier spelen 'referentieële integriteit' en 'normalisatie' een cruciale rol.
In de praktijk wordt dit bij de ontwikkelaars van software regelmatig over het hoofd gezien. "Als het programma maar doet wat de gebruiker gevraagd heeft, is het wel goed". Het gevolg van een dergelijke aanpak is meestal een extra onderhoudslast.
Hoe bijzonder zijn uw gegevens?
Dat is een vraag die samenhangt met de rol die u ziet voor de IT. Bij de artikelen over strategie op deze site heb ik daar meer over gezegd. Als u IT ziet als een 'enabler' dan is een eigen / uniek informatiemodel een competitief voordeel waar u veel geld mee kunt verdienen. Als u IT ziet als een 'facilitator' kunt u gerust volstaan met het adopteren van het informatiemodel dat uw softwareleverancier impliciet in zijn pakket heeft gebakken. Maar hier zit nogal wat tussen en het loont de moeite om daar intern aandacht aan te besteden. Zo'n activiteit leidt dan tot een Informatiemodel wat bestaat uit een 'Entity Relationship Diagram (ERD)' met een beschrijving van de gegevensgroepen (entiteiten), hun relaties en welk bedrijfsproces de eigenaar en beheerder van die gegevens is.
Voor de meeste organisaties en zeker voor ondernemingen is er sprake van gegevens over de product / marktcombinaties waar men actief op is en gegevens voor het besturen van de organisatie. Het top-level Informatiemodel ziet er dan als volgt uit:
Voor een energie handelsonderneming ziet een dergelijk model er als volgt uit:
Uiteraard zijn beide plaatjes slecht het hoogste niveau van een Informatiemodel. Voor een goede besluitvorming is dit slechts een aanzet. Men tenminste één niveau dieper moeten specificeren voor het inrichten van een relationele database.
In het plaatje hebben wij kleuren gebruikt om 'Information Ownerhip' aan te geven. Een betere manier is de onderstaande 'CRUD matrix' linvullen, met langs de vertikale as de Gegevens objecten, langs de horizontale as de Bedrijfsprocessen en in de cellen de rol met betrekking tot gegevensverwerking:
