Illustratie bij de serie de complexiteit van informatieprojecten

De complexiteit van informatieprojecten

Informatieprojecten, of het nu Business Intelligence, Analytics of Big Data betreft, gaan vaak moeizaam. Ze worden als complex ervaren.

In de serie ‘de complexiteit van informatieprojecten‘ verken ik wat de oorzaken hiervan zijn. De serie begint met het onderscheiden van de verschillende gebruikspatronen van informatie. Deze gebruikspatronen bepalen hoe de interactie tussen gebruikers en ontwikkelaars moet worden vormgegeven en welke rol context speelt in die interactie.

De inzichten van deze serie kunnen hopelijk helpen bij het verbeteren van verwachtingsmanagement rond de bijdrage van betrokkenen, om de complexiteit te reduceren en het informatieproject tot een succes te maken.

Lees de serie

GDPR

GDPR en een centraal klantbeeld: een zegen of juist een extra uitdaging

25 mei 2018: Een datum die bij steeds meer bedrijven met hoofdletters in de agenda staat geschreven. Vanaf dat moment gaat de Europese General Data Protection Regulation, afgekort GDPR, ook daadwerkelijk gehandhaafd worden. Dat betekent dat er hoge boetes kunnen worden opgelegd aan bedrijven die niet compliant zijn, tot wel 4% van de jaarlijkse omzet of 20 miljoen euro. De Autoriteit Persoonsgegevens houdt toezicht op de handhaving van deze regels in Nederland.

Aan de andere kant wordt steeds meer waarde uit klant gerelateerde data gehaald. Degene die zijn klanten zo effectief mogelijk kan benaderen (op het juiste moment met de juiste aanbieding) heeft een voorsprong op de concurrentie. De prijs die je daar als persoon (en als samenleving) voor betaalt is dat er meer over jou als klant bekend wordt en dat er ook meer wordt vastgelegd.

Voorbeelden hiervan zijn het creëren van een centraal (360 graden klantbeeld), het opzetten van een masterdata omgevingen voor klantinformatie of het implementeren van een customer data platform. De vraag is of het opzetten van zo’n gecentraliseerde omgeving nu juist een voordeel of een nadeel is in het kader van de GDPR? Om deze vraag te beantwoorden moeten we eerst ingaan op wat de gevolgen zijn van GDPR

De GDPR (in Nederland wordt dit de Algemene verordening Gegevensverwerking of AVG) is bedoeld om bedrijven te dwingen privacybewust te zijn. Dit wordt ‘privacy by design’ genoemd. Het zorgt ervoor dat de balans niet doorslaat naar ongelimiteerd verzamelen en toepassen van klant gerelateerde data. Het idee is dat er een afweging wordt gemaakt of en welke data wordt vastgelegd en waarom, dit wordt ‘data minimization’ genoemd. Het ‘waarom’ is de doelbinding en is leidend in het gebruik van de data (het doelbindingsprincipe). Dit bewustzijn is niet alleen van toepassing op klant gerelateerde gegevens. Andere vormen van persoonlijke informatie zoals medewerker gegevens vallen ook onder de GDPR. Dit artikel gaat specifiek in op klant gerelateerde gegevens.

Hoe weet je nu dat je binnen de regels van deze wet opereert? Dat weet je dus niet zeker. De regulering schrijft regels voor maar geeft vooraf geen inzicht of de daadwerkelijk genomen maatregelen afdoende zijn om niet gestraft te worden. Het is net als bij de belastingen: je kunt de regels implementeren zoals jij denkt dat het hoort, maar de controle vindt pas achteraf plaats. Het belangrijkste is dat je transparant en expliciet maakt dat je hebt nagedacht over privacy binnen je organisatie en dat je bewust bepaalde besluiten hebt genomen om aan de GDPR-regels te voldoen. Je kunt dan bij een controle in ieder geval onderbouwd in overleg gaan.

