Berichten

Free Frogs Data Governance Maturity ModelFree Frogs

Data Governance Maturity Models – Useless! Or not?

/in , /door

Data Governance maturity models can be a powerful tool for formulating improvement plans, communicating concepts and measuring progress, but they only work well when tailored to the specific context of the organisation.

I used to be convinced that Data Governance maturity models were highly overrated, with little or no added value. Nice pictures if you were lucky, standard terms that apply to most situations and a bit of extra fluff to sound clever.

A large part of my disapproval came from seeing multiple organisations struggling with Data Governance and seeing the (lack of) results achieved when using generic models, because little attention had been paid to organisation specifics including culture, actual data problems and the organisation’s goals and objectives. Any resulting output from the model was generally either irrelevant or too high-level to be useful. To make matters worse, because the output couldn’t be translated into a prioritized improvement roadmap, the end-result was usually a data governance effort which didn’t gain traction, got shelved, or was hugely inefficient.

I still have the same opinion of generic maturity models. However, if you take a generic maturity model and tailor it to a particular organisation, it is possible to identify specific improvement points within a short time frame. How do you do this? Tailoring the maturity model means focusing in on the organisation’s specific objectives, their actual data problems and the individual context within which the organisation operates. And adjusting the model accordingly.

Framing suggested improvements within an organisation-specific maturity model helps with focus, emphasising which particular data governance concepts need to be addressed and why this adds value. Tailoring the maturity model to the specific terms and language of the organisation helps with communication, highlighting where data governance fits into the overall picture. Prioritizing the improvements and translating them into a roadmap make the effort required even clearer, increasing enthusiasm levels as a result. And as this enthusiasm results in improved data governance, progression can be captured and shared by amending the maturity model graphic, generating yet more energy around the data governance programme.

Let’s make things more concrete.

Below is the generic Free Frogs Data Governance maturity model.

Free Frogs Data Governance Maturity Model

The various components of our overall view of Data Governance are visible in the model. However, we only use this generic version of the model in two specific situations.

(1)   The generic model provides an initial framework for discussions

Sometimes when people are new to data governance, it can be difficult to grasp how wide its impact is on a broad range of business issues. By using the model as a guide, we can focus discussions on the different aspects of data governance, their implications and their importance within different business situations. It provides a useful framework for the conversation around data governance, ensuring all important angles are covered; and it provides a handy memory aid to refer to in follow-up discussions and reviews.

The model also helps highlight that while different organisations have different data problems and priorities, it is still important to approach the specific data-related challenges within the context of the organisation’s overall data governance. For example, it’s almost impossible to have a conversation about data quality without also discussing definitions, master data and business rules; and it’s not very future proof to talk about data quality without also looking at lineage and culture.

(2)   The generic model provides an accelerant to the organisation-specific maturity model

The second situation in which we use the generic Free Frogs Data Governance maturity model is as a quick start to generate an organisation specific maturity model. Often, early on in conversations, it is already clear what pain is being experienced due to a lack of well-structured data governance. By placing these pain points within the context of the organisation’s particular goals, challenges and culture, we can focus in on the most relevant aspects of the generic maturity model. We then tailor these aspects to the organisation’s situation, adding in other organisation specific components and amending the language. This gives a more accurate picture of what needs to happen, than what is possible with a generic model. Additionally, an organisation specific model resonates more when we’re communicating.

After the model has been tailored to the organisation’s own situation, it can then be combined with the output of the data governance business case to quickly provide a concrete, prioritized, organisation-specific roadmap for the data governance effort.

The figure below shows one example of an organisation specific maturity model. In it, a subset of data governance subject areas with particular relevance to the organisation’s situation have been placed alongside other organisational factors to provide an organisation specific model.

Free Frogs Data Goverance Maturity Model Specific

It’s clear to see that a number of the subject areas are different to the generic maturity model. This tailoring helps the organisation focus on its particular data governance challenges. The model improves communication around data governance, highlighting which data governance aspects need focus if the overall added value of data in the organisation is to improve. When the underlying scoring level descriptions are shared, awareness of improvement steps needed becomes even clearer.

The tailored maturity model also gives an easy to understand overview of the original situation compared to the progression achieved in certain areas. Added to that, the underlying maturity model level descriptions and checklists provide concrete improvement points that the organisation can prioritize based on their unique situation of the organisation and translate into their data governance roadmap.

Conclusion: use a generic model only as an introduction; then switch to tailor-made to accelerate the data governance improvement efforts

Having compared the value of both maturity model uses outlined above I’m definitely a convert to the idea that a maturity model can add value, provided it is well thought out, and customized to the organisation’s situation. However, this has only served to further increase my perplexity for those in our subject area who try to apply standard data governance maturity models without thought to context, culture, and organisation specific challenges and goals. My advice: don’t do it!

Data governance MDM MDS Blog post Kees Molenaar

Master Data oplossing met behulp van Microsoft Master Data Services

/in , /door

In de vorige blog “De noodzaak van Master Data Management voor een datagedreven organisatie” is een casus geïntroduceerd. Deze blog gaat over het configureren van het Master Data Management (MDM) model aan de hand van deze casus.

Figuur 1: Focus van deze blog: Configureren

De vraag die in de vorige blog post nog niet is beantwoord is waarom we een MDM-oplossing nodig hebben. Het antwoord op deze vraag is heel simpel: er is vaak geen centrale omgeving waarbij de identificatie van entiteiten (personen, leveranciers, producten, etc.) wordt vastgelegd. Om tot een eenduidig beeld te komen is deze centrale identificatie-omgeving wel noodzakelijk en dit is precies wat MDM doet.

