Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Na data-ops inrichten, komt meer doen met data

Dit artikel delen:

Data science is hot. Elk bedrijf wil vandaag de dag nieuwe inzichten opdoen uit data om daarmee de concurrentiepositie te verbeteren. Daartoe investeren velen in een data lake, waarin alle typen data bij elkaar worden gebracht op een platform, in de hoop ze daarna in samenhang te analyseren. In de praktijk blijkt het nog een uitdaging om relevante data uit een keten van systemen te halen omdat de basis – de infrastructuur en data-ontsluiting – niet op orde is. Je zult eerst een betrouwbare datastroom moeten realiseren voordat je iets met de data kunt doen.

Eén van de uitdagingen ligt op het gebied van data literacy: wat betekent al die data nu eigenlijk precies? Betekent het woord klant in mijn erp-systeem hetzelfde als het woord klant in mijn crm- of marketing automation-software?

Daarnaast spelen vragen als: weet ik in welke context data zijn verzameld? Hoe betrouwbaar zijn de kwaliteit van de data? En misschien wel de belangrijkste vraag: welke data heb ik eigenlijk nodig om antwoord te krijgen op mijn vragen? Want meer data meenemen in je analyse betekent niet altijd dat het antwoord daar beter van wordt. Het kan ook dat je door de bomen het bos niet meer ziet. Je hebt daarom domeinkennis nodig om een goede interpretatie te maken van de data.

Is data herleidbaar?

"In het kader van de AVG ben je verplicht om te weten welke data je waar gebruikt"

Een andere uitdaging is data lineage: is het resultaat van een analyse te herleiden tot de bronnen? Het gebeurt namelijk regelmatig dat de verkregen inzichten onverwacht of tegenstrijdig zijn. Dan is het belangrijk dat je kunt aantonen waar de onderliggende gegevens vandaan komen en welke filtering en bewerkingsslagen zijn toegepast. Daarnaast ben je, als je aan de slag gaat met data van klanten of werknemers, in het kader van de AVG verplicht om te weten welke data je waar gebruikt. Je moet die data immers kunnen verwijderen als de klant daarom vraagt. En je moet zeker weten dat de klant toestemming heeft gegeven voor het gebruik van zijn data voor de desbetreffende toepassing.

Data-extractie is ingewikkeld

Wie denkt: gooi alle data maar in een bak en laat een slim algoritme op zoek gaan naar patronen en afwijkingen daarin, komt van een koude kermis thuis. Data-extractie is veel ingewikkelder dan verwacht. Ook bevatten de opgeslagen data vaak toch niet wat ‘men dacht’. Of er is geen vertrouwen in de opgedane inzichten. Het gevolg is dat je elke stap die half gedaan is, opnieuw moet zetten. Een grondige voorbereiding is dus het halve werk.

Begin met dataclassificatie

"Een gipskamer kan betere planningen maken als ze de weersvoorspelling integreren in hun datapijplijn"

Het advies is daarom om altijd te beginnen met het classificeren van je dataresources: welke databronnen zijn er beschikbaar binnen en buiten mijn organisatie? Wat kunnen ze potentieel opleveren? Kan ik ze prioriteren aan de hand van de Moscow-matrix (Must, Should, Could, Would-have)? Bronnen kunnen afhankelijk van de toepassing een andere prioriteit hebben. Neem een ziekenhuis. Een gipskamer kan betere planningen maken als ze de weersvoorspelling integreren in hun datapijplijn: bij sneeuw, natuurijs of ijzel stijgt het aantal botbreuken explosief.

Inventariseer de bruikbaarheid

Heb je een lijst met potentiële bronnen en een classificatie daarvan, ga dan per bron na hoeveel tijd het kost om de data bruikbaar te maken voor je doel. Als je eerst een groot datakwaliteitstraject moet starten omdat de data onvolledig zijn of te veel fouten bevatten, dan wegen de investeringen wellicht niet op tegen de opbrengsten.

Betekent deze werkwijze dat je teruggaat naar het oude extraction, transformation and load (etl)- en datawarehouse-principe, met ingewikkelde integratietrajecten en lange doorlooptijden? Dat hoeft niet, want er is een gulden middenweg: je ontsluit geselecteerde en goed beschreven datasets (die heel groot en ongestructureerd mogen zijn), verzamelt ze in een data lake en gebruikt ze naar behoefte als bouwblokken voor latere analyse en integratie. Op deze manier creëer je een betrouwbare datastroom die maximale waarde en flexibiliteit biedt.