Welke stappen kun je ondernemen om compliant te zijn? Dat is natuurlijk de hamvraag. Het ‘privacy by design’ principe is in de basis een cultuuruitdaging.  Er zijn ook enkele harde eisen en regels waaraan je moet voldoen en waar maatregelen voor genomen moeten worden:

  • Data Security
  • Breach Notification
  • Right to Access en Data Portability
  • Data Erasure / Right to be Forgotten

Data Security:

De meest voor de hand liggende eis is dat je als bedrijf je klantgegevens goed beschermt. Maatregelen op dit gebied komen in 2 vormen, namelijk maatregelen tegen ongeoorloofd gebruik en maatregelen tegen onbevoegde toegang (‘data breaching’).

De eerste zijn maatregelen in het kader van ‘data minimization’. Een belangrijke maatregel die in dit kader genoemd wordt, is ‘limit access to authorized users’, oftewel het voeren van een streng en consequent beleid ten aanzien van de toegang tot persoonsgegevens. Dit is aan de ene kant een organisationele of governance maatregel, namelijk krijgt iemand wel of geen toegang tot bepaalde gegevens.

Het kan echter ook nodig zijn extra beschermingsmaatregelen te nemen waarbij toegang tot specifiekere persoonsgegevens wordt gereguleerd. In de GDPR wordt namelijk nog onderscheid gemaakt tussen persoonsgegevens en gevoelige persoonsgegevens zoals financiële, afkomst of gezondheidsgegevens. Om op dit niveau de toegang tot specifieke gegevens te kunnen reguleren, moet de data wel als zodanig herkenbaar zijn. Dat kan via het classificeren van persoonsgegevens.

De tweede vorm maatregelen zijn maatregelen tegen allerlei vormen van hacking. Het beschermen van de toegang tot de data zelf kan op verschillende manieren:

Infrastructurele maatregelen: Denk aan het gebruik van VPN, strikte firewall regels en een gedegen patchbeleid.

Data beschermingsmaatregelen: Hiervoor worden wat handvaten voor maatregelen gegeven in de GDPR. Bijvoorbeeld door het extra beschermen van de persoonlijke data door encryptie en depersonalisatie technieken toe te passen. Dit laatste is overigens niet altijd mogelijk. Belangrijk in dit kader is dat data geclassificeerd is als persoonlijk en dat bekend is welke gegevens onder de GDPR vallen.

Authenticatiemaatregelen: Is de persoon die toegang wil tot de data ook daadwerkelijk de persoon die hij of zij zegt te zijn. De belangrijkste methode om tegenwoordig ongeoorloofd toegang te krijgen tot gegevens is ‘social hacking’, ofwel toegang krijgen door de zwakste schakel in het proces te gebruiken: de mens. Toegang tot systemen kan worden verkregen via simpele methodes als briefjes op computers of wachtwoorden die uitgewisseld worden via de mail. Maatregelen als 2-factor-authenticatie en het gebruik van certificaten kunnen hiervoor een oplossing bieden.

Autorisatie maatregelen: Dit gaat over de toegang die een gebruiker heeft tot bepaalde delen van de informatie of tot bepaalde functies op de data. Maatregelen op dit vlak gaan vaak samen met de data beschermingsmaatregelen en data classificatie is ook voor deze maatregelen een voorwaarde.

Breach Notification

Dit betekent dat je als organisatie processen moet hebben ingericht om tijdig en adequaat te handelen op het moment dat er een inbreuk is geweest op je data welke kan resulteren in een risico op de rechten en vrijheid van individuen. Je moet als organisatie in het kader van deze eis in staat zijn de getroffen personen op de hoogte kunnen stellen dat er inbreuk is gemaakt op hun persoonsgegevens.

Hiervoor zijn meetbare eisen gesteld. Vanaf het moment dat een inbreuk is vastgesteld moet je binnen 72 uur de personen van wie de gegevens op straat terecht zijn gekomen op de hoogte stellen (of je moet hele goede redenen hebben waarom dit niet in 72 uur mogelijk was).