De drive voor een centraal beeld is tegengesteld aan de trend van specifieke oplossingen (veelal cloud) die als een lappendekken het systeemlandschap vormen. Als gevolg van deze versnippering is veel inspanning nodig om de centrale identificatie over elke individuele oplossing gelijk te houden. Deze synchronisatie van het zogenaamde ‘golden record’ is als gevolg van de grote hoeveelheid werk erg kostbaar. Om deze hoge kosten te vermijden kan ook precies het omgekeerde worden gedaan, namelijk alle systemen hun identificatie laten creëren en naderhand alle identificatiesleutels laten linken. De onderstaande implementatiebeschrijving laat stap voor stap zien hoe dit MDM-patroon te creëren is met behulp van Microsoft Master Data Services (MDS).

In de onderstaande afbeelding staat de functionele beschrijving van de casus die verder wordt uitgewerkt. Het doel is het aan elkaar relateren van alle voorkomens van een klant die in verschillende systemen is vastgelegd.

Figuur 2: de casus

Om dit patroon te kunnen realiseren met MDS zijn de volgende stappen nodig:

Figuur 3: Proces voor het configureren van het model

 

1.      Hoofdentiteiten aanmaken

Om dit patroon te kunnen realiseren moeten er twee objecten worden aangemaakt. Het eerste object is het master object, in dit geval Klant (zie figuur 3). Het tweede object is de bronidentificatie, in dit geval CRM, helpdesk, betaling en orderidentificatie.

Figuur 4: de elementen voor MDM, master en bron

Er wordt in dit patroon gekozen om alle bronnen te combineren in een entiteit in plaats van voor elke systeem (CRM, Helpdesk etc) een losse entiteit te maken. Dit komt de generieke toepasbaarheid van de oplossing ten goede en hierdoor is de uitbreiding met een nieuw systeem, bijvoorbeeld loyalty, geen aanpassing aan het patroon. Deze twee objecten kunnen gerealiseerd worden door twee entiteiten (entity’s) aan te maken in MDS, zoals de twee onderstaande afbeeldingen tonen.

Figuur 5 en 6: Entiteit voor de MDM klanten en voor bron klanten

 

2.      Beschrijvende attributen toevoegen

Standaard voegt MDS altijd twee attributen toe, namelijk code en name. Code is de sleutel van de entiteit en moet ook uniek zijn. Er zijn hier twee opties, optie 1 een vrije invoer of optie 2 een gegeneerd getal (Checkbox “create code values automatically”). Aangezien voor dit MDM-patroon de sleutel niet wordt bepaald door MDS blijft de checkbox “create code values automatically” uit. Om matching van de brondata te kunnen uitvoeren zijn er aanvullende attributen nodig die de identificatie ondersteunen. In deze casus zijn de beschrijvende attributen FirstName en SourceSystem.

 

3.      Testdata vullen

Als er data gevuld (web interface, Excel interface of load procedures) is voor SRC_customer ziet de data er in de web interface en in Excel zo uit:

Figuur 7 en 8: Overzicht van de bron klanten incl. data in de webinterface en in Excel

 

4.      Bron en master koppelen

De volgende stap is het koppelen van de verschillende voorkomens van klanten uit systemen aan één master record per klant. Het is van belang dat afgedwongen wordt dat alleen maar gekoppeld kan worden aan een waarde in de lijst van master records. Deze beperking wordt gerealiseerd door in MDS een “domain-based” attribuut toe te voegen aan de entiteit SRC_customer. Vervolgens kan geselecteerd worden onder “Domain Entity” welke entiteit gebruikt moet worden om deze beperking van waardes te realiseren.

Figuur 9: Domein gelimiteerde waardes toevoegen als attribuut voor SRC_customer

Het effect van dit domein-gebaseerde attribuut vertaalt zich naar een keuzeselectie zoals de onderstaande afbeeldingen tonen. Hierdoor kunnen er alleen “master klanten” gekoppeld worden aan voorkomens van klanten in overige systemen.

Figuur 10 en 11: Selectie van master klant middels de keuzeselectie in de web interface en in Excel

 

Nadat alle gegevens uit de bronsystemen zijn voorzien van een “master klant” is het onderstaande overzicht dan het resultaat:

Figuur 12: Eindresultaat: Alle klanten uit de bronsystemen gekoppeld aan een “master klant”

 

Door deze manier van implementeren met MDS te kiezen ontstaat een groot aantal voordelen:

  • Ontkoppeling
    De registratie en het beheren van masterdata zijn ontkoppeld. Zo ontstaat de mogelijkheid om over bronsystemen heen te koppelen zonder deze fysiek te moeten integreren.
  • Flexibiliteit
    Het hebben van een lijst met alle unieke master items is vaak geen gegeven. Met behulp van MDS kan de lijst met Master items (in dit voorbeeld MDM Customer) uitgebreid worden zonder dat deze in een ander systeem bekend hoeven te zijn.
  • Excel integratie
    Het toevoegen, verrijken en toewijzen van master items kan ook middels Excel. Hierdoor kunnen standaard Excel functies gebruikt worden.
  • Hoge mate van business acceptatie en verantwoordelijkheid
    Met behulp van de Excel functionaliteit is het mogelijk om de verantwoordelijkheid voor het beheer van master data te leggen bij de gebruikers zelf. Excel is een vertrouwde en breed gebruikte applicatie wat de acceptatie en het gebruik verder vergemakkelijkt.
  • Inbegrepen bij SQL Server enterprise edition
    De investering in Master Data tooling is beperkt mits er al een enterprise edition versie beschikbaar is van SQL Server.
MDM MDS Reeks

De noodzaak van Master Data Management voor een datagedreven organisatie

/in , /door

