In de praktijk worden veel BI oplossingen vaak gebouwd n.a.v. een concrete vraag waarop het liefst snel een antwoord moet komen. In interactie met de toekomstige gebruikers komt het rapport dan tot stand.  Tijdens het bouwen worden ad hoc de problemen opgelost die zich aandienen, bijvoorbeeld op het vlak van datakwaliteit. In het beste geval documenteert de BI specialist het hoe en het waarom van de ad hoc oplossingen. Vaak gebeurt dit ook niet.
Als een oplossing in nauwe samenwerking tussen de gebruiker en ontwikkelaar  tot stand komt, is de kans groot dat het eindresultaat voldoet in de behoefte van de gebruiker en heeft deze vertrouwen in de stuurinformatie die het oplevert.
De tijd schrijdt echter voort en mensen veranderen van functie binnen de organisatie of verlaten de organisatie voor een andere baan.  Gevolg is dan dat de BI oplossing nieuwe gebruikers krijgt. Deze gebruikers hebben geen  kennis over het ontstaan van het rapport en de keuzes die er gemaakt zijn. Als de BI oplossing dan niet of niet voldoende gedocumenteerd is, is de kans groot dat men de betekenis ervan niet meer goed kan duiden. Er komt dan een moment waarop men zich zal afvragen: welke conclusies kan ik wel, en welke kan ik niet uit het rapport trekken? Wanneer dit soort twijfel ontstaat bij de gebruiker,  loopt het leven van het BI oplossing op zijn einde. Het kan dan in onbruik raken of, erger nog: het wordt wel gebruikt maar fout geïnterpreteerd, zodat de verkeerde beslissingen worden genomen.
Het is dus van “levensbelang” voor een BI oplossing dat kennis over de herkomst van de cijfers behalve in de hoofden van zij de betrokken zijn bij de totstandkoming ervan goed geborgd wordt.
Te denken valt aan het vastleggen van de volgende punten:

• Een beschrijvingen van wat de aanleiding was om de BI oplossing te maken. Per onderdeel  (rapport, stuurgetal, …) een beschrijving van welke vragen er mee beantwoord kunnen worden.
• Definities van concepten:  Een zo precies mogelijke beschrijving op functioneel niveau van de concepten (entiteiten, relaties, kengetallen) die een rol spelen binnen de BI oplossing. Bijvoorbeeld: Een actuele klant is een persoon of instantie die binnen een periode van 2 jaar voorafgaand aan een peildatum tot aan de peildatum een factuur heeft ontvangen.
• Operationalisatie van de concepten:  Een zo precies mogelijke beschrijving  hoe de voor het concept data bij elkaar wordt gezocht binnen de bronsystemen, hoe deze wordt bewerkt of gefilterd.
• Historie: Hoe wordt omgesprongen met historische data?  Is het mogelijk eerder gemaakte rapportages exact te reproduceren of wordt data overschreven?
• Laadmomenten:  Wanneer is welke data in de operationele systemen beschikbaar in de BI oplossing?
• Onderhoudsmomenten definiëren: Het identificeren van situaties die impact hebben op de BI oplossing. Bijvoorbeeld: Als er nieuwe producten geïntroduceerd en in het kader van een BI rapportage is worden deze producten ingedeeld in klassen, dan moet deze klassenindeling worden bijgewerkt.

Ter afsluiting nog een tip: Documentatie is niemands hobby. Zeker als het achteraf nog moet gebeuren, is de verleiding groot om dit tot een minimum te beperken. Bedenk dat bepaalde schrijfactiviteiten al tijdens het ontwikkeltraject gestart kunnen worden.  Bijvoorbeeld het beschrijven van de aanleiding en de concepten. Dit kan ook zeer verhelderend werken in de communicatie met de toekomstige gebruiker…

 Laat ik beginnen met het schetsen van een scenario dat menigeen bekend zal voorkomen. Een jonge organisatie, is ter ondersteuning van haar bedrijfsprocessen ooit begonnen met het bouwen van een eigen operationeel systeem. Dit systeem is samen met de organisatie meegegroeid. Wat ooit klein en overzichtelijk begon, is in de loop der tijd uitgegroeid tot een groot en complex systeem tjokvol met kennis die vitaal is voor het functioneren van de organisatie. In de loop der tijd hebben er verscheidene ontwikkelaars aan gewerkt. Deze zijn gekomen en gegaan met in hun hoofd belangrijke kennis over hoe het systeem werkt en hoe het met data omspringt. Er is nooit veel gedaan aan kennisborging. De focus heeft altijd vooral gelegen op het snel inspelen op nieuwe ontwikkelingen en het zo goed mogelijk bedienen van klanten. Zo nu en dan was daarvoor een snelle praktische (lees quick en dirty) oplossing nodig. Het systeem is keer op keer verder uitgebreid om aan de veranderende eisen van de business te kunnen voldoen. Gevolg is dat inmiddels niemand meer het overzicht heeft van hoe het systeem in elkaar zit. Dit maakt het maken van aanpassingen steeds lastiger.