Dat betekent dat je ten eerste geregeld moet hebben via goede monitoring en logging systemen dat je weet dat er ongeoorloofde toegang tot de data is geweest. Ten tweede moet je weten wiens rechten geschonden zijn en hoe zwaar de inbreuk is geweest. De classificatie van de persoonsgegevens speelt wederom een belangrijke rol, maar nu voor het bepalen van de zwaarte van de inbreuk.

Right to Access en Data portability

Een persoon heeft het recht om bij een bedrijf zijn of haar gegevens op te vragen in een technisch uitwisselbaar formaat. Net zoals een persoon zijn telefoonnummer kan meenemen, moet het ook mogelijk zijn om data ‘mee te nemen’ naar een andere leverancier. Als bedrijf moet je daar binnen een redelijke termijn op kunnen acteren. De regel is binnen een maand, maar kan verlengd worden naar 2 maanden als daar gegronde redenen voor zijn.

De grote uitdaging is te achterhalen welke gegevens allemaal van een persoon bekend zijn. Persoonsinformatie staat meestal verspreid over veel verschillende systemen die vaak ook niet gekoppeld zijn. Een eenduidig klantbeeld is een uitdaging waar veel bedrijven sowieso al mee worstelen. Een randvoorwaarde voor een invulling van deze eis is dus dat je alle gegevens die bekend zijn van een klant kunt identificeren.

De tweede stap is dat deze gegevens verzameld moeten kunnen worden en elektronisch ter beschikking worden gesteld.

Data erasure / Right to be Forgotten

Het recht van een persoon om verwijderd te worden uit de systemen van een organisatie en het recht om de persoonsgegevens buiten gegevens bewerkingen te houden. Hier zit een vorm van schizofrenie in. Naast de uitdaging zoals hiervoor beschreven om uit te vinden welke informatie allemaal van een persoon aanwezig is bij een bedrijf zijn er namelijk extra uitdagingen. Van sommige tot persoon herleidbare informatie is een bedrijf verplicht deze te bewaren. Dat kan bijvoorbeeld zijn om aan bepaalde eisen rondom dienstverlening achteraf te voldoen zoals terugroep acties van autobedrijven. Dat betekent dat het recht om vergeten te worden alleen geldt voor bepaalde, veelal marketing gerelateerde doelen.

Hoe gaat de controlerende autoriteit hier mee om? Dat zijn nog onduidelijkheden die vaak leiden tot te rigoureuze acties aan de kant van organisaties om maar aan de veilige kant van de lijn te blijven. Het vastleggen van de keuzes rondom de genomen maatregelen kan hierbij helpen.

Belangrijk is in ieder geval om een goed registratiesysteem op te zetten voor verwijderingen en de’ vergeetacties’ onweerlegbaar te loggen voor auditdoeleinden.

Centraal of niet?

Bij Free Frogs en PRDCT hebben we veel ervaring met het creëren van zo’n centraal data platform. De vraag was: Is centralisatie van klantinformatie een voordeel of juist een nadeel in het kader van de GDPR?

Aan de ene kant is het voor hackers lastiger om toegang te krijgen tot alle klant gerelateerde data als deze verspreid staan over verschillende systemen. Aan de andere kant, de schade is al geleden als zelfs maar op één systeem inbreuk wordt maakt. Daar wordt in de GDPR geen onderscheid in gemaakt.

Een ander nadeel kan zijn dat verschillende classificaties van persoonlijke gegevens op één plek aanwezig zijn. Dat betekent dat de data security maatregelen passend moeten zijn voor de persoonsgegevens van het hoogste classificatieniveau. De breach notification processen zullen echter in beide situaties gelijk zijn.

Maatregelen in het kader van data portabiliteit, right to access en right to be forgotten zijn juist weer veel eenvoudiger te nemen als er wel een centraal platform bestaat. Ten eerste zou namelijk duidelijk moeten zijn in welke systemen klant informatie staat. Er zijn processen opgezet om klantgegevens naar zo’n centraal platform te porteren en bestaat er dus een overzicht van waar de bron van deze gegevens zich bevindt en hoe de klantidentificatie plaatsvindt. Deze informatie kan gebruikt worden om klantgegevens weg te halen uit zowel de bronsystemen als wel het centrale platform zelf.