De behoefte van bedrijven en instellingen om datagedreven beslissingen te kunnen nemen groeit. Het is noodzakelijk om te beschikken over de juiste data en om een zo compleet mogelijk beeld te hebben van de eigen organisatie, klanten en partners. In de komende blogserie ga ik in op onderwerpen die randvoorwaarden zijn om datagedreven te kunnen worden.

Een belangrijk onderwerp hierin is Master Data Management (MDM). Dit onderwerp zal ik verder toelichten en ik leg uit wat dit betekent in het kader van datagedreven werken.

In de zoektocht naar het complete beeld moeten veel gegevens gecombineerd en geïntegreerd worden. Voor het maken van een klantbeeld is het bijvoorbeeld nodig om CRM-gegevens, helpdeskgegevens, betaalgegevens en ordergegevens te combineren. Om te komen tot het geïntegreerde klantbeeld moeten de klantgegevens gekoppeld worden. Er moet als ware een sleutelkastje komen waarbij alle sleutelgegevens van een klant worden verzameld. Lang niet alle systemen hebben namelijk dezelfde identificatie voor een klant, zoals onderstaande afbeelding laat zien. De sleutel is verschillend voor alle vier de systemen, terwijl dit wel over dezelfde persoon gaat.

Figuur 1 Voorbeeld Klantidentifiactiesleutels

Figuur 1: Voorbeeld klant identificatie sleutels van Klant 1

Behalve voor het bovenstaande voorbeeld voor het sleutelkastje voor klanten is dit principe voor nog veel meer soorten data toepasbaar, denk hierbij aan campagnes, locatiegegevens, producten en machines. Juist in het kader van IoT oplossingen is het koppelen van data over meerdere bronnen heen noodzakelijk, aangezien IoT oplossingen niet het hele beeld geven. Denk hierbij aan sensoren op een productiemachine, gekoppeld aan het onderhoudssysteem met de onderhoudsactiviteiten. Beide databronnen kunnen gecombineerd worden om juist de data van die specifieke machine te kunnen gebruiken om bijvoorbeeld het kapot gaan van de machine te voorspellen.

In de komende blogserie ga ik in op de mogelijkheden die Microsoft Master Data Services (MDS) biedt om in dit MDM-patroon te voorzien. De onderstaande onderwerpen worden behandeld.

Figuur 2 Processtappen MDM Voor MDS

Figuur 2: MDM processtappen voor Master Data Services (MDS)

De eerstvolgende blog zal gaan over het configureren van het model in MDS. Ik zal daarin de vraag “hoe implementeer ik dit patroon met behulp van MDS?” beantwoorden. De onderwerpen ‘Gegevens laden’ en ‘MDS gebruiken’ worden verder uitgewerkt aan de hand van het voorbeeld in figuur 1 met de verschillende identificerende sleutels van Klant 1.

The Benefits of Data Governance

/in , /door

Data Governance can be a hard sell. What can we do about it?

I was talking to a colleague the other day who was bemoaning the fact that Data Governance can sometimes be a really hard sell and I recognized what he meant. In some ways it’s similar to electricity. Or your wifi. When it doesn’t work, it’s immensely frustrating. However, when it does work, you don’t notice it and almost take it for granted.

When our data isn’t well organised, accurate or complete, we’re equally frustrated: it slows us down, stops us from answering certain questions or prevents us from generating the necessary insights. However, when our data is available, accessible, accurate and accompanied by the right context data, we rarely stop to appreciate it.

The Kano curve, captured in an article Professor Noriaki Kano wrote back in the 1980’s [1], describes this situation and provides some background as to why it occurs.

Although there are various interpretations of Kano’s graph, the basic theory describes a link between customers’ emotions and product success. Kano argues that a product or service is about more than just functionality: it is also about users’ reactions in response to the functionality and this reaction is dependent on the type of functionality delivered. It is this reaction which determines the success of the product or service and therefore we have to be clear about the types of functionality on offer and position information about the product or service accordingly. The basic premise is that there are (at least) three different types of functionality, or attributes:

  • When a product only possesses “threshold” attributes, i.e. basic features that users expect a product or service to offer, the best we can expect is that the customer will indifferent. (The worst case is that they will be frustrated when the threshold attributes aren’t available.)
  • If the product offers some performance attributes, users will begin to find the product or service attractive and this increases as the performance increases.
  • When “excitement” attributes are present, surprise features that users didn’t expect but that they are absolutely delighted by when they discover them, that’s when users start to become really pleased with a product.

So how does this relate to selling our Data Governance efforts?

If we recognize that Data Governance primarily delivers Threshold Attributes and Performance Attributes, we can use this knowledge when selling our Data Governance efforts to sell more effectively. If we’re also clear that it is not the Data Governance itself that delivers Threshold or Performance attributes, but rather the benefits delivered by Data Governance, our selling becomes even more focused. If we then add in which benefits we miss out on when our Data Governance isn’t well organised, we have multiple options to promote our Data Governance efforts depending on the priorities and motivational bias of our different stakeholder groups.

We can split this approach into a number of concrete steps.

(1)  Get clear which of the benefits we’re delivering are performance attribute benefits and stack them up

Kano’s theory proposes that no matter how many Threshold attribute benefits we deliver, we’re not going to make our users particularly happy. Therefore, we need to be clear what Performance attributes we’re delivering and promote these.

  • If our data is easier to link, we spend less time joining data sets together to answer questions and generate insights, so we get much more done in a day.
  • When a customer’s data is spread over various systems, if our master data management software pulls together an integrated view of the customer, we’re better able to help the customer when they phone our contact centre with a question.
  • If we can easily find the definition of a term used in a new dashboard, we can more quickly understand and interpret the figures shown and pinpoint why we’re experiencing a certain problem.