Ook is het niet al te best gesteld met de datakwaliteit. Dit alles komt pijnlijk duidelijk naar voren nu men managementinformatie wil gaan onttrekken aan de data in het systeem. Hoe kan dit ontstaan? Een verklaring zou kunnen zijn dat in het begin toen de organisatie nog klein en overzichtelijk was er nog geen behoefte was aan een dichtgetimmerd systeem dat data integriteit  afdwong. Data ging toen nog niet door vele handen zoals nu en er was overzicht. Het was belangrijker dat het systeem flexibel en open was zodat snel kon worden ingespeeld op de behoeften van de klant.

Inmiddels is de organisatie gegroeid en komt men erachter hoe afhankelijk men eigenlijk is geworden van dit systeem. Jarenlange ervaringen met klanten en de markt liggen er op een of andere manier in vastgelegd. De organisatie beseft dat er iets moet gebeuren. Maar wat? Hieronder volgen enkele tips die helpen grip te krijgen op deze situatie.

Tip: Weet wat je hebt

Allereerst moeten we weten wat we hebben. Het aanleggen van een data dictionary is een goede eerste stap. Ga op tabel en veldniveau beschrijven wat de functie ervan is. Deze informatie zal her en der uit de organisatie bij elkaar moeten worden geschraapt en op een centrale plek, de data dictionary worden vastgelegd.

Tip: Stel definities op

Kijk naar de business en identificeer de concepten (entiteiten) waar het om draait. Beschrijf vervolgens exact hoe deze concepten mappen met data in het systeem. Voorbeeld: Een actief abonnement bestaat uit een record in de tabel tbl_abonnement waarvan het veld einddatum leeg is. Dit record is via het veld relatie_id gekoppeld aan een record in de tabel tbl_relatie dat weer aan een record uit de tabel tbl_adres gekoppeld is via het veld relatie_id. Doe dit voor alle concepten.

Tip: Maak zaken telbaar.

Nu we definities hebben opgesteld van de belangrijkste concepten kunnen we als volgende stap de regels opstellen over welke dataitems wel en welke niet samen mogen gaan. Deze regels (ik noem ze ook wel declaratieve business rules) stellen we op in termen van de eerder genoemde conceptdefinities.  Vertaal deze regels naar concrete controle query’s die tellen hoe vaak (en welke) er verboden data combinaties in de database voorkomen. We hebben nu een manier om ‘vervuiling’ te meten.  Wellicht hebben we nu ook een aanknopingspunt op basis waarvan kan worden berekend hoeveel omzet er gemoeid is met deze vervuiling. Dit kan dan weer gebruikt worden voor het onderbouwen van een business case voor het verbeteren van de datakwaliteit.

Vervolgens moeten er stappen worden genomen om de datakwaliteit te verbeteren. Enkele tips:

Tip: Start een verbetercyclus

Een “big bang” aanpak waarin alle datakwaliteitsissues ineens worden opgelost is doorgaans geen haalbare optie. Dit is zeker het geval als het systeem nog volop in gebruik is. Het is dan beter kleine stapjes vooruit te maken. Start daarom een cyclus waarin de eerder genoemde controlequery’s bijvoorbeeld maandelijks worden uitgevoerd om zo doorlopend zicht op de stand van zaken te houden. Bedenk daarnaast verbeteracties die er op gericht zijn het bestaande aantal foute dataitems omlaag te brengen. Deze verbeteracties kunnen eveneens periodiek worden uitgevoerd worden.  Als de tijd verstrijkt, is het heel goed mogelijk dat we door voortschrijdend inzicht onze set controlequery’s of verbeteracties nog verder kunnen uitbreiden. Verwerk deze ook in de verbetercyclus.

 Tip: Maak de organisatie bewust

