De dataproblemen die niemand in vergaderingen toegeeft, en hoe je ze oplost

Made with AI

Sommige problemen zijn in een vergadering makkelijk te benoemen. Gaten in het budget, gemiste deadlines, een leverancier die niet levert. De structurele dataproblemen die organisaties vertragen, halen zelden de agenda. Ze zijn te diffuus om aan te wijzen, te vertrouwd om nog te melden, en vaak te ongemakkelijk om aan te kaarten bij de mensen die de oorspronkelijke beslissingen hebben goedgekeurd.

Dat maakt ze niet makkelijker op te lossen. Kwetsbare pipelines, ongedocumenteerde databronnen, inconsistente definities, platformcomplexiteit die niemand helemaal overziet: die problemen stapelen zich ongemerkt op. Tegen de tijd dat ze boven water komen, hebben ze de kostenstructuur van alles wat erop volgt al veranderd.

Dit artikel benoemt er vijf. Niet om de teams te bekritiseren die ze hebben geërfd, maar om het gesprek makkelijker te maken waarmee het oplossen begint.

De pipeline waar niemand aankomt

Elk datateam heeft er een. Een pipeline die output levert die goed genoeg is en waar al twee jaar niemand aan heeft gezeten. Niemand wil hem openen. Niemand weet precies wat hij doet. Degene die hem bouwde, is vertrokken.

Het risico is niet dat hij breekt. Het risico is dat als er eerder in de keten iets verandert, een schema-update, een nieuwe versie van de API van een bron, een nieuw veld waar de business op gaat leunen, de breuk onzichtbaar blijft tot het ertoe doet. Dan is de output al weken fout.

De oplossing is geen herbouw, maar documentatie. Zelfs een ruwe beschrijving van invoer, uitvoer, verwacht gedrag en bekende eigenaardigheden verkleint het risico flink. Begin daar.

Twee teams, twee cijfers

Finance zegt dat de omzet zes procent hoger is. Marketing zegt negen. Vanuit hun eigen positie hebben ze allebei gelijk. Het verschil zit in hoe ze omgaan met retouren, timing, attributie of valutaomrekening. Niemand heeft een definitie afgesproken en niemand heeft die opgeschreven.

Dit is een van de meest voorkomende dataproblemen in middelgrote en grote organisaties, en een van de moeilijkst op te lossen, omdat één definitie afspreken een gesprek tussen teams vraagt dat niemand voorrang heeft gegeven.

De kosten zie je in elke directievergadering waarin een cijfer een voetnoot nodig heeft, in elk rapport dat drie dagen uitleg kost, en elke keer dat het datateam een antwoord van een kanttekening moet voorzien.

De datacatalogus die alleen in iemands hoofd bestaat

Elk dataplatform heeft in de praktijk een datacatalogus. Die staat in Slack, in e-mailwisselingen, in het geheugen van wie er het langst werkt. Vraag waar een metric is gedefinieerd en iemand verwijst je naar een Confluence-pagina die in 2022 voor het laatst is bijgewerkt en naar een Slack-bericht van iemand die er niet meer werkt.

Een goede catalogus vraagt geen aparte tool. Hij vraagt een beslissing over waar definities staan en wie er eigenaar van is, en de toezegging om ze actueel te houden. Op dat laatste stranden de meeste pogingen.

Het platform dat het probleem van vorig jaar oploste

Dataplatforms worden op een bepaald moment ontworpen. De organisatie die drie jaar geleden opdracht gaf voor het ontwerp, was anders: kleiner, met minder teams, een eenvoudiger product, een ander datamodel. Het platform weerspiegelde dat.

De organisatie is veranderd, maar het platform niet. Er zijn functies aangeschroefd om het gat te dichten. Nu is de architectuur een verslag van elk compromis dat onder tijdsdruk is gesloten.

De vraag die het stellen waard is, is niet "hoe lossen we dit op?" Het is "wat zouden we ontwerpen als we vandaag begonnen?" Het verschil tussen dat antwoord en de huidige situatie is je achterstand aan technische schuld.

Vastgeketend aan de leverancier

Veel dataproblemen zitten in tools waar je geen volledige controle over hebt. Is de pipeline van de leverancier, dan kun je alleen oplossen wat de leverancier toestaat. Legt het SaaS-product het schema vast, dan is het datamodel van hen, niet van jou.

Dat wordt steeds relevanter nu organisaties de beslissingen over SaaS-verlengingen van drie tot vijf jaar geleden ter discussie stellen. De pipelinearchitectuur die logisch was toen de tool de beste optie op de markt was, is dat vandaag misschien niet meer. Dat gesprek kun je beter voeren voor de volgende verlenging dan erna.

Deze problemen benoemen is de eerste stap. De tweede is beslissen welk probleem je als eerste aanpakt: niet het dringendste, maar het probleem waarvan de oplossing de meeste ruimte geeft. Wil je er samen over nadenken, praat dan met ons datateam.