If we can list enough of these performance attribute benefits delivered by our Data Governance projects, our stakeholders better understand how Data Governance helps them and therefore why they should support it.

(2)  With threshold attributes, turn the message around

If some of our benefits relate to threshold attributes, we now know that the existence of these types of attributes doesn’t make users happy, but their absence does make users frustrated. Therefore, if we’re going to mention threshold attributes in our business case or sales pitch, we need to turn the message around. Instead of emphasising expected benefits, we need to get specific about the current problems, and their impact.

So rather than selling that we want to be able to compile a complete list of sales per product group or customers per region and the benefits this would bring, we can highlight how inefficient our processes are without these improvements. Rather than selling the benefits to be gained from having effective promotion data, we can make specific the problems we face when we can’t work out which promotions generate positive results and which promotions are failures, and how this affects our potential profits. Instead of promoting that with new customer channels we can increase the numbers of on-time payments, we can explain the risks we run when customers have unidentified poor credit records with us.

If we can explain the implications of our missing Data Governance, the current pain is felt more clearly. If we know we’re dealing with threshold attributes, we have to invert the message.

(3)  Focus on audience specifics

If we want to make our Data Governance sell more effective, we can further tailor it to our particular audience. There are various obvious ways to do this based on relevance, so I won’t go into these here. However, when looking at performance and threshold attributes, we can also group benefits into “towards” and “away” [2] and focus on which best fits our audience.

Toward people are focused on their goals and what they need to do to achieve them. They are motivated by improving, growing and moving forward. This energizes them.  Away people are more focused on what should be avoided or reduced. They are keen to minimise risk, reduce waste and are triggered when solutions will solve problems. They are more motivated by fixing things and preventing problems.

Both are valid points of view necessary in a balanced organisation. If we can recognize which trait is uppermost with a particular stakeholder or group, we can tailor how we present the benefits delivered by Data Governance more specifically, including whether we’re stacking up performance attributes benefits or inverting our threshold attribute benefits.

(4)  Link benefits to the wider strategy to add weight

Once we’ve clarified the benefits of our Data Governance efforts, focused on performance and threshold attributes and then split them into towards and away buckets, we can add extra weight by linking benefits to the overall strategy.

  • If our organisational goal is cost cutting, we need insights about which particular costs are most likely to spike so we can take preventative action to avoid this.
  • If we’re in a highly competitive market and marginal gains are the key to gaining a tiny extra sliver of market share, we need razor sharp context for our data to be able to identify the effects of the smallest tweaks to our approach.
  • If our goal is helping save the world by improving our record on sustainability, we need to be able to track our chosen metrics closely to see where we’re doing well and where we need to up our game.

In all cases, if the benefits of our Data Governance efforts can be linked to larger objectives, which in turn have a connection to the overall strategy, we have a stronger sell when attempting to persuade our stakeholders that Data Governance benefits are useful.

(5)  Make it personal

A final point in terms of making our Data Governance effort an easier sell is: make it personal. Where possible, focus in on specific user groups and collect their Data Governance stories and experiences to add real resonance to the message.

One way to gather these stories is to use the Data Journey. In each specific situation there are data creators and data consumers. They’re frequently not the same people, or even in the same team or department, and this disconnect can understandably lead to a mismatch of priorities.

The priority of the data creator may be to deal with a customer, issue or transaction as efficiently as possible, so he or she can get through as many cases in a day as possible. Maybe this leads to shortcuts in data entry, misspelling an entry or entering fake data in a mandatory field when there’s no time to look up or track down the correct data. (Maybe think about getting an MDM solution?) However, when the data consumer then accesses this data later in the process, attempting to achieve their goals, he or she discovers the data is incomplete, inaccurate or context-less.

We can use the Data Journey to reduce the likelihood of this problem occurring. Specific pairs of creators and consumers are encouraged to share their work experiences with each other to develop a common understanding both of the situation which leads to the inaccurate data capture and to the consequences. Together they come up with suggestions to improve the situation and together they take responsibility for improvements. A series of follow-ups take place to evaluate the suggested improvements and where necessary amend the approach. The resulting benefits can be specifically linked to these users.

The end result is that both the Data Governance effort and the resulting benefits are more personal. Rather than being impersonal business cases, the value generated makes a concrete difference for actual users and therefore resonates in re-telling far more than general examples would do.

To sum up, yes Data Governance can be a hard sell. However, with an approach which focusses on actual value in combination with a more nuanced delivery of benefits, we have good chance of selecting the right cocktail of possible Data Governance benefits, and optimal positioning, to ensure maximum resonance with each and every stakeholder.

 

  1. Kano, N., Seraku, N., Takahashi, F. and Tsuji, S. (1984) Attractive Quality and Must-Be Quality. Journal of the Japanese Society for Quality Control, 41, 39-48.
  2. Charvet, Shelle Rose (2015, 2nd edition) Words that change minds: mastering the language of influence

 

Image by ar130405 from Pixabay

5 Tips for Agile Data Governance

/in , /door

Agile Data Governance contains the same building blocks as traditional Data Governance. The key difference is approach. The more adaptive approach of Agile makes a big difference, both with effectiveness, and with how quickly we experience the benefits.

Agile used to be applied predominantly to software development. It’s now recognised that Agile methods have significant added value in a far wider set of business applications. Below are 5 practical tips for applying Agile methods to Data Governance.

1. Focus on frequent deliveries, each time delivering added value

Just as with software projects, short incremental deliveries can be applied to Data Governance efforts and offer various benefits, one of which is faster return on investment. Data Governance initiatives frequently used to experience business case hurdles when starting out. There are various reasons for this, one of which was that it was often an expensive ask. A far-reaching programme was scoped, involving organisational restructuring, new roles, extensive process remodelling and new policies, and results were typically only expected after the project had been running for a number of months.