Door het resultaat van de verbetercyclus te delen met de organisatie, kan gewerkt worden hogere mate van kwaliteitsbewustzijn onder de medewerkers. Betrek medewerkers uit verschillende plekken in de organisatie bij het verbeterproject. Maak bij zoveel mogelijk medewerkers inzichtelijk dat de ondernomen acties ook daadwerkelijk hun vruchten afwerpen. Maak bijvoorbeeld een datakwaliteitsmonitor die door iedereen te bekijken is.

Om te voorkomen dat we blijven dweilen met de kraan open, moeten er maatregelen genomen worden om te voorkomen dat hetzelfde probleem in de toekomst weer ontstaat. Enkele tips:

Tip: Ruim op

Velden die in onbruik zijn geraakt moeten worden verwijderd uit het systeem. Weersta de neiging om ‘voor de zekerheid’ oude datastructuren te behouden want ‘wie weet wat er dan omvalt’.

Tip: Los zaken structureel op

Idealen zijn prachtig maar als we naar de werkelijkheid kijken is het soms nodig snel te schakelen. Bijvoorbeeld om een nieuw product eerder dan de concurrent in de markt te zetten. Soms beweegt de markt sneller dan een ontwikkelteam kan bijhouden. In dit soort gevallen wordt vaak gekozen voor een quick en dirty oplossing. Mocht dit nodig zijn, neem dan nadien altijd de tijd om deze snelle oplossing om te zetten in een degelijke structurele oplossing.

Tip: Bewaak business rules geautomatiseerd.

Vervuiling ontstaat vaak doordat data integriteit en declaratieve business rules niet centraal of zelfs in het geheel niet worden afgedwongen. Moderne relationele database systemen bieden uitstekende mogelijkheden om dit te faciliteren in de vorm van referential en uniqueness constraints en triggers. Door hier optimaal gebruik van te maken zijn veel problemen te voorkomen. Deze manier van datakwaliteit afdwingen kan ook in stapjes worden uitgebreid. Dit kan gelijk opgaan met de eerder genoemde verbetercyclus. Telkens wanneer uit de periodieke controles blijkt dat een business rule geen enkele schending meer oplevert, kan op databaseniveau het geautomatiseerd afdwingen van deze regel in werking worden gesteld. De corresponderende controlequery kan vanaf dat moment worden verwijderd uit de verbetercyclus. Het komt voor, bij complexe triggers, dat dit een te zware wissel trekt op de transactiesnelheid van het systeem. In dat geval moet een andere oplossing gezocht worden. Bijvoorbeeld door achteraf te blijven controleren zoals we al deden of door wijzigingen aan te brengen in de invoerschermen.

Tip: Geef iedere gebruiker precies voldoende rechten

Een systeem waarin iedereen alle data naar hartelust kan wijzigen leidt bijna automatisch tot datavervuiling. Bekijk wie wat moet kunnen in het systeem om zijn rol in de organisatie naar behoren te kunnen vervullen. Als het systeem dit ondersteunt, ken dan iedere gebruiker precies die rechten toe die strikt noodzakelijk zijn. Als het systeem geen deugdelijk autorisatiemechanisme heeft, ligt hier de schone taak voor het ontwikkelteam om dit alsnog mogelijk te maken.

Tip: Vermijd hard coded keuzelijsten

In de meeste gebruikersschermen zijn ze wel te vinden: keuzelijsten die de gebruiker helpen met het invoeren van een valide waarde in een veld. De gebruiker kiest dan uit een lijst met veelzeggende omschrijvingen maar in werkelijkheid voert hij een code in. Reuze handig maar zorg er wel voor dat de items die in deze keuzelijsten getoond worden niet hard coded in de sourcecode voor gebruikersschermen staan. Deze waarden kunnen beter uit de database worden gehaald. Behalve dat dit voordelen met zich mee brengt met betrekking tot de onderhoudbaarheid wordt ook de kennis over welke beschrijving bij welke code hoort geborgd. Bovendien wordt het zo mogelijk door middel van een referential key te bewaken dat er enkel valide codes worden ingevoerd in de transactietabellen.

Tip: Kies het juiste datatype

Definieer het type van ieder database veld zo streng mogelijk. Dus als een veld een datum moet gaan bevatten, geef het dan een datumtype in plaats van bijvoorbeeld een teksttype, als het een geheel getal moet bevatten, geef het dan een numeriek datatype zonder decimalen.