Betrek domeinkennis bij je data science project

"En dan ineens ontdek je dat veel patiënten op zaterdagochtend ineens even achteruitgaan om later alsnog te stabiliseren"

Ben je er als je dit goed hebt opgezet en je data scientists allerlei voorspellingen uit de data wringen? Het kan dan nog altijd gebeuren dat je een slechte voorspelling doet. Terug naar het ziekenhuis. In de verzamelde data zitten ontzettend veel informatie die nuttig kan zijn om te voorspellen hoe het de komende tijd met de patiënt zal gaan: patiëntkenmerken uit het elektronische patiëntendossier , diagnostische informatie uit een keur van systemen, behandelinformatie en realtime-monitoringdata van hartslag, bloeddruk, zuurstofsaturatie en ga zo maar door. En dan ineens ontdek je dat veel patiënten op zaterdagochtend ineens even achteruitgaan om later alsnog te stabiliseren. Een team van medisch specialisten en data scientists kan zich hier dagenlang het hoofd over breken, maar vragen ze het aan het verpleegkundig team, dan krijgen ze te horen dat dat komt doordat 'we op zaterdag de patiënten net wat later wekken en dus ook net wat later hun medicatie geven'.

Met andere woorden: vergeet niet om collega's met domeinkennis in een vroeg stadium bij je analyses te betrekken. Want een goed ingerichte datastroom voorkomt weliswaar veel gezoek achteraf of de data echt wel klopten. Uiteindelijk kunnen alleen de domeinexperts de relatie leggen naar de praktijk van alledag.

Richt je data-ops goed in

Kortom, waarde destilleren uit een keur van data uit vele verschillende bronnen mag dan voor veel businessmensen op het eerste oog redelijk eenvoudig lijken, dat is het allerminst. Het is evenmin een eenmalig project dat je laat installeren en dan aan de it-beheerders overdraagt.

Je hebt de business nodig om relevante vragen aan te dragen. Enthousiaste techneuten zijn nodig om een betrouwbare infrastructuur en datastromen te realiseren, zodat je grote hoeveelheden data in je pijplijn kunt verwerken. Je hebt domeinexperts nodig, net als mensen uit het veld om je ideeën te toetsen aan de realiteit. En schuif ook specialisten aan die met analyses en technologie zoals machine learning of ai waardevolle inzichten creëren. En last but not least: je hebt personen nodig die er op toezien dat de hele operatie rondom data goed blijft lopen en de governance is geregeld. Dit alles is samen te vatten onder de noemer data-ops. Anders: de orkestratie van mensen, processen en technologie die nodig is om betrouwbare data en inzichten op te leveren die het antwoord geven op prangende businessvraagstukken.

Auteurs: Isha Lamboo, data engineer, Jos Smits, cto, en Dennis in ’t Groen, data scientist, allen bij Conclusion Virtual Sciences

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

Eens dat je eerst een betrouwbare, herleidbare en rechtmatig datastroom moet realiseren voordat je iets met de data kunt doen want de data governance wordt namelijk nog weleens vergeten. Dus hoe slechter je data governance hoe groter de kans dat je data lake een paddenpoel wordt en hoe hoger de kans dat er kafkaëske situaties ontstaan met bewijs uit het ongerijmde. En een mooi voorbeeld ook dat beeldscherm-dokters vaak de simpelste redenen van een bepaalde anomalie in de data niet zien, relevant ook gezien we in het kader van de pandemie tegenwoordig een junta van beeldscherm-dokters hebben.

Ook eens dat je domein-experts nodig hebt voor het ontwerpen van de juiste infrastructuur, met name als het om de pijplijn gaat. De gebruikelijke pijpfitters van de cloud vergeten nog weleens het belang van een goede data fabric want het convergeren van SAN en LAN in één netwerk is alsof je het verkeer van de Coentunnel van beiden kanten door één tunnelbuis laat gaan. Ik vraag me af of data architecten van de cloud nog weten dat schrijven een duurdere I/O operatie is dan lezen, zeker als je garanties wilt over de data integriteit. Ik zeg dan ook vaak dat schijven niks kosten maar alle (RAID/EC) penalties voor de data governance wel. Want Murphy struikelt nog vaak over het 'penny wise and pound foolish' van de juiste infrastructuur. Want het moet uiteindelijk alles kunnen maar het mag niks kosten......

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2021-01-22T10:57:00.000Z Isha Lamboo en anderen
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.