Smaller, leaner business cases, ideally where the project quickly becomes self-funding, are generally far easier to get approval for than extensive programmes. If we are clear what business value we expect from each incremental data governance iteration, and if each iteration then delivers the expected return, we have a far more convincing business case for continuing with subsequent iterations.  I’ve sometimes presented this as a “rolling business case” concept, where each new iteration is financed by the improvement gained in the previous iteration. This approach is particularly useful in organisations where budget availability or lack of understanding about the added value of Data Governance is blocking progress. Concrete returns are more difficult to dispute than optimistic projections.

As the value of Data Governance becomes more widely understood, it is more common for management to start with positive expectations. Providing faster returns which regularly add concrete value in the organisation helps keep both senior management and other stakeholders enthusiastic and engaged.

2. Ensure each iteration delivers usable products, so constant evaluation is possible

A key principle of Agile focuses on early and continuous delivery of value. Closely related to this is the concept of failing fast in Lean.  Eric Ries popularised the term “Minimum Viable Product” (MVP). In his book “The Lean Startup” he explains how MVP can be used to implement efficient validated learning using the Build-Measure-Learn feedback loop to quickly discover when we’re on the right track to deliver value and when we need to change direction.

If we start rolling out Minimum Viable Products early in our Data Governance efforts, we will quickly be able to gather stakeholder feedback about what works and what doesn’t. A huge benefit of this approach is that we can use the feedback we receive to tweak or, where necessary, completely overhaul the Data Governance building blocks we’ve implemented. If particular roles, responsibilities, data governance technology solutions or process changes aren’t generating the improvements we expected, we can evaluate why and change course.

A second benefit of this approach is that our users are more engaged because they experience benefits early on. Rather than having to wait for concrete returns as we set up a wide-ranging programme, our users begin to experience the measurable benefits of cleaned up data, complete data sets, more accurate definitions and sharply defined context within a couple of iterations. This is hugely motivating, especially if users have already lived through multiple failed Data Governance programmes.

3. Support, trust and motivate the people involved

Data Governance efforts usually contain a large people component, whether it’s gently nudging users to perform new activities, encouraging them to be more careful with their data quality or getting them thinking about and agreeing on definitions.

One of the underpinning principles of Agile is collaborative working as a way to empower users, stating “projects are built around motivated individuals, who should be trusted”. As with all change programs, if people understand why new work methods or extra effort is being asked of them, they are more likely to go the extra mile. Similarly, if they believe certain returns are possible, they are more likely to display the personal motivation required to make Agile working, in this case Agile Data Governance, a success.

Stakeholders should be given clear input about what is required of them and why. They should be given both the mandate and the necessary time to carry out any additional tasks required of them. They should be trusted to perform the extra activities required and the benefits of doing so should be clearly communicated. And they should be roundly praised for all improvements this leads to. Agile Data Governance often asks users to put in extra effort. They are more likely to stay enthusiastic and committed if they understand the benefits their efforts bring and if they are recognised for their extra work.

4. Focus on simplicity

One of the core aspects of Agile working is minimizing waste. Agile principle number 10 states “Simplicity – the art of maximizing the work not done – is essential”.

Data Governance programmes used to be herculean undertakings where considerable time was spent developing new organisational structures, committees, policies and processes, often before any benefits were felt by the organisation. Current wisdom focuses more on scaling back activities to the minimum required to generate returns.

Rather than investing effort changing organisational structures as a prerequisite to nominating data stewards, data custodians and data governance managers, we are now more likely to see virtual teams created. Often these are staffed with existing roles who have been given additional Data Governance responsibilities. Only if users enjoy their new responsibilities and the virtual team set-up delivers the anticipated extra value, is it worthwhile to formalise the extra responsibilities and implement any required organisational changes.

Similarly, instead of drafting lots of new processes and policy changes which ultimately may not be necessary, users can try out various process and policy suggestions. Once the best options are clear, these can be implemented. Subsequent iterations can then be used to improve, extend and formalize the implementation where necessary. At no point in Agile Data Governance is theory put before practice, or bureaucracy before concrete returns.

5. Regularly reflect on how to become more effective

Last but not least, most Agile methodologies contain a significant amount of reflection. In Scrum, there is a retrospective at the end of every sprint, where we evaluate what has worked and what can be improved upon. Lean has the learning loop, among other tools. Regularly reflecting on and evaluating how things are going, which aspects work well and were we can improve can greatly improve our effectiveness.

If we are going to get the most out of our evaluations, it is very important that we are honest with ourselves and this is easier in a safe environment. If people are afraid to voice concerns because of negative feedback or because it may have a negative impact on the overall project, the reflections will be less effective.

Equally important is that the output is evaluated and where possible, applied so that improvements are made. If reviews take place and the results are then put in a cupboard, people quickly loose interest. The regularity of the reviews is also important. If our reviews are too infrequent, important learning moments will be missed.

Finally, while lessons learned are important improvement tools, we also need to focus on the positives and celebrate our successes. By promoting our good news stories, we not only help keep key stakeholders motivated, we also inspire the rest of the organisation to get on board with Agile Data Governance.

If you would like more information about how we approach Agile Data Governance in Free Frogs, we would be delighted to hear from you. Please mail us at datagovernance@freefrogs.nl.

Good Practice: Communiceren met animatiefilmpjes

/in , /door

Net als wij barst je vast van de ideeën en heb je een visie die je wilt delen: over architectuur, producten, werkwijze, processen. Maar hoe breng je jouw boodschap op een leuke manier onder de aandacht?

Graag delen wij onze “Good Practices”