Tot slot

Over het algemeen is het opschonen van een vervuilde database geen simpele opgave. Hiervoor is in de eerste plaats een lange adem nodig. Het opstellen van een data dictionary en business rules zijn een belangrijke eerste stap. De vervolgstap kan zijn dat het bestaande systeem verbeterd wordt. Het kan natuurlijk zijn dat het huidige systeem zodanig slecht in elkaar zit dat er wordt overwogen om over te stappen naar een nieuw systeem. De opgedane kennis over hoe de data werkelijk in elkaar steekt en hoe hij hoort in elkaar te steken zal in dat geval belangrijke input zijn voor een migratietraject naar dat nieuwe systeem.  Aan datamigratietrajecten heb ik al eens eerder een post gewijd. Kijk hier voor meer.

In een vorige post ben ik ingegaan op hoe een manager 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 zich expliciet bewust wordt gemaakt van zijn eigen gedrag en daarnaast van de normen die gelden met betrekking tot dat gedrag, dan zal hij geneigd zijn, zijn gedrag aan te passen richting de norm.

Een voor iedereen welbekende toepassing van dit principe is het digitale snelheidbord. Je ziet ze overal in Nederland langs de weg 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 (kijk hier voor meer informatie) 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 decennia 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. Hiervoor heb ik in dit artikel al eens een lans gebroken.

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 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, op het moment dat hij niet gebruikt wordt, er in het scherm van het mobile device, de datum getoond wordt waarop de laatste aaneengesloten uren geregistreerd zijn (actueel gedrag). Daarnaast 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…

Managementinformatie wordt gemaakt op basis van data afkomstig uit een of meer bronsystemen. Tussen het moment van het onttrekken aan het bronsysteem en het moment van afleveren van managementinformatie bij de eindgebruiker kan de ruwe brondata aan verschillende transformaties worden onderworpen. Niet zelden wordt er in dit proces gebruik gemaakt van een of andere vorm van historische data opslag. Een belangrijke reden om datahistorie te bewaren is dat dit ons in staat stelt om op ieder gewenst moment eerder geproduceerde managementinformatie exact te kunnen reproduceren. Zo kan de gebruiker, op een later tijdstip verdere analyse uitvoeren op dezelfde cijfers als destijds. Dit wordt ook wel het non-volatility principe genoemd.

Binnen verschillende BI architecturen wordt op verschillende manieren omgegaan met brondata, het bewaren van historie en de transformaties die nodig zijn om van ruwe brondata managementinformatie te maken. De ene architectuur is er primair op gericht informatievragen die hier en nu spelen te kunnen beantwoorden en bevatten geen voorzieningen voor non-volatility.  Andere architecturen zijn ambitieuzer van opzet en garanderen wel non-volatility en houden tegelijkertijd rekening met het gegeven dat bronsystemen kunnen wijzigen evenals de informatiebehoefte van de gebruikers van managementinformatie. Alles daar tussenin is uiteraard ook mogelijk.

Verlies van historie

Bij de meeste BI architecturen kan informatie verloren gaan over de historie en herkomst van de brondata. Dit is altijd het gevolg van het transformeren van data waarbij de uitkomst van de transformatie wordt bewaard maar de data die als input voor de transformatie diende niet. Voor de meeste BI specialisten is dit gesneden koek (mag ik hopen), echter voor de business, de eindgebruiker van de BI architectuur, is dit lang niet altijd het geval (We hebben een datawarehouse dus we bewaren de historie van al onze data…). Daarom is het goed om eens te benoemen wat er allemaal gebeurt met de data uit de operationele systemen voordat het uiteindelijk is getransformeerd naar bruikbare management informatie.

Manieren om data historie te verliezen

Hieronder beschrijf ik aan welke transformaties data binnen een BI architectuur onderworpen kan worden en hoe dit tot verlies van data historie kan leiden.

Data cleansing

Dit is het opschonen van data door het toepassen van kwaliteitsregels alvorens deze data in het datawarehouse worden geladen. Er zijn verschillende situaties die er toe kunnen leiden dat een data item niet in het datawarehouse terecht komt:

• Er treden problemen op bij het converteren van velden van het ene gegevenstype naar het andere. Bijvoorbeeld: Een orderregel in het bronsysteem heeft een veld ‘Orderdatum’ van het gegevenstype ‘Tekst’ met de waarde ‘1 januari Z012’. Deze waarde kan niet geconverteerd worden naar het gegevenstype ‘Datum’ hetgeen noodzakelijk is om het op te kunnen slaan in het daarvoor bestemde datumveld de historische data opslag.
• Door het niet laden van onbestaanbare informatie. Bijvoorbeeld een orderregel met een negatief te factureren bedrag.
• Door het niet laden van informatie met ontbrekende sleutelwaarden. Bijvoorbeeld een record met persoonsinformatie waarvan het burgerservicenummer ontbreekt kan niet worden geladen omdat binnen het datawarehouse de entiteit persoon uniek identificeerbaar moet zijn met het burgerservicenummer.
• Door codes die niet bekend zijn in het datawarehouse, te vervangen door een standaardwaarde. Bijvoorbeeld een orderregel met een onbekende productcode die vervangen wordt door de waarde ‘UNKNOWN’ alvorens hij wordt opgeslagen in het datawarehouse.

Data integratie

Dit is het samensmeden van gefragmenteerde data tot een geheel. Ik onderscheid twee vormen van data integratie:

• Intra bronsysteem integratie. Dit is integratie van data die op verschillende momenten wordt onttrokken aan hetzelfde bronsysteem.  Als bij dit type data integratie historische informatie verloren gaat, is dit doorgaans een bewuste keuze. Soms wordt er bewust gekozen voor het niet of slechts deels opbouwen van een tijdslijn van een entiteit, bijvoorbeeld omdat dit geen business belang dient. Echter soms gaat het hier ook onvoorzien mis doordat sleutelvelden niet stabiel in de tijd zijn. Bijvoorbeeld: Stel we hebben een productregistratiesysteem waarin de producten uit het assortiment, zijn gedefinieerd. Het systeem dwingt af dat ieder product een unieke productcode toegewezen krijgt. Bij eerste invoer krijgt het product de unieke code ‘PRODUCTA’ toegewezen. Vervolgens wordt deze informatie geladen in het datawarehouse waarbij de productcode als unieke sleutel wordt gebruikt. Weer wat later komt men erachter dat de code foutief was en daarom wordt deze vervangen door een andere, eveneens unieke code ‘PRODUCTB’. Als vervolgens ook deze informatie wordt geladen in het datawarehouse, dan wordt de tijdslijn van het product met code ‘PRODUCTA’ niet voortgezet. In plaats daarvan wordt een nieuwe tijdslijn gestart voor het product met code ‘PRODUCTB’. Het feit dat product met code ‘PRODUCTA’ hetzelfde product betreft als het product met code ‘PRODUCTB’ gaat hier verloren.
• Bronsysteem overstijgende integratie. Dit is integratie van data die wordt onttrokken aan verschillende bronsystemen om zo een compleet beeld te creëren van een entiteit waarvan data gedistribueerd is opgeslagen. Bij dit type data-integratie kan historie verloren gaan als het integratie algoritme niet gegarandeerd 100% zonder fouten verloopt. Bijvoorbeeld persoonsgegevens die geïntegreerd moet worden op naam, geslacht en geboortedatum. Dit kan fout gaan als het integratiealgoritme geen rekening houdt met verschil in gebruik van diacrieten, hoofdletters, koppeltekens etc. in de naam. Als de architectuur van het datawarehouse  vereist dat direct tijdens het laadproces ook de data geïntegreerd wordt dan is er vaak geen weg meer terug. Als achteraf blijkt dat er iets is fout gegaan tijdens de data-integratie dan kunnen binnen het datawarehouse al zoveel afhankelijkheden zijn ontstaan met het foutief geïntegreerde data-item dat de kluwen niet meer zonder informatieverlies te ontwarren is. Daarnaast kan bij bronsysteem overstijgende integratie natuurlijk hetzelfde type probleem optreden als beschreven is bij intra bronsysteem integratie.

Calculatie

Dit is het berekenen van numerieke waarden op basis van verschillende getallen in een of meer records uit het bronsysteem.  Denk hierbij bijvoorbeeld aan het berekenen van een omzet voor een orderregel door het verkochte aantal te nemen en dit te vermenigvuldigen met de stuksprijs van het bestelde product en hiervan een eventueel verleende korting af te trekken. De berekende omzet wordt opgeslagen in het datawarehouse, maar de onderliggende getallen (aantal verkocht, stuksprijs en kortingsbedrag) niet.