Ten tweede is het veel eenvoudiger een elektronisch overzicht te maken en over te dragen als alle persoonsgegevens centraal beschikbaar zijn.

Ten derde kan het centrale systeem gebruikt worden om klantgegevens alleen voor bepaalde doeleindes te laten gebruiken. Het platform dient dan als eenduidige plaats van waaruit allerlei (marketing) activiteiten plaatsvinden en waar ook eenduidig gebruiksregels geïmplementeerd kunnen worden.

Conclusie

Het implementeren van maatregelen in het kader van de GDPR is een onzeker pad omdat onduidelijk is of de genomen maatregelen afdoende zijn. Transparantie en het vastleggen van de genomen maatregelen en de redenatie is cruciaal om aan te geven van goede wil te zijn en dat je als bedrijf het privacy by design principe hoog in het vaandel hebt staan. Tegelijkertijd wil je gebruik maken van de mogelijkheden die klantgegevens bieden in het verbeteren van je concurrentiepositie. Deze delicate balans is de uitdaging. Het centraal bijeenbrengen van klantdata kan helpen om een aantal eisen van de GDPR makkelijker in te vullen.

self-service analytics

Self-service analytics is niet alleen een technisch vraagstuk

Self-service analytics zou de nadelen van – vaak logge – centraal geleide BI moeten ondervangen. De vraag is of dat wel lukt. Het succesvol implementeren van self-service analytics is veel weerbarstiger dan vaak wordt gedacht. Maar als je weet waar je op moet letten heeft self-service analytics wel degelijk grote toegevoegde waarde.

Exceldorado heerst nog altijd

Ondanks dat business intelligence (BI) als vakgebied inmiddels volwassen is geworden, heerst in veel organisaties nog Exceldorado: een jungle van losse, vrijwel onbeheerbare spreadsheets met vaak bijna, maar net niet helemaal dezelfde inhoud.

Dit is niet helemaal verwonderlijk, gezien de nadelen van ‘corporate BI’: lange ontwikkeltijden van nieuwe informatieproducten, inflexibele oplossingen en een bureaucratisch beheer door het (moeten) volgen van regels, procedures en standaarden. Allemaal dingen waar je als eindgebruiker niet op zit te wachten wanneer je snel een rapportage nodig hebt. De verleiding om dan maar snel even een Excel-rapportje te maken is dan groot.

Is dat erg? Ja, dat is erg. Het is verspilling van tijd en geld. Het kost veel tijd (vaak verborgen tijd van medewerkers in de business) om al die losse Excel-rapportages te maken en te onderhouden. Het is bovendien foutgevoelig, er is veel risico op slechte datakwaliteit, er is veel dubbele content en de verwarring over definities ligt op de loer.

Self-service analytics overbrugt de kloof

De oplossing voor deze kloof tussen eindgebruiker en corporate BI wordt steeds meer gezocht in een zelfbedieningsconcept voor business intelligence en analytics: self-service analytics. Eindgebruikers krijgen daarmee de mogelijkheid om met een gemakkelijk te hanteren BI-tool snel hun eigen rapportages en analyses te maken. Ze zijn niet meer afhankelijk van IT om rapporten voor ze te maken en kunnen daarmee veel sneller en flexibeler voorzien in hun eigen informatiebehoefte.

Klinkt goed, toch? Zeker. Ik denk alleen dat veel van de self-service implementaties zullen uitdraaien op een moderne versie van Exceldorado. Eindgebruikers krijgen de beschikking over data en een self-service BI-tool en gaan daarmee losse, vrijwel onbeheerbare rapporten met vaak bijna, maar net niet helemaal dezelfde inhoud maken. Hé, waar zagen we dat eerder?

Dezelfde chaos, maar dan in een nieuwe tool. Per saldo zijn we dan niets opgeschoten.

Self-service analytics implementeren is geen technisch vraagstuk