Onze ervaring is dat animatiefilmpjes reuze geschikt zijn om je boodschap over te brengen. Wij gebruiken het vaak en het werkt als een dolle. Mensen sturen de filmpjes aan elkaar door en sommige filmpjes gaan zelfs viral binnen de organisaties waar we aan de slag zijn.

Maar je wilt niet afhankelijk zijn van een communicatie-afdeling of media-bureau. De beste filmpjes maak je zelf!

Handleiding supersimpel animatiefilmpjes maken met PowerPoint

Om animatiefilmpjes te produceren heb je echt geen ingewikkelde programma’s nodig. Filmpjes maak je gewoon met een geanimeerde presentatie in Powerpoint!

  1. Bedenk een script voor je verhaal;
  2. Maak een geanimeerde presentatie;
    • vaak is een bestaande PowerPoint-presentatie al een prima begin;
    • voeg animatie-effecten aan de objecten toe;
    • maak animatiepaden om objecten te laten bewegen;
    • stel de timing voor de overgangen tussen de dia’s in;
    • NB: stel geen effect in voor de dia-overgang;
  3. Selecteer een passend muziekje;
  4. Voeg het achtergrondmuziekje via invoegen > media > audio toe in je presentatie;
  5. Zet de audio-instellingen voor muziekje (klik op icoontje en kies vervolgens menu-item afspelen), zoals
    • stel volume in op laag (of evt. gemiddeld);
    • vink verbergen bij voorstelling aan;
    • kies of je wilt herhalen tot film of geluid wordt stopgezet;
    • bepaal hoe lang je wilt infaden en uitfaden;
  6. Sla de presentatie op als MP4.

En spreken de PowerPoint-iconen die we in de filmpjes gebruiken je aan? We hebben ze zelf gemaakt en we delen ze graag met je.

Voorbeelden van onze animatiefilmpjes

(gemaakt met PowerPoint)

Animatiefilmpje van 4 minuten dat we hebben gemaakt om het portfolioproces bij een organisatie bespreekbaar te maken.

Animatiefilmpje van 2 minuten dat mijn collega Erwin Pilon heeft gemaakt om een BI-programma in een organisatie bij een groot publiek onder de aandacht te brengen.

 

 

Illustratie bij de connected architectuur

Connected architectuur: einde aan de informatiechaos

/in , /door

— Geschreven door Marnix Dalebout & Martijn ten Napel
We leven in een tijd waarin datatechnologie zich versneld ontwikkelt. Door de sterke toename van informatie en de toepassingsmogelijkheden neemt complexiteit en daarmee informatiechaos toe.

Wij merken dat veel bedrijven worstelen met hun datagebruik. Niets lijkt zeker, behalve de verandering zelf. Door de jaren heen hebben wij een architectuur ontwikkeld die ‘by design’ om kan gaan met deze ontwikkelingen. Een architectuur die handvatten biedt om niet de beste, maar de best passende oplossing te vinden.

Deze architectuur noemen wij ‘connected architectuur’. Een middel om data-inrichting gestructureerd en toekomstbestendig op te tuigen. Een werkbaar receptenboek om stap voor stap een duurzaam datalandschap in te richten. Een handleiding waarmee een organisatie zichzelf continu kan aanpassen aan de toekomst.

Graag delen wij onze visie. Dat doen wij door het uitgeven van een boek, begin volgend jaar. En dat doen wij ook met online publicaties. In dit artikel geven we op hoofdlijnen weer wat connected architectuur is.

De chaos neemt toe

Organisaties zuchten onder een niet te stillen honger naar informatie. De vraag naar informatie is groter dan waaraan voldaan kan worden. Tegelijkertijd wordt verwacht dat nieuwe informatie steeds sneller beschikbaar komt. De verwachtingen worden opgeklopt door technologieleveranciers die gouden bergen beloven en door oneindige reeksen congressen, seminars, webinars en publicaties die allemaal over de belofte van data gaan.

Tussen informatieoplossingen mist vaak samenhang en integraliteit. Voor elk deelprobleem wordt een deeloplossing bedacht. En zo groeit er een woud aan oplossingen die ongeveer dezelfde informatie leveren, maar nét niet helemaal. Het landschap wordt complexer en de beheerlast zwaarder en onoverzichtelijker.

Data-inrichting wordt zo met de dag complexer en de chaos neemt toe. Dit heeft een negatieve invloed op het effectief leveren van nieuwe informatie. Daarbij komt dat met de steeds strenger wordende regelgeving het vaak onduidelijk is of je niet ongemerkt de wet aan het overtreden bent.

Managers en architecten willen de controle terugkrijgen. Ze zijn op zoek naar oplossingen die alle ontwikkelingen rondom datagebruik kunnen bijbenen. En ze zoeken naar richtlijnen om de juiste keuze te kunnen maken uit het overweldigende aanbod aan technologieën.

Het best passende antwoord

Aan ons wordt vaak de vraag gesteld: “Vertel me, wat moet ik doen om weer orde te krijgen in onze informatiechaos?”. Verbaasd wordt er gereageerd als we zeggen dat we niet naar de beste oplossingen zoeken, maar naar de best passende. Elke organisatie is anders ingericht en vraagt om een eigen benadering.

De gemeenschappelijke deler van onze aanpak is echter altijd het reduceren van complexiteit. Want niet alleen de uitdagingen van nu, maar ook de vragen van morgen zullen zich aan gaan dienen. Change will happen, be prepared.

Ons antwoord op de toenemende complexiteit, chaos en onzekerheid vatten wij onder de noemer ‘connected architectuur’, een gereedschapskist met instrumenten waarmee organisaties onderbouwde inrichtingsbeslissingen kunnen nemen.