Aggregatie

Dit is het berekenen van numerieke waarden door het samenvatten van data uit meerdere records uit het bronsysteem voor een of meer dimensies en dit opslaan in het datawarehouse. Tegelijkertijd worden de onderliggende detailgegevens niet bewaard in het datawarehouse. Een voorbeeld van aggregatie is het berekenen van het verkochte aantal van een product per week door de som van het verkochte aantal van alle orderregels voor het betreffende product die binnen dezelfde week vallen, op te tellen.

Wat is nou eigenlijk het probleem?

In de bovengenoemde voorbeelden onder het kopje data integratie is het probleem evident. Door voortschrijdend inzicht in de wijze waarop de data geïntegreerd moet worden of door er te laat achter te komen dat er iets mis is gegaan met de data integratie is het onmogelijk de oorspronkelijke brondata te reconstrueren en opnieuw te integreren volgens de nieuwe inzichten.

Ook rondom data cleansing strategieën kunnen we voorschrijdende inzichten krijgen. Bijvoorbeeld we komen tot het inzicht dat, geheel tegen de afspraken in, de order desk orderregels ‘misbruikt’ door een negatief te factureren bedrag in te voeren om zo geld terug te storten op rekening van klanten die te veel betaald hebben. Nu we dit weten, blijkt dat we, achteraf gezien, de orderregels met een negatief factuurbedrag wel degelijk hadden moeten meenemen in de berekening van de weekomzet. Echter deze orderregels zijn buiten het datawarehouse gehouden en zijn in de tussentijd mogelijk gewijzigd in het bronsysteem. Met terugwerkende kracht zijn we nu niet meer in staat de weekomzet te herberekenen volgens de nieuwe methode.

Organisaties zijn continue onderhevig aan veranderingen. Hetzelfde geldt voor de markt waarin zij opereren. Het kan dan ook niet anders dan dat de informatiebehoefte van de gebruikers van de BI oplossing verandert in de tijd. Om tegemoet te kunnen komen aan deze veranderende informatiebehoefte, moeten soms wijzigingen worden aangebracht in het datawarehouse. Stel dat de eindgebruiker aanvankelijk geïnteresseerd was in de omzet per product, per verkoper, per week. Om aan deze informatiebehoefte te voldoen, zijn de orderregels afkomstig uit het ordersteem geaggregeerd per product, verkoper en week. Het resultaat van deze aggregatie is opgeslagen. De onderliggende orderregels niet. Op een later moment geeft de eindgebruiker aan dat hij de omzet ook nog per verkoopregio wil kunnen bekijken. We hebben nu geen andere keus dan de omzet opnieuw te berekenen door de orderregels zoals ze nu in het ordersysteeem staan, opnieuw te aggregeren, ditmaal met de extra dimensie verkoopregio. Er is een gerede kans er inmiddels iets is veranderd in het orderregels in het ordersysteem. Als we het non-volatility principe belangrijk vinden, moeten we in dat geval de oorspronkelijke omzetcijfers (per product, per verkoper, per week) bewaren in het datawarehouse en daarnaast de omzetcijfers volgens de nieuwe berekening (per product, per verkoper, per week, per verkoopregio) gaan opslaan. De oorspronkelijke omzetcijfers uitsplitsen volgens een extra dimensie kan in dit geval dus niet.

Business beslist mee 

Nu we weten waar we historie kunnen verliezen, kunnen we, indien gewenst, hierop anticiperen. Dit kan door de juiste BI architectuur te kiezen, in combinatie met de juiste wijze van het modelleren van data. Voordat een organisatie een keuze maakt, is het belangrijk om helder te hebben welke consequenties deze keuze heeft in termen van mogelijk verlies van data-historie en hoe dit de flexibiliteit en onderhoudbaarheid van de oplossing beïnvloedt.  Architectuurkeuze is dus niet enkel een technische aangelegenheid. De business moet hier ook bij betrokken worden.

Management informatie, het woord zegt het al, wordt gebruikt om processen die werken binnen de organisatie te managen, bij te sturen. Er zijn verschillende manieren waarop dat kan.

