Denken Over Data

Mijn naam is Richard Steijn en ik ben dol op data dingen. In deze blog deel ik mijn ideeën, ervaringen, hersenspinsels en wat al niet meer over dit onderwerp.

Bezoek ook eens de website van Vaiper, mijn bedrijf.

Categorie: Business Intelligence

  • Hogere datakwaliteit door het zelfreinigend effect

    Hogere datakwaliteit door het zelfreinigend effect

    We leven in een tijd waarin data enorm belangrijk is. Organisaties buitelen over elkaar heen met de wens om datagedreven te werken. Deze data gebruiken we om de prachtigste dashboards te voeden en om allerlei analyses uit te voeren die tot nieuwe inzichten leiden. Een wet die echter nog altijd geldt, is: Garbage in = Garbage out. We kunnen nog zulke mooie rapporten en analyses maken en er nog zoveel machine learning op loslaten: als de brondata van slechte kwaliteit is, zal het informatieproduct dat je ervan maakt van dezelfde kwaliteit zijn.

    Bij mijn klanten loop ik geregeld tegen data van matige kwaliteit aan. Wat ik vaak waarneem, is dat BI-ontwikkelaars proberen “er toch nog iets van te maken”. In bepaalde eenvoudige gevallen is hier best wat voor te zeggen. Denk bijvoorbeeld aan een veld “Geslacht” dat de waarden M, m, man, V, v en vrouw kan bevatten. Het is duidelijk dat M en m staan voor “Man” en V en v voor “Vrouw”. Een simpele fix zou dan kunnen zijn: M, m en man vertalen naar “Man” en V, v en vrouw vertalen naar “Vrouw”.

    Echter, wanneer een fix minder voor de hand ligt en meer interpretatie en creativiteit eist van de BI-ontwikkelaar, heb ik mijn bedenkingen. Stel dat men een klantenbestand bijhoudt welk type klant het betreft. Het veld Klantcategorie bevat de waarden Premium, Standaard en Budget. Helaas wordt bij het invoeren van nieuwe klanten dit veld regelmatig niet ingevuld. Om, ter wille van een managementdashboard, toch zoveel mogelijk klanten aan een van de drie categorieën toe te wijzen, besluit de BI-ontwikkelaar om dit veld bij ontbrekende waarden in te vullen op basis van de omzet die de klant gemiddeld per jaar genereert.

    Het gevolg van deze benadering is dat in het dashboard iedere klant netjes aan een categorie wordt toegewezen. In het beste geval heeft de ontwikkelaar deze fix met de belanghebbenden besproken, gedocumenteerd en benoemd in het betreffende dashboard. In het slechtste geval verzint de ontwikkelaar op eigen houtje een fix en documenteert het niet. Verder wordt nu de indruk gewekt dat het datakwaliteitsprobleem niet bestaat of verder geen actie behoeft. Hierdoor blijft het werkelijke probleem in de brondata bestaan en zal alleen maar groeien naarmate de tijd verstrijkt. Dit bezwaar geldt overigens ook voor de simpele fix in het eerste voorbeeld.

    Zelfreiniging

    In het volgende gedachtenexperiment gaan we omwille van het verbeteren van de datakwaliteit gebruik gaan maken van het zelfreinigend effect. Dit houdt in dat eindgebruikers van de BI-oplossing zoveel mogelijk “niet gefixte” data te zien krijgen. Het idee is dan dat er mechanismen worden gecreëerd die er voor zorgen dat degenen die de “foute” data hebben ingevoerd, dit zelf corrigeren. Hiervoor moeten feedbackloops gecreëerd worden waarin zowel de eigenaar van de brondata als de gebruikers van hierop gebaseerde informatieproducten zijn opgenomen. Het basisidee is dat datakwaliteitsproblemen juist expliciet duidelijk worden gemaakt aan de eindgebruikers van de BI-oplossing.

    Een zo groot mogelijk draagvlak

    Om het zelfreinigend effect optimaal te laten werken, moet hier vanaf de start van het gebruik van de BI-omgeving aan worden gewerkt. Goodwill van alle medewerkers die de bronsystemen vullen en hun leidinggevenden is noodzakelijk. Hoe krijgen we dit voor elkaar? Dat is een uitdaging. Wat kan helpen, is deze personen in een vroeg stadium bij het project te betrekken. Ze moeten zelf het nut van Business Intelligence inzien, zowel voor de organisatie als voor henzelf.

    Geef iets terug

    Wat volgens mij ook goed zal werken, is om zoveel mogelijk mensen in alle lagen van de organisatie “iets terug te geven” uit het datawarehouse. Op een lager organisatieniveau kan dit in de vorm van handige overzichten en lijsten die niet direct beschikbaar zijn in de systemen waarmee ze dagelijks werken. Op hogere organisatieniveaus kan dit bijvoorbeeld door overzichten op een hoger aggregatieniveau of via een of meer KPI’s in een dashboard. Dit zal het draagvlak vergroten.

    Op deze manier maken we van zoveel mogelijk mensen aan de invoerkant van de bronsystemen tevens eindgebruikers van de BI-omgeving. Op de kwaliteit van de informatie die ze hieruit halen, kunnen ze nu zelf invloed uitoefenen. Men wordt zich op deze manier bewust van de gevolgen van fouten in de invoer. We hopen dan dat men de werkwijze in de toekomst gaat aanpassen om zo fouten te voorkomen.

    Aangeven wat er fout is

    Hoewel we “foute” data niet wegfilteren of corrigeren, geven we wel aan wat er fout aan is. Hiervoor moeten in kaart gebracht hebben welke business rules er gelden m.b.t. het betreffende data item (Voorbeeld: Iedere klant moet ingedeeld worden in een Klantcategorie). Vervolgens kunnen we per business rule gaan vastleggen hoevaak deze geschonden is en waar dit precies het geval is. Dit zou dagelijks in een organisatiebreed datakwaliteitsrapport getoond kunnen worden.

    De bron van de data

    Bij ieder data item, dus ook de als “fout” aangemerkte, wordt opgeslagen wat de herkomst is. Dit kan op verschillende niveaus gedaan worden. Je kunt vastleggen van welk bronsysteem, welke afdeling, eigenaar of misschien zelfs welke medewerker het afkomstig is. Zo is het duidelijk wie er actie dient te ondernemen.

    Voorkom toekomstige fouten

    Probeer in de bronsystemen zaken zo te regelen dat problemen in de toekomst worden voorkomen. Dit kan bijvoorbeeld door al aan invoerkant bepaalde data integriteitseisen af te dwingen.

    Stel een datakwaliteitsbewaker aan

    Maak iemand verantwoordelijk voor het bewaken van de datakwaliteit, en geef deze persoon mandaat om waar nodig actie te ondernemen. Deze persoon kan bijvoorbeeld dataeigenaars aanspreken op datakwaliteitsproblemen en verbeteracties in de bronsystemen initiëren.

    Enkele overwegingen bij deze benadering

    Een speciale categorie binnen het palet aan “foute” data is data die niet ingelezen is in het datawarehouse, doordat er bijvoorbeeld cruciale business keys ontbreken of incompleet zijn. De bedoelde betekenis van dit soort informatie is moeilijk te achterhalen. Dit is typisch data die door specialisten aangepakt moet worden. Het zelfreinigend effect gaat hier dus niet werken.

    Het blijft een uitdaging voor het data BI-team om alle business rules boven water te krijgen. Waarschijnlijk is de lijst aanvankelijk niet compleet en zal deze gaandeweg gaan groeien. Pas als een business rule onderkend is en er een controle mechanisme voor gebouwd is, zal dit resulteren in zichtbare datakwaliteitsproblemen aan de kant van de eindgebruikers van de BI-omgeving.

    Het benoemen van de herkomst van foute data kan ook resulteren in weerstand bij de betrokkenen. Het kan worden opgevat als een soort schandpaal. Toegang tot deze informatie moet zeer beperkt en weloverwogen gegeven moet worden aan de juiste personen. Hoe specifiek je moet zijn in het aanwijzen van de bron, is ook een aandachtspunt.

    En u?

    Hoe gaat uw organisatie om met datakwaliteit?

  • Waarheid in managementinformatie: perspectief is alles

    Waarheid in managementinformatie: perspectief is alles

    Dit is het vervolg op mijn vorige artikel Datakwaliteit en Managementinformatie: De Noodzaak van een Gouden Standaard. Daarin kwam het begrip “single version of the truth” (SVOT) aan bod, waarbij het vooral ging over het kiezen van betrouwbare databronnen en datakwaliteit in de context van een datawarehouseomgeving. In dit artikel ga ik dieper in op de vervolgstap: het produceren van managementinformatie (dashboards, rapportages, KPI’s, …) in een business intelligence (BI) omgeving, ervan uitgaand dat we alle benodigde broninformatie al hebben verzameld en geïntegreerd in een datawarehouse.

    Ook in de BI-context wordt er vaak gesproken over SVOT. Alleen draait het in dit geval om de zoektocht naar een organisatiebrede consensus over de precieze definitie van kengetallen, categorieën en entiteiten binnen de managementinformatie.

    Het bereiken van zo’n consensus is makkelijker gezegd dan gedaan. Zeker als we te maken hebben met veel verschillende gebruikersgroepen, zal er veel overleg nodig zijn om deze heilige graal te vinden. En zoals het een echte heilige graal betaamt, blijft hij waarschijnlijk onvindbaar.

    Laten we het probleem eens illustreren aan de hand van een voorbeeld waarin het begrip Medewerker een rol speelt.

    Een bedrijf heeft een financiële afdeling. Op deze afdeling geldt de overtuiging dat iedereen die op de loonlijst staat, een Medewerker is. Mensen die niet op de loonlijst staan, worden niet als Medewerker beschouwd.

    De afdeling Operations ziet dit anders. Zij beschouwt iedereen die daadwerkelijk werkzaamheden verricht voor het bedrijf als Medewerker, ongeacht of diegene op de loonlijst staat. Denk bijvoorbeeld aan ingehuurde consultants, freelancers of externe specialisten die tijdelijk betrokken zijn bij projecten. Deze mensen registreren uren, maken gebruik van bedrijfsmiddelen en hebben toegang tot interne systemen.

    De IT-afdeling hanteert op haar beurt weer een iets andere definitie. In aanvulling op de definitie van Operations beschouwen zij ook stagiairs en werkstudenten als Medewerkers, omdat zij toegang nodig hebben tot bedrijfsapplicaties en systemen.

    Hier zien we drie verschillende definities van het begrip Medewerker binnen dezelfde organisatie. Net als in mijn vorige artikel rijst ook hier weer de vraag: Wat is waar?

    Het antwoord is simpel: alle drie zijn natuurlijk waar. Het hangt er maar vanaf vanuit welk perspectief je kijkt. Wil je bijvoorbeeld de gemiddelde loonkosten per werknemer berekenen, dan is de definitie van de financiële afdeling bruikbaar. Wil je echter inzicht in de totale werkdruk binnen het bedrijf, dan zijn de definities van Operations en IT relevanter.

    Elke afdeling heeft waarschijnlijk zijn eigen definitie en zal die niet zomaar veranderen – en dat hoeft ook niet. Binnen hun eigen werkgebied zijn deze definities nuttig en dus prima te verdedigen. Maar als je managementinformatie wilt maken die voor de hele organisatie geldt, kunnen de definities op dat niveau anders zijn dan die van de afzonderlijke afdelingen. Andere context andere definities. Dit betekent dat binnen een organisatie meerdere definities van hetzelfde begrip naast elkaar kunnen bestaan. Een BI-omgeving moet al deze definities kunnen faciliteren, zolang het voor de gebruikers van managementinformatie maar helder is welke definitie wordt gehanteerd.

    Een BI-omgeving moet aansluiten bij de bestaande werkprocessen en mag nooit dicteren hoe de betrokken organisatieonderdelen moeten werken of communiceren. Er moet ruimte zijn voor verschillende zienswijzen die op hun eigen plek in de organisatie gewoon hout snijden.

    Ik ben dan ook, voor wat betreft definities, geen voorstander van het nastreven van een organisatiebrede “single version of the truth” want: “The truth is in the eye of the beholder.”

    PS

    Als u zich afvraagt welk van de kunstwerken bovenaan dit artikel “De Schreeuw” van Munch is, dan is het antwoord: allemaal, behalve de vierde van links. Munch maakte meerdere versies van dit werk in verf, lithografie en pastel. En die vierde? Die heb ik zelf onherstelbaar ‘verbeterd’. 😉

  • Datakwaliteit en Managementinformatie: De Noodzaak van een Gouden Standaard

    Datakwaliteit en Managementinformatie: De Noodzaak van een Gouden Standaard

    In iedere organisatie van enige omvang speelt het uitwisselen van informatie tussen de verschillende organisatieonderdelen een belangrijke rol. Het komt dan ook geregeld voor dat er van bepaalde gegevens verschillende versies circuleren. Stel je voor: een bedrijf slaat alle personeelsgegevens op in een centraal HRM-systeem. Daarnaast gebruikt elke afdeling een eigen, op zichzelf staand systeem voor specifieke operationele processen, zoals projectmanagement, klantrelaties of salarisadministratie. Ook hierin worden personeelsgegevens opgeslagen die oorspronkelijk zijn overgenomen uit het centrale HRM-systeem. Vanaf dat moment kunnen in zowel het HRM-systeem als in de afdelingsspecifieke systemen onafhankelijk van elkaar wijzigingen worden aangebracht. Dit kan ertoe leiden dat er in verschillende systemen tegenstrijdige informatie over een medewerker is opgeslagen. Dit voorbeeld is slechts het topje van de ijsberg. Soortgelijke problemen doen zich bijvoorbeeld voor bij klantgegevens die in CRM-systemen, facturatiesystemen en helpdesksystemen worden beheerd. Ook hier kan dit leiden tot inconsistenties. En wat te denken van productinformatie die zowel in in de productcatalogus, het warehouse management systeem en het ecommerce systeem staat?

    Gegeven deze verschillende registraties van hetzelfde ding, rijst nu de vraag: Wat is waar? Zolang de dagelijkse bedrijfsprocessen maar soepel lijken te verlopen, lijkt deze vraag niet zo belangrijk. Echter wanneer we van onze operationele data managementinformatie willen afleiden zullen we deze vraag moeten gaan stellen. Dit is de beruchte zoektocht naar de zogenaamde “Single version of the truth”. De heilige graal.

    Managementinformatie is natuurlijk geen doel op zich. Het is slechts een middel dat kan bijdragen aan het nemen van betere strategische beslissingen, het nog efficienter maken van de bedrijfsvoering, verbeterde klanttevredenheid, etc. Hoe voorkomen we dat er onduidelijkheid bestaat over welke data we moeten gebruiken voor het genereren van managementinformatie?

    Een antwoord hierop is Master Data Management (MDM). Het komt er dan op neer dat van alle niet transactionele informatie er een centrale administratie wordt aangewezen die als leidend beschouwd wordt binnen alle werkprocessen in de organisatie. Het decentraal wijzigen van gegevens die onder het MDM regime vallen is dan dus vloeken in de kerk. Dit betekent uiteraard wel dat alle werkprocessen en geautomatiseerde systemen hierop geënt moeten zijn. Dit is geen sinecure. Teruggrijpend naar de bovenstaande voorbeelden moet er dan MDM worden toegepast op de entiteiten Medewerker, Klant en Product. Als er gekozen is voor een datawarehouse als middel voor het verkrijgen van managementinformatie is het laden ervan door MDM een stuk eenvoudiger geworden. Transactionele data uit de verschillende bronsystemen kan dan relatief eenvoudig aan de entiteiten gekoppeld worden die onder MDM vallen.

    Bij het ontbreken van MDM “kiezen” veel organisaties noodgedwongen voor een alternatief. Namelijk door voor het verzamelen van brondata voor managementinformatie te kiezen voor een bronsysteem dat als leidend gezien moet worden. Deze leidende data (in deze context wordt nog wel eens gesproken van het “Golden Record”) wordt dan eventueel nog aangevuld met data uit niet leidende bronnen. Dit levert in de praktijk allerlei uitdagingen op met betrekking tot dataintegratie oftewel het aan elkaar koppelen van data uit verschillende bronsystemen. Vaak moet dan dat de trukendoos open om toch maar zoveel mogelijk data wel te kunnen koppelen. Tijdens dit dataintegratieproces zal naar alle waarschijnlijkheid bepaalde data afkomstig uit niet leidende systemen, genegeerd worden. In het beste geval zijn alle betrokkenen (van eigenaren van de bronsystemen tot aan eindgebruikers van de managementinformatie) het eens over de gekozen aanpak en is deze aanpak goed gedocumenteerd. In veel gevallen echter, zullen slechts weinigen kunnen overzien wat de gevolgen zijn van de toegepaste trucs voor de kwaliteit van de managementinformatie die hieruit voortkomt. Waarschijnlijk zijn dit alleen die personen die verantwoordelijk zijn voor de technische realisatie ervan. De verantwoordelijkheid voor datakwaliteit wordt op deze manier bij de verkeerde personen gelegd. Hoe dan ook: deze praktijk komt zeer veel voor.

    Als we eenmaal zover zijn dat de we brondata bij elkaar hebben gezocht, moet er nog managementinformatie van gemaakt worden.  In een volgend artikel ga ik hier wat dieper op in.

  • Managementinformatie en gedragsbeïnvloeding

    Managementinformatie en gedragsbeïnvloeding

    In een vorige post ben ik ingegaan op hoe een leidinggevende gebruik kan maken van managementinformatie om het gedrag van zijn mensen te beïnvloeden en zo werkprocessen bij te sturen. Naast het actief sturen door managers is er echter nog een andere manier waarop managementinformatie kan worden aangewend om gedrag te beïnvloeden. In deze post wil ik daar wat dieper op ingaan.

    Er bestaat namelijk een fenomeen genaamd ‘Feedback Loop’. De kerngedachte hierachter is de volgende: Wanneer iemand expliciet bewust wordt gemaakt van hun eigen gedrag en daarnaast van de normen die gelden met betrekking tot dat gedrag, dan zal hij geneigd zijn, zijn gedrag aanpassen richting de norm.

    Een voor iedereen welbekende toepassing van dit principe zijn de digitale snelheidsborden die je in Nederland overal langs de weg ziet staan. Zo’n bord geeft je enkel terugkoppeling over je actuele rijsnelheid zonder daar het predicaat goed of slecht op te plakken. Vaak staat er in de buurt wel een ander bord met de maximaal toegestane snelheid. Trek zelf je conclusies. Door middel van experimenten is aangetoond dat deze borden er voor zorgen dat er inderdaad significant langzamer gereden wordt. Dus enkel door informatie die op zichzelf al lang bij de bestuurder bekend is, in een andere context te plaatsen, past de bestuurder zijn gedrag aan. Let wel: we hebben het hier over gemiddelden. Het zal heus wel voorkomen dat een individuele bestuurder zich niets aantrekt van de feedback loop. Maar algemeen gesproken is het effect er wel degelijk.

    De werking van de feedback loop in verschillende toepassingsgebieden is al decenia bekend. In de jaren 60 is hier al uitgebreid onderzoek naar gedaan door o.a. Albert Bandura. Sinds die tijd zijn tal van praktische toepassingen bekend, waarvan het bovenstaande een voorbeeld is.

    Het toepassen van de feedback loop als stuurmiddel vind ik interessant omdat hier geen sprake is van gedragsaanpassing door straf of beloning maar door zelfregulatie. Het lijkt mij dat dit principe prima kan worden toepast op de werkvloer. Dit in het bijzonder bij organisaties waarin de medewerkers wat minder strak en hiërarchisch worden aangestuurd en waar veel ruimte is voor eigen initiatieven. In Nederland is dit type organisaties ruim vertegenwoordigd.

    Dan rijst vervolgens de praktische vraag: Maar hoe dan? Ik zie het als volgt: Managementinformatie hoeft niet alleen voor managers te zijn. Ook voor uitvoerende medewerkers kan dit nuttig zijn en beschikbaar gemaakt worden. We spreken dan van operational BI.

    Daarbij verwacht ik dat in de nabije toekomst steeds meer organisaties mobile apps zullen gaan verstrekken aan hun medewerkers om allerhande zaken op afstand te kunnen doen. Met de opkomst van Mobile BI is er een perfect platform aan het ontstaan om de juiste feedback bij de juiste persoon te brengen.

    Ter illustratie even een voorbeeld:

    Een consultancybureau geeft stelt aan haar medewerkers een mobile app ter beschikking waarmee zij op eenvoudige wijze kunnen vastleggen wanneer ze voor welke klant uren gemaakt hebben. Binnen dit bureau geldt de norm dat uiterlijk iedere maandag om 17:00 uur de gemaakte uren voor de afgelopen week moeten zijn ingevoerd. Deze mobile app heeft als nevenfunctie dat, als hij niet gebruikt wordt, er enerzijds in het scherm van het mobile device, de datum waarop de laatste uren aaneengesloten geregistreerd zijn (actueel gedrag) getoond wordt. Anderzijds wordt de datum getoond die de periode begrenst waarvoor geldt dat in ieder geval alle uren geregistreerd moeten zijn. Dit alles zonder er een alarmsignaal aan te koppelen, als de medewerker eens te laat is.

    En nu afwachten of de feedback loop zijn uitwerking heeft…

  • De BI as a service black box

    De BI as a service black box

    Uitbesteden is in.

    Tegenwoordig kunnen we op ICT gebied ongeveer alles uitbesteden waarvan we vinden dat we er zelf niet goed in zijn of geen energie in willen stoppen. In plaats van dure licenties en hardware aan te schaffen en te investeren in kennis om bepaalde software te kunnen beheren en ontwikkelen, kunnen we nu voor een maandbedrag gebruik maken van diensten en software van derden. Software-as-a-service (SAAS) dus. Door de keuze voor een SAAS oplossing worden we ontzorgt en kunnen we ons volledig richten op die dingen we wèl goed in zijn.

    Een speciaal geval van een SAAS oplossing is BI-as-a-service (BIAAS). De gebruiker hoeft zelf geen BI tools te installeren maar benadert deze doorgaans via de web browser. De BI tool bevindt zich vaak ergens in ‘the cloud’ en haalt haar data uit een data warehouse waarvan de ontwikkeling en het beheer ook is uitbesteed. Het data warehouse en de rompslomp eromheen, bevindt zich buiten het zicht van de afnemer van BIAAS. Het enige dat hij er eventueel merkt is dat er op gezette tijden data aan de operationele systemen die hij in gebruik heeft, wordt onttrokken om in het data warehouse te laden.

    Dat BIAAS de nodige voordelen biedt moge duidelijk zijn. Toch zou een afnemer van BIAAS er goed aan doen om er voor waken dat de BI omgeving te veel een black box wordt. Voor zover het zuiver technische aangelegenheden betreft is het prima dat de afnemer hier niets van mee krijgt. Business intelligence is echter niet alleen een technische aangelegenheid. Het onderliggende data warehouse is niet los te koppelen van degene die het gebruikt. Het is niet inwisselbaar zoals software voor tekstverwerking, spreadsheets, projectplanning of e-mail. Managementinformatie is per definitie gebaseerd op data die heel bedrijfseigen is.

    Het is belangrijk dat een bedrijf dat BIAAS afneemt in grote lijnen op de hoogte is van het data acquisitieproces die de BI toepassing van informatie voorziet. Men moet weten hoe deze data wordt schoongemaakt, getransformeerd en geïntegreerd tijdens het laden van het data warehouse. Welke data wordt beschouwd als ’onbruikbaar’ en wordt niet geladen. Hoe wordt data ‘verrijkt’ en ‘verbeterd’ en waarom? In dit soort zaken moet men inzicht hebben, om in staat te zijn de managementinformatie die aan het data warehouse wordt onttrokken op waarde te schatten.

    En stel je voor dat je als BIAAS klant in de toekomst toch weer je BI omgeving zelf in beheer wilt nemen of je wilt overstappen naar een andere aanbieder van BIAAS. Hoe ga je te werk als je helemaal niets weet van wat er zich achter de rookgordijnen van the cloud afspeelt?

    Laatst was ik op het Data Vault Automation Seminar waar een van de sprekers het had over ‘knowledge partnership’. Het bedrijf waarvoor de spreker werkte, een ICT dienstverlener, bouwde in opdracht BI oplossingen voor haar klanten. Deze BI oplossingen werden uiteindelijk door de klant zelf in beheer genomen. In de eerste fase nam de dienstverlener 100% het voortouw, in daaropvolgende fasen werd onder begeleiding de klant steeds meer betrokken bij het ontwikkelproces. Net zolang totdat de klant al het werk zelf kon doen. Al doende werd op deze manier de klant voorzien van de kennis hij nodig om op eigen benen te staan aangaande het beheer, het onderhoud en de doorontwikkeling van de BI oplossing. De dienstverlener en haar klant gingen een knowledge partnership aan. Nu ging het hier niet om een BIAAS oplossing, maar de gedachte sprak mij erg aan. Openheid versus geslotenheid. Deze klanten kloppen in de toekomst heus wel weer aan bij deze dienstverlener, juist door deze openheid.

    Een bedrijf dat op zoek is naar een BIAAS oplossing zou er goed aan doen een aanbieder te zoeken die met hen een knowledge partnership wil aangaan. De focus moet hier dan niet liggen op de techniek, want die moet op de achtergrond blijven. De focus zou juist moeten liggen op dat deel van de oplossing die specifiek is voor de afnemer van de service: de data. Zo kan voorkomen worden dat de BIAAS oplossing een black box wordt.

  • Managementinformatie: Wat is waar? (II)

    Managementinformatie: Wat is waar? (II)

    In deze post ga ik dieper in op het produceren van managementinformatie in een business intelligence (BI) omgeving, er vanuit gaand dat we alle benodigde broninformatie reeds bij elkaar hebben gezocht. Deze eerste stap heb ik reeds eerder beschreven.

    Als ik het heb over managementinformatie dan denk ik aan beknopte overzichten met gemiddelden en kengetallen op dashboards en dergelijke. Kortom informatie waarop een organisatie gestuurd kan worden. In data warehouse land wordt in dit verband vaak gesproken over de “single version of the truth”. Vaak wordt dit uitgelegd als: Organisatiebreed moet er consensus zijn over de definitie van alle begrippen (kengetallen, categorieën, ..) binnen de managementinformatie. Dit is makkelijker gezegd dan gedaan. Zeker als we te maken hebben met een grote schare aan eindgebruikers afkomstig uit verschillende delen van de organisatie, zal er een hoop overleg nodig zijn om deze heilige graal te vinden. En zoals een goede heilige graal betaamd, blijft hij waarschijnlijk onvindbaar.

    Laten we het probleem eens illustreren aan de hand van een voorbeeld waarin het begrip Medewerker een rol speelt.

    Een universiteit heeft een financiële afdeling. Op deze afdeling heerst de overtuiging dat iedereen die op de loonlijst staat, een Medewerker is. Mensen die niet op de loonlijst staan, zijn geen Medewerker.

    Faculteit A ziet dit anders. Zij beschouwt alle niet-studenten die daadwerkelijk werk verrichten voor de faculteit als Medewerkers. Immers, deze mensen schrijven uren, worden ingepland en leggen beslag op bepaalde ruimtes en hulpmiddelen. Zo komt het voor dat onderzoekers afkomstig van andere onderzoeksinstituten werkzaam zijn binnen de faculteit. Verder zijn er soms gastdocenten die een college verzorgen. Deze mensen staan niet op de loonlijst maar verrichten wel degelijk werkzaamheden.

    Faculteit B hanteert een iets andere definitie. Zij beschouwd in aanvulling op de definitie van Faculteit A ook studenten met een student-assistentschap als Medewerker.

    We hebben hier drie verschillende definities van het begrip Medewerker binnen een organisatie. Net als in mijn vorige blogpost rijst ook hier weer de vraag: Wat is waar?

    Het antwoord is simpel: Alle drie zijn natuurlijk waar. Het hangt er maar vanaf welk gezichtspunt je kiest. Als je wilt uitrekenen wat de student/docent ratio is op een bepaald moment, moet je eerst weten welke vraag je hiermee wilt beantwoorden. Wil je de gemiddelde loonkosten in beeld brengen die gemoeid zijn met het opleiden van een student, dan kun je uit de voeten met de definitie van het begrip Medewerker van de financiële afdeling. Ben je geïnteresseerd in het gemiddeld aantal uren inspanning dat het opleiden van een student kost, dan is de definitie van faculteit A of B wellicht nuttiger.

    De faculteiten zullen mogelijk niet snel bereid zijn de definitie van het begrip Medewerker over te nemen van de financiële afdeling en vice versa. Alle drie de definities hebben echter bestaansrecht. Immers zowel het werkprocessen op de financiële afdeling als de werkprocessen op de faculteiten werken (hopelijk) naar behoren. Je zou kunnen zeggen dat ieder organisatieonderdeel/bedrijfsproces in principe zijn eigen definitie kan hebben van een bepaald begrip en een BI omgeving moet al deze definities faciliteren. Dit hoeft helemaal geen probleem te zijn zolang het voor de eindgebruiker van managementinformatie maar steeds duidelijk is welke definitie gehanteerd wordt.

    Een bijzonder geval vormt die managementinformatie die organisatiebreed en dus afdeling overstijgend is. Dit is typisch het gezichtspunt van het hoger management. Om er hier zeker van te zijn dat we geen appels met peren gaan vergelijken is afstemming nodig met de verschillende organisatieonderdelen waarover we management informatie willen produceren.

    Stel, voortbouwend op het bovengenoemde voorbeeld, dat het College van Bestuur van iedere faculteit een beeld wil hebben van de gemiddelde kosten die worden gespendeerd aan het opleiden van een student per collegejaar. Hiervoor moeten onder anderen de volgende vragen beantwoorden:

    1. In hoeverre kunnen gewerkte uren van Medewerkers worden toegeschreven aan een bepaalde faculteit? Er zijn namelijk Medewerkers met meerdere deeltijdaanstellingen.
    2. Welke kosten kunnen gekoppeld worden aan gewerkte uren van Medewerkers? Denk aan loonkosten en allerhande geldstromen.
    3. Voor welk deel moeten we kosten voor het opleiden van een student toeschrijven aan een bepaalde faculteit? Denk hier aan studenten die cursussen volgen bij verschillende faculteiten.

    Op zich zijn dit stuk voor stuk lastige vragen die ik hier niet ga proberen te beantwoorden. Waar het om gaat is de definitie van het begrip Medewerker in dit verband. Het is duidelijk dat we met de definitie van het begrip Medewerker van de financiële afdeling hier niet uit de voeten kunnen. We kiezen hier de definitie van Faculteit B (dus ook student-assistenten worden als Medewerker beschouwd).

    Vervolgens is het zaak dat dit wordt afgestemd met alle faculteiten. De faculteiten hoeven de definitie van de begrippen die het College van Bestuur hanteert in principe niet over te nemen. Het gaat er hier alleen om dat we voor alle faculteiten inzicht krijgen in de ons ter beschikking staande brondata met betrekking tot Medewerkers. Hiervoor is input van de faculteiten nodig. Het zo verworven inzicht stelt ons technisch in staat om hieruit de management informatie zodanig te construeren dat deze voldoet aan de definities die het College van Bestuur hanteert. De faculteiten kunnen met de brondata op hun managementniveau nog altijd hun eigen ding mee doen, natuurlijk wel met het besef dat er op een hoger gelegen niveau op een (iets) andere manier naar gekeken wordt.

    Ik realiseer mij dat deze zienswijze niet door iedereen wordt aangehangen. In mijn optiek moet een BI omgeving gewoon aansluiten bij de bestaande werkprocessen. De BI omgeving moet nooit dicteren hoe de betrokken organisatieonderdelen moeten werken of communiceren. Er moet ruimte zijn voor verschillende zienswijzen. Hooguit kan de BI omgeving doordat zij inzicht geeft in de verschillen in interpretatie van bepaalde begrippen de aanzet zijn voor een “verbeterproces” om de definitie van begrippen meer op een lijn te krijgen door de organisatie heen.

    Ik ben dan ook een tegenstander van het nastreven van een organisatiebrede “single version of the truth” want: “The truth is in the eye of the beholder.”

  • Managementinformatie: Wat is waar?

    Managementinformatie: Wat is waar?

    In iedere organisatie van enige omvang speelt het uitwisselen van informatie een belangrijke rol.  Het komt dan ook geregeld voor dat er van bepaalde informatie verschillende versies circuleren. Stel je voor: Een hogeschool slaat van alle ingeschreven studenten informatie op in een centraal inschrijfsysteem. Daarnaast gebruikt iedere faculteit haar eigen op zichzelf staande studievolgsysteem (voor de niet ingewijden: een systeem waarin studieresultaten worden bijgehouden).  Ook hierin is informatie over studenten opgeslagen die oorspronkelijk bij instroom is overgenomen van het centrale inschrijfsysteem. Zowel in het inschrijfsysteem, als in het studievolgsysteem kunnen vanaf dat moment onafhankelijk van elkaar wijzigingen worden aangebracht op de studentgegevens. Het is dientengevolge heel goed mogelijk dat in beide systemen tegenstrijdige informatie rondom een bepaalde student is opgeslagen. Dit voorbeeld is slechts het topje van de ijsberg. Soortgelijke problemen doen zich voor bij medewerkers die zowel in het HRM systeem, het financiële systeem en soms ook in het studievolgsysteem (docenten) staan opgeslagen. En nog een (uit eigen ervaring): Als studenten die ingeschreven staan bij faculteit A een cursus volgen bij faculteit B dan wordt de betreffende cursus in het studievolgsysteem van beide faculteiten opgenomen.

    En dan rijst nu de vraag: Wat is waar? Je zou kunnen zeggen dat dit op zich geen interessante vraag is. De student kan immers netjes zijn studie doorlopen en daar is het ons toch allemaal om te doen. Dit is op zich waar. Het punt is alleen dat wanneer we managementinformatie willen gaan afleiden, we voor een dilemma staan. Deze managementinformatie is geen doel op zich maar speelt een belangrijke rol in de kwaliteitscyclus (en uiteindelijk ook in het accreditatieproces). Als de juiste mensen op het juiste moment kunnen beschikken over de juiste managementinformatie, kunnen er beter gestuurd worden.  Misschien doorloopt de student zijn studie dan wel wat sneller, of sluit zijn kennis beter aan op de arbeidsmarkt, om maar eens wat te noemen.

    Hoe voorkomen we dat er onduidelijkheid bestaat over welke informatie we moeten gebruiken voor het afleiden van managementinformatie?

    Een antwoord hierop is Master Data Management (MDM). Het komt er dan op neer dat van alle niet transactionele informatie er een centrale administratie wordt aangewezen die als leidend beschouwd wordt binnen alle werkprocessen in de organisatie. Het decentraal wijzigen van gegevens die onder het MDM regime vallen is dan dus vloeken in de kerk. Dit betekent uiteraard wel dat alle werkprocessen en geautomatiseerde systemen hierop geënt moeten zijn. Dit is geen sinecure. Teruggrijpend naar de bovenstaande voorbeelden moet er dan MDM worden toegepast op de entiteiten Student, Medewerker en Cursus. Als er gekozen is voor een data warehouse als middel voor het verkrijgen van managementinformatie is het laden ervan door MDM een stuk eenvoudiger geworden. Transactionele data uit de verschillende bronsystemen kan dan relatief eenvoudig aan de entiteiten gekoppeld worden die onder MDM vallen.

    Veel organisaties “kiezen” noodgedwongen voor een alternatief voor MDM. Namelijk door voor het verzamelen van brondata voor managementinformatie te kiezen voor een bronsysteem dat als leidend gezien moet worden. Deze leidende data wordt dan eventueel nog aangevuld met data uit niet leidende bronnen. Dit levert in de praktijk bijna per definitie problemen op met betrekking tot het aan elkaar koppelen van data uit verschillende bronsystemen. Het kan in dat geval haast niet anders dan dat de trukendoos open moet om toch maar zoveel mogelijk data wel te kunnen koppelen. Tijdens dit koppelproces zal naar alle waarschijnlijkheid bepaalde data afkomstig uit niet leidende systemen, genegeerd worden. In het beste geval zijn alle betrokkenen (van eigenaren van de bronsystemen tot aan eindgebruikers van de managementinformatie) het eens over de gekozen aanpak. Maar uiteindelijk zullen slechts weinigen kunnen overzien wat de gevolgen zijn van de toegepaste trucs voor de kwaliteit van de managementinformatie die hieruit voortkomt. Waarschijnlijk zijn dit alleen die personen die verantwoordelijk zijn voor de technische realisatie ervan. De verantwoordelijkheid voor datakwaliteit wordt op deze manier bij de verkeerde personen gelegd. Hoe dan ook: deze praktijk komt zeer veel voor.

    Bij het ontbreken van MDM pleit ik ervoor om in ieder geval alle brondata ‘as is’ te bewaren met een tijdsstempel. Namelijk het is best mogelijk dat we bijvoorbeeld door voortschrijdend inzicht bedenken dat het koppelen van data uit verschillende bronnen toch anders moet verlopen. Als we data historisch hebben bewaard, kunnen we met terugwerkende kracht deze nieuwe manier van koppelen alsnog gaan uitvoeren. Een data warehouse ingericht volgens principes als Data Vault  en Anchor Modelling is hier heel geschikt voor.

    We zijn nu op de helft. Als we eenmaal zover zijn dat de we brondata bij elkaar hebben gezocht, moet er nog managementinformatie van gemaakt worden.  In de volgende blogpost ga ik hier wat dieper op in.