De spagaat van self-service is dat je aan de ene kant alle gebruikers het roer in handen wilt geven, terwijl je aan de andere kant wilt voorkomen dat het een chaos wordt. Een manier om uit deze ongemakkelijke spagaat te komen is het beperken van de data of van de mogelijkheden en functionaliteit van de self-service tool, zodat gebruikers geen domme dingen kunnen doen. Dit is echter noch een goede noch een structurele oplossing. Het is een technische oplossing voor een niet-technisch probleem. Bovendien gaan gebruikers dan toch weer hun eigen Excel-bestanden creëren en zijn we weer helemaal terug bij af.

Succesfactoren van self-service analytics

Het implementeren van self-service analytics is veel meer dan het ter beschikking stellen van een mooie nieuwe glimmende BI-tool. Een nieuwe tool (technisch) implementeren is het makkelijke deel van self-service analytics. Wat veel lastiger is zijn de zaken die self-service analytics tot een succes kunnen maken. Er zijn vele succesfactoren voor self-service analytics te benoemen. Hieronder ga ik in op wat ik de drie belangrijkste succesfactoren vind.

Zonder data governance geen self-service analytics

Self-service analytics en data governance gaan hand in hand. Het is geen goed idee om alle gebruikers ongebreideld maar toegang te geven tot allerlei data en iedereen toe te staan om rapportages te maken die binnen en buiten de organisatie worden gebruikt. Een zekere mate van governance zal altijd nodig zijn. Bijvoorbeeld om te bepalen wie toegang heeft tot welke data en wat die persoon daar mee mag doen. Het afdwingen van compliance-regels van (externe) toezichthouders stelt in sommige organisaties zware eisen aan data governance. Maar ook intern is een goede data governance nodig, bijvoorbeeld om te zorgen dat niet verschillende definities van dezelfde begrippen worden gebruikt.

Organiseer self-service analytics als een community

Een actieve gebruikers-community helpt enorm om de mogelijke nadelen van self-service analytics te ondervangen. Een gebruikersgroep kan onderling tips & trucs uitwisselen, elkaar ondersteunen in het gebruiken van data en van de BI-tool en kennis delen over definities en eerder ontwikkelde informatieproducten. Dit voorkomt dat iedere gebruiker weer het wiel gaat (of moet) uitvinden.

Dit is makkelijk gezegd, maar niet eenvoudig uit te voeren. Dit moet georganiseerd worden, onder meer door het bieden van een platform om kennis en ervaring uit te wisselen en om onderling te communiceren en door het aanstellen van super-users, data-stewards, data-ambassadeurs, of welke benaming je maar wilt hanteren. Het enthousiast krijgen van gebruikers voor een actieve deelname aan een dergelijke community vergt vasthoudendheid. Maar als het eenmaal deel uitmaakt van hun normale werkproces onderhoudt de community zichzelf.

Bied centrale ondersteuning waar nodig

Self-service analytics is nooit helemaal zelfbediening. Gebruikers zullen altijd enige mate van ondersteuning nodig hebben. Op welk gebied, dat is erg afhankelijk van de organisatie en van de gebruiker. Maar in veel gevallen zal de BI-afdeling nog veel datapreparatie voor zijn rekening nemen. Ook hulp bij het maken van (de meer complexe) rapportages zal vaak nodig zijn, net als het geven van training in het gebruik van de BI-tool. En vergeet ook niet dat de analisten van de BI-afdeling kunnen helpen bij het helder krijgen van de informatiebehoefte van gebruikers. Dit houdt in dat de BI-afdeling actief de business moet benaderen om te bepalen op welke manier ze het beste de business kunnen helpen.

Betrokkenheid van alle partijen

Het aanbieden van self-service analytics is geen bedreiging voor een bestaande BI-afdeling die gewend is zelf alle rapportages en dashboards voor gebruikers te ontwikkelen. De inhoud van het werk zal echter wel veranderen. Implementatie van self-service analytics vraagt grote inspanning van de BI-afdeling in het ondersteunen van gebruikers, het opzetten en stimuleren van een gebruikers-community en het organiseren van data governance. Het vereist vooral ook grote betrokkenheid van de eindgebruikers van self-service analytics.