1. Reactief: het evalueren van reeds doorlopen processen. Op basis van kengetallen analyseren wat goed en wat er minder goed is gegaan tijdens deze processen. Als de vinger op de zere plek is gelegd, kan vervolgens actie worden ondernomen om het de volgende keer beter te doen.
2. Proactief: met behulp van stuurgetallen monitoren van lopende processen en deze vervolgens meteen bijsturen. Deze manier is gericht op het voorkomen van problemen of het bereiken van nóg betere resultaten.

In deze blogpost wil ik dieper ingaan op de laatstgenoemde vorm.

Bij het proactief sturen kan een manager ervoor kiezen om ongewenst gedrag te berispen en/of gewenst gedrag juist te belonen. Tijdens een opdracht bij een hoger onderwijs instelling, kwam ik hiervan een toepasselijk voorbeeld tegen. Een van de aandachtspunten binnen deze instelling is dat studenten soms te lang moeten wachten op hun cijfer na het maken van een tentamen. In de Onderwijs en Examenregeling (OER) is vastgesteld wat de maximale nakijktermijn is. Omdat de OER ten allen tijde na moet worden geleefd, maar dit dus niet altijd gebeurt, heeft men op een gegeven moment besloten tot het monitoren van de nakijktermijnen. Een tentamenresultaat is voor een student zichtbaar op het moment dat het door de examinator (vaak een docent) is ingevoerd en definitief gemaakt in het studievolgsysteem. De nakijktermijn kan dus worden bepaald door het aantal dagen te berekenen dat tussen de toetsdatum en de invoerdatum van het definitieve cijfer ligt. Per tentamen kan dan de gemiddelde nakijktermijn worden berekend. De onderwijsmanager, die binnen een opleiding de leidinggevende is van de examinatoren, kan deze informatie vervolgens gebruiken om in de periode na de tentamendatum te monitoren van welk deel van de afgenomen tentamens er daadwerkelijk een resultaat is ingevoerd in het volgsysteem.

Binnen grote onderwijsinstellingen wordt lang niet alles centraal geregeld. Zo was het ook met deze kwestie. Bij een faculteit zorgde  alleen al de gedachte aan het feit dat resultaten invoergedrag nauwkeurig in de gaten werd gehouden al voor zoveel weerstand onder de medewerkers dat dit nooit echt van de grond gekomen is. Een ‘big brother’ die te trage invoer van resultaten zou afstraffen was geen aanlokkelijke gedachte.

Daar tegenover stond een andere faculteit waar men ondanks de initiële bedenkingen toch is overgegaan tot het monitoren van de nakijktermijnen. Wekelijks kreeg iedere opleidingsmanager daar een vers overzicht met nakijktermijnen van recent afgenomen tentamens, waarmee hij aan de slag ging. Na een jaar bleek deze aanpak zeer succesvol te zijn geweest. Het percentage van tijdig nagekeken tentamens, was met tientallen procenten gestegen. Dit is een formidabel resultaat en tevens het bewijs dat het verzamelen en gebruiken van management informatie meerwaarde oplevert. Dat het in deze faculteit wel goed is uitgepakt is waarschijnlijk het gevolg geweest van de manier waarop er gestuurd is door de opleidingsmanagers. Men heeft er bewust voor gekozen examinatoren, die volgens de stuurgetallen, op schema liggen met de resultateninvoer te complimenteren. Examinatoren die achterliepen met de resultateninvoer werden daarentegen niet verwijtend benaderd maar ruim voordat de uiterste nakijkdatum bereikt was, gevraagd of het allemaal lukt en of ze wellicht hulp nodig hebben bij het nakijkwerk. Kennelijk is het aanbieden van ondersteuning in sommige gevallen een stimulans om tempo te maken. In bepaalde gevallen is dit ook een mooi moment om erachter te komen dat het werk niet af komt zoals gepland en er dus extra nakijkcapaciteit moet worden ingeschakeld.  Het netto resultaat is een kwaliteitsverbetering van het nakijkproces enkel door positieve bekrachtiging en ondersteuning bieden waar dat nodig is.

Kortom: managementinformatie geeft een zekere grip op wat er speelt in een organisatie maar managers moeten heel bewust kiezen hoe hiermee om te gaan. Sturen door overtreders op de vingers te tikken kan in bepaalde situaties best werken maar soms zal dit ook de nodige weerstand oproepen en zelfs verlammend werken.  Sturen door tijdige positieve bekrachtiging is het alternatief. Ook dit zal soms wel en soms niet werken. Het is het vak van de manager om te bepalen wat de juiste keuze is.