Wat is connected architectuur?

  • Connected architectuur is een architectuur die zich zowel richt op het gebruik als op de verwerking van informatie. Een architectuur die én de organisatie van de informatievraag én de inrichting van informatieoplossingen in het datalandschap structureert.
  • Connected architectuur is niet één oplossing waar alle data wordt verzameld, maar een architectuur waarbij data ‘verbonden’ wordt tussen verschillende databronnen. We noemen dit het datalandschap.
  • Connected architectuur biedt ontwerppatronen en implementaties om een informatie-ecosysteem te creëren van data-omgevingen die samenwerken. Informatieproducten kunnen geleverd worden zonder dat de benodigde data eerst fysiek geïntegreerd hoeft te zijn.

Maar dat is het niet alleen.

  • De architectuur moet ook geborgd worden in de organisatie. Met een andere manier van denken kunnen nieuwe informatievragen met zo min mogelijk frictie in het datalandschap worden geabsorbeerd. Hierdoor kan het datalandschap evolueren met de ontwikkeling van een organisatie.

Hoe zijn we tot connected architectuur gekomen?

Op onze zoektocht naar de best passende oplossingen komt een aantal zaken bij elkaar:

  • Het ontdekken van overeenkomsten in de uitdagingen op het gebied van informatie door het stapelen van inzichten die we hebben opgedaan in veel en verschillende projecten;
  • Een leven lang werken met de principes die achter agile werkmethoden schuilgaan;
  • Nieuwe type data en de technologische diversiteit waarmee deze verwerkt kunnen worden;
  • Het boek ‘The Business unIntelligence’ van Barry Devlin waarin de auteur een nieuwe referentiearchitectuur aanreikt waarin nieuwe type data een plek krijgen;
  • Gartner’s logical data warehouse concept en wat dat betekent voor het voorbereid zijn op toekomstige informatievragen in organisaties.

We hebben dit uitgewerkt tot een werkbaar receptenboek dat we inmiddels een aantal keer hebben toegepast. Het is een architectuur die zich in de praktijk bewezen heeft.

Wat zijn de uitgangspunten van connected architectuur?

Connected architectuur hanteert de volgende uitgangspunten:

  1. Binnen een organisatie verloopt de ontwikkeling van vragen en inzichten niet synchroon. Je moet om kunnen gaan met verschillende snelheden van verandering binnen één organisatie en met verschillende kennisniveaus in het werken met informatie. Je moet een visie hebben op wat samenhang in de informatievoorziening is en hoe je daarop gaat sturen.
  2. De enige zekerheid is constante verandering:
    • De vraag verandert: Mensen hebben moeite te verwoorden en te beseffen welke data nodig zijn en waarvoor, nu maar zeker straks. Hoe meer met informatie wordt gewerkt, hoe sneller de verandering plaatsvindt.
    • De organisatie verandert: Er komen nieuwe mensen met andere skills, belangrijke mensen gaan weg. Processen, doelen, budgetten en prioriteiten veranderen. Organisaties groeien of krimpen, worden overgenomen, verbreden of verdiepen.
    • Technologie verandert: De innovatie van vandaag is de legacy van morgen. Nieuwe technologieën, zeker op het gebied van big data en analytics, verschijnen en verdwijnen in hoog tempo. Waar investeer je in?
    • Wetgeving verandert: Er is een discrepantie tussen wat kan en wat mag. De wetgeving die bepaalt wat mag, verandert regelmatig.

Gecontroleerde verandering van het datalandschap

Maar hoe ga je met constante verandering om? Ons antwoord is altijd: actief werken aan het reduceren van complexiteit. Dat betekent dat bij alles wat je doet, voor ieder besluit dat je neemt de vraag gesteld moet worden: ‘Blijft het simpel en begrijpt iedereen wat we gaan doen?’. Door de menselijke maat niet uit het oog te verliezen wordt het makkelijker om de consequenties van iedere keuze voor alle betrokkenen transparant te maken. Dat betekent dat je mensen, processen en informatie in balans met elkaar brengt en houdt, passend bij wat haalbaar is in een organisatie.

Dat resulteert in ons leidend principe van ‘precies genoeg’. Als je in een volatiele omgeving iedere keer een klein stapje neemt, ‘precies genoeg’ om de voorliggende vraag te beantwoorden, kan je iteratief het datalandschap laten evolueren, zonder het draagvlak van alle betrokkenen te verliezen.

Een uitbreiding aan of verandering in het datalandschap is niet willekeurig. Wij bieden een methode om een routekaart te maken waarin duidelijk is wat de inhoudelijke richting is, wat de kaders zijn waarbinnen het datalandschap ontwikkeld wordt en hoe je iedere keer weer de volgende stap neemt.

Hoe ziet connected architectuur eruit?

Onderstaande afbeelding geeft connected architectuur weer.

Weergave van de connected architectuur

  • Informatievalorisatie: Het doel van informatiegebruik is het zo veel mogelijk oogsten van de waarde die in informatie opgesloten zit. Connected architectuur richt zich op informatievalorisatie.
  • De toepassing van informatie gaat niet automatisch, dat moet je organiseren.
  • Mensen weten pas welke informatie ze nodig hebben als ze deze gezien hebben. Het principe van ‘precies genoeg’ geldt ook voor de vraagkant van de architectuur in de informatiebenuttingslaag.
  • De informatievraag wordt vertaald in oplossingen die in de informatieleveringslaag beschikbaar zijn en waarvoor de infrastructuurlaag de technologische fundering geeft.

Dit kader hebben wij uitgewerkt op drie vlakken. Samen met onze opdrachtgevers wordt de voor de organisatie best passende uitwerking van het model vormgegeven.

Deze drie vlakken zijn:

  1. Een samenwerkingsmodel, gebaseerd op de principes van agile werken. Het ‘precies genoeg’-principe zit hierin besloten.
  2. Een architectuur besluitvormingsproces om te bepalen wat ‘precies genoeg’ is en om de wendbaarheid van het datalandschap te borgen.
  3. Een datalandschap inrichtingsontwerp om het landschap duurzaam in te richten zonder dat het tot chaos leidt.

Om samenhang te houden en inhoudelijk richting te geven aan de ontwikkeling van het landschap, moet de invulling van de drie vlakken bestuurd worden vanuit een organisatieonderdeel dat hiertoe opdracht heeft. In de markt is dit bekend onder het BI competence center (BICC). We hebben een mening over hoe het BICC vormgegeven moet worden wil het effectief opereren, maar dat is een onderwerp dat buiten de scope van dit artikel ligt. We gebruiken het label BICC, maar raak niet gefixeerd op de naam.

Het samenwerkingsmodel

Over het samenwerkingsmodel is apart een boek te schrijven, maar we volstaan om te verwijzen naar de serie ‘agile onder architectuur’ voor de zienswijze die aan onze connected architectuur ten grondslag ligt.

Het architectuur besluitvormingsproces

De meeste organisaties waar wij binnenkomen, worstelen met de vraag ‘waar moet ik beginnen?’. Het architectuur besluitvormingsproces helpt om een begin te maken door de informatievragen te bundelen naar generiekere use cases en te bepalen welke use cases op korte termijn prioriteit moeten krijgen.

Het gevaar bestaat dat je specifieke puntoplossingen maakt. Om dat te voorkomen, is het architectuur besluitvormingsproces ingericht in twee processen. Deze zorgen voor een kader om te kunnen bepalen wat de juiste beslissingen zijn, zonder de doorontwikkeling van het gehele datalandschap uit het oog te verliezen.

  1. Het domeinarchitectuur proces. Een proces waarmee de routekaart bepaald wordt. Dit proces geeft antwoord op de vraag welke solution architecturen wanneer geïmplementeerd moeten worden om invulling te geven aan de belangrijkste use cases binnen een organisatie.
  2. Het solution architectuur proces. Een proces waardoor de best passende (‘precies genoeg’) inrichtingsbeslissingen kunnen worden genomen, gebaseerd op de verantwoordingsbegrenzingen zoals opgelegd door de domeinarchitectuur.

Het datalandschap inrichtingsontwerp

Datalandschappen, kan je op vele manieren inrichten. Om het landschap duurzaam te ontwikkelen en de samenhang te behouden, is er een referentiearchitectuur nodig die als blauwdruk voor het inrichtingsontwerp dient.

Wij hebben een blauwdruk gemaakt gebaseerd op de REAL architectuur van Barry Devlin, waarin we elementen uit het logisch data warehouse concept van Gartner hebben verwerkt om de connectiviteit vorm te geven.

Hoe de blauwdruk wordt vertaald naar een implementatieplan en solution architecturen is een onderwerp op zich. In ons boek gaan we daar uitgebreid op in, maar op deze plek willen we de blauwdruk kort presenteren.

weergave van de datalandschap architectuur

Bovenin zijn de vijf gebruikspatronen van informatie benoemd die in het landschap een plek krijgen. Voor meer uitleg over de gebruikspatronen verwijzen we naar het artikel ‘Het doel van de informatievraag: informatievalorisatie’.

De drie pilaren vertegenwoordigen de categorieën van informatie die elk om een andere verwerking vragen, maar die gebruikers tegelijkertijd in samenhang willen gebruiken.

Deze samenhang ontstaat niet vanzelf; er zijn voorwaarden nodig die samenhang tussen de verschillende oplossingen borgen. Dat zijn voorwaarden op het gebied van context van informatie, consistentie van informatie en toegangsbeheer tot die informatie in het datalandschap.

De drie elementen die hiervoor ingericht worden, zijn:

  1. Masterdata voor integratie, dat het patroon vormt hoe je informatie in verschillende oplossingen aan elkaar verbindt. Verbinden betekent dat je de informatie integraal over oplossingen heen kan bevragen zonder dat je de data eerst samen moet brengen in één oplossing. Dit is ook wel bekend als ‘loosely coupled information’.
  2. Masterdata voor autorisatie, dat het patroon vormt waarmee toegang tot gegevens vanuit één punt onderhouden kan worden over de verschillende oplossingen heen. Hiermee kan geoorloofd gebruik gecontroleerd worden.
  3. Het datamodel in de verschillende oplossingen dat aansluit op de masterdata patronen voor integratie en autorisatie.

De informatie verstrekkingslaag maakt gebruik van de verschillende elementen om informatie in een door gebruikers gewenst formaat of gewenste vorm beschikbaar te stellen.

Hoe de blauwdruk wordt ingevuld in de implementatie bepaalt de wendbaarheid van het datalandschap. De architectuur besluitvormingsprocessen zijn ingericht om dit te bewaken; het agile samenwerkingsmodel om de noodzakelijke ontwikkelingssnelheid van het datalandschap en wendbaarheid van geleverde informatie mogelijk te maken.

Ik wil graag meer weten over connected architectuur, waar kan ik de informatie vinden?

We zijn bewust dat we misschien meer vragen oproepen met de introductie van onze connected architectuur. Een uitgebreide beschrijving komt beschikbaar in een boek dat we volgend jaar uitgeven. Maar je kan natuurlijk altijd contact met ons opnemen als je meer wilt weten.

Illustratie bij de serie de complexiteit van informatieprojecten

De complexiteit van informatieprojecten

/in , /door

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

/in , /door

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

/in , /door

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.